| |
| Autore |
Messaggio |
opzioni |
  rcc.roberto
[pagine pubblicate]
postato il:
10.07.2019, alle ore 09:26 |
 caccamo2: perche' per calcolare l'rms devi elevare i campioni al quadrato...
Ahh!! Grazie |
|
 MB54
postato il:
10.07.2019, alle ore 09:31 |
rcc.roberto: Se il problema sta nel tempo impiegato in quel momento che fa i conti, puoi invece fare i conteggi singoli dopo ogni lettura, distribuendo così il tempo impiegato.
Rallenterei esageratamente. Il calcolo di Vrms è saltuario, ed avviene ogni tot.
Il mestiere principale della MCU è il riconoscimento tonale sul segnale in ingresso applicando l' algoritmo di Goertzel, che prevede di acquisire un numero N di campioni (tramite ADC) e poi elaborarli. Da provare e valutare in alternativa ad un LM567.
La velocità complessiva dell' analisi è ovviamente la somma dei tempi di acquisizione e di calcolo. La selettività del riconoscimento è data dal rapporto fra sampling rate (SR) e numero di campioni acquisiti per ogni blocco di letture (N).
Per ottimizzare i tempi di risposta ho visto che è preferibile usare SR bassa (es 4200): con bassi valori di N si otterrà una ragionevole selettività , con tempi minori di calcolo essendo N bassa. Per ridurre il tempo totale intendo usare bassa Fosc per avere basso SR ed alto Fosc per i calcoli.
Quì un esempio di curve di risposta al variare di N
PROBLEMI:
1) non grave: purtroppo il valore del modulo di Goertzel varia con N, dove N (a differenza della FFT) può essere un qualunque intero, ma non tutti sono preferibili. E' risolvibile facilmente. Un esempio
La relazione fra modulo e Nbuoni è lineare ed i termini sono noti.
2) grave: il modulo dipende dal livello del segnale in ingresso, che è variabile. Da quì l' idea di misurare i Vrms in ingresso, ogni tanto: ad esempio uso il modulo di un tono ogni 6 per fare la media mobile di Vrms, definisco il rapporto modulo/Vrms e con il DAC della MCU comando un AGC o ALC audio.
La speranza è/era di non rallentare troppo le sequenze con questa misura. L' alternativa è un compressore audio 1:10 tipo SSM2167 e non ci penso più.
Direi che essendo riuscito finalmente ad usare Fosc 64M e facendo i relativi calcoli a 8 bit, la saltuaria misura di Vrms avviene in tempi compatibili con tutto il resto.
Ringrazio tutti per i contributi; se avete altre idee sono bene accette.
|
|
MB54
postato il:
10.07.2019, alle ore 09:54 |
marsram: Come tutti i PIC del genere, puoi usare come clock di conversione FRC, cioè l'oscillatore interno. E' indipendente dal clock è ha un tempo medio di 1.7us contro 1.0us per FOSC/64 @ 64NHz.
FRC si ottiene con ADCs<2:0>=011
Per avere un sampling rate MASSIMO di circa 4000 devo rallentare di molto il clock, ad esempio per Fosc 8M usare per il Tad Fosc/64(125 kHz, Tad=8 µS). Non solo: devo anche usare un lungo tempo di precarica del condensatore dell' ADC (20 Tad), avendo alla fine un tempo complessivo dell' ADC di 20+13=33 Tad ovvero 264µS. O usare Fosc 4M
Potendo adesso usare i 64MHz per i calcoli, dovrò riottimizzare le condizioni per avere i tempi minimi di acquisizione ed elaborazione.
|
|
gironico
postato il:
10.07.2019, alle ore 10:54 |
hai fatto un tentativo di lettura adc con un esp-12 ?
La vita è troppo breve per bere vini mediocri |
|
MB54
postato il:
10.07.2019, alle ore 11:05 |
gironico: hai fatto un tentativo di lettura adc con un esp-12 ?
No. Perchè? |
|
caccamo2
postato il:
10.07.2019, alle ore 13:40 |
MB54: La velocità complessiva dell' analisi è ovviamente la somma dei tempi di acquisizione e di calcolo. La selettività del riconoscimento è data dal rapporto fra sampling rate (SR) e numero di campioni acquisiti per ogni blocco di letture (N).
Per ottimizzare i tempi di risposta ho visto che è preferibile usare SR bassa (es 4200): con bassi valori di N si otterrà una ragionevole selettività , con tempi minori di calcolo essendo N bassa. Per ridurre il tempo totale intendo usare bassa Fosc per avere basso SR ed alto Fosc per i calcoli
attenzione che il clock dell'ADC non determina il sample rate ma solo il tempo di acquisizione, puoi lanciare l'acquisizione via software con la frequenza che desideri pur lasciano il clock dell'ADC al massimo.
... |
|
MB54
postato il:
10.07.2019, alle ore 16:58 |
caccamo2: [quote](MB54):puoi lanciare l'acquisizione via software con la frequenza che desideri pur lasciano il clock dell'ADC al massimo.
Se ti riferisci a quanto avevi indicato in un altro 3d, ovvero la possibilità di intervallare con un tempo morto le acquisizioni tramite delay o input via sw o interrupt, variando così il sampling rate.... ho provato, ma i risultati non sono stati positivi. Avevo anche cercato di infilare un loop di calcolo nel tempo di attesa. E' possibile (molto probabile) che abbia sbagliato io qualche cosa nel codice (erano le prime prove), oppure questo algoritmo ha esigenze differenti. Sostanzialmente la larghezza di banda appariva molto superiore a quella che sarebbe dovuto essere definita sampling rate e numero di acquisizioni per ogni blocco acquisito.
Avendoci preso gusto, riproverò sicuramente. Funzionasse potrei appunto usare i tempi morti per fare i calcoli. Batti e ribatti si piega anche il ferro (cit. R.Fratello).
|
|
picmicro675
postato il:
10.07.2019, alle ore 21:53 |
MB54:
for k = 0 to 24 ' rileggo testData e calcolo Vrms e Vdc
TmpVar = testData[k]
RMSQ = TmpVar * TmpVar + RMSQ ' longword 3,4 mS NN24
DC = TmpVar + DC ' circa 200 µS
next k
Togli i calcoli ai valori indicizzati.Addirittura riduci il calcolo a passaggi semplificati. Son convinto che tagli il numero di istruzioni alla grande
Po penso che con il Proton Basic, si riesca ad ottenere una ottimizzazione migliore.
Se pubblichi la routine, magari si prova a tradurla e fare delle prove con diversi compilatori. Alla fine potrebbe anche bastarti di inserire il pezzo tradotto in assembly. Sebbene piuttosto ostico con i prodotti mikroE.
Anno nuovo, forum nuovo.
Mi sa che lascio. |
|
caccamo2
postato il:
10.07.2019, alle ore 22:13 |
MB54: caccamo2: [quote](MB54):puoi lanciare l'acquisizione via software con la frequenza che desideri pur lasciano il clock dell'ADC al massimo.
Se ti riferisci a quanto avevi indicato in un altro 3d, ovvero la possibilità di intervallare con un tempo morto le acquisizioni tramite delay o input via sw o interrupt, variando così il sampling rate.... ho provato, ma i risultati non sono stati positivi. Avevo anche cercato di infilare un loop di calcolo nel tempo di attesa. E' possibile (molto probabile) che abbia sbagliato io qualche cosa nel codice (erano le prime prove), oppure questo algoritmo ha esigenze differenti. Sostanzialmente la larghezza di banda appariva molto superiore a quella che sarebbe dovuto essere definita sampling rate e numero di acquisizioni per ogni blocco acquisito.
Avendoci preso gusto, riproverò sicuramente. Funzionasse potrei appunto usare i tempi morti per fare i calcoli. Batti e ribatti si piega anche il ferro (cit. R.Fratello).
la larghezza di banda la definisce il filtro anti alias davanti all'adc, che e' obbligatorio, non il sample rate, il sample rate deve essere almeno 2 volte la larghezza di banda, in genere si fa 10 o 100 volte.
Io temo che l'impedenza d'ingresso dell'adc sia troppo bassa e tu non stia acquisendo correttamente.
Rallentare l'acquisizione non e' un buon modo di rimediare, devi metterlo almeno un filtro davanti all'adc.
... |
|
MB54
postato il:
11.07.2019, alle ore 07:52 |
picmicro675:
Togli i calcoli ai valori indicizzati.
Hai ragione; la riduzione dei tempi è minima, ma tutto fa.
picmicro675:
Addirittura riduci il calcolo a passaggi semplificati.
Non ho capito cosa intendi. Cosa dovrei fare?
picmicro675:
il Proton Basic,
ho solo il mikroBasic.
picmicro675:
assembly.
è una delle 1000 cose che mi sono ripromesso di studiare, forse quando sarò in pensione.
Diciamo che al momento sono soddisfatto; ho ridotto i tempi di 4 volte (8 bit anzichè 16 e Fosc a 64M): per un operazione da fare ogni tot eventi direi che mi può andare.
|
|
| |
