Enregistreur pluviomètre

Bonjour,

Comme suggéré dans un autre fil de discussion, j'ouvre une discussion spécifique à mon projet.

Donc, je dispose d'un pluviomètre à auget basculant Peet Bros installé à Madagascar. Pour des questions de logistique, je ne peux relever le pluviomètre qu'une fois par an et encore, pas systématiquement. J'ai utilisé un enregistreur du commerce mais, au bout de deux ans, au second relevé, après changement de la pile, il n'a pas redémarré. Je me suis alors dit que ça pourrait être intéressant de faire un enregistreur à base d'arduino.

Donc, cahier des charges court-terme :

  • enregistrer l'heure à la seconde près des basculements de l'auget, détectés par un contact magnétique
  • 2 ans d'autonomie
  • 8000 basculements/an (2000 mm de pluie)
  • jusqu'à 55°C dans le pluviomètre
  • case instrument cylindrique : diamètre 57 mm, hauteur 80 mm (avec marge possible)

À plus long terme, prévoir pour des coins plus humides (6000 mm/an on va dire) et pour le pluviomètre chinois ici.

À partir de ça et compte tenu de mon expérience (nulle) en arduino et de mon temps disponible très limité, je pensais à une solution avec un processeur M0, plus particulièrement le Mini Ultra Pro de Rocket Scream couplé à une batterie Li 18650 amovible. Avantages:

  • faible consommation de 20µA qui devrait permettre de tenir une dizaine d'années sur la batterie
  • gestion intégrée de la batterie
  • 2 Mo de mémoire flash pour le data logging (plutôt que du (micro)SD qui a tendance à beaucoup consommer)
  • port USB intégré pour charger directement le code
  • horloge RTC intégrée au processeur (mais sans sauvegarde)

En redirigeant le 5 V à l'aide d'un pont diviseur sur une entrée du proc, détecter quand on passe en alimentation USB externe et entrer dans un mode interactif sur le terminal pour régler l'heure et gérer/récupérer les données (à l'aide d'un programme à faire sur tablette windows/x86 ou autre).

