À la fin du mois de novembre 2021, une balise de suivi d’oiseau nous a été confiée par le Groupe Ornithologique des Deux-Sèvres. Muette depuis 4 ans sur le dos d’une outarde canepetière, perdue pour la science mais recapturée dernièrement, nous avions pour consigne d’en extraire les dernières données relevées.

Les outardes sont des oiseaux migrateurs et protégés. Ils passent l’hiver dans le sud de l’Espagne ou du Portugal et sont suivis en France entre autre par le CNRS et dans les Deux-Sèvres par le GODS depuis plus de dix ans. Notre petite boîte à trésor avait donc beaucoup voyagé.

Au premier abord, la chose ne semblait pas aisée : il s’agit d’un dispositif extrêmement léger, valant plusieurs milliers d’euros et surtout : scellé dans de la résine, pour être étanche. La première idée fut de le mettre sous un puissant projecteur, pour ré-activer les panneaux solaires relativement dépolis, mais ce projet aurait nécessité de disposer du matériel de réception des données transmises par la balise en temps normal. En effet cette balise, quand elle est alimentée par sa batterie, relève divers paramètres environnementaux (position, vitesse de déplacement, pression atmosphérique, température…) qu’elle stocke dans une mémoire tampon qui se décharge via fréquences radio de courte portée dans des récepteurs installés par les ornithologues autour des lieux de vie des animaux suivis.

Mais en l’absence de la partie « réception », la balise ne communique pas. Et puis, même si les panneaux solaires étaient légèrement dépolis, il y avait fort à parier que c’était la batterie qui était défaillante, 9 ans après sa mise en service.

De l’extérieur, quelques pistes électriques étaient visibles, mais pas assez pour comprendre le circuit de l’engin. Perdue pour perdue, il fut décidé d’ouvrir la balise avec une lame tranchante, le long des points de soudure structurelle côté panneaux solaires. Une fois la boîte ouverte, il fut constaté que la manœuvre avait endommagé une partie du circuit, éliminant notre première piste.

Toutefois, il fut également possible d’identifier les divers composants de l’engin : antenne d’émission, batterie (relevée pour la photo), micro-controleur général (toutes les pistes électriques convergent vers lui), une puce non identifiée, la mémoire EEPROM (avec ses huit grosses pattes), module de communication radio locale Zigbee (support bleu), module GPS (uBlox), antenne fractale (siglée d’un motif à triangles)… Il y a encore un baromètre quelque part, mais nous ne l’avons pas identifié. Et pour la suite, c’est la puce EEPROM qui nous intéressait, c’est elle qui stocke les données entre deux transmissions locales.

Il s’agissait d’une EEPROM SST25VF032B de 4 Mo. La puce fut confiée à l’un de nos adhérents qui se chargea de la dessouder du circuit électronique de la balise pour la ressouder sur un étrier de connexion (support bleu sur la photo suivante) à un programmateur d’EEPROM (modèle XGecu TL866II blanc et vert, qu’on va s’employer à faire tourner sous GNU+Linux au cours des prochaines séances…). Les données furent récupérées sous la forme d’un unique fichier binaire de 4 Mo.

Une fois le fichier extrait, nous nous sommes employés à retrouver un sens à ce que l’on pouvait voir dans un éditeur hexadécimal. En parallèle, nous avions contacté le fabricant de la balise pour lui exposer notre cas et lui demander des informations quant à la structuration des données de la balise en EEPROM. La réponse du constructeur fut simple : « c’est non documenté et imprévisible ; la seule méthode pour récupérer des données est de ré-alimenter la balise en présence d’un récepteur. » Oups…

En y regardant de plus près, les données étaient en texte simple et il s’agissait de trames CSV stockées sans ordre apparent dans la mémoire. Les trames étaient pré-fixées par un type de trame (A00, A01… G00, G01) et comportaient environ une dizaine de champs. Nous nous sommes concentrés sur les trames G00, car elles présentaient des valeurs identifiables à des coordonnées GPS, horodatées.

Une fois ces trames isolées, il est apparu qu’elles représentaient plus de la moitié du contenu de la balise, dans notre cas pour un total de 42 212 trames G00 dont nous avons pu interprêter et remettre en forme 6 champs (sur les 22 espérés par notre commanditaire). Après raffinement de ces données brûtes (par ré-écritures successives des champs) nous avions un fichier CSV contenant les données les plus importantes importables dans la base de donnée du GODS.

Exemple de trame G00 :
G0,010617,102144,-4016766,462176276,44,,356,8,71,13,5

Ré-écriture de la longitude (le 3e champ) via vim :
%s/,-(\d[^,]*),/,-0.\1,/

Mais nous avons poussé ce travail jusqu’à disposer d’une trace GPX valide, directement importable dans JOSM, un logiciel utilisé pour éditer la base de donnée du projet OpenStreetMap.

Exemple de présentation des données d’un point d’une trace GPX :

<trkpt lat="46.2176276" lon="-0.4016766"><ele>44</ele><time>2017-06-01T10:21:44Z</time><speed>0.00</speed></trkpt>

Sont alors apparues les pérégrinations d’une outarde cannepetière dans la plaine de Niort, relevées en 42 211 mesures valides entre mai 2017 et novembre 2017 :

Dans cette capture d’écran de JOSM, le dégradé de couleurs marque le temps qui passe et permet de suivre l’oiseau sur ses lieux de vie successifs.