bufferizzazione ADC

[eins]

Ti suggerisco di provare a rispondere alle domande che ti ho fatto nell'ultimo post

Scusami SandroCalligaro, credevo di aver risposto, almeno implicitamente, ma provvedo subito:
- sì, mi servono tutti i 12 bit, conosco il sovracampionamento ma non è qui il caso;
- ho considerato un eventuale ADC interno ma preferirei, anche per modularità, un ADC esterno; al momento preferirei un ADS1015 che abbiamo già in laboratorio, ma se proprio necessario potrei valutare un ADC con intefaccia SPI o parallela, però al momento vorrei cercare di capire se riesco a trovare una strada con quel che ho già disponibile, per molti motivi e ora anche per curiosità personale;
- preferirei non lasciare l'ambiete Arduino, ma ho anche disponibili dei Teensy 2.0 e 3.5, quest'ultimo ha già la SD integrata;

Se la registrazione non dev'essere di qualità valuta la possibilità di comprimere il segnale audio limitando di molto la quantità di dati da memorizzare. Io affronterei una cosa del genere con un micro dotato di ADC una volta programmato te lo dimentichi. Riusciresti a gestire in automatico l'acquisizione dei canali e il trasferimento dei dati in DMA, come ti hanno già suggerito eliminando il trasferimento ADC micro. Tu dovresti occuparti solo della codifica dei dati ricevuti e del trasferimento su SD. Avresti hw e fw molto molto più semplici e paradossalmente molto più veloci. Capisco l'idea di usare arduino ma ho paura che risulti il collo di bottiglia di tutto il progetto. Ci sono altre discussioni nel forum su STM32. Con poche decine di euro avresti un sistema di sviluppo completo. Partire da zero sarà faticoso ma personalmente credo ne valga la pena

Grazie luxinterior, hai ragione, spesso ripartire da zero vale la pena, sono quasi quarat'anni che lo faccio in campo elettronico e concordo con te che spesso è premiante, ma non è questo il caso; conosco anche l'ambiente STM32 ma se possibile vorrei restare su quanto ho già; non scordarti il mio punto di partenza: ho già un ADS1015 (non provvisto di buffer) e vorrei cercare di capire se riesco a fargli un buffer in uscita, eventualmente impiegando uno o più uC; tutto il resto lo posso adattare come voglio, ma questo è il punto di partenza e vorrei capire se la cosa è fattibile. In quanto ai due canali da acquisire non sono segnali audio, sono due segnali provenienti da sensori e sono già condizionati in una dinamica da 0 a 5 V e in una banda da 0 a circa 300/400 Hz, per cui possono essere direttamente campionati a 1.000 o 1.150 Hz; comunque non posso fare altro su questi due segnali, solo campionarli a 12bit e almeno 1.000 Sps

I colleghi ti stanno dando ottimi consigli che ti suggerisco di prendere bene in esame. Io aggiungo che usare due micro al posto di uno, quasi sempre non risolve i problemi, ma li aumenta. E non è che li raddoppi, li aumenta di 10^2...

Grazie venexian, ho ben chiaro che sicronizzare due uC indipendenti non è uno scherzo, ma in questo caso, almeno nell'ultima ipotesi che avevo fatto prima, dovrebbero agire independentemente sotto il solo controllo di un clock" esterno a 1 Hz (un ciclo al secondo e poi si scambiano i ruoli); non dovremmo ricadere nel caso di complessità esponenziali

Grazie a tutti per le ampie panoramiche che stanno venendo fuori, per me molto istruttive e stimolanti, vorrei però chiedere se possibile di focalizzare sul problema così come lo avevo posto all'inizio: dotare una sorgente di dati digitali, indipendentemente da cosa rappresenta la sorgente (in questo caso 2x1150x12 bit/secondo, il nostro ADS1015) di un buffer in grado di memorizzare almeno fino ad un secondo, per poi essere svuotato e ricominciare da capo. Questo è l'aspetto che se possibile vorrei capire meglio con il vostro prezioso aiuto. A tutti ancora grazie.

[luxinterior]

