Disséminées dans les divers types de trames, bien que peu importantes aux yeux de l’utilisateur « lambda », il serait dommage dans un contexte d’expérimentation de ne pas ouvrir une petite parenthèse sur ces données complémentaires. On va commencer par celles contenues dans les trames de type GGA avec le démonstrateur P10. Pour que les données soient cohérentes dès leur affichage, à partir de ce démonstrateur on attendra systématiquement que le nombre des satellites utilisables soit au moins égal à quatre comme l’impose la normalisation NMEA 0183.
Experience_10 : Données secondaires de GGA.
Outre la nature du positionnement, on peut obtenir dans cette trame une idée de la fiabilité de la géo-localisation. Dans ce démonstrateur nous allons nous limiter à ces deux informations secondaires. Pour extraire ces informations, nous devons au préalable les situer dans la trame de type GGA et les interpréter. Dans ce but la Fig.21 représente une telle trame extraite de la copie d’écran de la Fig.20 obtenue avec le démonstrateur Expérience_10.ino lorsque l’appareil alimenté depuis plus de dix minutes était « synchronisé » correctement avec six satellites.
• 1 : Heure d’acquisition des données en T.U.
• 2 : Latitude du récepteur GPS.
• 3 : Longitude de localisation.
• 4 : Type de Positionnement.
• 5 : Nombre de satellites en poursuite.
• 6 : Qualification du « FIX ». (Voir le tableau Fig.22)
• 7 : Altitude en Mètres au dessus du niveau moyen des Océans. (Mean See Level)
• 8 : Correction de la hauteur du géoïde en Mètres par rapport à l’ellipsoïde WGS84. (1)
Experience_10 : Données secondaires de GGA.
Finalement, le lendemain de la rédaction du chapitre précédent, j’ai décidé de modifier le démonstrateur Expérience_10.ino pour en exploiter également les données d’altitude. La Fig.23 montre une nouvelle copie d’écran de la fenêtre du Moniteur de l’IDE. Outre l’altitude et sa correction en hauteur, on peut remarquer que la date de la version a été mise à jour. Je vous invite au passage à aller vous renseigner sur ce que signifie géoïde WGS84 et la notion de MSL.
(1) : WGS84 est un système de coordonnées définissant un modèle de la Terre. Il est défini par un ensemble de paramètres primaires et secondaires dont les caractéristiques de la forme de l’ellipsoïde terrestre, sa vitesse angulaire, et sa masse.
Experience_11 : Données secondaires de GSA.
Elles concernent encore la précision des résultats mais dans deux directions cartésiennes ainsi que le listage des satellites en visibilité de l’antenne du GPS aptes aux calculs. Le démonstrateur Expérience_11.ino a pour mission de décrypter ces informations contenues dans les trames de type GSA. Comme il y a a aussi le préambule de type GSV on est obligé d’utiliser deux caractères pour la sélection. La Fig.24A présente l’affichage réalisé par P11 à deux instants séparés par un intervalle de temps notable pour que la configuration des satellites au dessus de l’horizon local ne soit pas la même. En particulier le 15 et le 13 sont passés sous l’horizon alors que le 25 et le 32 se sont hissés au dessus du géoïde. La Fig.24B constituée d’un extrait de la copie d’écran nous permet de passer en revue les paramètres d’une trame dont le protocole est de type GSA. Les dilutions horizontale et verticale étant d’orientations cartésiennes, leur combinaison PDOP s’obtient par « le théorème de Pythagore. C’est à dire que
• 1 : A pour Automatique, M pour Manuel.
• 2 : FIX 3D. (Ce sera toujours le cas.)
• 3 : Références des satellites utilisés pour le FIX.
• 4 : Dilution de précision. (PDOP)
• 5 : Dilution de précision horizontale. (HDOP)
• 6 : Dilution de précision verticale. (VDOP)
Concrètement, dans notre cas le FIX sera toujours Automatique et de type 3D.
Experience_12 : Mise en évidence d’une erreur de stratégie.
Initialement, P12 avait pour mission d’extraire et de présenter les données secondaires des trames de type GSV qui précisent l’élévation et l’azimut des divers satellites en visibilité ainsi que la puissance de leur signal en réception. Elles sont relatives à la configuration des satellites, complétant les données des trames de préambule GSA. Architecturé avec la structure des démonstrateurs précédents, la Fig.24 présente le résultat obtenu avec Expérience_12.ino qui ne fonctionne correctement que pour quelques groupes de données. En 1 ainsi qu’en 2 les données collectées sont correctes et le traitement des données cohérent. Nous verrons plus avant le contenu de ce type de trame. Les trames arrivent en rafales et à jet continu. Il faut beaucoup moins de temps pour puiser un OCTET dans le tampon FIFO du récepteur série interne à l’ATmega328 que pour la capture d’un caractère arrivant sur la ligne à la « lenteur » de 9600 baud. C’est cette différence de temps qui jusqu’à cette expérience nous avait permit de traiter les données « en temps partagé ». Il se trouve qu’avec Expérience_12.ino on arrive à des durées de traitement et d’affichage qui sont trop importantes. Arrivé en 3 on continue notre analyse logicielle alors que la suite des données, symbolisé par 5 est tronquée. La fin de la trame en cours est perdue, et se précipite en 4 le début de la trame suivante. Du coup, le programme travaille sur des données « imprévues » et tombe dans une boucle sans fin qui affiche des ‘8’.
CONCLUSION : Intercaler du traitement logiciel durant la capture d’un groupe de donnée n’est pas utilisable car les temps de traitement deviennent incompatibles avec la cadence des données sur la ligne série. Inévitablement si les durées de traitements deviennent significatives, on arrive à des pertes de données. Par ailleurs, la technique qui consiste à engendrer des décalages à gauche n’est plus envisageable « en temps partagé » car elle est trop couteuse « en cycles machine ».
SOLUTION : La nouvelle approche va consister à enregistrer l’intégralité des données d’un groupe qui arrivent en « rafales ». Puis, le total étant alors à notre disposition, effectuer les traitements et les affichages désirés. Les techniques de décalage du tampon de données ne sont plus pertinentes.
Experience_13 : Saisie en rafale des données.
Démonstrateur qui se charge de stocker presque l’intégralité du contenu d’un groupe de données. Presque, car deux difficultés réelles se présente pour le cas des trames de type GSV. Pour comprendre la complexité qu’engendre ce type de trames, commençons Fig.26 par décortiquer le contenu d’une trame de type GSV dont l’exemple présente le cas le plus complet :
On peut avoir jusqu’à quatre trames de type GSV dans une transmission. Ainsi la limitation pour le domaine grand public est de 16 satellites. ATTENTION, beaucoup de sites sur Internet stipulent que cette limitation est de trois trames GSV par groupe et de 12 satellites.
Première difficulté : N’enregistrer que les données pertinentes.
Le démonstrateur P13 effectue ce filtrage. Mémoriser l’intégralité des données d’une trame consiste à déclarer autant de tableaux que de types de trames dans un groupe. La Fig.27 va nous permettre d’optimiser la taille de ces tableaux. Un premier problème se présente : En fonction de la configuration des satellites, on peut avoir jusqu’à quatre trames de type GSV. Pour toutes les mémoriser il faudrait déclarer quatre tableaux de 59 cellules soit 236 octets de moins pour le programme et de moins entre la PILE et le TAS.
Comme les trames de type GSV ne contiennent que des informations relatives à la configuration des satellites, et qu’il s’agit de données secondaires, on ne va déclarer qu’un seul tableau, quitte à utiliser quatre groupes de données GPS successifs pour collecteur l’intégralité de ces informations.
STRATÉGIE : On commence par attendre le début de la première trame d’un groupe. L’expérience montre que les trames sont toujours dans l’ordre de celles de la copie d’écran de la Fig.27 le caractère ‘$‘ signalant le début d’une trame. On saute alors « GP » qui n’apporte aucune information utile. Puis, on se synchronique sur le groupe en testant le préambule GLL. Comme l’ordre des trames est connu, pour celles qui suivent on se contente de « sauter » le préambule et de mémoriser dans le tampon dédié. Préambule entièrement filtré commencent alors les données contenant de l’information. Tous les caractères qui suivent sont mémorisés jusqu’à rencontrer le marqueur de fin des données ‘*‘ qui ne sera pas mémorisé. On saute alors les deux caractères du CRC, le CR et le LF et le processus va recommencer pour la trame suivante. (CR : Retour de chariot. LF : Passage à la ligne.) On peut remarquer que pour les trames de type GSA le ‘A‘ qui suit le préambule et le ‘3‘ n’apportent pas 
vraiment d’information pertinente, car ce sera toujours le cas. Ils ne sont donc pas mémorisés. Reste à optimiser la taille des tampons mémoires spécifiques à chaque type de trame. Dans ce but nous allons nous servir de la Fig.27 qui représente une copie d’écran d’un groupe contenant trois trames de type GSV. (Image 04.JPG prouve qu’il peut y en avoir jusqu’à quatre.) Les caractères ont été coloriés de la façon suivante : En rouge et en marron les préambules non mémorisés. En orange les CRC non mémorisés. Des paquets de dix sont repérés en bleu clair et en violet. Enfin les paquets non égaux à dix en rose. Il est alors facile pour chaque ligne de totaliser ce qui est bleu clair, violet et rose. Le résultat est entre parenthèses en italiques et en gris. Comme vous pouvez le constater dans Expérience_13.ino les tailles déclarées sont augmentées d’une unité pour le logement de l’octet ‘\0′ qui marque la fin des chaînes de caractères.
Temps disponible pour le traitement et l’affichage.
Comme pour chaque démonstrateur, la Fig.28 présente une copié d’écran de la fenêtre contextuelle du Moniteur de l’IDE et commence par la présentation du programme en zone jaune. Contrairement à ce qui se faisait avant, ici il n’est plus nécessaire d’attendre que quatre satellites au moins soient au dessus de l’horizon, l’affichage reste cohérent dès la mise sous tension comme on peut le voir dans la zone bleu clair correspondant à la mise sous tension du système. Ensuite, les groupes qui suivent sont issus du fonctionnement d’Expérience_13.ino lorsque le nombre de satellites visibles (SV) est de dix conduisant à trois trames de type GSV dans les groupes de données. Le dispositif est donc sous tension depuis plusieurs minutes. Comme chaque trame de type GSV ne peut accueillir que quatre descriptions satellitaires au maximum, pour les dix unités il faut deux trames complètes et la dernière qui n’en compte que deux. Pour mettre en évidences leurs descripteurs, sur la Fig.28 les identificateurs sont coloriés en orange. Vous pouvez constater dans les « surlignages » en vert pastel qu’il faut trois groupes de données pour lister les dix satellites. Le croquis P13 chronomètre finement le temps nécessaire pour capturer l’intégralité de chaque groupe et le précise en tête d’affichage dans les zones coloriées en rose clair. On en déduit qu’il reste à peine un dixième de seconde pour effectuer les traitements et l’affichage. Le µP de la carte NANO est rapide, mais il faudra aussi que l’affichage ne traine pas trop !
Experience_14 : Données secondaires de GSV.
Avec P12 on désirait extraire les données secondaires relatives à la configuration des satellites avec les trames de type GSV complétant ainsi les données des trames de préambule GSA. Avec les préambules de type GSV, comme détaillé dans la Fig.26, on peut obtenir l’élévation et l’azimut des divers satellites en visibilité ainsi que la puissance de leur signal en réception. On peut alors se faire une idée de la configuration spatiale telle que celle montrée en Fig.6 de la page 4 de Principe de base du GPS.pfd disponible dans le sous-dossier <DOCUMENTS> et je vous invite fortement à le consulter. Dans P12 les affichages ont été réduits au maximum pour gagner du temps, au risque de ne pas être « parlants ». Cette concession à la lisibilité n’était pas suffisante et le démonstrateur divergeait. Le démonstrateur Expérience_14.ino respecte la nouvelle approche, avec pour bénéfice un affichage des données bien plus explicite.
Deuxième difficulté : L’intensité de réception du signal n’est pas toujours présente.
C’est précisément ce constat qui impose d’extraire les données satellitaires par simple exploitation d’indices qui se résume à une technique de décalage d’un pointeur dans le tampon pour explorer entièrement la trame de type GSV. Nous savons qu’une telle trame peut contenir entre une et quatre définitions de caractéristiques de satellites. Aléatoirement l’intensité de réception du signal peut ne pas être insérée dans la chaîne de caractère. Pour un même nombre de satellites la taille de la trame et la position des données ne sera alors pas identique. Le tableau de la Fig.29 précise la combinatoire possible. On constate qu’en fonction du nombre de satellites dans la trame et des informations de niveau de réception du signal on devrait envisager trente cas possibles. C’est bien trop pour utiliser des vérifications avec des instructions de type if. Aussi, on va utiliser la technique simple qui consiste à puiser les informations par simple décalage d’un INDEX dans la chaîne de caractère de Tampon_GSV et ce tant qu’il reste des octets de données. Pour savoir s’il reste des informations après avoir exploré les données d’un satellite, on regarde si après le délimiteur ‘,‘ il y a un chiffre. La copie d’écran du Moniteur de l’IDE qui représente un démarrage du GPS avec Expérience_14.ino est trop grande pour s’intercaler facilement dans la mise-en page de ce texte. C’est la raison pour laquelle elle est préservée dans Image 05.JPG du sous-dossier <IMAGES>. En standard en 1 le logiciel se présente. Puis en 2 une attente de six à sept minutes va s’écouler avant que quatre satellites au moins soient en hauteur de capture. En 3 , 4 , 5 et 6 on commence à dérouler des séquences dont pour deux cas les signaux sont trop faibles et leur intensité pas affichée. En 7 c’est le cas particulier d’un signal trop faible situé en fin de trame. En 8 un cas banal où c’est le premier satellite dont le signal est trop faible. Cet exemple est typique d’un cas où il y a quatre trames de type GSV. En 9 les quatre satellites de la trame sont en configuration favorable.
Enfin en 10 on rencontre le cas classique d’une dernière trame incomplète, avec ici un seul descriptif. On notera au passage que les satellites sont listés par ordre croissant de leur identificateur.
Experience_15 : Données du type RMC.
Non encore abordées, elles comportent des informations importantes pour la navigation qui n’ont rien de secondaires. Outre les coordonnées sphériques du mobile, on trouve dans la trame de type RMC le cap géographique de ce dernier ainsi que sa vitesse sol. En prime, da déclinaison magnétique locale est précisée information primordiale si l’on navigue à l’aide d’un compas magnétique, ce dernier étant utilisé en aviation pour vérifier les informations de la centrale inertielle sur les « liners » ou recaler le conservateur de cap à bord d’un petit aéronef.
Les données listées dans les trames de type RMC sont précisées dans l’encadré de la Fig.30 dont les informations sont glanées sur Internet. La ligne de cette Fig.30 est issue d’Expérience_15.ino qui se contente d’afficher le contenu du Tampon_RMC[] et n’effectue aucune extraction. Comme nous somme immobiles, on constate que la valeur de la vitesse affichée en 7 est aberrante. La valeur en 8 de la déclinaison magnétique n’est pas fournie, et les trois ‘,‘ au lieu de deux attendus nous permettent d’affirmer que le ‘A‘ en fin de chaîne est bien une donnée supplémentaire non précisée sur Internet. (Je suppose que c’est identique au 5 des trames VTG.)
Experience_16 : Données du type VTG.
Cette expérience partage avec celle de P15 une sorte d’inutilité. En effet, elle ne concerne que le cap suivi par le mobile et sa vitesse sol. Du coup Expérience_16.ino ne fait que visualiser le contenu de Tampon_RMC[] et n’effectue aucune extraction. La petite salamandre ne s’est pas trompée. On aura passé en revue tous les types de trames. Ainsi pour générer une application autonome nous aurons tous les éléments pour sélectionner et extraire les données pertinentes.
Experience_17 : Exercice de révision.
Avant d’envisager le développement d’une application autonome, nous allons tester la possibilité d’extraire et d’afficher toutes les données et de vérifier que même si l’affichage traine un peu, le temps pour tout traiter sera suffisant. Le démonstrateur Expérience_17.ino constitue un rassemblement des techniques élaborées dans les manipulations précédentes. Il réalise une synthèse de toutes les données pertinentes et les présente en clair sans économiser les textes pour pénaliser au maximum la durée des traitements et des affichages. En outre, on liste l’intégralité des trames d’un groupe avant d’en extraire les données pertinentes pour charger au maximum le travail effectué par le microcontrôleur. Tant que le nombre de satellites en configurations favorables n’atteint pas quatre, le programme se contente d’afficher toutes les trames suivi du texte « Attente de 4 satellites. » Dès que les traitements sont possibles, le programme passe à des affichages du genre de celui de la Fig.32 qu’il me semble utile de commenter. Normalement, à la mise sous tension le logiciel se présente en 1 suivi en 2 du contenu des données du groupe mémorisées. En 3 à la mise sous tension on devrait avoir pendant cinq à six minutes l’affichage du texte « Attente de 4 satellites.« , mais ici on a fait un RESET alors que le GPS est sous tension depuis un bon moment. C’est la raison pour laquelle le démonstrateur affiche directement les données qui sont cohérentes.
Les trois trames qui contiennent des données pertinentes ont leur préambule encadré en vert. Les trames GLL et GSA pourront être ignorées. Quand à VTG, il faut réaliser des essais en mouvement pour voir si l’on peut effectivement extraire des informations de vitesse sol et de cap. Ce ne sera envisageable qu’avec un appareil autonome. Comme c’était le cas pour le croquis P15 on ne liste les caractéristiques satellitaires qu’en étalant la saisie et l’affichage sur plusieurs trames. Par exemple ici c’est la trame n°3 sur 3 qui est prise en compte. Comme c’est la dernière et qu’il y a 11 satellites visibles en 5, le dernier groupe ne contient que 11 – 8 = 3 satellites. En 6 le 1 signale que le point est calé et le 07 précise qu’il y a sept satellites en poursuite, c’est à dire donnant des informations fiables pour les calculs. Il ne faut donc pas confondre le nombre de satellites au-dessus de l’horizon local et le nombre de ceux qui sont aptes à fournir des informations fiables.
Experience_18 : Optimisation du programme.
Tous les démonstrateurs qui précèdent avaient pour but de nous former à l’extraction des données d’un GPS sachant que j’ai abandonné l’idée d’utiliser une bibliothèque dédiée. L’inconvénient de cette approche c’est que nous avons été obligés d’apprendre le « langage des GPS » et de créer nos propres routines. L’avantage, c’est que l’on ne va utiliser que du code nécessaire. Il faut savoir qu’une application concrète autonome va devoir intégrer les routines d’affichages concernant le dispositif utilisé. Pour ce faire, il faut de la place dans le programme. Ensuite, on va désirer ajouter des fonctions. Pour que ce soit possible, il faut impérativement optimiser le code. Le but du démonstrateur Expérience_18.ino consiste à effectuer strictement le même traitement que celui de son prédécesseur, en optimisant la taille du programme et celle des données. Par ailleurs, afficher le contenu des trames est strictement inutile au point de vue opérationnel. Ce n’était justifié que pour nous aider à appréhender la norme NMEA 0183. Ce type d’information sera donc ignoré à partir de ce démonstrateur. La copie d’écran du Moniteur de l’IDE qui représente un fonctionnement stabilisé du GPS avec P18 est trop grande pour s’intercaler facilement dans la mise-en page de ce texte. C’est la raison pour laquelle elle est préservée dans Image 06.JPG du sous-dossier <IMAGES> comme c’était déjà le cas pour P14. Dans la zone jaune, comme chaque fois le programme se présente. Puis succèdent les renseignements de base dans la zones bleues et en vert et rose les informations secondaires. Comme dans les manipulations précédentes, les caractéristiques satellitaires sont réparties sur plusieurs groupes, repérables dans les zones roses. Il serait préférable de toutes les regrouper, quitte à las réunir dans des variables mémorisées, mais ici il fallait rester dans des traitements similaires pour pouvoir comparer. On peut vérifier en tête de listage que le programme en version « légère » fait 688 octets de moins, les données dynamique se sont réduites de 236 octet et la place disponible entre la PILE et le TAS a augmenté de 236 octets. Ces bénéfices sont substantiels. Une autre façon de gagner de la place en code objet et en mémoire dynamique, c’est de « supprimer » les chaînes de caractères qui sont considérés comme des tableaux variables logés à la fois en zone programme et en données dynamiques. Il suffit de loger les textes du dialogue Homme/Machine en mémoire non volatile EEPROM. C’est évidemment ce qui sera fait pour les applications qui vont suivre. (À condition que l’EEPROM ne soit pas utilisée pour y loger des données qui doivent être conservée lors de la coupure d’énergie.) Nous allons enfin pouvoir passer à des applications et développer des systèmes totalement autonomes avec leur écran et leur clavier …
La suite est ICI.
