Codage des données météo sur nos stations automatiques.

-

Format du codage des données dans les chaînes de transmission.

Petit rappel informatique de base :

L'élément principal transmis est en général un caractère (numérique ou alphanumérique) représenté par sa valeur (son "poids" binaire) dans un octet.

Un octet est composé (comme son nom l'indique) de 8 bits.
Chaque bit a un "poids" suivant sa position dans l'octet :



Cela a été considéré comme suffisant au débuts de l'informatique, pour des communications générales puisque tous les caractères étaient représentés (du moins les principaux) dans le code ASCII. D'autres codes plus complets ont vu le jour ensuite, en en confiant la représentation à 2 octets, au lieu d'un.

Si donc votre correspondant vous envoie "A9", votre ordinateur reçoit un paquet de données binaires "10000010 10011100" qu'il transformera ensuite en un "A" puis un "9"

En réalité, ce n'est pas tout à fait vrai, car l'usage veut qu'on transmette en premier les bits de "poids" forts - MSB - et en dernier ceux de poids faibles - LSB.
La chaîne sera donc : "010000001 00111001". Mais le principe est le même, c'est pour ne pas compliquer. De même que la transformation binaire -> hexadécimale (base 16), qu'il est inutile d'aborder ici !

C'est ce type de codage, universellement reconnu, qui est utilisé dans les transmissions de données météorologiques, entre des capteurs de température, d'humidité ou de vent, reliés à un émetteur, et la console de réception située à distance (appartement, local spécifique etc.), pour nos petites stations automatiques.

Ces chaînes seraient aisément décodables si une difficulté n'avait été rajoutée pour des raisons économiques :
La "mémoire" est actuellement le composant le plus cher de nos machines, quelles qu'elles soient, hormis bien sûr le processeur.
Les ingénieurs des fabricants de tous ces appareils qui mémorisent et/ou transmettent des données se sont donc attaqués à sa gestion la plus stricte, de façon à offrir des performances supérieures, si ce n'est des prix plus bas que la concurrence.

La première façon d'économiser de la place en mémoire est d'en utiliser le moins possible. Ou de remplir la même quantité avec plus d'informations.

Si vous avez un octet du genre "10000000" à transmettre, vous admettrez qu'il y a un énorme gaspillage à envoyer successivement sept 0 (perte de temps, et de place) alors qu'une formule du genre "1 +7°" serait plus courte et plus élégante. Manque de chance le ° est inconnu comme signe binaire !
Mais les informaticiens ont trouvé des clés, et les ont mises dans des tables pour régler le problème.

La seconde façon n'en est pas moins astucieuse !

Supposons que vous ayez une série de données exclusivement numériques à transmettre.
Dans notre bon vieux Code ASCII ci-dessus, on trouvera les valeurs numériques pour coder les 10 principaux chiffres :
0 = 30 (en notation hexadécimale),
1 = 31
2 = 32
3 = 33
…….
9 = 39

Transformons ces valeurs en binaire, comme dans le tableau ci-dessus, dans le sens MSB -> LSB
On obtient :

0 = 00011110 (0x128)+(0x64)+(0x32)+(1x16)+(1x8)+(1x4)+(1x2)+(0x1) = 30
1 = 00011111 (0x128)+(0x64)+(0x32)+(1x16)+(1x8)+(1x4)+(1x2)+(1x1) = 31
2 = 00100000 (0x128)+(0x64)+(1x32)+(0x16)+(0x8)+(0x4)+(1x2)+(0x1) = 32
3 = 00100000 (0x128)+(0x64)+(1x32)+(0x16)+(0x8)+(0x4)+(1x2)+(1x1) = 33
……
……
9 = 00100000 (0x128)+(0x64)+(1x32)+(0x16)+(0x8)+(1x4)+(1x2)+(1x1) = 39

N'est-il pas étrange que les 2 premiers bits de ces octets soient toujours à 0 ?
Non, bien sûr, puisque même la valeur la plus élevée, 39, est inférieure à 64 et à 128 !

Et les ingénieurs ont dit :"Puisque ces deux bits ne servent à rien, inutile de les inclure dans l'octet"
L'ennui, c'est qu'un octet doit faire 8 bits !
Donc 11110 (qui représente 30) ça ne veut "informatiquement" rien dire.

Mais, si on ajoute, à la place des 2 bits disparus, les 2 premiers bits de l'octet suivant (à qui on a enlevé aussi ses 2 bits inutiles !) on aura gagné 4 bits sur 2 octets et un octet complet au bout de 4 octets. Le tout étant de découper ensuite cette chaîne ininterrompue en …. octets de 8 bits chacun !
Mais qui ne veulent rien dire en eux-même.

Bien sûr, la station réceptrice connaît le codage et en extrait les valeurs réelles.
Malheureusement, nous simples observateurs des octets en question, et ne connaissant pas sur combien de bits sont codées nos données, nous ne trouverons jamais ces fameuses valeurs.

En plus, suivant le type de datas, certaines seront codées juste sur le nombre de bits nécessaires et les codages peuvent varier d'une ligne de transmission à l'autre.

À titre d'exemple, les 8 directions de vent n'ont besoin que de 4 bits (1 - 2 - 4 et 8 ) et les heures de 5 (1 - 2 - 4 - 8 et 16).

À moins de construire un programme de recherche séquentiel de décodage, qui ne garderait que les valeurs plausibles, ces données ne sont donc pas aujourd'hui interceptables par l'amateur.

À moins aussi d'aller faire de l'espionnage industriel chez les fabricants !
Ce qui n'est pas très beau, et même franchement laid !

Il vaut mieux faire marcher la machine à neurones …

AdM