Scusami, ovviamente non ti conosco, pensavo fossi alle prime armi con l'elettronica. (Arduino lo associo ai neofiti)
L'idea dell'ADC esterno, c'è poco da fare, è un vincolo troppo pesante che ti obbliga a trovare soluzioni contorte e complicate. Forse potresti semplifcare se puoi configurare l'ADC come master che invia i campioni di continuo, Dall'altro lato tu devi solo preoccuparti di essere pronto a ricevere (interrupt). Non sarebbe troppo difficile, ma sicuramente non affidabile al 100%.
Teensy non la conosco, scusami se insisto su STM32, c'è la libreria FATFS (ma il porting esiste per tanti altri devices) con cui gestisci la SD con formattazione FAT32 (dovesse servire puoi leggerla direttamente sul PC) Hai tutto pronto per leggere/scrivere files con chiamate simili al PC: fopen fread fwrite ecc... Nella miriade di librerie della ST trovi anche il driver per la SD o al limite lo prendi ad esempio per scrivere qualcosa di tuo. Come detto l'ADC è integrato gli dici da quale canale partire a quale canale fermarsi e dove mettere i dati e lui fa tutto da solo.

Non conosco l'applicazione bisognerebbe esaminare i dati. Spesso usando i dati grezzi ti serve velocità e tanta memoria invece potresti cercare di comprimere memorizzando ad esempio un valore e poi il numero di volte che si ripete o rimane all'interno di un range prestabilito. Oppure mettendo via le differenze rispetto ad un valore memorizzato come riferimento.

Poi bisognerebbe capire gli aspetti commerciali se stai facendo un piacere a qualcuno e devi fare la fatica per realizzare 1pezzo che pagheranno con una cena allora arduino ci può stare tutto.

[eins]

Scusami, ovviamente non ti conosco, pensavo fossi alle prime armi con l'elettronica. (Arduino lo associo ai neofiti)

Non devi assolutamente scusarti tu, semmai io che non ho precisato prima, ma lo ritenevo non essenziale. Circa 25/30 anni fa programmavo in assembler gli 8088/8086 e 8051, poi lo ST6. ma da quel momento c'è stato per me un gap di 20 anni senza elettronica digitale, solo analogica e adesso sono quasi un perfetto novizio sul campo. E poi non mi dispiace proprio fare la figura del ragazzino

Comunque questa applicazione mi serve per degli esperimenti di laboratorio con ricadute didattiche e sono fortemente vincolato a quanto detto in precedenza. Vorrei creare un buffer "general purpose", che poi userò nell'applicazione descritta, ma l'aspetto che mi interessa di più (anche perché è il solo voluto da me e sotto la mia diretta responsabilità) è quello della bufferizzazione della sorgente (ADC). Altrimenti prendono ragione quelli che vlevano altre strade eheheh

Quindi sto cercando di capire come bufferizzare questa benedetta sorgente per poi rileggerla con qualsivoglia metodo, mi interessa meno chi rilegge il buffer. Aggiungo caldamente, se non lo conoscete, di dare un'occhiata al Teensy, che è veramente favoloso: ADC 12 bit e SDcard integrati, CPU 32bit 70/120Mhx di clock, breadboard friendly (che per le applicazioni didattiche è il massimo), molta ram on board e soprattutto prezzo inferiore all'Arduino, anche se resta quasi completamente compatibile, il che in laboratorio non guasta.

Poi aggiungo che a cose fatte molto molto volentieri potrò pubblicare qui tutto il progetto completo, visto il suo scopo non commerciale. Comunque veramente grazie a tutti.

[dimaios]

Per semplificarti la vita ti consiglio di utilizzare direttamente la Teensy 3.5.
Montando un MK64FX512VMD12 della NXP rende disponibili ADC a 16 bit come puoi leggere nel datasheet del K64 alla sezione 3.6.1.
Inoltre monta il quarzo esterno per cui il campionamento è preciso ed il jitter minimizzato.
Puoi utilizzare il DMA per non avere problemi di perdita di campioni anche se a quelle frequenze di campionamento ce la fai sicuramente.
Il vantaggio è che puoi salire di risoluzione e frequenza di campionamento ben oltre quello che richiedi e poi pulire i segnali con operazioni DSP ( anche offline ).
Per quanto riguarda il salvataggio al volo dei dati non utilizzerei un file di testo ma scriverei un binario utilizzando il filesystem che la NXP fornisce come middleware con l'SDK dell'MCUXpresso.

