Connecter un arduino mkr fox à OpenWindMap

dam74

je précise la fin de "data" :
U = batteryVoltage /100 + 2 Volts
temperature en °C , octet signé
P = pressure + 850 hPa
humidity en %

@dam74 oui, le format de données est incorrect. Trop d’octets. Pour le moment, on ne supporte que le format décrit ici (vent uniquement).
https://forum.openwindmap.org/topic/202/format-messages-sigfox-de-arduino-vers-openwindmap

dam74

ah ok, 8 octets.
dommage car je pouvais suivre l'état de la batterie

dam74

j'ai vu sur le post https://forum.openwindmap.org/post/1203
que les pioupious envoyaient 3x4min de mesures. Dois-je faire pareil ?

pascal31

@dam74 les pioupious envoient toutes les 12 min 3 ensembles de valeurs. Par contre pour les Arduino, on ne peut faire que 2 ensembles (ou 1) toutes les 10min. Pas sûr de comprendre pourquoi, mais c'est comme ça pour le moment.

PS: Sinon une référence intéressante : https://build.sigfox.com/payload

dam74

@pascal31 OK merci, je modifierai mon code demain, là il pleut à torrents

nicolas

@dam74 @pascal31

Les Pioupious V1 transmettent toutes les 12 minutes. J'avais choisi cela de manière arbitraire, notamment pour respecter les contraintes réglementaires d'utilisation des fréquences 868MHz (Avec sigfox, maximum 140 messages / jour de 12 octets chacuns). Voir ici la notion de duty cycle / rapport cyclique autorisé : https://build.sigfox.com/sigfox-radio-configurations-rc

Mais cette configuration n'est pas vraiment compatible avec les standards de l'industrie et les recommandations WMO.

Entre temps, j'ai découvert qu'on pouvait faire 144 messages par jour avec Sigfox, soit un toutes les 10 minutes, si et seulement si on émet des messages d'une longueur plus courte.

140 messages de 12 octets : ok
144 messages de 12 octets : non
144 messages de 9 octets : non (12 octets réellement transmis)
144 messages de 8 octets : ok

Je pense qu'il vaut donc mieux se caler sur une transmission de 1x10 minutes ou 2x5 minutes. On sera plus cohérent avec le reste de l'industrie. Certes, on a un parc de Pioupious V1 qui fait du 3x4, mais ce parc va devenir minoritaire lorsque nous allons ajouter les stations de génération 2 et des autres constructeurs / autres réseaux.

D'un point de vue énergétique, 144x8 octets ou 120x12 octets, on est sur une consommation assez équivalente.

dam74

j'ai modifié mon code pour envoyer toutes les 10 min les 8 octets :
speedMin[0] , speedAvg[0], speedMax[0], directionAvg[0],
speedMin[1] , speedAvg[1], speedMax[1], directionAvg[1]

sur l'api http://api.pioupiou.fr/v1/sigfox-messages/922
les données reçues ont l'air crédibles
mais sur https://www.openwindmap.org/PP922
le graphique est bizarre !

je n'envoie pas les données dans le bon ordre je suppose, la vitesse moyenne correspond à la donnée de direction !

nicolas

typedef struct __attribute__ ((packed)) sigfox_wind_message {
        int8_t speedMin[2];
        int8_t speedAvg[2];
        int8_t speedMax[2];
        int8_t dirAvg[2];
} SigfoxWindMessage;

Ça fait, dans l'ordre :
speedMin[0], speedMin[1], speedAvg[0], speedAvg[1], speedMax[0], speedMax[1], dirAvg[0], dirAvg[1]

dam74

@nicolas c'est ce que je pensais , merci !

pascal31

Oui la norme ISM, c'est de ne pas occuper la fréquence plus de 1% du temps. Comme la trame sigfox dure 6s, ça fait 1 fois toutes les 10min.
Je suis parti aussi sur 2x4octets dans le code de la balise que je monte (à partir d'un capteur Peet Bros moins cher que le Davis mais peut-être moins solide, on verra). Je ne suis pas loin de tenter une première émission...

pascal31

Par contre, un peu dommage qu'on ne puisse transmettre des infos complémentaires une fois par jour. Par ex l'état de la pile ou autre. Est-ce qu'on pourrait prévoir une trame spéciale pour cela. Le premier octet pourrait indiquer au backend que c'est une trame spéciale et être ainsi aiguillé à part des mesures de vent...

pascal31

Bon pour les octets de vitesse tous les codes sont utilisés. Par contre pour les octets de direction on n'utilise que les codes de 0 à 179 (la direction a 2deg de résolution). Donc on pourrait avoir que si le dernier des 8 octets > 180 par ex, alors toute la trame est considérée comme spéciale. Ca laisse 7 octets pour passer toute sorte d'infos propriétaire dont la signification peut de plus être encodée de 180 à 255 par le dernier octet ! Ca fait pas mal de possibilités...

dam74

@pascal31 j'envoie une fois par jour 12octets, avec les données batterie, que je peux lire sur http://api.pioupiou.fr/v1/sigfox-messages/922

nicolas

Plus tard, on prévoira une option pour avoir une fonction de décodage custom.

pascal31

@dam74 oui j'avais vu cela dans ton code et comment ça se passe pour que les 4 derniers octets ne soient pas confondus avec les mesures de vent pioupiou à 12octets ?
En tous cas, si c'est ok j'utiliserai cette possibilité...

dam74

@pascal31 le message a 12octets n'est pas pris en compte, par contre il est sauvegardé et accessible par l API de Nicolas : d'ailleurs si cette API pouvait retourner 144 messages au lieu de 100, cela ferait 24h

GOELANDS D'AERIA

Bonjour,
Suite à la mort de notre Pioupiou N°91 qui a pris la foudre, j'ai entrepris la construction de la balise que Pascal a développé et gentiment partagé sur Github SWiMt. Cette balise est assemblée et j'ai récupéré les identifiants de la carte (ID et PAC). Pouvez-vous m'indiquer la marche à suivre pour la connecter à openwindmap? Il est indiqué d'envoyer un message privé a Nicolas, mais je ne trouve pas comment faire. Merci de votre aide et encore merci à Pascal pour son partage et son aide.
Bruno des Goélands d'Aeria (26).

dam74

@goelands-d-aeria bonjour, tu cliques sur Nicolas et dans le menu, tu choisis nouvelle discussion, c'est lui qui enregistre les cartes

GOELANDS D'AERIA

@dam74 Bonsoir et merci pour ta réponse, mais j'avais déjà essayé et quand je clique sur nouvelle discution j'ai une petite fenêtre qui s'ouvre qui indique :
"Error
This user has restricted their chat messages. They must follow you before you can chat with them"