Matériel et câblage GNSS/PPS#

Pourquoi#

Deux signaux distincts arrivent du récepteur GNSS, et ils n’ont pas le même rôle : le flux série (NMEA) donne une heure approximative avec une latence variable de plusieurs dizaines de millisecondes, tandis que l’impulsion PPS (Pulse Per Second) marque le top exact de la seconde avec une précision de l’ordre de la dizaine de nanosecondes. Câbler les deux correctement, et comprendre pourquoi les deux sont nécessaires, est le prérequis de tout le reste.

Matériel nécessaire#

ComposantRéférence indicativeRôle
SBCRaspberry Pi 5 (4 ou 8 Go)Compute
Récepteur GNSSu-blox NEO-M9N (UART + PPS)Référence de temps
Antenneactive, connecteur SMARéception des signaux satellites
Câble antennecoax 50 Ω, longueur connueDélai de propagation ≈ 5 ns/m à compenser si possible dans la configuration du récepteur GNSS
StockagemicroSD A2 ≥ 32 Go, ou SSD/NVMeSystème ; les journaux sont en RAM (tmpfs)
RéseauRJ45NTP/NTS, horodatage matériel
Refroidissementventilateur PWMStabilité thermique de l’oscillateur

Rien de plus n’est nécessaire pour un Stratum 1 fonctionnel, pas de HAT, pas de bus I2C utilisateur, pas d’horloge d’affichage externe.

Le matériel de ce serveur#

Le tableau ci-dessus reste volontairement générique : n’importe quel récepteur exposant NMEA + PPS et n’importe quelle antenne active SMA conviennent. À titre d’exemple, voici les modèles exacts retenus sur ce serveur.

ComposantModèle exactPoints clésPrix indicatif
SBCRaspberry Pi 5, 8 GoSoC BCM2712 (quad Cortex-A76 à 2,4 GHz), GPIO 40 broches, PHC sur le contrôleur réseau~ 80 €
Récepteur GNSSSparkFun GPS Breakout NEO-M9N, réf. GPS-17285u-blox NEO-M9N à TCXO interne, 4 constellations, UART + PPS (timepulse), connecteur SMA~ 70 €
Antenneu-blox ANN-MB-00active multibande L1 + L2/E5, gain LNA 28 dB, câble de 5 m, SMA mâle, base magnétique, IP67~ 50€
Boîtieranidees aluminium extra-haut (AI-PI5-SG-H)dissipation passive par l’aluminium, place pour un HAT, ouïes d’aération~ 30€
StockagemicroSD SanDisk MAX ENDURANCE 32 Gogamme haute endurance conçue pour l’écriture continue~ 20 €
Pile RTCbatterie RTC Raspberry Pi (rechargeable)maintient l’heure hors tension, rechargée en continu par le Pi~ 5 €

Soit un total de l’ordre de ~ 250 €, alimentation et frais de port non compris.

Trois de ces choix ne sont pas neutres pour un serveur de temps :

  • L’antenne ANN-MB-00 est multibande (L1/L2) alors que le NEO-M9N n’exploite que la bande L1 : la compatibilité descendante joue, on gagne surtout la robustesse (IP67, base magnétique, câble de 5 m) pour une pose derrière une fenêtre ou en extérieur, sans surcoût déraisonnable. Cette antenne n’est pas compatible officiellement avec la bande L5.
  • Le boîtier aluminium dissipe passivement, ce qui aide à figer le point de fonctionnement thermique du quartz (chapitres Stabilisation thermique et Du quartz nu au pseudo-TCXO) ; le ventilateur PWM vient s’y ajouter.
  • La carte MAX ENDURANCE est dimensionnée pour l’écriture continue : c’est une sécurité complémentaire du choix de mettre les journaux en tmpfs (chapitre Système de fichiers), qui réduit déjà l’usure de la carte.

Le récepteur GNSS doit exposer à la fois une sortie série (NMEA) et une broche PPS matérielle séparée. Un récepteur USB “tout-en-un” sans PPS exposé ne permettra jamais d’atteindre une précision microseconde : le port USB introduit lui-même une latence variable de plusieurs millisecondes.

Comment : le câblage#

Montage réel du serveur : Raspberry Pi 5 et carte GNSS NEO-M9N dans le boîtier aluminium.
Le montage réel de ce serveur. Sous la carte rouge SparkFun (module u-blox NEO-M9N-00B visible) se trouvent le Raspberry Pi 5 et son ventilateur ; le récepteur est relié au GPIO par quelques fils (PPS (bleu), UART (TX:blanc/bleu), 3V3 (orange), GND (blanc/orange)). Le coaxial noir est relié sur l'antenne active par le connecteur SMA, tandis que l'Ethernet (câble noir) et l'alimentation officielle (câble blanc) complètent l'ensemble. Le câble bleu est un bus I2C dédié à un affichage, hors du périmètre de ce guide, visible sur la photo mais sans rôle dans ce serveur. Aucune modification matérielle du Pi.

