Suite logique aux préliminaires qui avaient pour but de faire un peu connaissance avec la norme NMEA 0183 on va dans ce chapitre aborder enfin l’extraction de toutes les données en vue plus tard de les présenter sur des afficheurs plus propices que le Moniteur de l’IDE à créer une appareil autonome. Pour ce développement logiciel on va persister à se servir de la trame de type GGA. L’idée de base consiste à reprendre la structure de P06, d’extraire toutes les données coloriées dans la Fig.13 puis de les afficher en clair sur la ligne série USB de dialogue avec le P.C.
Experience_07 : Extraction de toutes les données de base.
Bien qu’il soit peu probable que l’utilisateur utilisera le petit appareil dans l’hémisphère SUD au lieu d’afficher ‘N’ par défaut pour la latitude, on puisera l’information dans les trames GPS. Cette approche augmente la fiabilité et la perspective de vérifier que les données affichées soient cohérentes. Le démonstrateur Expérience_07.ino réalise une mise en page minimale pour l’affichage de l’heure et pour celui des coordonnées géographiques. Pour l’heure, ajoute si nécessaire le zéro en tête si Heure, Minutes ou Secondes sont inférieures à dix. Pour les coordonnée géographiques, comme le montre la copie d’écran de la Fig.15 elles sont proposées dans un format plus habituel de type Degrés/Minutes/Secondes que celui DD,MM.MMMMM de la donnée brute du GPS. Il faut prendre garde au fait que beaucoup de descriptions sur Internet de la NMEA 0183 font référence à un format de type DD,MM.MMMM alors qu’actuellement il y a cinq décimales pour la valeur des minutes au lieu de quatre, et ce autant pour la longitude que pour la latitude. On se doute que dans P7 cette constatation est prise en compte. Sur la Fig.15 la trame complète réceptionnée est affichée, avant les données traitées dans les zones coloriées en rose. On peut alors comparer toutes ces informations. Il est temps d’aller faire un petit tour dans les autres types de préambules.
REMARQUE : Durant le développent d’Expérience_06.ino je me suis heurté à un comportement vraiment étrange du programme alors que je n’avais ajouté que deux instructions banales de type if (HEURE < 10) Serial.print(‘0’) qui ne peuvent faire diverger le programme. Pourtant, c’est ce qui s’est passé. J’ai donc subodoré une collision entre la PILE et le TAS. C’est la raison pour laquelle dans le démonstrateur P06 j’ai ajouté le test de PILE dans la séquence d’initialisation, test qui sera « propagé » car sa présence n’engendre pas de gène.
Conclusions expérimentales.
À l’usage suite à de nombreux essais, je me suis rendu compte que le +5V la carte Arduino NANO étant alimentée par sa mini-prise USB était un peu faible et présentait un taux de « brouillage » non dérisoire. Sur l’oscillogramme de la Fig.16 on peut observer que la tension crête à crête de « l’herbe » fait pratiquement 1V, générées quand on branche le module GPS. Par contre, quand on alimente avec une pile de 9V rechargeable sur l’entrée IN, la perturbation est moindre car l’impédance interne est plus faible. On peut donc imaginer que le fonctionnement en version autonome sera fiable. Si vous observez Image 01.JPG disponible dans le dossier <IMAGES> vous allez découvrir que je dispose de trois modules de type un peu différents bien que tous utilisent le même circuit intégré spécialisé. Il semblerait à l’usage, sans pour autant être formel, que plus les dimensions de la petite antenne de capture sont de tailles réduites, plus grand est le temps de synchronisation du GPS. C’est le modèle B dont l’antenne est un carré de 25mm de coté qui semble donner les meilleurs résultats. Il importe également d’envisager dès ce stade du développement l’intégration d’Arduino et du module NEO-6M dans un petit boitier pour en faire un appareil totalement autonome. Il faut donc vérifier que les deux éléments électroniques acceptent une promiscuité inévitable et trouver une orientation de l’antenne qui convienne. Une première étude aboutit à placer le circuit imprimé du GPS verticalement contre la carte Arduino qui est de type NANO pour des raisons d’encombrement. De ce fait, l’antenne se trouvera également dans un plan vertical. Il semble que cet attelage soit techniquement acceptable. Sur Image 02.JPG on observe que la LED rouge d’Arduino placé sur une plaquette à essai signale la réception d’un signal sur sa voie série. Noter que l’on ne peut pas confondre avec la LED PW qui signale la présence du +5Vcc car sur le petit circuit imprimé cette LED « trop présente » à mon sens a été isolée. À l’aide d’un cutter, j’ai coupé la piste qui la relie à sa résistance de limitation de courant. Sur la photographie d’Image 03.JPG saisie de l’autre coté du module NEO-6M on peut remarquer que dans l’encerclé jaune la LED bleue de ce module est allumée. Dans la pratique elle s’illumine durant la transmission des données lorsque suffisamment de satellites sont utilisables pour les calculs.
Experience_08 : Extraction de la date.
Toujours dans l’exploration du contenu des données de la norme nous allons travailler un peu avec la trame de préambule RMC et passer l’affichage de l’heure de T.U. en heure légale française. Puisque le logiciel ne peut pas savoir si l’on est en heure d’hiver ou heure d’été, dans ce « Sketch » on va préciser cette information en tête de programme sous forme d’un paramètre Hiver de type booléen. Les résultats obtenus avec Expérience_08.ino sont montrés sur la Fig.17 qui est une copie d’écran de la fenêtre du Moniteur de l’IDE en avec la « présentation » du « Sketch » dans la zone jaune, et l’indication en zone bleue de l’espace situé entre la PILE et le TAS. Pour celle et ceux qui désirent en savoir plus sur ce thème, vous trouverez le petit fichier technique Collision_entre_la_PILES_et_le_TAS.pdf préservé dans le sous-dossier <DOCUMENTS>. Puis, le GPS étant synchronisé, se suivent à chaque seconde l’affichage du contenu de la mémoire Tampon[] contenant une trame de type RMC dans les zones vertes et l’extraction des données dans les zones roses. Contrairement au cas de la Fig.15, ici c’est l’heure légale en France qui est affichée.
Experience_09 : Attendre des données cohérentes.
À sa mise sous tension, le GPS n’a rien à analyser pour effectuer ses traitements, il lui faut attendre que suffisamment de satellites soient en visibilité pour en capturer les signaux et combiner ces derniers pour déterminer la position géographique du récepteur. En théorie, avec trois « balises » on peut se situer sur Terre. Toutefois, si vous consultez Principe de base du GPS.pdf disponible dans le dossier <DOCUMENTS>, vous allez constater que pour effectuer un traitement de localisation le système attend d’avoir au moins quatre satellites fiables en visibilité. Riches de cette information on peut analyser l’historique d’un démarrage dont la Fig.18 constitue une copie d’écran de la fenêtre contextuelle du Moniteur de l’IDE. Sur cette illustration les traits colorés séparent des instants « éloignés » les uns des autres. En 1 on vient de mettre sous tension l’ensemble. Le logiciel se présente, puis l’espace entre la PILE et le TAS est évalué et commence alors l’étude des signaux qui arrivent. Le programme démarre un compteur à 0000 et incrémente ce dernier toutes les secondes d’attente. Ce sont les trames de type GGA qui servent à déterminer l’instant où les informations deviendront utilisables car c’est la trame qui présente le plus de caractères dans un groupe de données, lorsqu’elle est complète. Si elle fait 73 caractères, alors les données sont utilisables et toutes les trames sont documentées. En 2A et en 2B l’analyse se poursuit. Jusqu’à 2A les trames ne font que 31 caractères car de nombreux champs ne sont pas renseignés entre les séparateurs « virgules ». Après 113 secondes de la mise sous tension, l’information de l’heure TU est disponible et la longueur des chaînes de caractère passe de 31 à 40. Puis en 3 l’attente se poursuit jusqu’à ce 
qu’en 4 le nombre de satellites utilisables dépasse le nombre minimal nécessaire de quatre. Et en 5 commence alors la phase d’exploitation possible des données. On constate dans cet exemple qu’il a fallu attendre 353 secondes pour obtenir des données utilisables soit 5 minutes et 52 secondes. Cette durée d’attente dépend directement de la configuration de la noria des satellites GPS. Par exemple sur la Fig.19 on ne doit attendre que 4 minutes et 40 secondes. L’attente est plus courte. D’une façon générale, la durée d’attente avant utilisation possible des données sera toujours de l’ordre de cinq à six minutes.
La suite est ICI.
