Un NTP con precisión GPS

Los sistemas GNSS, (GPS) necesitan patrones de tiempo muy exactos por lo que usan relojes atómicos. Así que si disponemos de un receptor de GNSS activo en nuestro sistema parece bastante lógico usarlo para sincronizar un servidor de tiempos  

No debemos confundir el protocolo NTP (Network Time Service) con el servidor ntp para linux que puede ser: ntp,  open-tpd o chronyd (Este último es el mas reciente).

Además debe familiarizarse don PPS (Pulse-Per-Second) y PTP ( Precision Time Protocol ).

El comando de dragonOS/ubuntu timedatectl nos dice el dia de la semana, fecha, hora y si hay algun servidor NTP activo en el sistema

Partiendo de nuestra instalación que tenemos funcionando Xiaomi A2 + NMEA over network  & Raspberry Pi 3 B + dragonOS (ubuntu) + gspd  vamos a arrancar un NTP e intentar que reciba los datos gps de gpsd

chrony

Se ha elegido como primera opcion chrony por ser el desarrollo más moderno de un programa NTP
  • sudo apt update  (OK)
  • sudo apt upgrade (OK)
  • sudo apt install chrony (chrony es una implementación flexible del protocolo NTP.  chronyc – interfaz de línea de comandos para chrony, chronyd – es el daemon que puede iniciarse en el momento del arranque del host)
  • sudo apt install pps-tools gpsd-clients  para pruebas
  • Verificar que la versión de gspd es al menos la 3.22. Para ello teclear en un terminal (gspd -V)
  • Conectar el dispositivo gps (En nuestro caso arrancar NMEA Over Network en el teléfono móvil y comprobarlo con gpsdmon; si no va reinicie ambos dispositivos)
  • sudo systemctl start chrony.service => arranca el servicio
  • sudo systemctl stop chrony.service => para  el servicio
  • sudo systemctl restart chrony.service => rearranca el servicio
  • sudo systemctl status chrony.service => muestra los errores del arranque
  • systemctl is-active chronyc  => active  si está activo  o inactive si está inactivo
  • chronyc tracking  Para comprobar que funciona chronyc, indica el servidor NTC, el tiempo del mismo, la diferencia con el tiempo local
  • chronyc sources =>  Las dos primeras columnas indican M ( ^ servidor, =  peer y  # local) y S ( “*” sincroniza  “+” se acepta para combinar  “-” se rechaza apra combinar,  “?” conexión perdida) y la tercera indica el nombre/IP de las fuentes o servidores NTP de los que recibe el tiempo. así en nuestro caso debe de ser "#* GPS"
  • chronyc sourcestats
  • sudo chronyc makestep fuerza la sincronización

Recuerde que Chrony siempre debe arrancar antes que gpsd, por lo que si rearranca chronny debe a continuación hacerlo con gpsd. 

Por algún motivo chronyd funciona recupera la informacion del pool de servidores NTP, etc.  no es capaz de recuperar la información de gpsd, pese ha que se han probado multiples configuraciones del parametros  como SOCK  y cp,p PPS SHM1 que se definen en  /etc/chrony/chrony.conf las ultimas aquí:

refclock SOCK /var/run/gspd.sock delay 0.0. refid PPS  
refclock SHM1  offset 0.0 delay 0.1. refid PPS  

NTP

Despues de no conseguir que chrony cumpliera con las expectativas  puestas en él  para este proyecto pasamos a  probar con NTP
  • sudo apt update  (OK)
  • sudo apt upgrade (OK)
  • sudo apt install ntp
  • Modificar el fichero de configuracion /etc/ntp.conf incluyendo las siguientes líneas
# GPS Serial data reference (NTP0) 
server 127.127.28.0 
fudge 127.127.28.0 time1 0.9999 refid GPS 
# GPS PPS reference (NTP1) 
server 127.127.28.1 prefer 
fudge 127.127.28.1 refid PPS
  • sudo systemctl start ntp.service => arranca el servicio
  • sudo systemctl stop ntp.service => para  el servicio
  • sudo systemctl restart ntp.service => rearranca el servicio
  • sudo systemctl status ntp.service => muestra el log de arranque y por tanto los errores del arranque si los hubiera
  • systemctl is-active ntp  => responde active  si está activo  o inactive si está inactivo
  • sudo ntpshmmon => nos indica si gpsd  está enviando por memoria  SHM  los datos , se sale con CTRL-C
  • ntpq -p => muestra los servidores NTP de los cuales recibe datos 
  • ntptime => da informacion de los errores del reloj etc.
  • ntptrace => muestra la sincronización en tiempo real del reloj
  • ntpdate <nombre servidor> => para una sincronizacion  en el momento
    • sudo ntpdate 0.ubuntu.poolntp.org
  • sudo date --set "YYYY-MM-DD HH:MM:SS" por si necesita poner la fecha  y la hora a mano
  • timedatectl set-time HH:MM:SS por si necesita poner la hora a mano
  • timedatectl set-timezone Europe/Madrid  por si necesita poner la zona horaria a mano
Comando ntpq -p que nos muestra que se están obteniendo datos a través de la memoria compartida de gpsd. Observe el distinto St (stratus) de los servidores, a mayor valor, menos precisión. a nadie se le escapa el "jitter" o retardo de la señal del GPS.

  • date => comando  proporciona la hora del sistema
  • date  -u => comando  proporciona la hora del sistema en tiempo universal UTC
  • timedatectl o  timedatectl status  o timedatectl show=> nos dice si el reloj del sistema está sincronizado con NTP  "system clock synchronized= yes/no" y "NTP service= n/a"
  • ntpstat => nos indica que se comunica con el servidor de tiempo, si no está en el sietma se puede instalar como siempre sudo apt install ntpstat
ntpstat nos indica que el servidor NTP se ha sincronizado con la señal GPS que le ha suministrado GPSD "Synchronised to UHF radio at stratum 1" 

El Stratum 1 indica que obtiene la señal de un GPS o reloj atómico STratum 0, frente a los servidores de tiempo que son stratum 2 y 3

Seguramente se ha fijado que en los ficheros de configuración de los servidores NTP en lugar de servidores concretos, o ademas de estos aparecen otros del tipo "pool 0.ubuntu.pool.ntp.org" que realmente invocan al pool de NTP que en la actualidad engloba a cerca de 5.000 servidores lo que asegura una alta disponibilidad a fallos y ataques. Auneuq disponer de un NTP propio como el qu hemos configurado es la opción mas razonable en tiempos revueltos.


RESUMEN

Hemos conseguido que nuestro ordenador (Raspberry pi model 3B con dragonOS) tenga el tiempo sincronizados con los relojes atómicos de los sistemas GNSS (GPS), es decir la mejor calidad posible (Stratum 0)  cuyas señales estamos recibiendo en un teléfono móvil (Xiaomi Mi A2 Androd 9) que envia a través de la Wi-Fi (mediante mensajes UDP con formato NMEA) al proceso GPSD que le pasa la información al NTP (Seguramente con Chrony también se podrá pero no hemos sabido hacerlo). 

Para leer mas

Referencias

Prohibida la reproducción parcial o total de este artículo sin permiso previo del autor

Comentarios

Publicar un comentario

Entradas populares de este blog

SDR - Software Defined Radio - IIIb: Receptores RSP o MSI (MSI3001: MSI2500 + MSI001)

Imagen
Los receptores SDR del tipo RSP (por la denominación de los modelos originales) o MSI  por el empleo de los circuitos integrados MSI2500 (procesador de señal) y MSI001 (sintonizador) son menos populares que los basados en los receptores RTL-SDR (RD828D/R860/R820T2 y RTL2832U) . Sin embargo presentan varias características que los hacen muy atractivos: Trabajan a partir de los  1-10 kHz de forma nativa, los RTL-SDR lo hacen a partir de los 300 - 500 kHz y además hasta los 20-30 MHz de forma directa (canal Q). En algunos modelos disponen de entradas diferenciadas de RF según la banda de frecuencia a sintonizar (1, 2, 3 ó 5) con conmutación interna automatica o externa manual. Disponen de un ancho de banda de IF de hasta 10 MHz (Los RTL-SDR hasta los 2,4 MHz) Digitaliza las señales con hasta 14b  (Los RTL-SDR hasta 12b) Por contra presentan dos inconvenientes: Menor software disponible (SDRuno / SDRConnect y SDRAngel) Mayor precio de los modelos originales  MSI (SDRPlay) en comparación c
Leer más

Ayudas a la navegación aerea: NDB, VOR, ILS y ATIS

Imagen
NDB El NDB (Non-Directional Beacon) o baliza no direccional es un sistema de radiofaro en el cual el equipo de tierra emite una señal de radio omnidireccional (en todas direcciones) de frecuencia fija, las frecuencias asignadas al NDB están comprendidas entre 190 y 1750Khz.    Los NDB transmiten en AM (Portadora y doble banda lateral) como todas las comunicaciones aéreas, y incluye un código de la estación codificado en alfabeto MORSE.   Cuando un receptor dotado de goniómetro sintoniza un radiofaro NDB es capaz conocer la dirección y el sentido en el que se encuentra, si sintoniza dos o mas la posición exacta, y de forma derivada la velocidad y otras variables.   Desde Valencia con   SDRuno  (BW:1500 kHz Decimation:32),  RSP1 y YouLoop 6m se reciben los siguientes radiofaros aéreos:       340 kHz PND  356 kHz SGO  (... --. ---)Tipo: NDB Localización: Valencia (Sagunto)  S= -102 dBm SN= 10 dB 362 kHz EBT  (. -... -) Tipo: NDB Localización: Valencia (Betera) S= -109 dBm SN= --   380
Leer más

Por una montaña más segura

Imagen
Tenemos una falsa seguridad en  los  teléfonos móviles. Quién haya salido con alguna frecuencia a la montaña o al campo abierto sabe que fuera de los núcleos urbanos no hay datos, y cuando uno se adentra un poco en el campo o en la montaña deja de haber cobertura y está aislado del mundo, lo que popularmente se conoce como "estar vendido". Las bandas de telefonía móvil van de los 800 a los 3.500 MHz que trabajan bien en entornos urbanos pues se reflejan con facilidad (rebotan) pero que difícilmente pueden propagarse en caso de obstáculos como montañas, por lo que puede asimilarse a un alcance visual. Sin cobertura de ninguna compañía de telefonía no se puede llamar al 112, y por tanto no es posible pedir ayuda. Esta serie de entradas sobre radiocomunicación y seguridad en la montaña intentan informar de los sistemas actuales y analizar su funcionamiento y posibles alternativas en aras de que si desgraciadamente se produce una emergencia que pueda informarse de ella para su r
Leer más