Acquisizioni remote sincronizzate

[eins]

Salve a tutti,

devo acquisire pochi canali analogici (credo che userò degli USB-6008/6009 della NI) in punti distanti tra loro (anche chilometri) o addirittura in città diverse. Ho assolutamente necessità che queste acquisizioni remote siano sincronizzate tra loro a livello del millisecondo. Qualcuno ha qualche idea, anche apparentemente inusuale, per affrontare questo problema? Vorrei comunque che il segnale di sincronia venisse in qualche modo trasformato in analogico per essere poi presentato su uno dei canali di acquisizione, in maniera tale da averlo perfettamente allineato nel tempo con gli altri canali acquisiti. Intanto anticipo qualche proposta:

1) inviare ogni tanto un impulso radio di sincronia da una trasmittente unica a varie riceventi, una per ogni punto di acquisizione (ma immagino che i costi e le autrizzazioni non siano banali);

2) sintonizzarsi su un ricevitore GPS, cioè leggere i dati da un GPS con un microprocessore (ad esempio Arduino) e poi codificare quei valori con livelli analogici in uscita in modo da essere inviati al DAC;

3) cercare di sintonizzarsi sui segnali temporali inviati da Francoforte o dalla RAI;

4) ho già provato ad allineare temporalmente i vari portatili (Windows), ma nel migliore dei casi ottengo errori di decine di millisecondi (purtroppo invece devo stare entro il millisecondo) e poi preferirei far entrare il segnale di sincronia direttamente dal DAC;

5) sto cercando di capire se un collegamento GSM potrebbe essermi utlile.

Posso chiedere se vi viene in mente qualcosa d'altro?
posso anche chiedere se mi sapreste suggerire un GPS con uscite leggibili con Arduino?

Grazie moltissimo in anticipo, eins.

[jordan20]

Due domande fondamentali.
1) formato dei dati?
2) tipo di codifica?

ma nel migliore dei casi ottengo errori di decine di millisecondi

Conoscendo la codifica si può capire se e quali rigeneratori di segnale (sia di sincronismo che dati) servono...

[obiuan]

2) sintonizzarsi su un ricevitore GPS, cioè leggere i dati da un GPS con un microprocessore (ad esempio Arduino) e poi codificare quei valori con livelli analogici in uscita in modo da essere inviati al DAC;

se ho capito bene, ti basta che siano sincronizzate ma non ti serve comandare da remoto l'istante dell'acquisizione. in questo caso, un qualunque modulo gps con un'antenna patch ti va benissimo...e non ti serve leggere i dati nmea in uscita, i moduli hanno normalmente un pin che da un impulso al secondo. quando il gps è agganciato, la tolleranza su quell'impulso è di 1us, per tutti i moduli gps ovunque essi siano, e visto che i satelliti sono tutti sincroni fra loro puoi avere una sincronizzazione perfetta senza sforzo.

ovviamente, questo funziona se-e-solo-se le varie stazioni vedono il cielo.

[jordan20]

Se scegli l'etere come mezzo trasmissivo, queto appieno obiuan

[obiuan]

Se scegli l'etere come mezzo trasmissivo, queto appieno obiuan

visto che ha parlato di sincronizzare PC, credo abbia stazioni intelligenti in ogni luogo...quindi se sincronizza con ricevitori gps poi puo' acquisire col PC e mandare via internet senza problemi....sempre che io abbia capito quello che vuole fare

[eins]

