Intégration matérielle du TrueTime

Le boîtier original de 1995 abrite un affichage LCD 16x2 et une LED bicolore. Jeff Geerling a conservé ces éléments et les a reliés à un Raspberry Pi 5 4 Go via le connecteur GPIO. Le GNSS L1 HAT de Jimmy Paputto, équipé d’un récepteur u‑blox NEO‑M9N, se fixe sur le Pi grâce à un support en aluminium fourni avec le châssis. Le montage inclut un dissipateur thermique, un ventilateur réglé à 50 % de cycle, et une isolation thermique du bas du Pi où se trouve le cristal d’oscillateur, afin de réduire les dérives de fréquence liées aux variations de température.

Le Pi utilise le système d’exploitation Raspberry Pi OS « Lite », flashé sur une carte micro‑SD. Aucun environnement graphique n’est installé, ce qui minimise la charge CPU et préserve la stabilité du signal PPS (Pulse‑Per‑Second) fourni par le HAT via le port /dev/pps0.

Chaîne logicielle et configuration Chrony

Le logiciel du HAT est compilé à partir des sources GitHub : 

sudo apt -y install build-essential cmake libgpiod-dev python3-dev
git clone https://github.com/jimmypaputto/gnsshat.git
cd gnsshat
mkdir -p build && cd build
cmake .. -DBUILD_PYTHON=ON -DBUILD_EXAMPLES=ON
make -j$(nproc)
sudo make install
Cette compilation crée un pont qui transmet les trames NMEA à gpsd, puis à chrony via la mémoire partagée.

Le fichier /etc/chrony/chrony.conf contient les lignes essentielles suivantes : 

# GNSS + PPS time server
refclock SHM 0 offset 0.0 delay 0.05 refid NMEA noselect
refclock PPS /dev/pps0 refid PPS lock NMEA prefer trust poll 3 filter 16
maxclockerror 0.5
hwtimestamp *
pool 0.pool.ntp.org iburst
pool 1.pool.ntp.org iburst
allow 10.0.0.0/16
allow 172.17.0.0/16
maxupdateskew 100.0
makestep 1000 3
rtcsync
maxchange 0.1 1 -1
Les deux références de temps – SHM (gpsd) et PPS – offrent une redondance : le PPS fournit une précision de l’ordre de la centaine de nanosecondes, tandis que le flux NMEA assure la correction de l’offset de secondes.

Les paramètres maxclockerror 0.5 et hwtimestamp * indiquent à Chrony de considérer le Pi comme un horloge matérielle de haute précision, ce qui est crucial pour un serveur de niveau stratum 1.

Optimisations de stabilité du Pi

Le Pi 5 possède un oscillateur à quartz (XO) qui n’est pas un TCXO. Pour limiter les variations de fréquence, l’auteur a activé force_turbo=1 dans /boot/firmware/config.txt, maintenant le processeur à 2,4 GHz en continu. Cette contrainte augmente la consommation d’environ 1 W mais évite les sauts de fréquence qui déstabiliseraient le compteur de temps.

Le ventilateur tourne à un régime constant (≈50 % de cycle) afin d’éliminer les fluctuations thermiques rapides. L’isolation du bas du Pi, où le cristal est monté, réduit les gradients de température, ce qui se traduit par une dérive mesurée de moins de 0,5 ppm sur des intervalles de 6 à 12 heures.

Enfin, les interruptions PPS sont isolées sur le cœur 3 (CPU 3) grâce à l’affinité CPU du noyau Linux. Cette isolation minimise la latence d’interruption, qui dans le meilleur des cas reste de l’ordre de quelques centaines de nanosecondes, bien en dessous du jitter acceptable pour un serveur NTP de référence.

Évaluation des performances et limites

Après plusieurs jours de suivi avec chronyc sources -v et chronyc tracking, la dérive moyenne du serveur est restée sous 0,2 ms, avec un offset maximal de 0,8 ms lors de redémarrages du service. Le serveur répond aux requêtes LAN (10.0.0.0/16) et aux clients traversant Twingate, prouvant la viabilité d’une solution « DIY » dans un environnement professionnel.

Les limites proviennent principalement du quartz du Pi 5 : sans TCXO, la stabilité à long terme (plusieurs jours) reste inférieure à celle d’un module dédié PHC. De plus, la dépendance à l’alimentation continue du HAT et du Pi impose une gestion de l’alimentation fiable, sinon la batterie RTC (ML2020) ne garantit qu’une marge de quelques secondes après une coupure prolongée.