La ST in questo senso è comunque molto più "carrozzata" ed implementi più velocemente il software grazie all'Atollic TrueStudio for STM32 congiuntamente all' STM32CubeMX per configurare il dispositivo.
Con una board NUCLEO è veramente molto semplice.
L'SDK è molto migliore di quella della NXP.

[venexian]

Leggere i datasheet e sempre utile prima di iniziare un progetto...

Tu scrivi

Preferirei usare un ADC esterno ... perché avrei bisogno di un campionamento con temporizzazione accurata e la temporizzazione di un uC dipende totalmente dalla stabilità del risuonatore o quarzo, mentre immagino che la stabilità della frequenza di acquisizione a 3,3Khz del ADS1015 sia maggiore...

Mentre nel datasheet si legge

8.3.5 Oscillator
The ADS101x have an integrated oscillator running at 1 MHz. No external clock can be applied to operate these devices. The internal oscillator drifts over temperature and time. The output data rate scales proportionally with the oscillator frequency.

Che, in termini più schietti è come dire che quel convertitore è un... ferro da stiro e non può fare ciò che vorresti. Va aggiunto che se devi starci dietro con il micro non puoi sincronizzare nulla e devi lavorare tutto in interrupt (*).

Oltre a questo c'è un piccolo problemino di fondo. Tu scrivi

mi servono tutti i 12 bit... in una dinamica da 0 a 5 V e in una banda da 0 a circa 300/400 Hz, per cui possono essere direttamente campionati a 1.000 o 1.150 Hz...

Ho come l'impressione ci sia un po' di confusione con i numeri. Anche prendendo gli estremi più convenienti, ti serve un filtro anti-aliasing in ingresso che abbia un ripple in banda inferiore a 0.01 dB, un'attenuazione fuori banda minimo di 78 dB e la transizione deve avvenire in meno di un'ottava... CIUMBIA!
Me lo fai vedere questo filtro? Perché c'è il filtro, vero?

Se davvero ti servono quei numeri, il buffer di uscita è la cosa che ti dovrebbe preoccupare di meno.


(*) E farlo con un arduino è una cosa che fa... sorridere.

[eins]

Oltre a questo c'è un piccolo problemino di fondo. Ho come l'impressione ci sia un po' di confusione con i numeri. Anche prendendo gli estremi più convenienti, ti serve un filtro anti-aliasing in ingresso che abbia un ripple in banda inferiore a 0.01 dB, un'attenuazione fuori banda minimo di 78 dB e la transizione deve avvenire in meno di un'ottava... CIUMBIA! Me lo fai vedere questo filtro? Perché c'è il filtro, vero?

Innanzitutto grazie per i molti spunti, per me tutti molto utili. Vorrei far osservare a venexian che in qualche punto sopra scrivevo che i due segnali che ricevo sono già limitati in banda intorno ai 300 Hz (forse qualcosa poco sopra, ma sicuramente sotto i 400Hz). Li ricevo già così, ben condizionanti, amplificati, filtrati e puliti dal front-end analogico (anzi, sono stato conservativo, forse i segnali sono già limitati intorno ai 200Hz, ma non ne ho certezza). Nessun bisogno di farci altro, quindi il filtro c'è sicuramente, ma sta prima, lasciando tranquilli sia Nyquist che Shannon, visto che campiono almeno ad 1KHz o sopra.

Ma non era questo il problema che ponevo, credo che l'errore di fondo sia mio e me ne scuso, anche se in ritardo. Mi interessa solo l'aspetto del buffer di una sorgente di bit, poi che il tutto sia una parte di un problema più ampio per un momento vorrei poterlo ignorare e concentrarmi solo sul buffer, come da titolo.

E' sicuramente colpa mia anche il non aver sottoineato sufficientemente che posso disporre di un clock di riferimento ad 1 Hz di precisione "assoluta" (un segnale PPS proveniente da un GPS), quindi l'eventuale jitter sarebbe solo quello interno al secondo, quindi inferiore al millisecondo che è il mio "quid" temporale in un campionamento ad 1KHz. Per questo motivo ipotizzavo eventualmente di usare quel clock come interrupt per switchare due uC identici che si scambiano i ruoli, come dicevo prima, ma qui entriamo in un ambito dove non ho esperienza diretta.

