Réseau de capteurs de température sans fil LoRa

Je souhaite surveiller la température dans ma maison et aussi à l'extérieur, afin de bien connaitre les variations journalières et saisonnières, avoir une meilleure estimation des résistances thermiques, et mieux gérer la quantité de chaleur à injecter en hiver.

Je dois donc placer des capteurs de température dans divers endroits, non seulement dans la pièce principale, mais aussi dans le garage, la véranda, les combles (et juste sous les tuiles, la température en canicule doit être impressionnante).

Je possède déjà quelques capteurs et un récepteur que l'on trouve dans le commerce, mais c'est souvent limité à deux capteurs externes, et pas question d'enregistrer les données. Je me vois donc contraint de le faire moi-même, avec au moins une dizaine de capteurs et de quoi collecter les données et les stocker (datalogger).

De plus, je veux que ça marche sur pile pour l'émission, avec une autonomie d'au minimum une année, et si la réception marchait aussi sur pile, ce serait top.

Cela parait simple. Mais pas tant.

Il s'agit de choisir les composants qui constitueront le système.

Le système, que ce soit en émission TX ou en réception RX, sera centré sur un microcontrôleur de la famille MSP430 que j'ai l'habitude d'utiliser dans divers autres projets comme l'oxymètre de pouls ou ma pendule DCF77.

J'ai déjà des MSP430G2553 sous la main, autant m'en servir pour l'émission, je sais qu'on peut les mettre en sommeil avec une consommation ridicule, ce ne sera pas lui qui posera des problèmes.

Pour la réception, comme il faudra un afficheur et de quoi stocker les données, un modèle plus gros comme le MSP430G2755 déjà utilisé pour ma pendule DCF77 sera probablement requis.

Un capteur de température, c'est facile à faire. Dans le cas présent, comme je souhaite avoir une précision importante sans avoir à réaliser de calibration, j'ai décidé d'utiliser le TMP117 de Texas Instruments (son remplaçant le TMP119 est plus cher, sans avantage particulier pour mon application), qui présente une interface I²C, facile à connecter à un microcontrôleur.

Ce capteur n'est pas difficile : une alimentation entre 1.7 et 5.5 volts est suffisante, et on peut programmer divers modes de fonctionnement. 150 nA en veille, une consommation équivalente à 3.5 µA avec une lecture de température toutes les secondes.

La température est donnée sur 16 bits, soit 2 octets.

Comme je souhaite une consommation aussi faible que possible, un affichage avec du e-paper, du papier électronique, semble une bonne solution, sauf qu'il faudra que je me procure un écran, mais lequel ?

En attendant, j'utiliserai un vieux dogL128 de Display Visions, qui consomme peu et me servira pour mettre au point le système, mais surtout que j'avais déjà sous la main. Son interface SPI sera simple à mettre en œuvre, et ce sera très utile pour afficher l'état de la réception des données.

Enregistrer les données réclame une mémoire de masse, et le plus simple sera d'utiliser une carte SD, que l'on peut piloter relativement simplement via une interface SPI.

L'usage d'une carte SD permettra de récupérer simplement les données sur un PC pour les exploiter pleinement.

Du côté quantité de données, lire la température une fois par minute est déjà beaucoup, cela fera 2880 octets par jour, arrondissons à 3000 car on devra aussi stocker la date et l'heure, avec une dizaine de capteurs on arrive à 30 koctets par jour, soit 11 Moctets par an. N'importe quelle petite carte SD suffira. Mais certainement pas la mémoire du microcontrôleur.

Le plus simple pour moi sera de me resservir du code et du matériel déjà utilisé dans ma pendule DCF77.

Au moins, ça m'évitera d'entrer l'heure dans le système.

Mais il me faut trouver le moyen de transmettre la température, ainsi que la tension des piles histoire de savoir s'il faut les changer.

C'est le domaine nouveau pour moi, enfin du point de vue réalisation pratique (je sors de l'école des télécoms, quand même). Ceci dit, j'avais déjà réalisé dans ma jeunesse un petit émetteur FM avec un microphone, tout en composants discrets. Fin des années 70s.

