Précision des données et fréquence de mise à jour

[fat]

Bonjour,

en regardant le format des messages que les balises envoient à openwindmap sur le reseau sigfox, j'en viens à me poser la question suivante: Ne serait-il pas intéressant de réduire la précision des données remontées afin d'en diminuer la taille et donc de pouvoir augmenter la fréquence de mise à jour.

Sur mon android de dev, on envoie un message de 11 octets toutes les 10 minutes pour rester dans la limite de 140 messages / jour):

• wind speed min: 2 mesures sur 1 octet chacun
• wind speed moy: 2 mesures sur 1 octet chacun
• wind speed max: 2 mesures sur 1 octet chacun
• wind direction: 2 mesures sur 1 octet chacun
• température: 1 octet
• voltage batterie: 2 mesures sur 1 octet chacun

sur la version de pascal (https://github.com/pcaunegre/MkrfoxWindShield), on envoie un message de 12 octets toutes les 10 minutes pour rester dans la limite de 140 messages / jour):

• wind speed min: 2 mesures sur 1 octet chacun
• wind speed moy: 2 mesures sur 1 octet chacun
• wind speed max: 2 mesures sur 1 octet chacun
• wind direction: 2 mesures sur 1 octet chacun
• voltage batterie: 1 octet
• température: 1 octet
• capteur: 1 octet
• version du soft: 1 octet

la direction est encodée avec une résolution de 2.5°. n'est ce pas bcp ? En se limitant à 22.5°, on peut doubler la fréquence d'envoi de la direction du vent (ca tient sur 4 bits). Avec 22.5° on a une précision qui correspond à des mesures affichées traditionnellement de N à E en passant par NE et NNE. Ca semble amplement suffisant pour un grand nombre d'usages. Qui a besoin de connaître la direction du vent avec une précision à 2.5° ?

On peut faire le même raisonnement pour la vitesse. Qui a besoin d'avoir une résolution à 0.25km/h ?

Il serait intéressant de pouvoir proposer plusieurs options. Afin de pouvoir détecter la méthode d'encodage utilisée, il suffirait de:

• si taille de message < 12 octets, alors encodage actuel
• si taille de message == 12, alors on prend le dernier bit du message pour déterminer la version du protocole (ou le premier bit du dernier octets). A réfléchir.

pour le parapente, je trouve qu'il est plus intéressant d'avoir une fréquence plus élevée au détriment d'une grande précision. J'attends pas 12.46 +/ 0.5km/h et une orientation de 30° +/- 2° pour décoller.
Par contre voir la balise tourner ou varier en intensité toutes les 2.5 minutes c'est bcp plus intéressant que de l'avoir toutes les 5 minutes.

Après se pose aussi la question de l'augmentation du nombre de métriques à sauvegarder au niveau backend.

my 2 cents
++ Jérôme

[pascal31]

@fat (Petite rectification, sur MkrfoxWindShield on envoie 12 octets une fois par jour, et sinon 8 octets toutes les 10 min).

Dans l'absolu, on pourrait faire comme tu dis.

Après, le calcul du vent moyen est fait sur 5min, ce qui est assez fréquent (la norme en donnée MTO étant sur 10min). Et c'est ça qui compte, plus que des valeurs très fréquentes, il me semble, pour les différents usages du vent que l'on fait (aéro, voile, etc) pour être en sécurité.

[nicolas]

Il y a une restriction réglementaire sur le temps d'occupation de la bande radio.
On peut faire, au maximum :

• Soit 140 messages de 12 octets par jour.
• Soit 8 octets toutes les 10 minutes + quelques messages de diag et monitoring quotidiens

Pour moi, les paramètres version du soft et type de capteur ne doivent pas être envoyés à chaque fois. Un message au démarrage et/ou quotidien suffit.

J'avais fait des essais avec une balise GSM transmettant toutes les minutes. Mais c'était difficile à lire. C'était plus perturbant qu'autre chose, car ça faisait un graph avec trop de reliefs.

Effectivement, on peut réduire la résolution de la direction.
6 bits : 5.625°
5 bits : 11.25°
4 bits : 22.5°

À la limite, on pourrait faire :

• min1
• min2
• moy1
• moy2
• max1
• max2
• dir1[1:6], dir2[1:2]
• dir2[3:6], temp[1:6]