In ultimo ringrazio molto delle schede che mi segnalate, per me tutto è prezioso e le guarderò con molta attenzione, però per il momento dovrò cercare di risolvere il problema con quello che ho già, come detto in precedenza. Ma poi, tempo permettendo, leggerò tutti i datasheet che potrò, ringraziando nel frattempo tutti del vostro aiuto.

[venexian]

E' un approccio un po' singolare quello in cui prima si scelgono i componenti e poi si leggono i datasheet... magari funziona. Come già detto in altro thread, non si finisce mai di imparare.

Oltre al super-filtro che però, come dici, esula dall'ambito della discussione e quindi con mio cruccio non riuscirò a vedere, mi resta ancora il dubbio che tu non abbia capito che quel convertitore è... free running! Come fai a campionare a 1 kHz più preciso di un quarzo se l'oscillatore se ne va a spasso per i fatti suoi? Forse però anche questo esula.

Allora il mio consiglio per il buffer di una sorgente di bit è due Arduino, un GPS per il clock preciso, una RAM di buffer ovviamente seriale, e la SD.

Se trovi le librerie in rete di sicuro funziona.

[eins]

E' un approccio un po' singolare quello in cui prima si scelgono i componenti e poi si leggono i datasheet... magari funziona. Come già detto in altro thread, non si finisce mai di imparare.

In laboratorio ho trovato del materiale a disposizione e vorrei usare quello, eventuali eccezioni potrei farle, ma non agevolmente. Componenti (ed approcci) che sto cercando di studiare pian piano, con i datasheet e anche col vostro aiuto. Perché ti sembra strano tutto questo? Se sapevo tutto non cercavo aiuto, se non sapevo niente neanche mi ponevo il problema, no?

Oltre al super-filtro che però, come dici, esula dall'ambito della discussione e quindi con mio cruccio non riuscirò a vedere

mai parlato di "super" filtro, ho solo semplicemente detto che il segnale mi arriva già sufficientemente filtrato, per cui non devo preoccuparmi io di interporre un filtro anti-aliasing e posso campionare a 1000 o più Sps. Trovi sbagliato questo?

mi resta ancora il dubbio che tu non abbia capito che quel convertitore è... free running! Come fai a campionare a 1 kHz più preciso di un quarzo se l'oscillatore se ne va a spasso per i fatti suoi? Forse però anche questo esula.

Beh, su questo non sono totalmente d'accordo, non è in free-running perché rimane comunque temporizzato da un oscillatore interno (per quanto impreciso e soggetto a derive varie) e a me basterebbe che non derivasse per più di un campione ogni secondo, poi si riallineerebbe intrinsecamente ogni secondo grazie al clock esterno ad 1Hz molto affidabile. Ma mi riservo di pensare al tutto con calma, visto gli argomenti su cui non ho molta dimestichezza.

Allora il mio consiglio per il buffer di una sorgente di bit è due Arduino, un GPS per il clock preciso, una RAM di buffer ovviamente seriale, e la SD. Se trovi le librerie in rete di sicuro funziona.

Beh, questo era quello che proponevo io, resta solo il piccolissimo problema che non so farlo e non so neanche se è concretamente possibile farlo, finora sono solo idee che in parte avevo prima ed in parte mi sono venute parlandone qui. Vedrò con calma se riuscirò a raccapezzarmici.

Permettimi in conclusione di ringraziarti sentitamente per il tempo che mi hai dedicato, per me molto prezioso, ma vorrei evitare di irritarti ulteriormente. Ho i capelli bianchi e non me la sento e non ho voglia di essere causa di nervosismo o ironia per nessuno, specialmente su un forum che ho sempre visto come molto costruttivo. Da te ho imparato tanto e te ne ringrazio veramente molto, ora tocca a me mettere a frutto quanto da te ed altri suggerito, fermo restando il fatto che se riuscirò a fare qualcosa, con molto piacere la metterò qui per pubblica utilità.

Ancora grazie a te e a tutti.

[venexian]

Anch'io ho i capelli bianchi e non sono irritato.