Et là, c'est le drame car de nombreuses solutions sont possibles, je le sais car j'ai carrément fait un site sur les technologies de liaison, ayant eu à regarder ce qui existait avant ma retraite.

Sauf qu'il n'y a pas de miracle. Pour transmettre, il faut de l'énergie, et là j'aimerais que ça marche sur piles pendant au moins un an, voire plus si possible. Il va donc falloir regarder des solutions peu gourmandes, où on fera bien attention à la manière dont les informations sont émises. De nombreux laboratoires ont travaillé sur ce sujet, mais comment trouver une solution disponible « sur étagère », pas trop chère et que l'on peut utiliser facilement ?

J'ai déjà quelques thermomètres sans fil, qui consomment très peu, ils fonctionnent sur piles. Sauf que j'ai eu beaucoup de déconvenues sur la portée : ils fonctionnent avec peine à quelques mètres, disons d'une pièce à l'autre, et si un mur en béton se présente, alors c'est terminé, plus de communication.

Ces appareils sont généralement très rustiques et fonctionnent en tout ou rien sur la fréquence permise des 433 MHz.

Ces faits m'ont poussé à regarder d'autres solutions.

Il se trouve que j'avais quelques kits eZ430-RF2500 de chez Texas Instruments qui permettent de mettre en place une communication RF entre deux kits, avec une très basse consommation, et ils marchent sur piles.

Ces kits sont basés sur la puce CC2500 de TI connectée à un MSP430, travaillant dans la bande des 2.4 GHz, autrement dit la bande habituelle du WiFi, Bluetooth et consorts. Cela semble une bonne idée au départ, et TI propose même le firmware correspondant à ce qu'ils appellent le « SimpliciTI™ Network Protocol ».

Ces kits sont anciens, mais bon, cela devrait me permettre de voir si j'ai une chance de réaliser mon objectif de transmission, et dépasser les murs de ma maison. Il fut facile de les mettre en œuvre, c'est généralement bien fait chez TI.

Résultat : le moindre mur en béton bloque la transmission. C'est mal parti.

Je connaissais le protocole de communication LoRa essentiellement de nom, qui assure pouvoir couvrir des distances qui se chiffrent en kilomètres. Oui, des kilomètres, ce n'est pas une faute de frappe.

Si en plus la consommation électrique reste raisonnable, ça devrait le faire ! Et c'est dans cet objectif que le protocole LoRa « Long Range » a été conçu.

Donc une bonne occasion de la regarder droit dans les yeux, surtout qu'on est en mars.

LoRa est un protocole, autrement dit une méthode d'émission-réception en ondes radiofréquence (RF), proposé par la société Semtech.

LoRa désigne le protocole "de bas niveau", concernant le matériel. Il existe une couche supplémentaire qui s'appelle LoRaWAN (pour Wide Area Network) standard défini par la LoRa Alliance qui s'appuie sur le protocole de base, et je ne m'en servirai pas, je veux juste transmettre quelques bits. Si vous vous embarquez dans LoRaWAN et que vous débutez, eh bien vous serez vite perdu.

Le protocole LoRa peut fonctionner sur diverses fréquences (du genre 433 MHz, 868 MHz ou 915 MHz) mais il existe de nombreuses restrictions concernant celles qui sont utilisables, et qui dépendent du pays concerné. Vous pourrez les trouver sur Internet : Frequency Plans by Country, mais méfiez-vous et vérifiez sur des sites officiels si vous pouvez travailler dans telle ou telle fréquence.

En France (et souvent en Europe), c'est EU863-870 et EU433 :

• EU433 : 433.05 à 434.79 MHz avec au moins 24 canaux (le créneau de fréquence est divisé en sous-créneaux, les canaux). Les 3 premiers canaux sont 433.175, 433.375 et 433.575 MHz. Les autres canaux sont libres, mais avec une limite de transmission à 12 dBm et un usage de moins de 10% du temps.
• EU863-870 : 863 à 870 MHz avec au moins 24 canaux. Trois canaux sont définis à 868.10, 868.30 et 868.50 MHz. Pour les autres, il faudra vous renseigner avec le règlement de l'ETSI.

