Acquisizioni remote sincronizzate

[IsidoroKZ]

Di solito tutti i sistemi basati su windows non sono real time, non ti puoi fidare della tempistica dei programmi. La scheda NI che vuoi usare dovrebbe avere una base tempi dentro, con cui fare acquisizioni continue.

Il suggerimento e` di usare un circuito di acquisizione in real time, con timestamp del gps. Convertire il segnale del gps in un impulso codificato in ampiezza e farlo convertire A/D mi pare una complicazione assurda.

Chissa` se DirtyDeeds sa qualcosa circa le temporizzazioni delle schede NI?

[eins]

Sì hai capito benissimo, scusa se ho fornito questa informazione a sprazzi, ma anche questa soluzione l'ho pensata a sprazzi mentre ne discutevamo insieme. Comunque non mi complico molto la vita, poiché comunque per un uC, Arduino o altro, devo comunque passarci per interfacciarmi col GPS (a proposito stavo vedendo questo: http://www.futurashop.it/index.php?rout ... ct_id=2446 che ne pensi?).

Inoltre non è da poco evitarmi di rimettere le mani a sistemi di acquisizione che oramai sono consolidati e ben funzionanti. Questa soluzione avrebbe tra l'altro il vantaggio di essere indipendente dal sistema di acquisizione, utilizzabile da tutti e con ogni sistema con 1KHz o più di sample rate (forse potrebbe essere utilizzata anche da altri). In quanto alla ricostruzione dell'informazione (decodifica ASK o altro) non la farò io ( ), ma sarà comodamente fatta offline in laboratorio con Matlab ed aggiungere una routine una sola volta per tutte non dovrebbe essere troppo complicato. E poi vuoi mettere la stramberia di questa soluzione? Ma, scherzi a parte, secondo te potrebbe funzionare?

[eins]

Grazie anche a IsidoroKZ, ma i vincoli del problema è che devo continuare ad usare i sistemi esistenti, non posso e non avrebbe senso proporre di cambiare l'hardware di acquisizione, Conosco anche io discretamente il mondo NI e i dispositivi USB-6008 e USB-6009 sono i più semplici ed economici della gamma (peraltro ottima ma molto costosa). Acquisiscono con un clock hardware interno e mettono tutto su uno shift register che perde i dati quando è pieno (FIFO) e che va solo letto di continuo, ma non hanno un orologio interno. Con due o tre schedettine con un arduino (o PIC o altro) risolverei il problema egregiamente. Quello che non sapevo e che ho appreso qui ora è che i moduletti GPS sono facili da interfacciare (SPI se ho capito bene) e soprattutto hanno quel benedetto impulso del secondo che mette tutto a posto. Mi sembra che facciano proprio al caso mio.

Grazie veramente a tutti. Chissà se potrò sdebitarmi in qualche modo, la sola cose che conosco abbastanza bene è il Labview, ma gli interessati sono pochi mi sembra. Un caro saluto a tutti.

eins

[IsidoroKZ]

In bocca al lupo. Stai cercando di risolvere un problema con strumenti non adatti. Verifica che quello che misuri sia sensato, sia sincronizzato. Fra un arduino, di cui non controlli il programma (perche' chiami routine gia` scritte) e un PC dietro, non sarei proprio sicuro che si riesca a sincronizzare i campioni entro un millisecondo.

[DirtyDeeds]

Chissa` se DirtyDeeds sa qualcosa circa le temporizzazioni delle schede NI?

La maggior parte delle schede NI non ha un clock sincronizzabile con un clock esterno. Alcune di quelle con bus PXI sono sincronizzabili attraverso un'altra scheda apposta da montare sullo stesso bus.

[eins]

@DirtyDeeds: grazie DirtyDeeds, ma nel mio caso specifico non si sarebbe comunque potuto applicare, visto che le due acquisizioni sono molto lontane tra loro, oltre che per il fatto che, come fai giustamente notare tu, molti dispositivi NI non hanno un bus di sincronizzazione del clock, compresi gli USB_6008 e USB-6009 che userò io, che sono al livello più "chip" della NI.

@IsidoroKZ: grazie anche a te Isidoro, ma mi sembra che gli strumenti comincino a prendere la forma che volevo, anche grazie al prezioso aiuto di obiuan e all'impulso dei secondi dei GPS. Con pochissima spesa e senza grosse modifiche mi sembra di poter provare a risolvere il mio problema, senza dover spendere troppo e senza dover modificare niente dell'esistente. Ora si tratterà di vedere come realizzare questo tandem GPS-uC, ma mi sembra già più abbordabile.

Per tutti: visto il molto aiuto ricevuto mi sembra doveroso condividere anche quello che tenterò di fare a questo punto: considerando che le date delle acquisizioni saranno certe e scontate, mi limiterò a cercare di codificare su 1000 campioni solo i dati HH:MM:SS, che se proprio vogliamo essere pignoli potrebbero collassare agli 86.400 secondi di un giorno, pari a 17 bit di dati, ma anche con una codifica fortemente insatura potrei tentare di codificare il tutto su tre Byte (uno per le ore, uno per i minuti e uno per i secondi) con una tecnica del tutto simile alla codifica RS232, facendo ad esempio salire e scendere il livello analogico tra 0V e 5V ogni 20 o 30 ms, a partire da un segnale di start e fino ad un eventuale segnale di stop. La decodifica susseguente mi sembra piuttosto agevole. Ovviamente qualsiasi altra idea sarà la benvenuta.

Se riesco a fare qualcosa di decente riporterò qui il risultato. Fin da adesso un grazie di cuore a tutti. Buon Natale e Buone Feste, eins.

[IsidoroKZ]

Aspettiamo i risultati! Hai anche pensato a un modo per verificare che la sincronizzazione funzioni?

[eins]

Aspettiamo i risultati! Hai anche pensato a un modo per verificare che la sincronizzazione funzioni?

Oh no Isidoro, questo problema di sicuro non mi si pone. O almeno non si pone a me! Ho sicuramente una schiera di persone dietro di me pronte ad infilzarmi se le acquisizioni non dovessero essere allineate temporalmente. Credimi, almeno non devo fare io la fatica di validare i dati. Comunque grazie per le tue preoccupazioni. Di nuovo Buone Feste.