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

Antena exterior logarítmica UHF/VHF : Metronic 425010 - Ia Características

Imagen
  Caracteristicas teóricas Marca: Metronic  Modelo: 425010  Tipo: LPDA -  Array de Dipolos Logaritmicos Periódicos Numero de elementos: 32 MateriaL: acero Largo: 1.160 mm Elemento mas largo: 435 mm => 172,413 MHz Elemento más corto: 65 mm => 1.153 MHz Peso 0.8 kg Ancho de banda:  170-860 MHz 170-230 MHz 470-862 MHz  Ganancia  UHF 9/10dB VHF 8dB Disponible en mano a mano por 25 €  y en  Amazon por 25€ Especificaciones Descripción En las antenas LPDA hay un elemento activo y por delante del mismo todos lo están y por detrás del mismo hay uno o dos pero en menor medida. Como en todas las antenas logaritmo periódicas en el extremo de los radiadores mas cortos (punta) se une uno de los soportes con la malla del coaxial y el otro con el vivo, y en el extremo trasero se unen ambos soporte. Detalle del extremo de los radiadores. Se tratan de varillas de 4mm de acero tratado ¿? con la  arandela de resorte que se traba con una muesca del radiador y la arandela con una tuerca que se atornil
Leer más

ESP32 LoRa for dummys - Inicio

Imagen
Un ESP32 - LoRa no es un electrodoméstico que se enchufa y funciona, al contrario es un dispositivo que para que funcione se tiene que configurar y programar,  a través de ordenador y un software específico como un IDE (entorno integrado de desarrollo). Pero en elloe stá la gracia, pues resolviendo los problemas que se vayan planteando a lo largo de este proceso aprenderá de hardware, de software, de progrmación, ..., que es lo que en el fondo pretende esta guía, aprender de forma divertida.  1- ADQUIRIR EL HARDWARE     Lo primero que se necesita es comprar una placa de desarrollo ESP32-LoRa.      Una placa de desarrollo contienen además del microprocesador ESP32 diversos elementos que permiten que trabaje de forma autónoma, lo cual le evita muchos quebraderos de cabeza. Al procesador (ESP32) y a los de protocolos de comunicación que suele llevar la placa por defecto (USB-SERIE, BLUETOOTH y Wi-Fi) le añadimos LoRa) aunqee también hay la opción de incorporar la recepción de GPS, pero ¿Q
Leer más