A priori, la consommation d'énergie est de l'ordre de 10 à 100 mA pour la transmission, et 20 mA pour la réception, avec des consommations de l'ordre du microampère en sommeil.

La modulation de l'onde porteuse peut porter sur une des trois composantes suivantes :

• L'amplitude : c'est l'ASK, et la version simpliste « tout ou rien » s'appelle l'OOK. Très souvent employée.
• La fréquence : la FSK ou la modulation de fréquence bien connue en radiophonie car procurant une bien meilleure qualité.
• La phase : le PSK est moins couramment utilisée, car plus délicate à mettre en œuvre.

LoRa module la fréquence, mais d'une manière très particulière, le Chirp Spread Spectrum (CSS). Un chirp en anglais est un gazouillement, un son dont la fréquence varie.

La fréquence va changer entre F_low et F_high en montant (up-chirp) ou en descendant (down-chirp), la variation entre ces deux valeurs étant la bande passante.

Un chirp est divisé en sections appelées chips, et c'est toujours une puissance de 2 appelée Spreading Factor (parfois aussi Sweep Rate). Par exemple, un Spreading Factor=4 divise le chirp en 2⁴ soit 16 chips. Ceci va permettre d'encoder 4 bits, puisque l'on a 16 valeurs, en faisant démarrer la fréquence à partir d'un des chips, par exemple en montant, quand on arrive au max, on repart de la fréquence basse pour terminer le signal.

De cette manière, la durée d'un chirp est toujours la même, la variation de la fréquence reste toujours dans la bande passante désirée, et on code plusieurs bits sur un slot de time, le chirp. Nous avons donc plusieurs paramètres que l'on pourra choisir, souvent en fonction de ce que l'on souhaite faire, de la distance ou de la vitesse :

• La fréquence de base
• La bande passante, différence de fréquence entre le minimum et le maximum. On peut voir ça comme un canal.
• La durée d'un chirp
• Le nombre d'étages, de chips dans un chirp, par exemple 16, ce qui fera un Spreading Factor de 4

Il est possible de faire du "hopping", c'est-à-dire changer de fréquence pour éviter d'occuper trop longtemps un canal. Ce sera rarement le cas, surtout pour des petits messages.

Mais attention, la durée d'un chirp et le Spreading Factor sont liés, on ne peut pas inconsidérément augmenter le nombre d'étages, de chips, dans une durée fixe. Sinon ce serait un miracle, on pourrait augmenter à l'envi le nombre de bits transmis dans un slot de time.

Et c'est également lié à la bande passante.

Si vous augmentez le Spreading Factor d'un cran, entre 2 et 3 par exemple, cela correspond à passer de 2 bit par chirp à 3 bit. Mais alors le temps double, et on pourrait caser 2 x 2 bits dans un chirp à 3 bits.

LoRa utilise fréquemment un Spreading Factor de 6/7 à 12, autrement dit de 6 à 12 bits par chirp.

Plus on augmente la bande passante, plus la vitesse de montée/descente de la fréquence augmente, et donc sa dérivée, ce qui permet d'augmenter le débit des données. Sauf qu'augmenter la bande passante vous expose aux interférences avec d'autres émetteurs...

Pour LoRa, on utilise souvent une fréquence centrale de 433 MHz avec une bande passante de 250 kHz, soit un chirp entre 432,875 MHz et 433,125 MHz.

Il existe également un autre paramètre, le Coding Rate. LoRa propose de la correction d'erreur afin de surveiller la qualité de la transmission, mais cela ajoute forcément des bits supplémentaires dans la transmission, la redondance requise pour voir si un bit se retourne pendant la transmission.