Eccomi, innanzitutto grazie delle tante risposte, veramente tempestive e preziose. Cerco di spiegare meglio: ogni stazione di acquisizione sarà costituita da un portatilino (Windows) a cui sarà collegato un modulo Daq via USB. Tale modulo Daq può acquisire 4 o 8 canali analogici, diciamo a mille campioni al secondo (in realtà probabilmente basterà acquisire 2 o 3 canali, lasciandone almeno uno libero). Di queste stazioni ve ne saranno almeno due nella stesa città poste a qualche chilometro di distanza e forse anche una terza, eventualmente più lontana, tutte quante con pesone accanto, che ad un'ora stabilità cominceranno ad acquisire qualche minuto di tracciati (presumibilmente potranno essere in contatto col cellulare, ma questo non è sicuro, ma di sicuro si accorderanno prima per un orario di inizio comune). poi dopo alcuni minuti di registrazione (o forse anche un po' più, ma mai più di qualche ora) i due o tre gruppi si ritrovano in laboratorio per confrontare queste acquisizioni ed è fondamentale che ne ricostruiscano il sincronismo temporale. Per qusto forse il segnale (l'impulso) del GPS potrebbe essere prezioso. Ma da solo mi sembra che non basti. Forse lo potrei leggere con un microcontrollore e con questo generare un segnale analogico da inviare al canale di acquisizione libero con l'aggiunta di una informazione sull'ora esatta, sempre codificata in analogico.

A questo punto vi chiederei quali moduletti GPS potrei usare e se è possibile, oltre al segnale impulsivo di sincronia, leggere con un uC dal GPS anche HH:MM:SS

[obiuan]

A questo punto vi chiederei quali moduletti GPS potrei usare e se è possibile, oltre al segnale impulsivo di sincronia, leggere con un uC dal GPS anche HH:MM:SS

allora, i migliori GPS in commercio ad oggi sono gli u-blox. Dovresti trovare facilmente l'u-blox 6, ma per la tua applicazione ti va benissimo anche il 5.

I moduli GPS comunicano normalmente mediante UART e SPI, e trasmettono stringhe codificate in ASCII secondo il protocollo NMEA. Quello che riceverai sulla UART sarà una cosa del tipo:

$GPGGA,123519,4807.038,N,01131.000,E,1,08,0.9,545.4,M,46.9,M,,*47
$GPGSV,2,1,08,01,40,083,46,02,17,308,41,12,07,344,39,14,22,228,45*75

etc etc (dopo l'* c'è una checksum)

Una specifica completa la puoi trovare qui:

http://www.gpsinformation.org/dale/nmea.htm

Un microntrollore può facilmente restare in attesa sulla UART, il GPS spedirà un set di stringhe NMEA al secondo. Inizialmente, fino a chè l'RC interno del modulo non sarà calibrato, questo secondo sarà fuori sincronismo. Poi, dopo diciamo un paio di minuti in condizioni di buon segnale, l'RC si calibrerà, la sincronizzazione avvenuta verrà segnalata in una delle NMEA e da lì in poi sarai certo di essere sincrono ai satelliti.

in realtà, puoi usare anche direttamente il PC con un convertitore uart-usb, ovviamente dovrai usare un max232 o similari per la generazione dei livelli. metti la tua applicazione di alto livello in attesa sulla uart aspettando che la flag di rc tarato vada a true, e poi con un semplice parsing di stringhe avrai data e ora. con l'impulso del gps triggeri l'acquisizione che poi leggi sempre dal PC attraverso qualche altro canale.

[obiuan]

ho letto solo ora...1khz per canale, non puoi farcela con la uart. le stringhe nmea sono anche quasi un kilobyte se i satelliti in vista sono tanti, in un millisecondo non riesci a riceverle nemmeno a 115kbaud. devi andare in spi se vuoi ricavare l'ora da quelle, con la seriale sincrona vai facilmente a 5 mbit. però ti serve per forza un micro nel mezzo, che acquisisca le nmea, faccia il parsing e restituisca al PC i pochi bytes che servono.

poi, onestamente mi sfugge il significato di questo:

Forse lo potrei leggere con un microcontrollore e con questo generare un segnale analogico da inviare al canale di acquisizione libero con l'aggiunta di una informazione sull'ora esatta, sempre codificata in analogico.

non capisco...i canali di acquisizione cosa devono acquisire? se ho capito bene, ti serve avere vari campioni e sapere l'ora esatta alla quale sono stati acquisiti. se è così, la vedrei bene fatta in questo modo:

- Un micro, diciamo pure l'arduino, collegato in SPI al modulo GPS e in UART al PC.
- L'arduino va in polling sul canale SPI del GPS attentendo che l'RC si tari.
- Una volta tarato, comunica via UART al PC che è pronto con i dati e attende il via dal PC
- Il modulo GPS, automaticamente, nonappena tara l'RC inizia a dar fuori sul pin Time l'impulso a 1s.
- L'acquisitore usa l'impulso di syncro per triggerare un'acquisizione
- contestualmente all'impulso di syncro, il GPS manda fuori le NMEA con i nuovi dati acquisiti.
- L'arduino legge dall'SPI data e ora, dall'acquisitore il campione, e trasmette tutto via UART al PC

che dovrebbe essere relativamente semplice.

[eins]

quoto me stesso: quando dicevo:

"Forse lo potrei leggere con un microcontrollore e con questo generare un segnale analogico da inviare al canale di acquisizione libero con l'aggiunta di una informazione sull'ora esatta, sempre codificata in analogico."

intendevo dire proprio una follia, ma che nel mio caso potrebbe avere qulche vantaggio:

l'idea è quella di interrogare con un uC in polling ogni secondo il moduletto GPS, ricevere la stringa ASCII, fare il dovuto parsing, buttare tutto il resto e tenere solo HH:MM:SS (diciamo 3 Byte) e poi (per favore non svenire!) con il DAC del uC codificare una serie di livelli analogici (tra 0V e 5V) con una codifica digitale ancora da decidere (AMK, FSK, PSK o qualche altra codifica stramba da personalizzare all'uopo) che possa essere riletta dall'ADC a 1KHz (su 1.000 campioni credo che ce la dovremmo fare a cosificare 3 Byte). alla fine dei 1.000 campioni l'impulso sancisce sincronismo. Buttato tutto fuori a ruota libera! Potrebbe funzionare? Uno dei vantaggi è che non dovrei minimamente toccare il software di acquisizione che è già lì bello che funzionante (scritto da me in Labview anni fa, ma di cui non è che mi ricordi molto!).