Le schéma ci-dessous détaille les liaisons.

┌──────────────────────┐                      ┌────────────────────────────────┐
│    u-blox NEO-M9N    │                      │         Raspberry Pi 5         │
│   (récepteur GNSS)   │                      │       (GPIO, 40 broches)       │
│                      │                      │                                │
│                  TX  │─────────────────────►│ GPIO15 / RXD0 (ttyAMA0)        │
│                  RX  |                      | GPIO14 / TXD0                  │
│                 PPS  │─────────────────────►│ GPIO4  (pps-gpio)              │
│                 GND  │──────────────────────│ GND                            │
│                 VCC  │◄─────────────────────│ 3V3                            │
│                      │                      │                                │
│ [SMA] antenne active │                      │                                │
└──────────────────────┘                      └────────────────────────────────┘
  • TX (UART, ttyAMA0) : transporte les trames NMEA/UBX (position, date approximative). C’est ce flux qui permet de savoir quelle seconde vient de sonner.
  • PPS (GPIO 4) : une impulsion électrique par seconde, alignée sur le front montant de la seconde UTC. C’est elle qui donne la précision.
  • Alimentation en 3,3 V, jamais en 5 V : les GPIO du Pi ne tolèrent pas le 5 V en entrée.

Le kernel Linux traite le PPS via le module pps-gpio, qui déclenche une interruption matérielle (IRQ) à chaque front montant et expose le résultat sur /dev/pps0. Ce point est développé au chapitre Acquisition GNSS/PPS.

Erreurs à éviter#

  • Inverser TX et RX. Erreur classique : le TX du récepteur va au RX du Pi, pas à son propre TX. Si ttyAMA0 ne reçoit rien, c’est la première chose à vérifier.
  • Câble antenne trop long sans compensation. Le signal radio se propage à ~5 ns/mètre dans un câble coaxial. Sur quelques mètres, l’effet est négligeable ; au-delà, chrony permet de compenser ce délai explicitement (directive offset du refclock PPS, cf. chapitre Chrony), mais il faut d’abord mesurer la longueur réelle du câble.
  • Antenne mal placée. Une antenne GNSS a besoin d’un ciel dégagé. Derrière une vitre orientée vers le ciel ouvert, ça fonctionne correctement (c’est le cas en production sur ce projet) ; enfermée dans un boîtier métallique ou au sous-sol, non.
  • Oublier la pile de sauvegarde RTC. Si le Pi utilise une horloge temps réel embarquée à pile (RTC), celle-ci doit être connectée avant le premier démarrage pour bénéficier de la charge automatique, sinon l’horloge repart de zéro à chaque coupure d’alimentation, ce qui retarde l’acquisition du premier fix GNSS après reboot.

Vérifier#

Avant même d’installer quoi que ce soit côté logiciel, deux vérifications physiques suffisent à ce stade :

  1. Continuité du câblage : à l’aide d’un multimètre, vérifier l’absence de court-circuit entre 3V3 et GND une fois le récepteur connecté, avant la première mise sous tension.
  2. Alimentation du récepteur : une fois le Pi démarré (avec un OS minimal, cf. chapitre suivant), le récepteur GNSS doit afficher une LED d’activité (selon modèle) dès qu’il capte des satellites, généralement quelques dizaines de secondes à quelques minutes en cold start.

La vérification logicielle complète (ppstest, gpspipe) est couverte au chapitre Acquisition GNSS/PPS.


📚 Pour aller plus loin

  • Le signal PPS des récepteurs u-blox modernes est aligné sur la transition de seconde UTC avec une précision de ±10 à 30 ns (spécifications constructeur u-blox NEO-M9N).
  • La latence des trames NMEA en liaison série (UART 9600 bauds) est de l’ordre de ±10 ms, non-déterministe car dépendante de la charge CPU et du buffer UART, ce qui justifie structurellement la nécessité du PPS pour toute précision meilleure que la milliseconde. Voir Michael A. Lombardi et al. (NIST), Time and Frequency Measurements Using the Global Positioning System (GPS), 2001, sur la latence des interfaces série face au signal PPS matériel.
  • Le format des trames de navigation GPS L1 C/A (débit 50 bits/s, trame de 30 s) est spécifié dans IS-GPS-200 (Interface Specification, dernière révision N).
  • Documentation constructeur du matériel de ce serveur : NEO-M9N Data sheet (UBX-19014285) et son Integration manual (UBX-19014286, via le portail u-blox) ; antenne ANN-MB Data sheet (UBX-18049862) et Product summary (UBX-18047741) ; carte SparkFun et son hookup guide.