Les Coding Rates disponibles sont 4/5, 4/6, 4/7 et 4/8. Pour 4 bits utiles, on transmet en réalité 5, 6, 7 ou 8 bits, les bits supplémentaires servant à vérifier si la transmission est correcte.

Un paquet LoRa est divisé en plusieurs parties :

1. Préambule : 8 symboles par défaut (modifiable entre 6 et 65535) + 4.25
2. En-tête optionnel si l'option Explicit Header Mode est activée
   • Longueur de la charge utile (payload)
   • Coding Rate
   • Présence du CRC dans la charge utile (Cyclic Redundancy Check)
   • Le CRC de l'en-tête
   L'en-tête est transmis avec un Code Rate de 4/8.
   Pas d'en-tête avec un Spreading Factor de 6.
3. La charge utile fait au maximum 255 octets
4. puis son CRC de 2 octets si activé.

Le préambule, avec son quart de chirp, est particulier afin de le reconnaitre correctement :

On comprend vite que le récepteur devra avoir les mêmes réglages que l'émetteur en ce qui concerne le préambule et l'en-tête. Sans en-tête, il faudra que l'émetteur et le récepteur soient d'accord concernant sa longueur. Sans oublier la fréquence, bande passante et Spreding Factor.

Si LoRa propose la couche physique de base, des couches supérieures ont été standardisées dans le protocole LoRaWAN, au sein d'un consortium ou alliance.

J'ai deux octets à transmettre, plus un ou deux autres pour indiquer l'origine des données, aussi je ne vais certainement pas alourdir les échanges et gâcher de l'énergie. Je la dépenserai plutôt dans la fiabilité de la connexion.

La durée du paquet dépend de pas mal de paramètres, et la formule de calcul est donnée dans le chapitre 4.1.1.7 des spécifications du SX127x, une puce produite par Semtech que je vais utiliser.

Voici un tableau récapitulatif pour vous donner une idée, en fonction des paramètres principaux à savoir le Spreading Factor et la bande passante allouée. Les autres paramètres sont particuliers à mon application :

