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

No pretendo llover sobre tu desfile inalámbrico. Te has topado con un requisito difícil pero inesperado. Algo así justifica la reevaluación de todo el diseño del sistema.

Lo primero que me viene a la mente es sincronizar ambas unidades con un oscilador. Tiene comunicación Bluetooth, lo que da a entender que el alcance es del orden de los 10m. Podrías conectar tus unidades con cable coaxial RG174 o una fibra óptica, que llevaría el reloj.

En segundo lugar, hay osciladores de precisión. En orden creciente de precisión y costo.

• TCXO (oscilador de cristal con compensación de temperatura). Deriva de 1 a 3 ppm, típicamente.
• OCXO (oscilador de cristal controlado por horno). Deriva del orden de 0,02 ppm. Algunos OCXO han bajado 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 sobre eso 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 mucho para la sincronización de precisión (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 precisión de tiempo de 50 ns.
Para tener una desviación de 0,5 μs durante 600 s (10 minutos), su reloj (el reloj de 12 MHz en su diseño actual) debe tener una desviación inferior a 0,0008 ppm. 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 flexible. Si puede corregir cada segundo, su reloj podría tener una desviación de 0,5 ppm.

Los módulos GPS con salidas de 1 pps están fácilmente 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 el tiempo de su transmisión de ondas y recibir eventos entre dos eventos PPS cualesquiera.

A menudo, 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 manejar correctamente los eventos de rollover, 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 cambia con un período más largo que los intervalos que intenta medir (por ejemplo, 429 segundos a 10 MHz).

Puede usar este contador para marcar la hora de diferentes eventos externos. Si uno de esos eventos son pulsos de 1 pps de un receptor GPS, entonces la precisión básica a largo plazo del reloj de la CPU se convierte en un problema. Lo único que importa es su estabilidad a corto plazo. Puede guardar marcas de tiempo GPS en un búfer FIFO y comparar las marcas de tiempo de otros eventos con los valores en 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.

Suponer$GPS_n$y$GPS_{n+1}$son las marcas de tiempo del reloj de la CPU para dos pulsos de 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 desea medir que se encuentra entre$GPS_n$y$GPS_{n+1}$, su hora exacta es:

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 (normalmente del orden de ±100 ns), incluso si el 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 una precisión de milisegundos, lo cual fue lo suficientemente bueno para la aplicación. Según mi lectura, este documento explica bastante bien la sincronización de microsegundos: http://www.math.u-szeged.hu/tagok/mmaroti/okt/2010t/ftsp.pdf

Esencialmente, si tiene conocimiento del 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 que pueden ser utilizado como referencia. La otra característica interesante mencionada en el documento es la estimación de sesgo horario mediante regresión lineal.

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

Todavía no he tenido la oportunidad de probarlo yo mismo, pero, por lo que sé, BlueZ (la pila oficial de protocolos Bluetooth de Linux) acaba de agregar soporte para HDP , incluido el soporte para CSP. Entonces, aunque no parezca que se ejecutará en una plataforma compatible con la pila BlueZ, tal vez el código al menos proporcione una buena implementación de referencia.