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

Question

Necesito sincronizar dos microcontroladores para que puedan medir la velocidad de las ondas que se propagan. Las mediciones de retardo de tiempo deben tener una precisión de microsegundos (error inferior a 1/2 de un microsegundo).

Tengo dos microcontroladores ( ATmega328 ) que utilizan un cristal de 12MHz.

Ambos están equipados con transceptores Bluetooth. Los transceptores Bluetooth envían y reciben paquetes con una fluctuación de ~15 milisegundos.

Espero poder sincronizar los microcontroladores utilizando los transceptores Bluetooth, o algún otro método creativo.

He intentado sincronizarlos tocándolos juntos, pero necesito que permanezcan sincronizados durante unos 10 minutos, y sus relojes se desvían demasiado rápido. Tal vez si fuera posible predecir con exactitud la deriva del reloj, este método funcionaría.

¿Cómo debo hacer para lograr esta sincronización?

Answer 1

No pretendo aguarte la fiesta de los inalámbricos. Te has encontrado con un requisito difícil pero inesperado. Algo así justifica la reevaluación de todo el diseño del sistema.

1º Lo que se me ocurre es sincronizar ambas unidades con un solo oscilador. Tienes comunicación Bluetooth, lo que indica que el alcance es del orden de 10m. Podrías conectar tus unidades con un cable coaxial RG174 o una fibra óptica, que llevaría el reloj.

2do. Hay osciladores de precisión. En orden de precisión y coste crecientes.

• TCXO (oscilador de cristal con compensación de temperatura). Deriva de 1 a 3 ppm, normalmente.
• OCXO (oscilador de cristal controlado por horno). La deriva es del orden de 0,02 ppm. Algunos OCXO tienen una deriva de hasta 0,0001 ppm.
• Reloj atómico ( Estándar de rubidio por ejemplo). Menciono el reloj atómico sobre todo para dar un marco de referencia. Más información aquí .

3ª , oscilador de precisión entrenado con el GPS. Cada satélite GPS lleva varios relojes atómicos a bordo. Normalmente, hay muchos satélites GPS a la vista. El GPS se utiliza mucho para el cronometraje 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), que proporciona una sincronización precisa de 50ns.
Para tener una deriva de 0,5μs a lo largo de 600s (10min), tu reloj (el de 12MHz en tu diseño actual) debería tener una deriva inferior a 0,0008ppm. Pero si puedes corregir el error de sincronización cada cierto tiempo desde una fuente externa de baja deriva, el requisito de la deriva en el reloj puede ser más relajado. Si puedes corregir cada segundo, entonces tu reloj podría tener una deriva de 0,5ppm.

Answer 2

Los módulos GPS con salidas de 1pps son fáciles de conseguir y baratos.

No es realmente necesario disciplinar el oscilador de la CPU al GPS (por ejemplo, con un PLL). Mientras puedas "marcar el tiempo" de los eventos externos en relación con el reloj de la CPU, es relativamente sencillo interpolar el tiempo de tus eventos de transmisión y recepción de ondas entre dos eventos PPS cualquiera.

A menudo se puede utilizar 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 la CPU de ancho arbitrario. Puede ser complicado manejar correctamente los eventos de desbordamiento, tanto del contador de hardware como del contador de software, pero al final, puedes tener, digamos, un contador de 32 bits que cuente a la velocidad del reloj de la CPU (dando una alta resolución) y se desborde con un período más largo que los intervalos que estás tratando de medir (por ejemplo, 429 segundos a 10 MHz).

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

Supongamos que \$GPS_n\$ y \$GPS_{n+1}\$ son las marcas de tiempo del reloj de la CPU para dos pulsos sucesivos del GPS. También se conocen las horas reales (del reloj atómico) asociadas a cada uno de esos pulsos (a partir de los mensajes del 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 y que caiga entre \$GPS_n\$ y \$GPS_{n+1}\$ su hora exacta es:

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

Por último, si tienes esta configuración funcionando en dos sistemas separados, cada uno con su propio receptor GPS, puedes comparar los tiempos calculados para varios eventos en los dos sistemas con alta precisión (normalmente del orden de ±100 ns), incluso si los relojes de la CPU de los dos sistemas no están sincronizados.

Answer 3

Ya he implementado antes una sincronización de reloj inalámbrica para microcontroladores, pero sólo con una precisión de milisegundos, que era suficiente para la aplicación. De mi lectura, este documento explica la sincronización de microsegundos bastante bien: http://www.math.u-szeged.hu/tagok/mmaroti/okt/2010t/ftsp.pdf

Esencialmente, si se conoce el evento de transmisión y el evento de llegada de un paquete de radio en el transmisor y el receptor respectivamente, se tiene un evento observable común (suponiendo que se ignore el tiempo de propagación de la onda de radio) entre los 2 sistemas que se puede utilizar como referencia. La otra característica mencionada en el artículo es la estimación de la desviación del reloj mediante regresión lineal.

Answer 4

Consulta el Protocolo de Sincronización de Relojes Bluetooth (CSP) que es una parte opcional del Perfil del dispositivo de salud (HDP) Las secciones de ese documento que son relevantes para la CSP son la 2.1 y la 8.

Todavía no he tenido la oportunidad de probarlo por mí mismo pero, por lo que veo, BlueZ (la pila de protocolos Bluetooth oficial de Linux) sólo se ha añadido soporte para el HDP incluyendo el apoyo a la CSP. Así que aunque no parece que vayas a correr en una plataforma que soporte la pila BlueZ, pero tal vez el código al menos proporcione una buena implementación de referencia.