Posts made by nicolas

@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;

// /!\ avec ce format, il faut transmettre
// impérativement deux périodes de 5 minutes
// xxx[0] -> de T-10 à T-5 minutes
// xxx[1] -> de T-5 minutes à T
// T étant l'heure de transmission

//  alternativement, pour transmettre 1 période / message :
// à la fréquence que vous voulez
// (maximum toute les 10 minutes)

// 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);
}

@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é.

Pour la protection de polarité inverse, on peut s'en sortir sans trop de pertes avec un MOS
https://www.ti.com/lit/an/slva139/slva139.pdf

En fait, l'idéal serait un connecteur :

• automatique, sans outils, comme le 9296
• autodénudant / IDC
• colorisé rouge / noir

J'ai commandé des connecteurs "automatiques" AVX 9296 pour tester.

Mail de Renaud : retour de la campagne de remise en état :

La plus part des soudures sont à reprendre à la moindre manipulation, avec le temps les fils ont perdus de leur souplesse et cassant aux soudures.

• Émission sigfox : 50-60mA pendant 6 secondes / toutes les 12 minutes
• GPS : 20mA pendant 30s à 2 minutes / 1 fois par jour / repos : hors-tension
• MCU + capteurs : conso moyenne 6uA. Petits pics très brefs.

@nicolas said in PiouPiou 180 Conso excessive.:

Je viens de mesurer les consos sur un Pioupiou fonctionnel :

• À l'allumage, led fixe : 18mA
• À l'allumage, led fixe, transmission Sigfox : 53mA
• À l'allumage, led qui scintille, GPS actif : 20mA
• En marche normale, hors transmission : 6µA (=0,006mA)

Oui, les données vont être transmises (à zéro) même si l'appareil est ouvert et n'a pas d'hélices.

Ressources :
https://www.ti.com/lit/an/slva678/slva678.pdf
https://www.cap-xx.com/wp-content/uploads/2015/04/Using-a-Supercapacitor-to-Power2.pdf
https://www.ti.com/lit/an/slvaev9/slvaev9.pdf