Servidor horario
Cómo conseguir alta precisión en el tiempo asociado a las medidas astronómicas
Introducción
Cuando se realizan medidas en astronomía, por ejemplo en fotometría y astrometría, se requiere que los datos medidos lleven asociados una fecha y hora que debe ser suficientemente precisa para que las mediciones tengan valor científico, especialmente si las queremos reportar y compartir. La precisión requerida dependerá lógicamente de lo que estemos midiendo. Se requerirá mucha precisión si, por ejemplo, se trata de medir una estrella variable de muy corto periodo, un “Near-Earth Asteroid” que se desplazan a gran velocidad, una ocultación producida por un cuerpo del sistema solar, etc.
Los aficionados frecuentemente emplean ordenadores para controlar cámaras qué capturan imágenes a partir de las cuales se van a realizar las medidas de fotometría o astrometría mediante el correspondiente proceso de reducción, y el tiempo asociado a las imágenes se toma de la hora del ordenador. Sin embargo, el reloj de los ordenadores suele tener importantes derivas que generan falta de precisión en el tiempo asociado a las capturas.
Lo habitual es que un ordenador se configure para sincronizarse automáticamente a través del servicio NTP (Network Time Protocol) cada cierto tiempo. Por ejemplo, en el caso de Windows 7 esto se configura mediante la utilidad Fecha y Hora, en la solapa de “Hora de Internet”. Una solución que aporta una sincronización más precisa y que utilizan muchos aficionados es el software freeware Dimension 4. Pero con estas opciones los errores estarán del orden de varias décimas de segundo, que en algunas aplicaciones será suficiente, pero en otras no nos aportará el nivel de precisión que necesitamos. El problema fundamental está relacionado con el hecho de que la sincronización con servidores externos plantea dos aspectos que afectan al proceso: la propia precisión de los servidores (nivel o stratum que se explica a continuación) y la latencia de las comunicaciones (los retrasos difícilmente predecibles entre nuestro ordenador y el servidor horario de los datos que viajan en su camino a través de las redes de telecomunicación).
Es importante conocer el concepto de “stratum” (nivel) del servidor horario. Un servidor stratum 1 está sincronizado con un reloj local muy preciso, por ejemplo, atómico o GPS. Un servidor stratum 2 está sincronizado con un servidor stratum 1, un servidor stratum 3 se sincroniza con un servidor stratum 2, y así sucesivamente.
Volviendo a los dos problemas que afectan a la sincronización, el stratum y la latencia, lo ideal sería poder tener en la red local de nuestro ordenador (u ordenadores) un servidor stratum 1, ya que no tendremos apenas retrasos en la comunicación entre nuestros ordenadores y el servidor horario y además éste estará sincronizado con un reloj local de alta precisión. Parece fácil decirlo, pero es que además es fácil hacerlo y en este documento se describe cómo, consiguiendo sincronización horaria con precisión mejor de 1 ms.
Servidor stratum 1 para nuestro observatorio astronómico
Para construir un servidor stratum 1 para nuestro observatorio astronómico, necesitamos estos elementos:
-
Placa Raspberry PI. Yo he utilizado la Raspberry PI 3 que en Amazon se encuentra por unos 35€.
-
Caja para Raspberry por unos 5€ en Amazon
-
Fuente de alimentación para la Raspberry PI, unos 10€ en Amazon.
-
Tarjeta micro SD de 8GB, unos 4€ en Amazon.
-
Placa GPS para integrar en la Raspberry PI de Uputronics, más la antena exterior, conjunto que se vende por unas 39 libras en https://store.uputronics.com/index.php?route=product/product&product_id=81
-
Cable Ethernet
Reunidos todos estos elementos, los pasos a seguir son los siguientes:
Grabación de la micro SD
Grabar en la micro SD la imagen con el sistema operativo de la Raspberry. Yo he utilizado la imagen 2019-07-10-raspbian-buster-full.img que puede encontrarse en:
https://www.raspberrypi.org/documentation/installation/installing-images/
Hay varios programas accesibles en la web para grabar una imagen en un disco a partir de un fichero con extensión img. Yo he utilizado BalenaEtcher, disponible para Mac y Windows.
Ensamblado de los elementos
El ensamblado es muy sencillo. Solamente tenemos que insertar la micro SD una vez grabada en la Raspberry, colocar la placa GPS en el conector de tiras de pines de la Raspberry fijándola con los tornillos que se suministran.
Para ubicar este conjunto en la caja se requiere un poco de bricolaje, ya que hay que hacer una abertura en el lateral para el conector SMA de la antena, y hacer un taladro en la tapa superior para que el led de la placa GPS se vea una vez que ésta se coloque en su sitio. Para que la tapa inferior y superior encajen se precisa también algunos cortes en el plástico allí donde los tornillos de fijación de la placa GPS no dejan que el cierre funcione correctamente.
Una vez colocado la Raspberry con la placa GPS en la caja, conectamos la antena y comprobaremos en unos minutos que el GPS funciona porque el led comenzará a parpadear una vez por segundo. Pero para esto la antena tendrá que estar colocada con visión del cielo para que el GPS pueda recibir los satélites necesarios.
Hay muchas soluciones de caja para el ensamblado, cada uno puede escoger la que más le guste, lo único importante es que conviene que el led del GPS esté visible como comprobación de que la señal PPS está funcionando correctamente.
Configuración de la Raspberry PI
El objetivo de este paso es configurar la Raspberry para que opere como un servidor horario stratum 1 con sincronización basada en GPS. El GPS que utilizamos tiene una importante funcionalidad y es que a través de un pin suministra una señal PPS (un pulso por segundo) basada en la señal recibida de los satélites, y que se va a utilizar para la sincronización local. Gracias a esta señal, el servidor horario se convierte en stratum 1.
Para el proceso de configuración se necesita un monitor con entrada HDMI, un teclado, un ratón y un cable HDMI. No he incluido esto en la lista de elementos para el servidor, porque se necesitan sólo temporalmente, y se puede utilizar para este proceso aquellos de los que se disponga para otro ordenador. Para eventuales futuras conexiones no será necesario porque dejaremos habilitada la conexión por SSH.
Insertamos al micro SD en la Raspberry, conectamos monitor, teclado, ratón y fuente de alimentación y accedemos al sistema operativo de la Raspberry. Conectaremos con un cable Ethernet a nuestro router por si el proceso de instalación requiere acceso a Internet.
Los pasos a seguir están bastante detallados en el siguiente enlace y llevan unos pocos minutos:
Como comentarios al proceso general, solo añadiré que en mi caso he preferido no activar la WIFI en la Raspberry y configurar una dirección IP fija para que el servidor horario esté accesible a través de la LAN de mi observatorio conectándola a un switch o a una boca libre en el router con un cable Ethernet.
Tras estas configuraciones, ¿qué hemos hecho en la Raspberry?.
Fundamentalmente:
-
Hemos activado el SSH. Esto nos servirá para conectarnos en el futuro a la Raspberry a través de Ethernet o WIFI, y tomar el control del Linux sin necesidad de colocar el monitor, teclado y ratón.
-
Hemos configurado la función PPS para que opere a partir de la señal recibida en el pin 18 en la GPIO de la Raspberry.
-
Hemos activado y configurado la función NTPD para que el equipo opere como un servidor horario basado en PPS. En la configuración se han añadido los servidores horarios que utiliza el servicio en combinación con la señal PPS generada localmente con el GPS. Se recomienda que escojas los de tu región, por ejemplo los que podemos encontrar aquí para España: https://wiki.bandaancha.st/Lista_de_servidores_NTP_stratum_1_en_España
Después de realizar la configuración, y esperando unos minutos podremos comprobar los resultados ejecutando el comando ntpq -p en la consola de comandos.
La siguiente captura es de la consola de mi Raspberry con el comando ntpq -p.
Es importante conocer los siguientes códigos referidos al carácter que antecede al nombre de cada servidor:
Space discarded due to high stratum and/or failed sanity checks.
“X” designated falseticker by the intersection algorithm.
“.” culled from the end of the candidate list.
“-“ discarded by the clustering algorithm.
“+” included in the final selection set.
“#” selected for synchronization but distance exceeds maximum.
“*” selected for synchronization.
“o” selected for synchronization, pps signal in use.
Hay que fijarse que PPS está encabezada por “o”: oPPS (0), lo que indica que la sincronización por PPS está funcionando. A continuación, vemos que ha seleccionado el servidor ntp2.wirehive.net (encabezado por “*”) que es un stratum 2 para aplicarle el ajuste del PPS del GPS. El servidor del Observatorio de San Fernando “hora.roa.es” ha participado en la selección (encabezado por “+”) pero en este caso no ha sido seleccionado a pesar de ser un stratum 1: son decisiones del algoritmo del servicio ntpq.
Con esta comprobación vemos verificado que nuestro servidor stratum 1 está funcionado correctamente.
Configuración de los PC’s de nuestra red local
Esta es la fase final, y hay que hacerla en todos los PC’s de nuestra red local (ya sean conectador por cable o por WIFI) para que usen la Raspberry como servidor horario.
El primer paso es sencillo, en el Panel de Control de Windows con la utilidad Fecha Hora, deshabilitaremos la sincronización NTP en la solapa de Hora de Internet. Si tenemos instalado Dimension 4, lo desinstalaremos completamente.
A partir de aquí el objetivo es instalar NTPD, y la forma recomendada es utilizar el instalador de Meinberg. Tal como se indica en la página de Meinberg: “Los paquetes NTP de Meinberg proporcionan un instalador GUI para Windows que instala el servicio NTP y los programas ejecutables asociados que han sido compilados a partir del código fuente NTP público original disponible en la página de descarga NTP en ntp.org”.
El instalador se puede encontrar en el siguiente enlace:
https://www.meinbergglobal.com/english/sw/ntp.htm
A fecha de hoy, Agosto 2019, la opción más adecuada es descargar el instalador: ntp-4.2.8p13-win32-setup.exe (3.81 MB) versión de 8 de Marzo del 2019.
Las siguientes indicaciones no pretenden ser una guía detallada, ya que hay bastante información al respecto en la web, pero son notas de mi experiencia durante la instalación en Windows 7.
Después de aceptar el acuerdo de instalación, seleccionar la carpeta y las opciones de paquetes que ofrece por defecto.
Marcar la casilla de crear una configuración inicial y seleccionar la región que corresponda:
Cuando pregunta si se quiere editar el fichero de configuración se debe indicar sí. Se abrirá en un editor el fichero ntp.conf y se debe añadir en la sección # Servers:
# Servers
server 192.168.1.207 minpoll 5 maxpoll 5 iburst prefer
(con la IP que corresponda a la Raspberry, en mi caso 192.168.1.207 que he configurado como IP fija)
Al añadir esta línea estamos especificando que sincronice usando nuestro servidor horario Raspberry cada 32s (el valor de 5 se refiere a potencia de 2: 2^5=32)
El servidor Raspberry debe ser el único que quede marcado como “prefer”, de esta forma estamos dando prioridad a nuestro servidor horario local stratum 1.
Dejar marcadas las casillas según la captura siguiente.
Cuando solicita un ID y clave, se puede mantener ntp como sugiere para el ID y poner la clave que se desee, por ejemplo, ntpntp.
Comprobación del funcionamiento
Una vez terminada la instalación, esperamos unos minutos y en una pantalla de consola de comandos de Windows ejecutamos ntpq -pn y deberemos ver algo como lo siguiente:
Podemos comprobar que la Raspberry (IP 192.168.1.207) está seleccionada para sincronización (* por delante) y se reconoce como stratum 1 (st 1).
Los valores de offset y jitter están por debajo del milisegundo (offset nos indica la diferencia de tiempo con la fuente de sincronización y jitter la dispersión). El valor de jitter veremos que acaba estabilizándose en 0.977, que se corresponde con 1 ms para una resolución de 10 bits (1024), no bajando de este valor, aunque posiblemente el valor real si se representase con mayor resolución sería inferior).
He comprobado que estos valores de offset y jitter (tanto en equipos conectados por Ethernet como por WIFI) se mantienen siempre por debajo del 1ms, por lo que hemos conseguido nuestro objetivo: ya tenemos los PC’s de nuestro observatorio perfectamente sincronizados.