L'utilisation d'une batterie Li 18650 amovible permet d'arriver avec une batterie de remplacement chargée et de faire l'échange rapidement (en étant alimenté en même temps en USB pour ne pas perdre l'heure).

Dans les incertitudes, il y a la consommation réelle et l'auto-décharge de la batterie, en particulier dans il fait chaud dans le pluviomètre.

Mettre tout ça dans une boîte étanche.

Si vous avez des remarques à faire sur mon projet ou des propositions d'autres solutions, n'hésitez pas :slight_smile: .

2 ans d’autonomie

faible consommation de 20µA qui devrait permettre de tenir une dizaine d’années sur la batterie

L’auto-décharge des LITHIUM-ION n’est pas négligeable. Cela m’étonnerait que l’autonomie dépasse 18 mois.

+1

Quand on tombe dans des courants de cet ordre l'auto décharge devient significative, voire prépondérante, et ne peut plus être négligée dans l'estimation de l'autonomie. Elle s'accroit avec la température..("jusqu'à 55°C dans le pluviomètre") et la protection interne des accus contribue également à cette auto-décharge.

Elle va forcément s'autodécharger lentement (5% à 10% de sa charge par mois selon son âge et la température), c'est pourquoi il faudra la recharger et s'en servir de temps en temps pour éviter une décharge totale et destructrice - ce n'est pas une batterie Ni/Mh.
L'autodécharge n'est pas linéaire et diminue dans le même rapport que la charge restante.
Vous entendrez peut-être parler d'un taux de 1% à 2% par mois, mais il s'agit des accus Li-ion bruts, sans le circuit de protection qui rajoute 3%.

Source : Tout sur la bonne utilisation des batteries Li-ion - Portable - Ordinateurs portables - FORUM HardWare.fr

Alternative : Les piles ( primaires) Li-SOCl2, série LS ou LSH de Saft ou de la concurrence sont excellentes sur ce plan (la perte de charge est estimée à 1% par an à 20°C) . Bonne tenue aux températures élevées.
D'accord ce n'est pas rechargeable mais dans le contexte....... :wink:

Batterie amovible ? soigner la qualité des contacts dans la durée vu l'ambiance.

Carte de Rocket Scream ? il me semble qu'ils maîtrisent le sujet !!

MarsaMatruh:
Bonjour,

Comme suggéré dans un autre fil de discussion, j'ouvre une discussion spécifique à mon projet.

  • case instrument cylindrique : diamètre 57 mm, hauteur 80 mm (avec marge possible)

Bonsoir
Bon TON TOPIC à TOI , c'est quand même mieux :grin:

Donc 0.25 dm3 ~ de dispo pour embarquer le systéme complet

ton volume d'instrumentation est contraint par quoi ? , c'est le cylindre avec l'obturateur bleu sur cette illustration ?

Comme déjà soulevé par Henri et Al1 , le point dur c'est l'autodécharge du bloc "énergie" une fois sur site.

pour le reste tu a besoin en log d'une info du genre timestamp unix (32 bits de log ) par basculement

Il faudra aussi embarquer de la redondance , à chaud je dirais au moins 2 RTC et 2 mémoires physique différentes .

Je me suis souvenu que les anciens ? pluviomètres utilisés en aéro etaient des pluviomètres à augets , mais dont le contact de basculement était réalisé par du contact mercure.

Pour être très franc , je ne sais pas du tout ce qui est utilisé comme techno aujourd'hui " l'instrumentation météo" ce n'est pas dans mes compétences , je vais me renseigner rapidement sur ce qui ce fait actuellement 8)

To be continued

Oui, la case instrument est le cylindre sous le bouchon bleu.

Pour l'énergie, je n'avais pas bien évalué l'autodécharge. J'avais lu dans un coin 1% par mois mais je découvre dans tous les autres coins plutôt 10%/mois :confused: (y compris sur les fiches techniques des batteries vendues par adafruit) . Pour le coup, la solution batterie est morte. Sauf que les cartes Rocket Scream n'ont leur faible consommation que lorsqu'elles sont alimentées par la batterie. Je peux remplacer la batterie par une pile mais, à ce moment là, je ne peux plus utiliser l'USB et la pile en même temps (ça va charger la pile). Je ne peux alors plus régler le RTC en utilisant l'USB car il faudra couper le courant en repassant sur la pile. Soit je me passe de RTC en notant l'heure de mise en service (voir en versant de l'eau après le démarrage et avant l'arrêt en même temps que je prends une photo pour bien mémoriser. C'est ce que je fais déjà :grin: par sécurité mais c'est un peu lourd et pas top pour la cohérence des données). Sinon, j'utilise un RTC externe. Mais quand je regarde la fiche du DS3231, je vois Standby Supply Current à 110 µA (max). Ça commence à faire beaucoup sans être catastrophique (une batterie LS 17500 de la Saft a une capacité de 3.6 Ah soit 3 ans). Il ne faut pas se rater. Des suggestions?

Quant à la redondance, c'est peut-être un peu abusif pour un petit projet de science amateur actuellement. Mais, dans mes rêves, au démarrage, le RTC interne du M0 va chercher l'heure du RTC externe puis on coupe l’alimentation du RTC externe (avec un transistor?). À chaque impulsion de l'auget, on enregistre l'heure du RTC interne, on allume le RTC externe (on attend un peu), on enregistre l'heure du RTC externe, on éteint le RTC externe. Et si j'ai bien compris, on a aussi mémoire flash interne au processeur et mémoire flash externe sur la carte.

Commutation pile/USB : un PMOS en série avec la pile, passant en absence de 5V USB, bloqué en présence de 5V USB. Moins élégant : une diode schottky en série avec la pile evite sa charge.

RTC externe : d'autres circuits , dépourvus de quartz interne compensé en fréquence , ont des consommations plus faibles : par exemple le PCF8563 qui , sous 3V et I2C inactif tourne à 0,65 µA maxi sur une plage de température étendu. Microchip a sans doute le même genre de RTC externe 'frugal'

MarsaMatruh:
Oui, la case instrument est le cylindre sous le bouchon bleu.
...
Pour l'énergie, je n'avais pas bien évalué l'autodécharge.
...
J'avais lu dans un coin 1% par mois
...
Sauf que **les cartes Rocket Scream **

:grin:

Pourquoi, fais tu une "fixette" sur cette carte ? :smiley:

A suivre , donc !
"Se coucher tard ... nuit ! " :grin:

Les nouvelles batteries NI-MH ont un taux d'auto-décharge faible. Il s'agit des batteries LSD (Low Self Discharge). Il serait intéressant de trouver des spécifications.

Quelques infos intéressantes : Review: Testing Sanyo’s Eneloop Low Self-Discharge Rechargeable Battery

Apparemment une température élevée pose également problème.

Pour l’alimentation, une fois sorti des batteries Li-ion ou Li-poly gérés par la carte, je ne fais pas de fixation sur les batteries, bien au contraire. Ça ne me dérange pas une fois par an de remplacer la pile usagée par une neuve.

Concernant les NiMH à Faible Auto Décharge (FAD), je suis depuis longtemps le topic sur hfr. Les FAD se déchargent au début puis se stabilisent à 2/3 de leur capacité… au moins pour des températures ambiantes raisonnables.

Je peux aussi mettre deux piles alcalines ou Li en série mais c’est plus encombrant. Cependant les piles Li-SOCl2 de la Saft paraissent pas mal. Elles ont l’air d’avoir une décharge avec un plateau de tension très plat. La tension de cellule augmente avec la température. La question demeure surtout d’empêcher la charge des piles avec une commutation comme proposé par al1fch. J’ai un petit doute par rapport à la diode schottky qui va me baisser un peu la tension de service de la batterie. Néanmoins, quand je regarde les caractéristiques des composants utilisés dans la carte sur laquelle je fais une fixette :wink: , je vois pour la gestion de la batterie (BQ24074RGTT) 70 mV de perte à 3V/50°C et pour le régulateur en sortie (MCP1700T-3302E/MB) quasi rien (<<0.01 V) à courant nul (<1 mA). Je pars de 3,6 V. Je dois arriver à 3,3 V. J’ai le droit à 200 mV de perte pour la diode. Correct?

Bonjour
j'ai eu qq soucis pour ouvrir correctement le schéma de la carte Mini Ultra Pro,
Il me semble que la pile LiSOCl2 avec sa diode série pourrait être branchée sur l'entrée du régulateur MCP1700 et non a la borne BAT du circuit intégré BQ de charge.
Mais bien entendu la perte de 200mV dans la diode schottky fait hésiter !!

Ça pourrait être possible en allant se brancher sur V.BUS. Je me demandais si le circuit de gestion de batterie allait aimer. Sur le forum ti, il y a une question qui ressemble: est-ce que si on met du 5 V sur la sortie, ça pose problème? Oui, ça va charger la batterie en 5 V (je n’aurai rien de branché sur la sortie batterie :slight_smile: ) mais, sinon, on est dans les Absolute Maximum Ratings (voltage at OUT can be in the –0.3 - 7 V range). Je crois que ça va se tenter.

Par ailleurs, pour le circuit de régulation de la batterie, la chute de tension est de 70 mV pour 1 A de charge aval. C’est peut-être moins à 20 µA…

Bonjour

Les points"durs" contraignants ayant été posés :

  • dimensions case équipement
  • autodécharge du bloc énérgie

la phase qui s'annonce maintenant est donc de définir exactement

ce qui doit constituer le systeme complet, nécéssaire ET suffisant, pour déterminer sa conso systemique.

Comme dans toutes choses, ce sera In fine une affaire de compromis pragmatiques. 8)

