Come è noto, i moderni modi digitali weak signal (come FT8, WSPR, JT65, ecc.) richiedono un riferimento temporale estremamente preciso: uno scostamento anche di circa un secondo può compromettere completamente la decodifica dei segnali. le versioni più vecchio di Raspberry Pi sono prive di un orologio hardware (RTC) integrato e per recuperare l’ora esatta si appoggiano alla rete. Ma sia rPi 5 che  i PC tradizionali dispongono di un RTC al quarzo che, pur mantenendo l’ora quando il sistema è spento, è soggetto a deriva e non offre la precisione richiesta dai modi weak signal, quindi anche per queste piattaforme è necessario disporre di una sincronizzazione più precisa.

Per l’rPi , che nasce per l’uso mobile, ho quindi integrato un ricevitore GPS con lo scopo di rendere il sistema autonomo, ma preciso, E’ utilizzato sia per determinare la posizione geografica, sia come sorgente di riferimento temporale. In questo contesto è utile chiarire il ruolo del protocollo Network Time Protocol (NTP), che è il meccanismo standard utilizzato dai sistemi operativi per sincronizzare l’orologio. NTP funziona scambiando pacchetti con uno o più server remoti e stimando il ritardo di rete e la sua variabilità; in condizioni favorevoli può raggiungere precisioni dell’ordine dei millisecondi, ma la qualità del risultato dipende fortemente dalla stabilità della connessione. Su reti mobili o congestionate l’errore può aumentare sensibilmente, rendendo questo metodo non sempre adeguato per applicazioni radio che richiedono un timing rigoroso.

Per ottenere una precisione superiore è necessario ricorrere a una sorgente temporale hardware, come quella fornita dal segnale Pulse Per Second (PPS) presente in alcuni ricevitori GPS. Il GPS, infatti, non si limita a fornire dati di posizione, ma mette a disposizione anche un riferimento temporale assoluto derivato dagli orologi atomici dei satelliti. Tuttavia, il dato temporale trasmesso nel flusso seriale NMEA non è sufficientemente preciso a causa delle latenze introdotte dalla trasmissione e dall’elaborazione. Il segnale PPS risolve questo problema fornendo un impulso elettrico sincronizzato con estrema precisione all’inizio di ogni secondo UTC. In pratica, mentre il flusso NMEA indica che ora è, il PPS indica con grande accuratezza quando inizia il secondo, permettendo al sistema di allineare l’orologio con precisione dell’ordine dei microsecondi. Le due sorgenti sono quindi complementari: il PPS da solo non è sufficiente senza il contesto temporale fornito dall’NMEA.

Dal punto di vista software, il sistema si basa su gpsd – un sottositema specifico per la gestione del ricevitore GPS – e su chrony per la sincronizzazione dell’orologio di sistema. Chrony è particolarmente adatto a questo tipo di configurazione perché è in grado di combinare sorgenti diverse (NTP, GPS, PPS) e di gestire anche segnali intermittenti. Quando il PPS è disponibile e agganciato correttamente, viene utilizzato come riferimento primario (stratum 1), mentre il dato NMEA serve a fornire il contesto temporale necessario per interpretare correttamente il segnale PPS. In assenza del PPS, chrony continua a funzionare utilizzando il tempo derivato dal GPS via seriale oppure, se disponibile, da server NTP di rete.

Questa distinzione è particolarmente importante perché il sistema è disponibile in due varianti hardware con caratteristiche diverse. Nella mia versione basata su Raspberry Pi utilizzo un modulo GPS  VK-2828, collegato direttamente ai pin GPIO e dotato di uscita PPS. In questo caso il segnale viene acquisito a livello di kernel e consente a chrony di disciplinare l’orologio con precisione molto elevata, tipicamente nell’ordine dei microsecondi. Si tratta della configurazione ideale per l’uso con modi weak signal, in cui la qualità del riferimento temporale è critica. Da tenere presente che il modulo GPS risente del rumore EMI generato dal raspberry, se possibile è opportuno tenerlo distanziato almeno una decina di centimetri, o almeno frapporre fra il modulo e la scheda uno schermo, come un foglio di rame o di alluminio, per ridurre il degrado del segnale.