[obiuan]

.... solo HH:MM:SS (diciamo 3 Byte) e poi (per favore non svenire!) con il DAC del uC codificare una serie di livelli analogici (tra 0V e 5 V) con una codifica digitale ancora da decidere (AMK, FSK, PSK o qualche altra codifica stramba da personalizzare all'uopo) che possa essere riletta dall'ADC a 1KHz (su 1.000 campioni credo che ce la dovremmo fare a cosificare 3 Byte). alla fine dei 1.000 campioni l'impulso sancisce sincronismo. Buttato tutto fuori a ruota libera! Potrebbe funzionare?

vediamo se ho capito. hai già un programma in labview che legge a 1khz da un acquisitore a 4 canali. per avere direttamente nelle acquisizioni un time-stamp, vorresti codificarlo in qualche modo in analogico e farlo rileggere a uno dei 4 canali, in modo da non dover riscrivere il software su PC...

quindi dovresti trasformare l'informazione di tempo in un livello analogico con un dac e trasmetterla dall'altra parte in modo che ti stia tutta nei mille campioni che fai al secondo. ho capito bene? ma perché in analogico se hai 1000 campioni? manda via un bit alla volta e hai 1000 bit di informazione inviabili...ti ci sta anche un crc

comunque, se ho capito, mi sembra che ti complichi la vita un bel po' solo per non rimettere le mani sul labview. complichi il software sull'arduino, e poi una volta che sarai riuscito a far funzionare tutto ti troverai con 1000 dati raw al secondo nei quali c'è sparsa l'informazione di tempo, e di tocca fare un altro software per ricostruirli.