Je pose là en "vrac" ce qui est ma vision/perception à cet instant

Le système doit etre autonome en énergie mini 2 ans

au bout de ces 2 ans (ou avant), il peut être procédé à la récupération des data loggé (la charge utile d'info)

une info unitaire là c'est un timestamp : 1 timestamp = 1 basculement =1 volume connu de pluie récéptionné

( J'évacue pour l'instant dans la discussion le log éventuel d'autres infos tel que T° et H° )

Ton systeme ne doit faire que des choses trés simples :

se reveiller lors d'un basculement , récupérer/générer le timestamp "actuel"
enregistrer au fil de l'eau ce timestamp
se rendormir et attendre un nouveau basculement

AMHA les 1eres nouvelles question importantes sont :

quel est le moins mauvais candidat (quelle "carte" et combien ? ) pour ordonnancer çà

ai je besoin d'une carte "couteau suisse" ou seulement d'une carte minimale ?

Par exemple quel est l’intérêt réel d'avoir sur site une carte capable de gérer de la recharge alors qu'il n'y aura jamais de recharge ?
la source d'énergie n'est utilisée qu'en fourniture !

Pour la redondance , c'est en ce qui me concerne un vieux reflexe pro qui veut que l'info utile soit absolument préservée (un peu d'info est toujours mieux que pas d'info du tout)

Au passage tu a évoqué comme exemple pour la RTC le DS3231, la conso que tu pointe de 150µ est une conso en situation alimenté en externe et en condition de dialogue I²c ,
le DS3231 en mode time keeping (juste alimenté par son Vbat) est beaucoup plus faible , j'irais au datasheet + tard

Tu n'a besoin de savoir/demander l'heure qu'il est :wink: , que lors d'un basculement

Pareil pour le systeme mémoire , il ne nécessite au pire que d'etre alimenté 1 fois par seconde pour écrire (et eventuellement véifier seulement qq octets (4 dans le cas d'un timestamp de type UNIX)

Son but final étant d’être dépouillé aprés la fin de mission

perso pour moi un systeme un petit peu secure coté redondance serait :
2 contacteurs de basculement distincts (ton systeme n'existe que par la detection unitaire de basculement)
2 fournisseurs de timestamp distincts
2 systemes de mémorisation distincts

C'était juste ma 1ere reflexion, il y en aura surement d'autres 8)

Le "vrai" boulot , commence maintenant :smiling_imp:

Artouste:
...
Je me suis souvenu que les anciens ? pluviomètres utilisés en aéro etaient des pluviomètres à augets , mais dont le contact de basculement était réalisé par du contact mercure.

Pour être très franc , je ne sais pas du tout ce qui est utilisé comme techno aujourd'hui " l'instrumentation météo" ce n'est pas dans mes compétences , je vais me renseigner rapidement sur ce qui ce fait actuellement 8)

To be continued

Et donc complément 8)

