Guest said in Changer la description d'une station:
Bonjour
Le pioupiou 1032 se superposerait sur la Balise FFVL du Pignu sur le site Spotair serait il possible de le déplacer un peu sur la carte de ce site ?
D’avance merci
Bonjour
Il faudrait plutôt contacter le développeur du site SpotAir.
En attendant de tout refaire, j'ai amélioré la page de consultation des mesures :
Plus qu'à ajouter des petites flèches sur le graph, pour la direction du vent.
-> https://forum.openwindmap.org/topic/205/refaire-un-graphique-pour-afficher-les-mesures/1
J'ai également fait en sorte que la carte mémorise le dernier endroit zoomé. C'est bien plus pratique.
Je n'arrive pas à croire qu'il eut fallut 7 ans pour enfin prendre le temps de faire ça !
J'ai développé une balise autonome pouvant être fabriquée facilement, à base d'Arduino MKR Fox et d'un anémomètre DAVIS.
Le logiciel est optimisé pour une très basse consommation : ~20µA en marche, hors émission. Cela permet de s'alimenter soit par un petit panneau solaire, soit sur des piles (autonomie de 2 ans ou plus avec des piles alcalines ou lithium).
Mesure du vent moyen/min/max + direction moyenne, avec transmission toutes les 10 minutes via le réseau Sigfox. Mesure de la température possible en option.
Budget matériel : ≤ 250 euros
Trois stations sont déjà en test sur le terrain depuis plusieurs semaines. Elles fonctionnent bien.
Une vingtaine de prototypes supplémentaires sont en cours de déploiement en France, Allemagne, Portugal, Autriche, Belgique et Suisse.
Quelques variantes, sur piles ou solaire : (ici, avec une prise USB externe pour les tests)
Comparaison avec des stations Pioupiou, MeteoWind, NetAtmo et LCJ (ultrason) :
@ray je vous ai envoyé un mail
Si c'est une MeteoWind que vous avez acheté chez Next Model RC, elle est déjà connectée au réseau OpenWindMap. Elle a un numéro 800 quelque chose (ex: 805). Le numéro est normalement inscrit sur un autocollant ou sur la notice.
Si c'est une MeteoWind achetée ailleurs, la procédure est plus complexe. On peut échanger par mail à ce sujet.
Les mesures sont ensuite consultables à l'adresse openwindmap.org/mw{NUMERO}, exemple : openwindmap.org/mw800
Pour qu'elle apparaisse sur la carte, il faut nous indiquer sa position : https://forum.openwindmap.org/topic/167/mettre-à-jour-la-position-gps/1
Pour changer la description sur la page des mesures, adressez-vous ici : https://forum.openwindmap.org/topic/66/changer-la-description-d-une-station/1
@pascal31 Oui, on peut choisir la puissance d'émission dans le soft. On peut imaginer ajuster celle-ci via un downlink sigfox, en fonction du niveau de signal moyen constaté. Sur le Pioupiou, actuellement, le module est configuré pour n'émettre qu'à 11dBm car l'antenne a un peu de gain et qu'on ne doit pas dépasser la limite réglementaire de 14dBm.
@jr peux-tu corriger la position et la description du 301 ?
Position : 45.11655820296315, 5.792623602119972
Le graphique présent sur OpenWindMap.org, pour afficher les deux dernières heures, est un peu dépassé.
Voici ce que j'imagine pour une nouvelle version :
date réglable, comme sur http://xavier.duv.free.fr/pioupiou/index.html?800
valeurs mini / max en fond, comme sur l'actuel
https://echarts.apache.org/examples/en/editor.html?c=confidence-band
couleurs de la courbe moyenne en fonction de la vitesse du vent, comme sur l'app pioupiou
https://echarts.apache.org/examples/en/editor.html?c=line-gradient
flèches de direction en bas du graph, comme sur l'app pioupiou
valeurs numériques affichées dans un tableau colorisé, comme sur windguru
Quel outil utiliser ? JS brut, Echarts, D3, un autre ?
Reçu et testé les connecteurs AVX "automatiques". Vraiment pas convaincu. Pas adapté à une utilisation démontable.
À la limite, on peut tenter les borniers à ressort / sans tournevis. Exemple : https://fr.farnell.com/phoenix-contact/ptsa0-5-2-2-5-z/terminal-block-wire-to-brd-2pos/dp/1792951
@jr Oui mais seulement lors du démarrage, et pas de manière fiable. Ça affiche parfois 3.6V alors que la pile est HS. L'idéal serait de pouvoir détecter et prévenir de l'usure au moins un mois à l'avance.
Ok, je vais récupérer une dizaine de piles en fin de vie, issues des SAVs Next Model RC.
Ça va permettre de faire des tests.
L'idée globale avec cette techno de batterie, c'est que la tension reste stable, mais la résistance interne augmente.
Il faut donc mesurer la chute de tension lors d'un appel de courant.
A priori, les transmission Sigfox devraient être lissées par la supercap.
La solution "zero budget énergétique", serait de mesurer la chute de tension pendant l'allumage du GPS. Mais c'est seulement une fois tous les X jours (voir même jamais si l'on ne relocalise qu'en cas de déplacement grâce à l'accéléromètre).
Possible d'allumer très brièvement la LED, par exemple une fois par heure. Juste le temps de prendre une mesure avec l'ADC. Mais est-ce que la pile réagit assez rapidement ? Il faudrait tester.
Une piste, également, du coté de ces deux fonctions :
uint8_t TD_SIGFOX_PowerVoltage (void);
Retrieve the power supply voltage measured during last SIGFOX transmission.
Returns the power supply voltage value during last SIGFOX transmission in 1/10s of mV plus 2 V if MSB is 0, or plus 3 V if MSB is 1.
uint32_t TD_SIGFOX_PowerVoltageExtended(void)
Retrieve the power supply voltage measured during last SIGFOX transmission.
Returns the power supply voltage value during last SIGFOX transmission in mV.
Le seul souci, c'est que ça mesure après le régulateur.
@ratamuse
Ou ce modèle, spécialement conçu pour notre type d'application et cette techno de batterie : https://www.ti.com/lit/ds/symlink/bq35100.pdf
Mais honnêtement, je ne suis pas très convaincu par cette solution. C'est cher, ça complexifie, et finalement ça ne mesure pas grand chose.
@tam Le boitier chauffe au soleil, donc la température mesurée ne veut pas dire grand chose. Je la garde juste en "diagnostic technique". On pourra par exemple tenter de modéliser l'usure de la pile en fonction de la température.
@tam effectivement, la doc dit ça :
https://github.com/Telecom-Design/TD_RF_Module_SDK/blob/master/lib/libtdcore/src/td_measure.c
/***************************************************************************//**
* @brief
* Accurately measure the Power Supply voltage or the temperature.
*
* @param[in] mode
* If true, measure the temperature, if false, measure the power supply
* voltage.
*
* @return
* The measured temperature is given in 1/10 degrees Celsius, the power supply
* voltage is given in mV. If ADC is not available, returns 0.
******************************************************************************/
Mais ça paraît cohérent avec mon code ?
https://github.com/pioupiou-archive/pioupiou-v1-firmware/blob/main/firmware/src/pp_monitoring.c
static void ProbeTemperature () {
float temperature = (TD_MEASURE_VoltageTemperatureExtended(true) / 10.);
if (temperature < tempMin) tempMin = temperature;
if (temperature > tempMax) tempMax = temperature;
tempAvg += temperature;
tempCount++;
}
static void ProbeVoltage () {
int32_t voltage = TD_MEASURE_VoltageTemperatureExtended(false);
if (voltage == 2000) return; // = reading has failed ?
if (voltage < voltageMin) voltageMin = voltage;
if (voltage > voltageMax) voltageMax = voltage;
voltageAvg += voltage;
voltageCount++;
}
@pascal31 Interne au module TD, donc après le régulateur. C'est d'ailleurs étonnant que ça nous sorte 3.6V, alors que le module est alimenté en 3.3V régulé. Doit y avoir un souci quelque part.
Voici le code que tu peux utiliser.
Avec ça, je pourrai te connecter facilement à notre backend.
// pour transmettre 2 périodes / message :
// message de 8 bytes
typedef struct __attribute__ ((packed)) sigfox_wind_message {
int8_t speedMin[2];
int8_t speedAvg[2];
int8_t speedMax[2];
int8_t directionAvg[2];
} SigfoxWindMessage;
// alternativement, pour transmettre 1 période / message :
// message de 4 bytes
typedef struct __attribute__ ((packed)) sigfox_wind_message {
int8_t speedMin;
int8_t speedAvg;
int8_t speedMax;
int8_t directionAvg;
} SigfoxWindMessage;
// pour l'encodage du vent sur 1 byte
// (code original du Pioupiou)
uint8_t encodeWindSpeed (float speedKmh) {
uint8_t encodedSpeed;
if (speedKmh < 10.) {
// 0 to 9.75 kmh : 0.25 km/h resolution
encodedSpeed = (uint8_t)(float)(speedKmh * 4. + 0.5);
} else if (speedKmh < 80.) {
// 10 to 79.5 kmh : 0.5 km/h resolution
encodedSpeed = (uint8_t)(float)(speedKmh * 2. + 0.5) + 20;
} else if (speedKmh < 120.) {
// 80 to 119 kmh : 1 km/h resolution
encodedSpeed = (uint8_t)(float)(speedKmh + 0.5) + 100;
} else if (speedKmh < 190.) {
// 120 to 188 kmh : 2 km/h resolution
encodedSpeed = (uint8_t)(float)(speedKmh / 2. + 0.5) + 160;
} else {
// 190 or + : out of range
encodedSpeed = 0xFF;
}
return encodedSpeed;
}
// pour l'encodage de la direction sur 1 byte
uint8_t encodeWindDirection (float direction) { // radians
direction = direction / M_PI * 180.; // radians to degrees
if (direction < 0.) direction += 360.; // -180-180 to 0-360+
// encode with 2° precision
// add 0.5 for rounding when converting from (float) to (int)
return (uint8_t)(float)(direction / 2. + 0.5);
}
Bonjour
A priori, tous les Pioupious que nous avions dans ce lot on été loués. Il n'y en a plus de disponibles pour le moment.
@Tam Attention également à la conso de la led à l'allumage. Pour le GPS, pas de soucis, il est pour le moment alimenté en direct sur la pile (ce qui n'est pas forcément mauvais - un pic de courant de temps en temps pour éviter la passivation de la pile).
La technologie de pile utilisée pour le Pioupiou V1 est très spécifique.
Contrairement aux piles usuelles, la tension ne faiblit pas avec la décharge. Elle reste à 3.6V. C'est seulement lorsque l'on tire du courant que celle-ci s'écroule.
Il arrive donc régulièrement que l'on ait un appareil en bon état, mais qui semble ne plus fonctionner. On sort la pile pour la mesurer : elle affiche 3.6V alors qu'elle est vide. Cela pousse à diagnostiquer l'appareil comme en panne, à tord.
Nous devons impérativement équiper le Windbird d'un système de mesure de la pile en charge. On pourrait par exemple mesurer la tension de la pile lorsque le GPS est allumé.