¿Cómo sincronizar dos microcontroladores con una precisión de microsegundos?

No quiero que llueva en tu desfile inalámbrico. Te has topado con un requisito duro pero inesperado. Algo así merece una reevaluación de todo el diseño del sistema.

La primera cosa que viene a la mente es sincronizar ambas unidades con un oscilador. Tiene comunicación Bluetooth, lo que sugiere que el alcance es del orden de 10 m. Puede conectar sus unidades con un cable coaxial RG174 o con una fibra óptica que lleve el reloj.

2do , hay osciladores de precisión. Para aumentar la precisión y el coste.

• TCXO (oscilador de cristal con compensación de temperatura). 1 a 3 ppm de deriva, por lo general.
• OCXO (oscilador de cristal controlado por horno). Deriva en el orden de 0.02ppm. Algunos OCXO se han reducido a 0.0001 ppm.
• Reloj atómico ( estándar de rubidio , por ejemplo). Menciono el reloj atómico principalmente para dar un marco de referencia. Más información sobre aquí .

3º , oscilador de precisión entrenado con GPS. Cada satélite GPS tiene varios relojes atómicos a bordo. Por lo general, hay muchos satélites GPS a la vista. El GPS se utiliza para la sincronización de precisión mucho (uso menos conocido en comparación con la navegación por satélite). La mayoría de los receptores GPS tienen una salida de 1PPS (un pulso por segundo), lo que proporciona una sincronización precisa de 50 ns. Para tener una deriva de 0.5μs sobre 600s (10min), su reloj (el reloj de 12MHz en su diseño actual) debe tener una deriva menor a 0.0008ppm. Pero si puede corregir el error de tiempo de vez en cuando desde una fuente externa de baja deriva, el requisito de la deriva en el reloj puede ser más relajado. Si puede corregir cada segundo, entonces su reloj podría tener una deriva de 0.5 ppm.

Los módulos GPS con salidas de 1pps están disponibles y son económicos.

No es realmente necesario disciplinar el oscilador de la CPU al GPS (por ejemplo, con un PLL). Siempre que pueda "marcar la hora" de los eventos externos en relación con el reloj de la CPU, es relativamente sencillo interpolar la hora de su ola de transmisión y recepción de eventos entre cualquiera de los dos eventos PPS.

Con frecuencia puede usar la combinación de un temporizador de hardware en el microcontrolador, junto con un contador de software para sus eventos de desbordamiento, para crear un contador de ciclos de CPU de ancho arbitrario. Puede ser complicado lidiar correctamente con los eventos de reinversión, tanto del contador de hardware como del contador de software, pero al final, puede tener, digamos, un contador de 32 bits que cuenta a la velocidad del reloj de la CPU (dando alta resolución ) y se desplaza con un período más largo que los intervalos que está tratando de medir (por ejemplo, 429 segundos a 10 MHz).

Puede usar este contador para marcar diferentes eventos externos. Si uno de esos eventos son pulsos de 1 pps de un receptor de GPS, entonces la precisión básica a largo plazo del reloj de la CPU se convierte en algo que no importa. Lo único que importa es su estabilidad a corto plazo. Puede guardar las marcas de tiempo de GPS en un búfer FIFO y comparar las marcas de tiempo de otros eventos con los valores de ese búfer. Como sabe que los pulsos del GPS están separados exactamente por un segundo, puede encontrar la hora exacta de cualquier otro evento mediante la interpolación.

Supongamos que \ $ GPS_n \ $ y \ $ GPS_ {n + 1} \ $ son las marcas de tiempo del reloj de la CPU para dos pulsos GPS sucesivos. También conoce los tiempos reales (reloj atómico) asociados con cada uno de esos pulsos (de los mensajes GPS), \ $ Time_n \ $ y \ $ Time_ {n + 1} \ $. Si \ $ Ext \ $ es la marca de tiempo del reloj de la CPU para algún evento externo que desee medir que se encuentre entre \ $ GPS_n \ $ y \ $ GPS_ {n + 1} \ $, su hora exacta es:

$$ Time_n + \ frac {Ext - GPS_n} {GPS_ {n + 1} - GPS_n} $$

Finalmente, si tiene esta configuración ejecutándose en dos sistemas separados, cada uno con su propio receptor GPS, puede comparar los tiempos calculados para varios eventos en los dos sistemas con alta precisión (generalmente del orden de ± 100 ns), incluso si los relojes de la CPU de los dos sistemas no están sincronizados.

He implementado una sincronización de reloj inalámbrica para microcontroladores antes, pero solo con milisegundos de precisión, lo cual fue lo suficientemente bueno para la aplicación. De mi lectura, este documento explica bastante bien la sincronización de microsegundos: enlace

Esencialmente, si conoce el evento de transmisión y el evento de llegada de un paquete de radio en el transmisor y el receptor respectivamente, tiene un evento observable común (asumiendo que ignora el tiempo de propagación de la onda de radio) entre los 2 sistemas Eso puede ser usado como una referencia. La otra característica interesante que se menciona en el artículo es la estimación de la inclinación del reloj mediante regresión lineal.

Consulte el Protocolo de sincronización de reloj Bluetooth (CSP), que es una parte opcional del Dispositivo de salud Perfil (HDP) Las secciones de ese documento que son relevantes para CSP son 2.1 y amp; 8.

Todavía no he tenido la oportunidad de probarlo, pero, por lo que puedo decir, BlueZ (la pila oficial de protocolo Bluetooth de Linux) simplemente compatibilidad agregada para HDP , incluida la compatibilidad con CSP. Entonces, aunque no suene como si estuvieras ejecutando en una plataforma que admita la pila BlueZ, quizás el código al menos proporcionará una buena implementación de referencia.