Je n'avais pas rêvé , j'avais bien vu "il y a déjà longtemps" :wink: des pluviometres de type auget sur site/installation aéro avec du contact basculant mercure

C'était les 1eres expérimentations des "enregistrement électrique automatique" (sic) , le "gros *" contact mercure basculant était simplement pris entre une batterie et 2 totalisateurs electromagnetiques à impulsion , l'un avec une RAZ mécanique qui devait etre faite à chaque relevé , l'autre avec la RAZ "plombée/condamné" , les relevés des 2 totalisateurs fait simultanément et à heure fixées permettait donc de detecter des problèmes d'enregistreurs.

La gestion de l'instrumentation MTO pour ce qui est des infos Aéro civile dépend de Météo France

  • je devrais (re)voir dans qq temps une vieille station équipée comme çà 8)

Disons que sur la question du couteau suisse versus le système fait main assemblé pièce par pièce par un artisan respectueux des traditions du fin fond de la forêt amazonienne malgache :grin: , j'aimerais bien faire un système avec un ATmega328P programmé sur carte UNO (ou autre) puis transféré sur un PCB maison avec uniquement les composants nécessaires. Je pense que le micro-ampère est approchable et que ça doit le faire sur une pile-bouton (exemple pour la température).

Mais, d'un autre côté, comme mentionné au début

mon expérience (nulle) en arduino et de mon temps disponible très limité

fait que j'ai déjà mis presque deux jours pour répondre à ce message :confused: . Je voudrais aussi faire quelque chose de (très) simple pouvant être reproduit par d'autres personnes ayant les mêmes centres d'intérêts que moi mais peu de compétences en électronique. C'est pour ça que le couteau suisse m'attire, eût-il une gestion de batterie sans intérêt pour le projet, un proc surpuissant et j'en passe.

Bonsoir

LoRADuino.png
j'utilise, avec ou sans module LoRa, cette petite carte (c'est en fait une Pro Mini 8Mhz 3,3V avec un régulateur AP 2112, une mémoire Flash SPI externe de 8Mbit et un chargeur d'accu Li-On Microchip MCP73381
Coût 4$ sans le port pour la version sans module radio LoRa

https://www.electrodragon.com/product/atmega328p-arduino-plus-lora-sx1278-board-loraduino/

je joins içi son schéma :

LoRADuino.png

MarsaMatruh:
Disons que sur la question du couteau suisse versus le système fait main assemblé pièce par pièce par un artisan respectueux des traditions du fin fond de la forêt amazonienne malgache :grin: , j'aimerais bien faire un système avec un ATmega328P programmé sur carte UNO (ou autre) puis transféré sur un PCB maison avec uniquement les composants nécessaires. Je pense que le micro-ampère est approchable et que ça doit le faire sur une pile-bouton (exemple pour la température).

Mais, d'un autre côté, comme mentionné au débutfait que j'ai déjà mis presque deux jours pour répondre à ce message :confused: . Je voudrais aussi faire quelque chose de (très) simple pouvant être reproduit par d'autres personnes ayant les mêmes centres d'intérêts que moi mais peu de compétences en électronique. C'est pour ça que le couteau suisse m'attire, eût-il une gestion de batterie sans intérêt pour le projet, un proc surpuissant et j'en passe.

Bonjour

