Come sincronizzare due microcontrollori con un'accuratezza dei microsecondi?


37

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?


2
Potresti dirci cosa stai cercando di fare e perché le unità devono essere sincronizzate? Può essere, i dettagli della tua applicazione possono indicare una soluzione. Come problema generale, questo non è molto semplice, specialmente per i dispositivi wireless di piccole dimensioni.
Nick Alexeev

2
È impossibile ottenere la sincronizzazione basandosi sul Bluetooth. Il jitter di 15 ms è semplicemente troppo per ottenere 0,5 us di sincronizzazione. È necessario qualcosa con jitter molto basso e latenza fissa per la quale è possibile correggere. Sarebbe più facile se si potesse ottenere un singolo clock per entrambi e bufferizzare l'orologio per bilanciare i ritardi.
Travisbartley,

Scusa il ritardo. L'obiettivo del progetto è quello di rimuovere i fili da un progetto esistente di strumenti di misurazione digitali portatili. L'utente desiderava un design wireless, poiché danneggiava i cavi attuali. Le unità misurano la propagazione delle onde negli alberi in piedi, che sono abbastanza veloci da richiedere una sincronizzazione di 0,5us tra i due sensori.
Kevin,

Wireless economico o: infrarossi. Un impulso IR potrebbe essere sufficiente per risincronizzare gli orologi quando si sono leggermente allontanati.
JimmyB,

1
Questo documento propone un sistema Bluetooth 4.0 con sincronizzazione ~ 10uS, con test sperimentale.
user2943160

Risposte:


23

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.


Una volta ho lavorato a un progetto in cui dovevamo ottenere questo tipo di precisione sui server in esecuzione nei data center in tutto il mondo. Lì il modo più semplice era usare il GPS. Si è scoperto che non tutte le macchine / i data center potevano accedere al GPS, quindi la nostra soluzione alla fine è stata una vera sfida. Farlo con i microcontrollori sarà ancora più difficile.
Nomad Alien

4
+1 per "garantisce una nuova valutazione dell'intero progetto del sistema".

1
A seconda del budget, è possibile acquistare unità GPS che emettono una frequenza programmabile (0-10 Mhz) allineata in fase al segnale GPS per ~ $ 150 ea. Guarda uBlox LEA-6T. Esse dichiarano un errore temporale di 30 nS RMS, 99% <60 nS.
Connor Wolf,

9

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.

GPSnGPSn+1TimenTimen+1ExtGPSnGPSn+1

Timen+ExtGPSnGPSn+1GPSn

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.


Potresti essere un po 'più esplicito su come funzionerebbe? Ho difficoltà a capire dalla spiegazione attuale.
NickHalden,

@NickHalden: OK, fatto.
Dave Tweed

Hmmm ok, questo non si basa sulla frequenza dell'orologio della CPU che è costante tra i due impulsi da 1 secondo? Ad esempio, prendi un circuito oscillatore a cristallo particolarmente orribile in cui il 99% degli impulsi si verifica tra 0,00 e 0,05 secondi e quindi l'1% finale si verifica tra 0,05 e 1,00 s. Quell'esempio patologicamente costruito non rovinerebbe tutto o mi manca ancora qualcosa?
NickHalden,

Sì, questo significa "stabilità a breve termine".
Dave Tweed

Oh, mi piaceva questo quando ho commentato? Haha è imbarazzante. Comunque, grazie per la spiegazione +1 da parte mia.
NickHalden,

8

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.


La precisione di 1,5µs nello scenario a singolo hop e la precisione media di 0,5µs per hop nel caso multi-hop sono state mostrate fornendo risultati sperimentali. Bello.
Li-aung Yip,


3

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.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.