Quatrième Partie
Découverte la réception SDR sous Raspberry Pi OS
J’ai écrit cette suite d’articles dans un but pédagogique afin d’aider tous ceux qui, comme moi, souhaitaient découvrir, en les pratiquant, les techniques de réception SDR. Les spécialistes du domaine trouveront sans doute quelques approximations et erreurs dans mes explications. J’espère qu’ils ne m’en voudront pas et qu’ils me contacteront pour que nous les rectifions ensemble par la suite. Je parle aussi, ici ou là, de difficultés ou de bugs, si certains les ont surmontés, qu’ils me contactent pour que nous mettions à jour ce document. S’ils ont aussi parfois de meilleures solutions d’installation ou d’utilisation, qu’ils n’hésitent pas à me l’écrire.
CONTACTEZ-MOI à l’adresse : f80543@gmail.com
Introduction
La réception des signaux émis par les radiosondes et la « chasse » qui peut s’en suivre sont deux activités passionnantes. Avec ce quatrième article, nous allons poursuivre l’utilisation des nano-ordinateurs Raspberry Pi et de leur système d’exploitation éponyme, pour voir comment il est possible de suivre ces objets en direct, de récupérer les points GPS de leur trajectoire et d’estimer celui de leur chute au sol.
Quoi décoder ?
Voici, mis à jour, le tableau présentant un aperçu des décodages traités dans cette série d’articles. Les cases vierges dans la dernière colonne signifient que la réception sera traitée dans les mois qui viennent.
Exemples de radiosondes actuellement utilisées dans le monde (source illustrations : https://www.sciencedirect.com/topics/earth-and-planetary-sciences/radiosondes
La Raspberry Pi et ses accessoires (suite)
Réception radiosonde
La réception et la « chasse » aux radiosondes est une activité passionnante que nous allons maintenant détailler. Nous allons voir ici comment les suivre en direct, récupérer les points GPS de leur trajectoire et estimer celui de leur chute au sol.
Les segments de fréquences utilisés par les radiosondes sur l'Europe sont compris entre 400.05 MHz et 406.00 MHz.
De nombreux détails sur le radiosondage et la chasse aux radiosondes sont disponibles sur le site http://radiosonde.eu/.
Dans le secteur civil, les radiosondages sont effectués dans le cadre de programmes mondiaux qui permettent de fournir les données d'observation indispensables à la prévision journalière du temps. Les observations standard sont en théorie effectuées à 0000 et 1200 UTC, mais les heures de lancement réelles varient d'un pays à un autre et, dans certains cas, les mesures sont faites au moins quarante-cinq minutes avant l'heure théorique. Les lancements peuvent également avoir lieu jusqu'à deux heures après l'heure théorique, si des problèmes surgissent dans la préparation de la radiosonde avant le vol, si la réglementation du trafic aérien d'un pays limite les heures de lancement ou si une défaillance se produit pendant le vol initial. Par ailleurs, certains pays procèdent régulièrement à des observations intermédiaires à 0600 et 1800 UTC.
Source : https://www.itu.int/dms_pubrec/itu-r/rec/sa/R-REC-SA.1165-1-199706-S!!PDF-F.pdf
Si vous vous connectez en début d’après-midi sur le site sondehub.org vous verrez plus d’une dizaine de radiosondes, en vol au-dessus du territoire français.
Site https://tracker.sondehub.org/ (précurseur de https://v2.sondehub.org/ - capture de mars 2021)
Nombre de ces radiosondes sont du modèle M10, fabriquées par la PME française Météomodem, mais bien d’autres existent. Sous Raspberry Pi OS, le logiciel radiosonde_auto_rx est à même de décoder nombre de leurs signaux. Sous Windows, c’est le logiciel SondeMonitor qui est souvent préconisé ; même si MultiPSK est là aussi au rendez-vous.
Site https://tracker.sondehub.org/ (précurseur de https://v2.sondehub.org/ - capture de mars 2021)
Radiosonde_auto_rx sous Raspberry Pi OS
Le logiciel radiosonde_auto_rx cité plus haut est un logiciel Python disponible ici :
https://github.com/projecthorus/radiosonde_auto_rx/wiki. Il fait partie du Projet Horus, un projet de radioamateur spécialisé dans les radiosondes à haute altitude en Australie.
La clé RTL-SDR étant fonctionnelle, son installation se fait de la manière suivante :
- Mises à jour, installation de Python et des dépendances nécessaires à l’application, récupération de paquets :
- sudo apt-get update
- sudo apt-get upgrade
- sudo apt-get install python3 python3-numpy python3-setuptools python3-crcmod python3-requests python3-dateutil python3-pip python3-flask sox git build-essential libtool cmake usbutils libusb-1.0-0-dev rng-tools libsamplerate-dev
- Installation de radiosonde_auto_rx:
- git clone https://github.com/projecthorus/radiosonde_auto_rx.git
- cd radiosonde_auto_rx/auto_rx
- ./build.sh
- cp station.cfg.example station.cfg
- Récupération de paquets complémentaires
- sudo pip3 install -r requirements.txt
- Ajustement des paramètres dans le fichier de configuration (cfg) :
- sudo nano station.cfg
Préalablement à une première ouverture du logiciel, et sans envoi de données vers un site distant, il est à cet instant simplement nécessaire d’ajuster les bornes de fréquences ([search_params] -> min_freq / max_freq) aux valeurs européennes.
radiosonde_auto_rx : optimisation du fichier station.cfg
Le programme se lance ensuite (depuis son répertoire) :
- cd radiosonde_auto_rx/auto_rx
- python3 auto_rx.py
Premier lancement de radiosonde_auto_rx
Après quelques tests, j’ai également blacklisté dans le fichier station.cfg la fréquence parasite 403.2 MHz (never_scan [403.2]) spécifique aux configurations utilisant un tuner R820T.
Dès qu’un signal valide est détecté, les données relatives à la sonde sont affichées à l’écran et, en fonction des options d'exportateurs activées (SondeHub, APRS, OziPlotter), s’y ajoutent les informations liées à leurs retransmissions.
Réception de signal avec radiosonde_auto_rx
Une interface Web permet l’affichage d’une carte de position pour les sondes repérées par le logiciel. On y accède à l’aide de son navigateur Internet à l’adresse : http: // localhost: 5000.
Divers réglages et informations de journalisation sont disponibles depuis cette page.
Suivi en local de la radiosonde détectée par radiosonde_auto_rx(/p>
On notera qu’en version v1.5.3., à la première ouverture de l’interface web, un message d’erreur, apparemment sans conséquence s’affichait dans la fenêtre de radiosonde_auto_rx :
The WebSocket transport is not available, you must install a WebSocket server that is compatible with your async mode to enable it. See the documentation for details. (further occurrences of this error will be logged with level INFO)
A la mi-juin 2021 ; une recherche Internet semblait indiquer que cette alerte est générée par le paquet engineio (https://github.com/miguelgrinberg/python-engineio/blob/main/engineio/server.py, ligne 588). Un mois plus tard, Mark Jessop (alias darksidelemm, VK5QI) répondait sur la page issues (questions) dédiée à ce logiciel (https://github.com/projecthorus/radiosonde_auto_rx/wiki).
Message de Mark Jessop.
Testé ce 31 août 2021, la version v1.5.5 n’affiche plus l’erreur.
L’envoi des données collectées vers des sites collaboratifs se paramètre au sein du fichier station.cfg. Les captures d’écran présentées plus haut, montrent ainsi qu’elles sont, dans mon cas, envoyées vers les serveurs Sondehub et APRS-IS.
Pour Sondehub, aucune inscription préalable n’est nécessaire. Pour initier l’envoi, il faut simplement paramétrer en conséquence le fichier stationg.cfg cité plus haut :
- En entrant ses coordonnées géographiques (paragraphe Station Location),
- En changeant les paramètres du paragraphe Sondehub / Habitat (depreciated) Upload Setting :
- habitat_enabled = True
- uploader_callsign = MON_INDICATIF # un identifiant unique à créer ou à utiliser si nous en avons déjà un
- upload_listener_position = True
- uploader_antenna = discone
- sondehub_contact_email = f80543@gmail.com
Fichier station.cfg (Sondehub Upload Settings)
Une fois ces informations saisies, une visite sur le site https://v2.sondehub.org/ montre que notre station est reconnue et qu’elle a envoyé ses données à l’approche d’une sonde.
Reprise de mes données capturées sur le site sondehub.org
Pour joindre le site https://radiosondy.info/, la procédure d’inscription se fait ainsi :
- Inscription sur le site et vérification de ses informations https://radiosondy.info/user/edit_profile.php. Soyez vigilant à créer un nom d’utilisateur (callsign) en accord avec les règles du site (voir http://www.aprs-is.net/connecting.aspx#loginrules).
- Génération d’un mot-de-passe à associer à son « Call-sign » https://apps.magicbug.co.uk/passcode/.
Auto génération du mot-de-passe APRS
Mes informations sur le site radiosondy.info
- Modification de cfg (paragraphe APRS Upload Setting) :
- aprs_enabled = True
- aprs_user = F80543 # Mon identifiant sur radiosondy.info
- aprs_pass = 00000 # Le Mot de passe auto généré
- upload_rate = 30
- aprs_server = radiosondy.info
- aprs_port = 14590
- station_beacon_enabled = True
Les autres paramètres du paragraphe restent inchangés.
Fichier station.cfg (APRS Upload Setting)
Une fois ces étapes réalisées, et au passage d’une radiosonde vers votre QRA, le site en détaille le parcourt avec, ici en orange le réel et en jaune celui qui avait été estimé.
Site radiosondy.info
Mise à jour
Au fil du temps, l’application de certaines mises à jour majeures s’avère indispensable. Dans ce cas, un message d’alerte s’affiche au niveau du panneau de commande.
Message : radiosonde_auto_rx doit être mis à jour
La marche à suivre est disponible sur la page : https://github.com/projecthorus/radiosonde_auto_rx/wiki/Performing-Updates :
- sudo apt-get update
- sudo apt-get upgrade
- cd radiosonde_auto_rx
- cd auto_rx
- sudo systemctl stop auto_rx
- git pull[Git est un logiciel libre de gestion de versions de logiciel. git pull récupère les dernières modifications distantes du projet et les fusionne dans la branche locale]
- ./build.sh
Processus de mise à jour de radiosonde_auto_rx vers la version 1.5.0
Après avoir sauvegardé son fichier de configuration, il faut installer le nouveau puis le reconfigurer en y intégrant ses précédents paramètres[10] :
- cp station.cfg station.cfg.old
- rm station.cfg
- cp station.cfg.example station.cfg
- sudo nano station.cfg
Cette dernière commande ouvre l’éditeur de texte et permet de ré-entrer les paramètres.
Il est important de suivre la mise à disposition des mises à jour car le passage direct d’une version « n » à une version « n+2 » ou « n+3 » peut s’avérer périlleux.
Un beau matin, au lancement du logiciel, alors que j’étais en version 1.5.1. sont apparus des messages d’erreur dont je ne pus immédiatement trouver la cause :
- 2021-05-24 12:32:19,172 ERROR:Habitat - Unable to fetch UUIDs, retrying in 10 seconds - 'uuids'
- 2021-05-24 12:33:00,442 ERROR:Habitat - Gave up trying to get UUIDs.
- 2021-05-24 12:33:00,443 ERROR:Habitat - Unable to post listener data - no UUIDs available.
- 2021-05-24 12:33:00,443 ERROR:Habitat - Unable to initialize callsign.
Mes recherches sur Internet furent infructueuses. Je décidais finalement de lancer une procédure de mise à jour comme indiquée plus haut. Ceci fait je relançais le logiciel et je me retrouvais avec de nouvelles erreurs qui empêchaient, cette fois ci, le lancement du logiciel.
Message d’erreur au lancement de radiosonde_auto_rx version 1.5.3
J’eus plus de chance dans mes recherches. Sur Google, les termes radiosonde_auto_rx et import semver m’amenèrent à une information me spécifiant qu’il me fallait installer un nouveau paquet python :
- sudo pip3 install semver
Ce paquet installé, le logiciel se lança à nouveau. Je dus cependant recréer mon fichier de configuration station.cfg. Rien n’est vraiment simple ici !
Messages d’alertes au lancement de radiosonde_auto_rx version 1.5.3
Fichier station.cfg (V1.5.3.)
Voici, après configuration, le contenu de mon actuel fichier station.cfg expurgé de la plupart de ses commentaires. En gras et en rouge les changements par rapport au fichier original station.cfg.example :
###################
# RTLSDR SETTINGS #
#############
[sdr]
sdr_quantity = 1
[sdr_1]
device_idx = 0
# Rattrapage du calage de la clef
ppm = 0
# Gain de la clef, préférer une valeur fixe et maximale déterminée avec rtl_test
gain = -1
bias = True
[sdr_2]
# As above, for the next SDR, if used. Note the warning about serial numbers.
device_idx = 00000002
ppm = 0
gain = -1
bias = False
# Add more SDR definitions here if needed. ([sdr_3], [sdr_4])
##############################
# RADIOSONDE SEARCH SETTINGS #
##############################
[search_params]
# Debut de la bande à scanner
min_freq = 400.05
# Fin de la bande à scanner
max_freq = 406.0
# délais entre la dernière donnée décodée et le redémarrage du scanning
rx_timeout = 180
# scanne uniquement ces fréquences
only_scan = []
# Exclue systematiquement ces fréquences du scanning
never_scan = [403.2]
# Fréquences à scanner en priorité
always_scan = []
####################
# STATION LOCATION #
####################
# Lattitude du recepteur (utilisé pour Habitat et aprs)
station_lat = 44.xxxx
# Longitude du recepteur (utilisé pour Habitat et aprs)
station_lon = -1.xxxx
# Altitude du recepteur (utilisé pour Habitat et aprs)
station_alt = 10.0
gpsd_enabled = False
gpsd_host = localhost
gpsd_port = 2947
###########################
# HABITAT UPLOAD SETTINGS #
###########################
[habitat]
# Indicatif utilisé pour transmettre les données à Habitat
uploader_callsign = F-80543
# Valide l’envoi d’info au serveur Habitat (False invalide)
upload_listener_position = True
uploader_antenna = discone
# Délais entre chaque envoi (ne pas descendre en dessous de 30s)
upload_rate = 30
# An optional contact e-mail address.
sondehub_contact_email = f80543@gmail.com
########################
# APRS UPLOAD SETTINGS #
########################
[aprs]
# Envoi vers un serveur aprs (true = validé)
aprs_enabled = True
# Utilisateur aprs (voir APRS IS)
aprs_user = XXXXXX
# Mot de passe aprs (voir APRS IS)
aprs_pass = XXXXX
# Délai entre chaque envoi vers l’aprs
upload_rate = 30
aprs_server = radiosondy.info
aprs_port = 14590
aprs_object_id = <id>
aprs_use_custom_object_id = False
aprs_position_report = False
aprs_custom_comment = Clb=<vel_v> t=<temp> h=<humidity> p=<pressure> <freq> Type=<type> Radiosonde
station_beacon_enabled = True
station_beacon_rate = 30
station_beacon_comment = radiosonde_auto_rx SondeGate v<version>
station_beacon_icon = /`
###########################
# CHASEMAPPER DATA OUTPUT #
###########################
[oziplotter]
ozi_update_rate = 5
ozi_enabled = False
ozi_port = 8942
payload_summary_enabled = True
payload_summary_port = 55673
#######################
# EMAIL NOTIFICATIONS #
#######################
[email]
# envoi d’alerte par email à chaque detection
email_enabled = False
launch_notifications = True
landing_notifications = True
landing_range_threshold = 30
landing_altitude_threshold = 1000
error_notifications = False
# serveur smtp – exemple ssl0.ovh.net
smtp_server = localhost
# port smtp – exemple 587
smtp_port = 25
# type d’authentification – exemple TLS
smtp_authentication = None
# user smtp
smtp_login = None
# mot-de-passe smtp
smtp_password = None
# adresse expediteur
from = sonde@localhost
# adresse destinataire
to = someone@example.com
subject = <type> Sonde launch detected on <freq>: <id>
###################
# ROTATOR CONTROL #
###################
[rotator]
rotator_enabled = False
update_rate = 30
rotation_threshold = 5.0
rotator_hostname = 127.0.0.1
rotator_port = 4533
rotator_homing_enabled = False
rotator_homing_delay = 10
rotator_home_azimuth = 0.0
rotator_home_elevation = 0.0
###########
# LOGGING #
###########
[logging]
per_sonde_log = True
###########################
# WEB INTERFACE SETTINNGS #
###########################
[web]
web_host = 0.0.0.0
# port du serveur web local – exemple 80 - 5000 par défaut
web_port = 5000
# durée en minutes de conservation des données sur le serveur web
archive_age = 120
web_control = False
web_password = XXXX
kml_refresh_rate = 10
##################
# DEBUG SETTINGS #
##################
[debugging]
save_detection_audio = False
save_decode_audio = False
save_decode_iq = False
#####################
# ADVANCED SETTINGS #
#####################
[advanced]
search_step = 800
# niveau en db minimum pour détecter un signal (par rapport au bruit)
snr_threshold = 10
# nombre maximum de « pics » détectés
max_peaks = 10
min_distance = 1000
scan_dwell_time = 20
detect_dwell_time = 5
scan_delay = 10
quantization = 10000
decoder_spacing_limit = 15000
temporary_block_time = 120
synchronous_upload = True
payload_id_valid = 3
sdr_power_path = rtl_power
################################
# DEMODULATOR / DECODER TWEAKS #
################################
drift_tweak = False
# meilleurs décodages
rs41_experimental = True
rs92_experimental = True
dfm_experimental = True
m10_experimental = True
lms6-400_experimental = True
ngp_tweak = False
######################
# POSITION FILTERING #
######################
[filtering]
max_altitude = 50000
max_radius_km = 1000
min_radius_km = 0
radius_temporary_block = False
Aide à la récupération - ChaseMapper
Tout comme radiosonde_auto_rx, ChaseMapper fait partie du Projet Horus. Ce logiciel fournit des prévisions de trajectoire, calculées à partir de modèles météorologiques GFS régulièrement téléchargés. Il acquiert les données de localisation du ballon à partir de radiosonde_auto_rx et la position du récepteur à partir des données GPS locales[11]. Puis, dans une session de navigateur, il dessine une carte géographique pour fournir une aide visuelle aidant à la récupération de la radiosonde.
Les cartes peuvent également être servies à partir d'un cache local, permettant une utilisation sans connexion Internet.
ChaseMapper est disponible sur le site : https://github.com/projecthorus/chasemapper
L’installation se fait au travers des 3 commandes suivantes :
- sudo apt-get install git python3-numpy python3-requests python3-serial python3-dateutil python3-flask python3-pip
- sudo pip3 install flask-socketio pytz
- git clone https://github.com/projecthorus/chasemapper.git
Pour un premier essai, je décide de ne rien changer dans le fichier de configuration de radiosonde_auto_rx. Je crée celui de Chasemapper et, pour seul changement, j’indique ma position géographique pour un centrage correct des cartes (via l’éditeur nano) :
- cd /home/pi/chasemapper
- cp horusmapper.cfg.example horusmapper.cfg
- sudo nano horusmapper.cfg
Fichier horusmapper.cfg
Après l’ouverture du logiciel radiosonde_auto_rx, ChaseMapper se lance depuis une seconde fenêtre LXterminal :
- cd /home/pi/chasemapper
- python3 horusmapper.py
Tout fonctionne correctement, ChaseMapper reçoit les données de radiosonde_auto_rx.
Nous les retrouvons cartographiées à l’ouverture du navigateur Internet à l’adresse : http://localhost:5001/
Tout comme c’est le cas avec radiosonde_auto_rx v1.5.3., l’ouverture de cette fenêtre par le navigateur Internet entraine le même message d’alerte dans la fenêtre ChaseMapper :
The WebSocket transport is not available, you must install a WebSocket server that is compatible with your async mode to enable it. See the documentation for details. (further occurrences of this error will be logged with level INFO)
Ici, sans application d’une mise à jour de Chasemapper, il ne m’a pas été possible de supprimer cette alerte ; peut perturbante semble-t-il, puisque l’ensemble semble parfaitement fonctionner.
Mon QRA est représenté par une voiture. Par une nouvelle modification dans le fichier de configuration j’indique que je suis à mon domicile et non en itinérance en passant la variable car_source_port de gdpd à station.
Fichier horusmapper.cfg
Radiosonde_auto_rx et ChaseMapper en fonctionnement
Radiosonde_auto_rx et ChaseMapper en fonctionnement avec l’interface cartographique en arrière-plan.
Par défaut, le logiciel reçoit les prédictions de vol au travers de l’API Tawhiri qui nécessite une connexion Internet. Celle-ci est indispensable, même si elle peut se contenter d’accès intermittents.
Toujours dans le cas d’un fonctionnement dégradé (connexion Internet intermittente), il peut être utile de gérer localement ses cartes géographiques. Il est pour cela nécessaire d’associer FoxtrotGPS à ChaseMapper comme décrit dans le tutorial du projet Horus : https://github.com/projecthorus/chasemapper, au paragraphe Offline Mapping via FoxtrotGPS's Tile Cache.
Création d’un script exécutable et dépose sur le bureau
Pour faciliter le lancement de l’application depuis le bureau voici les étapes pour la création d’un script de lancement du programme.
- S’il n’existe pas encore, créez le répertoire qui contiendra nos exécutables et positionnez-vous dans celui-ci :
- mkdir /home/pi/bin
- cd /home/pi/bin
- Créez votre script (la sauvegarde se fera par <CTRL-O>, le retour en ligne de commande par <CTRL-X>.
- nano /home/pi/bin/ChaseMapper.bash
Script de lancement
- Rendez le script exécutable :
- sudo chmod 744 /home/pi/bin/ChaseMapper.bash
Afin que ce script soit accessible sur le Bureau, il faut créer un fichier d’appel[13]. Créer le fichier depuis celui-ci par un clic droit de la souris, ou passez par une fenêtre LXterminal et déplacez-vous dans le répertoire /home/pi/Desktop pour créer ce nouveau fichier (sudo nano ChaseMapper.desktop). Prenez modèle sur l’exemple ci-dessous (l’usage du copier/coller à partir d’un élément déjà existant sera une aide non négligeable).
Contenu du fichier ChaseMapper.desktop
Ceci réalisé, mais en cas de difficulté : sur le Bureau, positionnez-vous sur la nouvelle icône créée. Choisissez Propriété avec le bouton droit de la souris. Ouvrez l’onglet Droits d’accès et vérifiez que le choix Tout le monde est sélectionné pour Contrôle d’accès/Exécuter.
Pour l’icône, toujours via le choix Propriété, il est possible de naviguer à sa recherche dans les répertoires en cliquant sur celle qui est proposée par défaut. De très nombreuses icônes sont disponibles dans /usr/share/icons.
Choix de l’icône liée au fichier ChaseMapper
Droits d’accès du fichier ChaseMapper
Toujours en cas de problème, vérifiez les droits, puis le propriétaire et le groupe associés des fichiers bash et .desktop.
Droits, propriétaire et groupe des fichiers .bash et .desktop
Enfin, si le nom du raccourci n’est pas celui que vous avez saisi dans le fichier .desktop, fermez votre session et rouvrez là. Tout devrait alors rentrer dans l’ordre.
ANNEXE-3 - Horloge, GPS et synchronisation
La position GPS de votre carte Pi et la gestion de la date et de l’heure sont des points très important pour son bon fonctionnement. Elles le sont plus encore dès que l’on s’attaque aux décodages de certains signaux digimodes. Pour toutes les écoutes « à la maison », la présence d’une connexion internet avec timedatectl installé par défaut sur la Raspberry maintient notre système « à l’heure » en le synchronisant sur des sources de référence. Immobile, notre position GPS peut être entrée dans les fichiers de configuration de nos logiciels. Par contre, si nous nous trouvons un jour en mode déconnecté, loin de tout accès Internet, l’usage d’un récepteur GPS associé aux daemons GPSD et Chrony deviendra alors indispensable ; GPSD capturant (en plus de nos coordonnées) le temps GPS et Chrony ajustant l'horloge système selon celui-ci. Ce sera par exemple le cas si vous décidez d’installer le logiciel ChaseMapper qui fournit des prévisions de trajectoires de radiosondes et qui, à chaque lancement, doit récupérer, en temps réel, la position GPS du récepteur.
Retrouvé dans mon matériel, je décide donc d’installer le récepteur USB BU-353S4 de GlobalSat (Prolific Technology Inc.) : (https://www.amazon.fr/GlobalSat-BU-353-S4-R%C3%A9cepteur-SiRF-Star/dp/B008200LHW) pour l’associer au logiciel GPSD.
Voici la procédure de reconnaissance du GPS et ’installation de GPSD :
- Avant de brancher le GPS, lancez la commande dmesg (affichage de la mémoire tampon des messages du noyau) et repérez les dernières lignes d’informations,
- Insérez le GPS,
- Relancez dmesg. Les dernières lignes doivent maintenant indiquer la présence du GPS et son port de connexion (ici ttyUSB0),
Le GPS Prolific Technology est attaché au port /dev/ttyUSB0 (commande dmseg)
- La commande lsusb confirmera la bonne reconnaissance de l’équipement,
Présence du GPS Prolific Technology (commande lsusb)
- Installez le daemon GPSD :
- sudo apt-get install gpsd gpsd-clients python-gps
- Modifiez le fichier socket (le paramètre ListenStream=127.0.0.1:2947 devient ListenStream=0.0.0.0:2947):
- sudo systemctl stop gpsd.socket
- sudo systemctl disable gpsd.socket
- sudo nano /lib/systemd/system/gpsd.socket
Fichier gpsd.socket après modification
- Modifiez le fichier de configuration gpsd:
- sudo nano /etc/default/gpsd (donnez à la variable DEVICES la valeur "/dev/ttyUSB0".
Fichier gpsd après modification
- Vérifiez le fonctionnement :
- sudo gpsd /dev/ttyUSB0 -F /var/run/gpsd.socket
- gpsmon
Moniteur gpsmon lancé en ligne de commande
- Permettez le lancement automatique de GPSD pour les prochains démarrages de la Raspberry Pi [Voir RPi – quick-start : http://www.satsignal.eu/ntp/Raspberry-Pi-quickstart.html ]
- sudo ln -s /lib/systemd/system/gpsd.service /etc/systemd/system/multi-user.target.wants/
Avec l’option -s, la commande ln a pour but d’établir un lien symbolique entre 2 fichiers.
Après une nouvelle vérification (gpsmon) et un redémarrage, nous pouvons installer chrony :
-
- Installation :
- sudo apt -y install chrony python-gi-cairo
- Modification du fichier conf
- sudo nano /etc/chrony/chrony.conf
- Installation :
Il s’agit ici d’ajouter en fin de fichier la ligne suivante :
refclock SHM 0 offset 0.5 delay 0.2 refid NMEA
-
- Relance du daemon :
- sudo systemctl stop chronyd
- sudo systemctl start chronyd
Pour vérifier le bon fonctionnement de l’ensemble il faut alors redémarrer la carte et lancer - avec, puis sans accès Internet - les commandes suivantes :
- sudo chronyc sources -v
Information sur le bon fonctionnement de la source de synchronisation du temps (chronyc sources -v)
Avec Internet accessible (de haut), sans accès Internet (en bas)- sudo chronyc tracking
Information sur le bon fonctionnement de la source de synchronisation du temps (chronyc tracking)
Avec Internet accessible (de haut), sans accès Internet (en bas)- timedatectl
Information sur le bon fonctionnement de la source de synchronisation du temps (timedatectl)Coup d’œil sur la configuration
Voici pour info, le contenu de mes fichiers système après installations.
pi@raspberrypi:~ $ cat /lib/systemd/system/gpsd.socket
- Relance du daemon :
- [Unit]
Description=GPS (Global Positioning System) Daemon Sockets[Socket]
ListenStream=/var/run/gpsd.sock
ListenStream=[::1]:2947
ListenStream=0.0.0.0:2947
SocketMode=0600[Install]
WantedBy=sockets.targetpi@raspberrypi:~ $ cat /etc/default/gpsd
# Default settings for the gpsd init script and the hotplug wrapper.
# Start the gpsd daemon automatically at boot time
START_DAEMON="true"# Use USB hotplugging to add new USB devices automatically to the daemon
USBAUTO="true"# Devices gpsd should collect to at boot time.
# They need to be read/writeable, either by user gpsd or the group dialout.
DEVICES="/dev/ttyUSB0"# Other options you want to pass to gpsd
GPSD_OPTIONS="-n"
GPSD_SOCKET="var/run/gpsd.socket"pi@raspberrypi:~ $ cat /etc/chrony/chrony.conf
# Welcome to the chrony configuration file. See chrony.conf(5) for more
# information about usuable directives.
pool 2.debian.pool.ntp.org iburst# This directive specify the location of the file containing ID/key pairs for
# NTP authentication.
keyfile /etc/chrony/chrony.keys# This directive specify the file into which chronyd will store the rate
# information.
driftfile /var/lib/chrony/chrony.drift# Uncomment the following line to turn logging on.
#log tracking measurements statistics# Log files location.
logdir /var/log/chrony# Stop bad estimates upsetting machine clock.
maxupdateskew 100.0# This directive enables kernel synchronisation (every 11 minutes) of the
# real-time clock. Note that it can’t be used along with the 'rtcfile' directive.
rtcsync# Step the system clock instead of slewing it if the adjustment is larger than
# one second, but only in the first three clock updates.
makestep 1 3refclock SHM 0 offset 0.5 delay 0.2 refid NMEA
A propos de l'auteur
