Come sincronizzare due microcontrollori con un'accuratezza dei microsecondi?

Devo sincronizzare due microcontroller in modo che possano misurare la velocità delle onde di propagazione. Le misurazioni del ritardo devono avere una precisione di microsecondi (errore inferiore a 1/2 di un microsecondo).

Ho due micro-controller ( ATmega328 ) che usano un cristallo a 12MHz.

Entrambi sono dotati di ricetrasmettitori Bluetooth. I ricetrasmettitori Bluetooth inviano e ricevono pacchetti con un jitter di ~ 15 millisecondi.

Spero di sincronizzare i microcontroller usando i ricetrasmettitori Bluetooth o qualche altro metodo creativo.

Ho provato a sincronizzarli toccandoli insieme, ma ho bisogno che rimangano sincronizzati per circa 10 minuti e i loro orologi si sono spostati troppo velocemente. Forse se fosse possibile prevedere con precisione la deriva dell'orologio, questo metodo funzionerebbe.

Come devo fare per ottenere questa sincronizzazione?

Non intendo piovere sulla tua parata wireless. Hai incontrato un requisito difficile ma inaspettato. Qualcosa del genere merita una rivalutazione dell'intero progetto del sistema.

La prima cosa che viene in mente è di spegnere entrambe le unità da un oscillatore. Hai una comunicazione Bluetooth, che suggerisce che la portata è dell'ordine di 10m. È possibile collegare le unità con un cavo coassiale RG174 o una fibra ottica, che porterebbe l'orologio.

Secondo , ci sono oscillatori di precisione. Al fine di aumentare precisione e costi.

• TCXO (oscillatore a cristallo compensato in temperatura). Deriva da 1 a 3 ppm, in genere.
• OCXO (oscillatore a cristallo controllato da forno). Deriva nell'ordine di 0,02 ppm. Alcuni OCXO sono scesi a 0,0001 ppm.
• Orologio atomico ( standard del rubidio , per esempio). Sto citando l'orologio atomico principalmente per fornire un quadro di riferimento. Maggiori informazioni qui .

In terzo luogo , oscillatore di precisione addestrato con GPS. Ogni satellite GPS ha diversi orologi atomici a bordo. Di solito, ci sono molti satelliti GPS in vista. Il GPS è molto utilizzato per i tempi di precisione (utilizzo meno noto rispetto al navigatore satellitare). La maggior parte dei ricevitori GPS ha un'uscita 1PPS (un impulso al secondo), che fornisce una tempistica precisa a 50 ns.
Per avere una deriva di 0,5 μs su 600s (10min), l'orologio (l'orologio a 12 MHz nel progetto attuale) dovrebbe avere una deriva inferiore a 0,0008 ppm. Ma se è possibile correggere l'errore di temporizzazione ogni tanto da una sorgente esterna a bassa deriva, il requisito per la deriva nell'orologio può essere più rilassato. Se riesci a correggere ogni secondo, il tuo orologio potrebbe avere una deriva di 0,5 ppm.

I moduli GPS con uscite 1pps sono prontamente disponibili ed economici.

Non è davvero necessario disciplinare l'oscillatore della CPU al GPS (ad es. Con un PLL). Finché è possibile "timestamp" di eventi esterni relativi al clock della CPU, è relativamente semplice interpolare il tempo di trasmissione dell'onda e ricevere eventi tra due eventi PPS.

È spesso possibile utilizzare la combinazione di un timer hardware sul microcontrollore, insieme a un contatore software per i suoi eventi di overflow, per creare un contatore del ciclo della CPU di larghezza arbitraria. Può essere complicato gestire correttamente gli eventi di rollover, sia del contatore hardware che del contatore software, ma alla fine, si può avere, diciamo, un contatore a 32 bit che conta alla velocità del clock della CPU (dando alta risoluzione ) e passa con un periodo più lungo degli intervalli che si sta tentando di misurare (ad es. 429 secondi a 10 MHz).

È possibile utilizzare questo contatore per timestamp di diversi eventi esterni. Se uno di questi eventi è rappresentato da impulsi da 1 pps di un ricevitore GPS, l'accuratezza di base a lungo termine del clock della CPU diventa un problema. L'unica cosa che conta è la sua stabilità a breve termine. È possibile salvare i timestamp GPS in un buffer FIFO e confrontare i timestamp di altri eventi con i valori in quel buffer. Dato che sai che gli impulsi GPS sono esattamente a un secondo di distanza, puoi trovare l'ora esatta di qualsiasi altro evento interpolando.

$GPS_n$$GPS_{n+1}$$Time_n$$Time_{n+1}$$Ext$$GPS_n$$GPS_{n+1}$

Infine, se questa impostazione è in esecuzione su due sistemi separati, ciascuno con il proprio ricevitore GPS, è possibile confrontare i tempi calcolati per vari eventi sui due sistemi con elevata precisione (in genere nell'ordine di ± 100 ns), anche se il I clock della CPU dei due sistemi non sono sincronizzati.

In precedenza ho implementato una sincronizzazione dell'orologio wireless per i microcontrollori, ma solo con una precisione di millisecondi, che era abbastanza buona per l'applicazione. Dalla mia lettura, questo documento spiega abbastanza bene la sincronizzazione dei microsecondi: http://www.math.u-szeged.hu/tagok/mmaroti/okt/2010t/ftsp.pdf

In sostanza, se si ha conoscenza dell'evento di trasmissione e dell'evento di arrivo di un pacchetto radio rispettivamente sul trasmettitore e sul ricevitore, si ha un evento osservabile comune (supponendo che si ignori il tempo di propagazione dell'onda radio) tra i 2 sistemi che possono essere usato come riferimento. L'altra caratteristica ordinata menzionata nel documento è la stima dell'orologio inclinato usando la regressione lineare.

Dai un'occhiata al CSP (Bluetooth Clock Synchronization Protocol) che è una parte facoltativa del profilo del dispositivo sanitario (HDP) Le sezioni in quel documento che sono rilevanti per CSP sono 2.1 e 8.

Non ho ancora avuto la possibilità di provarlo da solo, ma, per quanto ne so, BlueZ (lo stack ufficiale del protocollo Bluetooth Linux) ha appena aggiunto il supporto per l'HDP , incluso il supporto per CSP. Quindi, anche se non sembra che tu stia funzionando su una piattaforma che supporta lo stack BlueZ, ma forse il codice fornirà almeno una buona implementazione di riferimento.