Nella versione amd64, invece, viene generalmente utilizzato un ricevitore GPS USB. Questi dispositivi, nella maggior parte dei casi, non rendono disponibile il segnale PPS, oppure lo fanno in modo non facilmente utilizzabile. Di conseguenza il sistema deve basarsi esclusivamente sul flusso NMEA ricevuto via USB, che è soggetto a buffering, latenza del driver e scheduling del sistema operativo. Questo introduce un’incertezza temporale significativamente maggiore: nella pratica, la precisione ottenibile si colloca tipicamente nell’ordine dei millisecondi, con possibili picchi nell’ordine delle decine di millisecondi in condizioni di carico elevato. Sebbene questo livello sia sufficiente per molti utilizzi, rappresenta comunque un limite rispetto alla configurazione con PPS e va tenuto in considerazione per applicazioni più esigenti. Nel caso di Ft8 questo non costituisce un problema, visto che il protocollo richiede una precisione di ±0,5 secondi (idealmente tra -0,1 e +0,25 s)

Quindi la logica di sincronizzazione è diversa per la versione rPi, in cui il segnale più affidabile è sempre quello PPS, e quella amd64, in cui in presenza di connettività internet il segnale NTP è generalmente più preciso di quello che arriva dal GPS senza PPS. Chrony comunque monitora in tempo reale le sorgenti di sincronizzazione disponibili e usa quella che garantisce la precisione migliore. Precisione che sia per GPS che per NTP è largamente migliore di quella necessaria ad effettuare connessioni con i modi che richiedono un riferimento temporale affidabile.

Il funzionamento del sistema è trasparente per l’utente, ma è comunque importante poter valutare rapidamente la qualità della sincronizzazione. A questo scopo ho sviluppato una piccola utility, gpsclock, che mostra l’ora UTC insieme ad altre informazioni utili come il locator Maidenhead, l’altitudine, il numero di satelliti, lo stato del fix GPS e soprattutto la sorgente attiva dell’orologio (PPS/GPS, NTP o clock locale). Questo consente di capire immediatamente se il sistema sta operando nelle condizioni ottimali.

Nella schermata viene visualizzata (1) l’ora UTC, (2) il locator calcolato dalle coordinate GPS, (3) la quota se il gps è in modalità 3D, (4) il numero dei satelliti visibili, (5) il modo operativo GPS, (6) la sorgente dell’orologio di sistema.

Per i più esperti che volessero avere delle analisi più approfondite è possibile utilizzare i comandi di diagnostica di chrony, come chronyc sources e chronyc tracking, che permettono di osservare nel dettaglio le sorgenti disponibili, gli offset temporali e la qualità della sincronizzazione. Inoltre, chrony è configurato per funzionare anche come server NTP sulla rete locale (192.168.0.0/16), permettendo ad altri dispositivi di sincronizzarsi utilizzando questo sistema come riferimento, anche in assenza di connessione Internet.

Infine, i dati del GPS sono resi disponibili sulla rete locale tramite gpsd sulla porta TCP 2947, così da poter essere utilizzati anche da altri dispositivi o applicazioni in rete.
Nel menu accessori è inoltre presente una voce xgps che consente di visualizzare in tempo reale tutte le informazioni dettagliate sullo stato del ricevitore, posizione, e dei satelliti visibili.

Il risultato è un sistema compatto e completamente autonomo, alloggiato in un contenitore stampato in 3D, capace di fornire sia un riferimento temporale di alta precisione sia dati di posizione affidabili.

In sintesi

Hamlinux può utilizzare un ricevitore GPS per mantenere ora e posizione precisi anche senza connessione internet. A seconda dell’hardware disponibile, la precisione dell’orologio può variare sensibilmente, ma la flessibilità della configurazione è in grado di soddisfare anche le applicazioni radio più esigenti.

Info