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#

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 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#

┌──────────────────────┐                      ┌────────────────────────────────┐
│    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/RX (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).