• Charge utile (payload) : 5 octets (ça n'est vraiment pas beaucoup)
• Implicit Header = pas d'en-tête (et donc pas de CRC)
• Préambule : 10
• Low rate optimization activé

Pour information, je sévirai sur la bande des 433 MHz.

Ces temps traduisent le débit obtenu. Notez que cela varie entre 6 millisecondes et plus de 15 secondes. Les valeurs peuvent devenir vraiment très importantes ! Surtout pour transmettre 5 misérables octets, soit 40 bits, et en éliminant le superflu...

Ces temps ne dépendent pas de la puissance d'émission, bien évidemment, ce qui en fait un paramètre indépendant. On pourra donc se demander s'il ne vaut mieux pas raccourcir le temps pour économiser de l'énergie, ça dépendra des résultats obtenus en réception.

Convaincu de devoir tester LoRa, il a fallu que je choisisse une puce particulière, ce qui n'est pas évident car il existe une pléthore de propositions.

La mise en œuvre est délicate car vous devez faire très attention aux connexions, en particulier le routage de l'antenne. Aussi il est nettement plus simple d'utiliser des modules déjà prêts, souvent adaptés à une fréquence particulière.

Pour rester basique, j'ai choisi la puce SX1278 de Semtech, qui est implémentée dans un module dénommé Ra-01 (le Ra-02 est le même, avec un prise antenne spéciale), fabriqué par une compagnie chinoise qui s'appelle Ai-Thinker. Ce module commence à avoir de l'ancienneté, est largement utilisé dans divers projets, ce qui devrait me faciliter la tâche de programmation.

Cette puce est plus particulièrement adaptée pour travailler dans la bande des 433 MHz, autorisée en France, certes largement encombrée par plein de petits appareils, mais avec une faible portée.

Émission TX

Réception RX

Il est probable que j'utiliserai une version plus grosse du MSP430 pour la réception, vu la quantité de textes à afficher. Pour l'instant, il s'agit de confirmer le fonctionnement de l'émission-réception.

• Le SX1278 s'arrange pour gérer son alimentation et requiert une tension entre 1.8 et 3.7 V pour assurer une puissance de sortie jusqu'à 17 dBm. Au-dessus, il faudra au moins 2.4 V.
  Sa capacité à générer une interruption si la tension devient trop basse n'est pas disponible en mode LoRa.
  En réception, il consommera plus d'une dizaine de mA, ce qui obligera à changer les piles trop souvent à mon goût, ou alors en mettre des très grosses.

  À noter : je ne comprends pas les fournisseurs qui indiquent un fonctionnement du module Ra-01 avec une tension minimale de 2.5 volts, alors que le schéma est simple, seule la puce de Semtech requiert une alimentation. J'ai essayé à 1.8 volt, et ça fonctionne très bien... Mais si on veut émettre à 20 dBm, il faut un peu plus de tension, c'est vrai.

• Le MSP430G2553 peut fonctionner à partir de 1.8 V, mais à 6 MHz maximum. Plus la fréquence est basse, moins il consommera. Ceci dit, comme je veux lire la tension d'alimentation, j'ai besoin de l'ADC qui réclame 2.2 volts. À 1 MHz, le MSP430 consommera environ ¼ de mA, autant essayer de le faire marcher à cette vitesse-là pour l'émission et cela fonctionne très bien.
• Le capteur de température TMP117 demande 1.8 V pour fonctionner largement. Il consomme 150 nA en veille, et 3.5 µA avec 1 lecture par seconde.

Conclusions :

• En émission TX, l'alimentation sera de 2.2 volts, avec un LDO pour réguler correctement, surtout que j'utiliserai probablement une supercapa et une cellule solaire quand ce sera possible. Sinon ce sera une pile lithium dont on pourra tirer toute l'énergie disponible (et plus) puisque l'on demande une tension très faible.
  Mais on va voir que les performances requises pour mon application à la maison vont canarder les temps de transmissions et donc la consommation de courant...
• En réception RX, la consommation de plus de 10 mA empêche un fonctionnement sur piles raisonnable. L'alimentation sera sur secteur, en 3.3 volts, cela facilitera les traitements et l'usage des périphériques.

J'ai refait un driver pour piloter la puce SX1278 avec le MSP430G2553, programmer le SPI sur le module USCI_A0 pour garder USCI_B0 en I²C à destination du capteur de température.

Il a bien sûr fallu réaliser deux prototypes, un pour émettre et l'autre pour recevoir.

La puce est capable de retourner non seulement le message reçu, mais aussi de donner les :

• RSSI Received Signal Strength Indicator
  À ne pas confondre avec les dBm émis (TX) bien que l'unité soit la même.
  Là, il s'agit de la réception (RX) qui est une indication de la puissance du signal reçu, mais ce n'est pas une valeur absolue que l'on peut comparer avec d'autres récepteurs. D'autant plus que cette valeur dépend du mode de réception, ce n'est pas la même chose en FSK et en LoRa.
• SNR Signal to Noise Ratio
  Autrement dit le rapport signal à bruit, en dB (pas en dBm, c'est un vrai ratio entre le niveau de signal RSSI et le plancher de bruit).

À l'usage, ces valeurs sont d'un intérêt relatif, le plus important est de correctement recevoir les messages.

Du coup, lorsque l'ensemble est en veille (je compte émettre quelques fois par heure), la consommation est de quelques microampères, ce qui sera très bien pour la longévité des piles.

La communication a fonctionné après quelques jours de travail, assez facilement du reste.

Par contre j'ai été déçu par les premiers essais concernant la portée, un peu mieux qu'avec le kit eZ430, mais bon, pas de ouf non plus. Mais bon, les paramètres étaient "au hasard" à ce moment-là.

J'ai réalisé les deux protos, émission et réception, afin de mettre au point les paramètres de communication dans les conditions objectives. Pour la réception, j'ai utilisé un afficheur dogL128 que j'avais sous la main, qui consomme peu, ce qui me permet de faire fonctionner l'ensemble avec des piles, ce qui est quand même commode pour tester la distance de communication (se déplacer avec l'émetteur n'est pas pratique, bien sûr, puisqu'il n'affiche rien).

J'ai relevé les consommations électriques suivantes, c'est principalement l'émetteur RF qui en est responsable :

Lorsque la transmission se termine, la consommation redescend à bien moins de 10µA, tout est en mode sommeil, seul le MSP430 tourne pour se réveiller après un temps programmable.

Le plus déroutant fut de trouver les bons paramètres pour obtenir la portée souhaitée, entre les pièces d'une maison, et entre la maison et le jardin. Je me suis vite rendu compte que le plancher en béton armé entre le premier étage et le rez-de-chaussée est un vrai obstacle, et dès que je sors dehors, plus rien ne marche.

J'ai réalisé une série de tests avec diverses valeurs de paramètres, en particulier en diminuant la bande passante et en augmentant le Spreading Factor, plus la puissance d'émission, et il a fallu pousser les valeurs dans les coins pour obtenir des résultats utilisables, et on est vraiment loin des kilomètres de portée annoncée.

J'ai fini par remarquer la corrélation directe entre les résultats de transmission et le temps de transmission. À 3 dBm soit 2 mW de puissance émise, voici l'impression générale :

Vous pouvez oublier le SF6, les résultats sont bien trop mauvais, et en plus, à 500 kHz, je recevais des messages intempestifs, certainement du bruit.

Du coup, la règle est relativement simple : à 2 mW, il faut pousser à fond vers 15.6 kHz, et SF11, avec des durées d'émission importantes. Car je suis obligé de choisir un jeu de paramètres qui marchera pour toutes les situations, je ne peux pas émettre avec plusieurs jeux différents, ou alors il faudrait plusieurs récepteurs...
Reste à espérer que ça marche mieux en augmentant la puissance d'émission. Cette fois, j'ai juste recherché la limite pour obtenir une réception correcte en fond de jardin.

Les résultats des essais indiquent clairement qu'il faudra une durée de transmission d'une seconde, je choisis 31.25 kHz et SF10. Je pourrai aussi réduire la puissance d'émission lorsque la distance se réduira, aussi je prévoirai de quoi choisir directement sur le hardware, localement.

On ajoutera un courant de veille de quelques microampères, mais ça n'est pas ça qui changera la face du monde. Il va falloir d'assez grosses piles pour une durée de vie d'au moins un an.

Ou de la récupération d'énergie, quand ce sera possible, et ça tombe bien, dans le jardin, j'ai beaucoup de lumière. Mais pas dans les combles, ni le garage.

Capacité pour conserver la tension

L'envoi d'un paquet requiert un courant assez important que la source d'énergie aura peut-être du mal à fournir. Cela peut arriver si jamais la résistance interne de la source est élevée, comme certaines supercapacités (ESR). Dans ce cas, la tension de 2.2 volts, normalement régulée par le LDO, aura tendance à chuter.

Comme les envois sont espacés, il serait souhaitable de limiter cette chute de tension néfaste, par exemple en utilisant une capacité suffisamment importante pour compenser. Mais de combien ?

La solution est simple si on considère qu'il faut stocker 81 mC, entre 2.2 volts et une tension basse que l'on peut fixer à 2 volts, ce qui nous fait 200 mV d'excursion. La formule Q=CV nous donne alors la capacité : 81/200 = 0.4 F. C'est une très grosse capacité, une supercap, que l'on pourra ajouter pour aider l'émission d'un paquet. Elle se rechargera gentiment entre les paquets. On fera attention à choisir une valeur faible de résistance interne (ESR).

Idéalement, elle pourrait remplacer la batterie en amont du LDO. Dans ce cas, il faudrait que la récupération d'énergie soit capable de fournir 81 mC, ce qui nous fait 135 µA en 600 s, soit 10 minutes. Cela nous donne un ordre de grandeur, et on n'oubliera pas que la nuit, les cellules solaires marcheront nettement moins bien...

Capacité énergétique

J'ai déjà parlé des capacités énergétiques dans mon article sur les clignoteurs ultra-basse consommation, et j'en reprends le tableau ici, pour rappeler quelques valeurs utiles, même si ce ne sont que des ordres de grandeur (cela varie un peu d'un constructeur à un autre).

La durée de vie :

On comprend vite qu'avec une consommation en réception supérieure à 10 mA, il faudrait changer les piles AAA tous les 4 matins. Donc on passera en alimentation sur 220V.

En ce qui concerne l'émission, nous avons vu que l'on pouvait arriver dans la centaine de microampères, et donc deux piles AAA feront l'affaire pour un an. Reste à espérer que je pourrai diminuer la puissance d'émission, et/ou réduire la durée d'un paquet dans la configuration finale, mais cela permet de donner un ordre de grandeur pour la conception.
Une pile bouton pourra convenir si jamais la distance avec le récepteur est suffisamment faible pour réduire la puissance. Je prévoirai donc diverses options sur le circuit imprimé.

Récupération d'énergie

Comme je vais aussi parler de cellules solaires pour récupérer l'énergie, voici un petit récapitulatif :

référence	temps couvert	soleil max	surface
Sanyo AM1437 amorphe	144 μA 3,0 V	2 450 μA 3,3 V	12x30 mm 4 cellules
Ixys monosilicium	700 μA 0,48 V	17 000 μA 0,58 V	7x22 mm 1 cellule
Solems 5/48/16 amorphe	90 μA 3,34 V	6 600 μA 3,9 V	16x48 mm 5 cellules
Vishay TEMD5080 diode PIN	25 μA 0,35 V	1 022 μA 0,55 V	2.8x2.8 mm 1 cellule
Vishay TEMD7000 diode PIN	60 μA 0,40 V	1 400 μA 0,52 V	0.5x0.5 mm 1 cellule

En pratique, les capteurs de température ne seront jamais au soleil. Des cellules amorphes pourraient faire l'affaire, probablement avec une bonne taille, à l'extérieur. À ce moment-là, autant utiliser des batteries rechargeables NiMH à la place des piles, et je pourrai toujours les recharger si jamais la tension descend trop.

Le plus simple sera de mettre les cellules en parallèle sur la batterie, avec une tension un peu supérieure à celle des batteries, ce n'est pas ce faible courant qui viendra la perturber, et inutile de s'encombrer avec une puce spécialisée dans la récupération, qui optimiserait le point de fonctionnement. On ne cherche pas le rendement, il suffit de prendre assez grand pour que ça marche.

Supercapacité

C'est encore plus simple si on remplace la batterie par une supercapacité. Cette fois, il faut prévoir un fonctionnement de 16 heures sans recharge (pire cas), avec une tension qui reste supérieure à 2.2 V en permanence. La limite supérieure d'une supercapacité est souvent de 3 volts, ce qui nous laisse 700 mV d'excursion (ce n'est pas beaucoup, on exploite peu toute la capacité). Dans ce cas, pour assurer un courant de 100 µA pendant 16 heures, ça nous fait une charge de 5.8 C. Sur 700 mV, il faut alors une capacité de plus de 8 F, ce qui est gros (en taille).

En exploitant mieux la supercapacité, par exemple à partir de 1 volt, alors on aurait 3 fois plus de charges disponibles, elle pourrait être trois fois plus petite. Cela peut se faire en prévoyant un circuit élévateur de tension, mais ils présentent souvent un rendement assez faible pour de petits courants.

Mais bon, on trouve assez facilement des supercapacités de dizaines de Farads avec 4 ou 5 volts de tension maximale. Elles sont assez grosses, et les prix sont devenus plus raisonnable que dans le temps, quelques euros. Ce sera une option externe que j'envisagerai une fois que la configuration finale sera connue.

La supercapacité n'a d'intérêt que si on peut récupérer de l'énergie tous les jours.