le critére de conso au repos est évidemment le point primordial
Pour l'instant, tu es dans une phase de selection/sourcing, il faut passer les candidat en revue en pesant les avantages et inconvénients de chacun.
Ta dead line est (au moins pour l'instant :grin: ) assez éloignée pour bien prendre le temps de faire LA bonne selection

Al1 a exposé un candidat, il y en a encore à passer en revue 8)

al1fch:
Bonsoir

LoRADuino.png
j'utilise, avec ou sans module LoRa, cette petite carte (c'est en fait une Pro Mini 8Mhz 3,3V avec un régulateur AP 2112, une mémoire Flash SPI externe de 8Mbit et un chargeur d'accu Li-On Microchip MCP73381
Coût 4$ sans le port pour la version sans module radio LoRa

Atmega328P Arduino Plus Lora SX1278 Board, Loraduino R1.2 - ElectroDragon

je joins içi son schéma :

Bonsoir Al1
La mémoire spi onboard m'a fait repenser à l'ESP32-CAM d'un topic récent (arduicool)
Je me demande si une carte du genre ESP32-CAM (mais sans la cam :grinning: ) ne pourrait pas convenir ?

en accolant un DS3231 pour l'origine du timestamp , il y a déjà pas mal de chose utilisables

De même que je me demande si l'utilisation de SPIFFS pour le log n'est pas envisageable ?

Je n'ai pas encore assez de recul avec le concept , je crois que J-M-L avait pondu un tuto dessus (faut que je retrouve)

Perso je verrais bien un esp32 faisant du log timestamp en spiffs et pourquoi pas aussi dupliqué sur sd (hé hop ! une redondance :smiley: )

Les phases de demande d'énergie seront quand même bréves

A voir si l'esp est capable de fournir de l'alim suffisante par GPIO pour alimenter un DS3231 en phase comm I²C (pas le VBAT du DS3231) et une SD , je n'ai pas les limitations en tête.

A suivre donc

Tous les ESP32 sont obligatoirement associés à une Mémoire FLASH SPI (qu'on ne voit pas si l'ESP32 est sous capot métallique) Une puce ESP32 seule, sans cette mémoire Flah SPI externe ne peut fonctionner.

Toute carte à ESP32 fonctionnelle peut servir à enregistrer un gros volume de données , en utilisant au besoin SPIFFS.
Bonsoir Artouste

Une des particularités de la carte ESP32-CAM est la présence d'une RAM SPI ('pseudo statique') indispensable pour gérer les donées video volumineuses.
Dans l'application Enregistreur Pluviometre cette RAM SPI ne présente aucun d'intérêt et par ailleurs le régulateur 3,3V de ces cartes n'est pas des plus efficace.

En cas d'utilisation d'un ESP32 mieux vaut se tourner vers une carte dotée d'un meilleur régulateur 3,3V ( carte LOLIN D32 par exemple )

carte µSD...en atmosphère humide j'ai un doute sur la fiabilité des contacts.

al1fch:
Tous les ESP32 sont obligatoirement associé à une Mémoire FLASH SPI (qu'on ne voit pas si l'ESP32 est sous capot métallique) Donc toute carte à ESP32 peut servir à enregistrer un gros volume de données.

Une des pasrticularités de la carte ESP32-CAM est la présence d'une RAM SPI indispensable pour gérer eldonéens video. Dans l'application Enregistreur Pluviometre cette RAM SPI ne présente pas d'intérêt et par ailleurs le régulateur 3,3V de ces carts n'est pas des plus efficace

En cas d'utilisation d'un ESP32 mieux vaut se tourner vers une carte doté d'un meilleur régulateur 3,3V ( carte LOLIN D32 ou D32 PRO )

oui al1 , c'est comme aux échecs , il faut avoir un coup d'avance en réflexion :smiley: , j'etais déjà parti sur une carte sans regulateur 8) , il n'y a peut etre pas/plus besoin de régulateur si l'on fait de l'alim a partir de 2 piles 1.5V en série (taille/capa/autodécharge ? ) et pas de la rechargeable .

En fait il faut surtout que je bosse... le spiffs :smiley: et surement ses subtilités (le diable se cache souvent dans les détails) :smiling_imp:

Ce n'est là qu'une reflexion

A suivre

j'utilis des cartes minimales avec un ESP32 (module WROOM) sans inteface USB ni régulateur
je les alimente sous 3,2V avec un accu LiFePo4 18650. Consommation en deep-sleep 5µA


Pour la plie mieux vaut éviter de dépasser 3,6V (valeur absolue de la doc)