Trovo però strano che si domandi supporto e poi, quando vengono fatti notare dei problemi concreti, si risponda, con molta gentilezza, 'non sono affari tuoi, io ho chiesto altro'...

Per dimostrarti con i fatti che non sono irritato, continuo a darti i miei pareri tecnici, tralasciando quelli relativi all'approccio alla progettazione.

il segnale mi arriva già sufficientemente filtrato, per cui non devo preoccuparmi io di interporre un filtro anti-aliasing e posso campionare a 1000 o più Sps. Trovi sbagliato questo?

Teoricamente non è sbagliato, ma ci sono dei dettagli che contrastano tra loro e un progettista dovrebbe accorgersene (1). Se hai bisogno di 12 bit di risoluzione, significa che la precisione che ti serve è 'maniacale'. Stiamo parlando dello zero virgola zero eccetera per cento... Se ti viene detto che il segnale ha una banda dalla continua a 300 Hz e tu campioni a 1000 Hz, la domanda che dovresti farti è questa. Se mi serve una tale precisione a 300 Hz, significa che il segnale a tale frequenza non è alterato dall'azione del filtro (2). In questo caso, come può essere che da 500 Hz in poi, il segnale abbia spurie non superiori a -80 dB?

Questo è il dubbio, l'interpretazione è un'altra cosa, questa è la mia. Quei 300 Hz sono la banda utile del segnale, ma questo non significa che da 300 Hz in poi il segnale sia zero. Se ricevi le specifiche di un front-end da interfacciare a un ADC del quale tu decidi la frequenza di campionamento, sei tu che devi informarti su quale sia il roll-off del filtro anti-aliasing già presente. Se non sufficiente, devi aggiungerne uno tu.

Poi, non è che se ci sono spurie oltre i 500 Hz uno se ne accorga. Proprio no, non ha modo di farlo guardando i dati campionati, ma il suo lavoro è equivalente a quello che cerca di misurare il milligrammo con una pesa da camion.

Beh, su questo non sono totalmente d'accordo, non è in free-running perché rimane comunque temporizzato da un oscillatore interno

Questa E' la definizione di free running in questa applicazione...

a me basterebbe che non derivasse per più di un campione ogni secondo,

Deriva molto, molto, MOLTO di più. Comunque, non basterebbe questa restrizione perché...

poi si riallineerebbe intrinsecamente ogni secondo grazie al clock esterno ad 1Hz molto affidabile.

... perché, dicevo, questa è un'affermazione completamente senza senso.

Ti faccio notare che, anche se ti fosse possibile riallineare gli intervalli di campionamento ogni secondo, tutta la teoria della conversione, compresa la famosa frequenza di Nyquist, si fonda proprio sull'equidistanza dei campioni. Se non è costante puoi tornare all'esempio della bilancia, altro che i 12 bit...

Allora il mio consiglio per il buffer di una sorgente di bit è due Arduino...

Mi autoquoto per scusarmi: era una battuta, ma l'hai presa seriamente. L'architettura che ti ho descritto è un assurdo impossibile sotto quasi ogni aspetto.


(1) Ooops... questo è un commento sull'approccio, ma è solo funzionale, credimi.
(2) Che ci deve essere, anche se non è compito tuo mettercelo.

[eins]

Io mi fermo qui, non ritengo utile a nessuno una sterile polemica. Credo che tu faccia molta confusione fra contenuti in frequenza e precisone di quantizzazione.Ti ho detto che il segnale mi dovrebbe arrivare già pulito oltre i 300 Hz, io ancora non l'ho mai visto, ma c'è chi lo assicura e quindi non è compito mio metterlo in dubbio. Per quanto riguarda i 12 bit, non sono sicuramente maniacali, lo sarebbero forse 16 o 24, ma 12 bit sono uno standard normale in tutti i laboratori e comunque sono omogenei ad altri canali che provengono da quello stesso processo in osservazione. Ed in ultimo sì, cercherò di leggere e bufferizzare con uno o due uC, se non altro per curiosità. Era questo quanto chiedevo, se riuscirò a fare qualcosa lo posterò, altrimenti cambierò strada, ma quella e solo quella è ora il mio obiettivo.

Ti ringrazio ancora, ma non ho tempo né vedo utilità nel proseguire, quindi per me chiudo qui.
Buone cose.