Avec OpenGD77 sur mon MD-UV390, on peut afficher l’état de la batterie de deux façons dans le bandeau supérieur de l’écran: un pourcentage ou une tension. La tension n’est pas très parlante pour moi, et le pourcentage est vraiment fantaisiste.
La fonction qui donne le pourcentage restant de la batterie est une simple droite (0 % à 6,4 V, 100 % à 8,2 V), qui ne représente pas du tout la façon dont se décharge une batterie lithium-ion. J’ai d’abord voulu la remplacer par une courbe Li-ion « théorique », trouvée dans la documentation générique sur ces batteries. C’était encore pire: 50 % au bout de 10 h, 7 % alors qu’il restait encore 7 h 30, etc. Complètement farfelu.
Pour avoir un pourcentage juste, il me fallait mesurer la décharge de ma batterie, depuis la charge complète jusqu’à ce que le poste s’éteigne tout seul, quand la tension arrive à 6,2 V (environ 3,1 V par cellule, sans danger pour la batterie).
(Note: j’ai calibré la tension lue par le poste avec un multimètre avant de faire la mesure.)
Dans l’écran Radio Info, la première page affiche les deux valeurs (tension et pourcentage), et la sixième un graphique de décharge. Comme je ne me voyais pas rester les yeux rivés sur cet écran à prendre des notes pendant toute la décharge, il me fallait autre chose. J’ai donc pensé enregistrer les données de décharge de la même façon que le flux NMEA du récepteur GNSS peut être enregistré dans la mémoire flash. Et comme cette fonction d’enregistrement existe déjà, il suffit d’ajouter des lignes au journal existant au lieu d’en créer un autre. La norme NMEA prévoit des phrases « propriétaires » (elles commencent par $P) pour ajouter ses propres informations: les logiciels ignorent celles qu’ils ne connaissent pas, donc on ne casse rien.
Cette fonctionnalité demande deux petites modifications du firmware:
- le mécanisme d’enregistrement NMEA ajoute une ligne d’état de la batterie toutes les minutes;
- le réglage Options → General Options → GPS gagne une option: aux choix Off, On, NMEA et Log s’ajoute Log Bat. Cette nouvelle option Log Bat n’enregistre que l’état de la batterie, et prend donc peu de place dans la mémoire flash. En mode Log, les lignes batterie s’ajoutent aux données de position.
Une fois le firmware modifié et recompilé, on charge la batterie à bloc et on passe le poste en mode Log Bat. J’ai choisi de le faire dans un endroit sans réception GNSS (un bâtiment avec un toit en tôle; le récepteur a donc cherché des satellites pendant tout le test), réglé sur une fréquence FM sans trafic, pour que la décharge soit la plus régulière possible. Je n’avais pas trop fait attention aux réglages d’économie d’énergie avant le test: il s’est avéré que le mode Eco était désactivé (Eco Level: 0), avec une luminosité qui retombe à 5 % après 30 secondes sans interaction.
À mon grand étonnement, l’appareil a mis plus de 30 heures à se décharger dans cet état. Vraiment épaté. Pour information, j’utilise la batterie livrée avec le poste, dont l’étiquette annonce 7.4V/3600mAh/26.64Wh. Si elle tient vraiment sa capacité nominale, cela fait une consommation moyenne d’environ 120 mA en réception (3600 mAh / 30 h).
Restait à récupérer ces mesures. Le journal est dans la mémoire flash du poste, sans système de fichiers, et je n’ai pas trouvé d’option pour le lire dans qDMR, le CPS que j’utilise habituellement. J’ai donc écrit mon propre utilitaire, ogd77reader: un seul fichier Python, sans aucune dépendance, pour Linux et macOS. Il utilise la commande de lecture que le firmware officiel possède déjà pour le CPS, il marche donc aussi avec le firmware d’origine, et il ne fait que lire, jamais écrire. Poste branché en USB, une commande suffit:
./ogd77reader.py log journal
Elle produit une copie brute du journal, un fichier NMEA par session (lisible par GPSBabel, QGIS, etc.), et un fichier CSV avec toutes les mesures de batterie, prêt pour un tableur.
Le poste a enregistré une mesure par minute, soit 1808 mesures utiles entre la batterie pleine et la coupure, toutes en réception (aucune émission pendant le test). Voici ce qu’elles donnent, comparées au calcul d’origine d’OpenGD77 et à la courbe Li-ion générique:
| Tension | OpenGD77 d’origine | Courbe Li-ion générique | Mesuré | Temps restant (environ) |
|---|---|---|---|---|
| 8,3 V | 100 % | 95 % | 100 % | 30 h |
| 8,0 V | 88 % | 80 % | 81 % | 24 h |
| 7,8 V | 77 % | 68 % | 70 % | 21 h |
| 7,6 V | 66 % | 50 % | 59 % | 18 h |
| 7,4 V | 55 % | 30 % | 50 % | 15 h |
| 7,2 V | 44 % | 15 % | 38 % | 11 h 30 |
| 7,0 V | 33 % | 7 % | 23 % | 7 h |
| 6,8 V | 22 % | 4 % | 13 % | 4 h |
| 6,6 V | 11 % | 2 % | 5 % | 1 h 30 |
| 6,4 V | 0 % | 0 % | 2 % | 35 min |
| 6,2 V | 0 % | 0 % | 0 % | coupure |
La droite d’origine est un peu trop optimiste (5 à 10 points de trop dans la seconde moitié), la courbe générique beaucoup trop pessimiste. Les temps restants ne valent que pour ce test en réception au repos: en émission, ou avec un GPS qui suit des satellites, la batterie se vide plus vite. Le pourcentage, lui, reste juste, puisqu’il indique la part de charge restante.
J’ai remplacé la droite du firmware par cette table mesurée, dans ma version maison d’OpenGD77. Résultat: une batterie pleine affiche 100 %, 50 % veut vraiment dire qu’il reste la moitié, et 7 % ne cache plus 7 h 30 d’écoute. Et je sais maintenant que ce poste tient plus de 30 heures en écoute sur une seule charge !