ESP controller en voeding sensoren

[bnwgraaf]

Ik heb een esp8266 controller, waaraan 6 of 7 sensoren komen te hangen (o.a. UV, infrarood, temperatuur, luchtdruk, ...)

Deze print zal voeding krijgen via twee kleine zonnepanelen, gekoppeld aan een batterijlader (CN3065) met daaraan een Li-Ion batterij.

De esp controller zal in deepsleep mode staan en één keer per minuut of paar minuten ontwaken, sensoren uitlezen en de data via WIFI naar Domoticz software versturen.

Nu dacht ik eerst de sensoren te voeden vanaf de 3.3V aansluitingen op de esp controller. Maar ten eerste vraag ik me af, of het niet te veel sensoren zouden zijn die spanning vanaf de esp zouden krijgen. Daarnaast heb ik ontdekt, dat de 3.3V pinnen op de print spanning blijven geven, ook wanneer de controller in deepsleep mode is en dus wordt continu de batterij leeg getrokken.

Ik heb ook een 3570.1210.051 "DIL-Reed Relay".
Kan ik nu een ground en een digitale pin van de esp aansluiten op de schakelaansluitingen van deit relais en de sensoren via de geschakelde aansluitingen van het relais rechtstreeks verbinden met de voeding (zodat de sensoren de voeding niet over de esp print krijgen)?

Ik heb al een keer getest en kan zo het relais schakelen via de esp en meet dan een stroom van 0.05 A.

Als dat zo kan, kan ik de Ground en Digitale pinnen van de esp rechstreeks op het relais aansluiten, of moet daar ook iets van een weerstand tussen?

[AlexanderB]

Daar hoeft geen weerstand tussen, maar het lijkt me wel flink overkill, een p-channel mosfetje had ook volstaan.

Let er ook ff op dat sommige 3.3v regelaars gruwelijk veel stroom trekken ook al slaapt de ESP, kan de moeite zijn om de ESP zelf gewoon direct op de lithium cel te hangen.

[bnwgraaf]

@AlexanderB
Dank je voor je snelle reactie. Je bedoelt dat het relais overkill is? Eerlijk gezegd heb ik net naar aanleiding van jouw reactie voor het eerst gelezen over een p-channel mosfet; hoewel ik in mijn leven wel meer "geprutst" heb met elektronica, ben ik zeker geen specialist en kan daar nog erg veel leren! :-)

Het genoemde relais heb ik echter nog liggen, vandaar.

Je opmerking over de regelaars heb ik ook over na zitten denken. Ik overweeg dan ook om een "kale" esp te gebruiken, zonder developer board. Ik heb begrepen dat dat ook weer scheelt in verbruik.
Je hebt het over rechtstreeks op de batterij aansluiten.
Ik heb de solar lader waar ook een uitgang op zit voor het aansluiten van de print (load). Ik wilde daar de esp op aansluiten, zodat deze gescheiden is van het laadcircuit en de lader op tijd stopt met laden als de batterij vol is.

Ook wist ik niet zeker of deze lader de batterij beschermt wanneer deze onder de minimale spanning terecht komt. Ik vroeg me dan ook af of ik een protectie printje voor de batterij moet zetten (volgens de beschrijving van de lader zou die nog benodigd zijn).
Voor de esp had ik dan een step-up module bedacht naar constant 5V.

Zie ook bijgaande afbeelding. Is dat een goede opzet, of ga ik ergens de mist in? Of is dit misschien ook overkill?

[bnwgraaf]

Overigens is dit de lader (van zomaar een website, niet waar ik hem gekocht heb)...
Als hij een beveiliging tegen overladen heeft, zou er dan niet ook een beveiliging tegen te lage batterij spanning zijn?
Wellicht kan ik een variabele spanning op de batterij aansluiting zetten en dan de spanning op de load/sys aansluiting meten en kijken of die plotseling naar 0V gaat wanneer de batterij spanning onder een bepaalde waarde komt...

[Voor 4% gewijzigd door bnwgraaf op 13-03-2021 21:59]

[AlexanderB]

Oke, ik zie wat je bedoelt, maar ik zou dat inderdaad een beetje anders aanpakken.

Die boost converter naar 5V is geen goed idee, zelfs als die 100% efficient was (en dat is ie niet) dan wordt de 5V terug naar 3.3V geconverteerd door het verschil op te stoken als warmte. Tevens goede kans dat de 5v naar 3.3 regelaar een flinke sluipstroom heeft, dus al met al gooi je makkelijk de helft van je zonne-energie weg om niks, en dat is natuurlijk zonde.

Ik zou de ESP8266 rechtstreeks met ongeregelde batterijspanning (3V~4.2V) voeden. Werkt in praktijk prima. Waar je wel ff naar moet kijken is of al de sensoren die je wil gebruiken daar ook tegen kunnen, of dat je daarvoor alsnog 3.3V nodig hebt.

---

Als de sensoren wel echt 3.3v nodig hebben heb je een paar opties.
* een 3.3V LDO (Low Drop Out) regelaar met een lage sluipstroom (quiescent current) gebruiken.
* De 3.3v regelaar van het dev bordje halen en schakelen met een uitgaande pin van de ESP of via een mosfet, afhankelijk van hoeveel stroom de sensoren gaan gebruiken.

---

Die oplader is eigenlijk vrij 'dom', hij regelt de uitgangsspanning (met enige tolerantie) en begrenst de laadstroom, maar verder doet ie niks. Je kan dit soort printplaatjes ook krijgen met ingebouwde protectie chip, of een los protectie bordje gebruiken. Overigens zitten de system en battery aansluitingen gewoon aan elkaar gekoppeld, dus die kan je aan elkaar tekenen in je circuit.

Ik weet niet welke zonnepaneeltjes je wilde gaan gebruiken, maar denk dat er nog wel wat te optimaliseren is.

[bnwgraaf]

AlexanderB schreef op zaterdag 13 maart 2021 @ 22:06:

Ik zou de ESP8266 rechtstreeks met ongeregelde batterijspanning (3V~4.2V) voeden. Werkt in praktijk prima. Waar je wel ff naar moet kijken is of al de sensoren die je wil gebruiken daar ook tegen kunnen, of dat je daarvoor alsnog 3.3V nodig hebt.

Super bedankt weer; ik heb nog genoeg te leren, maar dat was ook een doel van dit project! :-)

Ik begrijp dus dat de esp prima werkt tussen de 3V en de 4.2V (zoals van de Li-Ion komt). Maar sluit ik de batterij in dit geval dan rechtstreeks op de VCC/Vin van de esp aan en niet via de usb aansluiting, om zo de regulator te omzeilen, of begrijp ik dat verkeerd?
Is het in dat geval sowieso beter om een kale esp te nemen in plaats van een developers board?
Ik heb al eens van een kale esp een schakelaar gemaakt voor mijn Hue ledlampen, dus ik weet hoe die te programmeren...

Overigens zitten de system en battery aansluitingen gewoon aan elkaar gekoppeld, dus die kan je aan elkaar tekenen in je circuit.

Maar als ik het goed begrepen heb, en die twee zouden aan elkaar gekoppeld zitten, dan zou de lader mogelijk niet goed kunnen bepalen wanneer de batterij vol is, doordat er ook nog een "load" aan hangt met het risico dat de batterij overladen wordt. Ik dacht dat dit printje dat zou voorkomen.
Los ik dat probleem dan wel op wanneer ik het protectie boardje voor de batterij plaats, zodat de batterij binnen zijn toelaatbare minimum en maximum spanning blijft?

[bnwgraaf]

@AlexanderB
Ah, dit beschrijft nog eens wat jij al geschreven had, of niet?
https://randomnerdtutoria...ipo-and-li-ion-batteries/

[AlexanderB]

bnwgraaf schreef op zaterdag 13 maart 2021 @ 22:46:
Ik begrijp dus dat de esp prima werkt tussen de 3V en de 4.2V (zoals van de Li-Ion komt). Maar sluit ik de batterij in dit geval dan rechtstreeks op de VCC/Vin van de esp aan en niet via de usb aansluiting, om zo de regulator te omzeilen, of begrijp ik dat verkeerd?
Is het in dat geval sowieso beter om een kale esp te nemen in plaats van een developers board?
Ik heb al eens van een kale esp een schakelaar gemaakt voor mijn Hue ledlampen, dus ik weet hoe die te programmeren...

Direct aan de VCC van de chip inderdaad, en liefst een bordje zonder usb/regelaar, of de regelaar er af halen of los maken.

---

bnwgraaf schreef op zaterdag 13 maart 2021 @ 22:46:
Maar als ik het goed begrepen heb, en die twee zouden aan elkaar gekoppeld zitten, dan zou de lader mogelijk niet goed kunnen bepalen wanneer de batterij vol is, doordat er ook nog een "load" aan hangt met het risico dat de batterij overladen wordt.

De lader 'stopt' niet op die manier. Het is een CC/CV lader, hij begrenst de stroom die naar de batterij gaat, en als de constante spanning (4.2V) bereikt is, dan houd ie die vast, en zakt de stroom langzaam in tot 0 omdat de batterij simpelweg geen stroom meer opneemt. Als er een belasting parallel over de batterij heen zit, dan gaat er tijdens het opladen alleen wat minder stroom de batterij in wanneer de load een deel gebruikt.
100% geen probleem.

Beschermingschip dient er in dit geval vooral voor als de zon lang niet schijnt en de ESP de batterij leeg trekt. Maar je zou ook een stukje in de software kunnen opnemen om de batterijspanning te meten en het ding langer in slaap te laten als de spanning te laag gaat, en pas weer metingen/wifi activiteiten gaat doen als de spanning weer op peil is. Maar een DW01 chipje is goedkope backup. Of je koopt een 'protected' lithium batterij, dan zit ie ingebouwd.

---

bnwgraaf schreef op zaterdag 13 maart 2021 @ 22:58:
@AlexanderB
Ah, dit beschrijft nog eens wat jij al geschreven had, of niet?
https://randomnerdtutoria...ipo-and-li-ion-batteries/

Soort van. Goede uitleg over LDO's en quiescent current, maar ik zou het circuitje helemaal overslaan, en de ESP gewoon direct op de batterij hangen ipv 3.3V Is officiëel niet de bedoeling, maar het werkt wel.

[jomas]

bnwgraaf schreef op zaterdag 13 maart 2021 @ 22:46:
Ik begrijp dus dat de esp prima werkt tussen de 3V en de 4.2V

Hou er rekening mee dat volgens de specificatie van de fabrikant van de esp8266 de voedingsspanning moet liggen tussen 2.5V en 3.6V.

Met 4.2V ga je hier dus behoorlijk boven.

[AlexanderB]

Mja, verschil tussen theorie en praktijk, die lithium batterij zal echt niet heel de tijd op 4.2v staan. Een diode in serie zetten om 0.5-0.7V van de spanning af te halen kan natuurlijk altijd.

[bnwgraaf]

@jomas en @AlexanderB
Bedankt weer voor jullie reacties!

Ik zit nog steeds een beetje te twijfelen.

Ik vond bijvoorbeeld deze regulator: https://www.reichelt.nl/n...0-t8ta-p68647.html?&nbc=1
Als ik het goed zag een redelijk lage dropout voltage. En een maximaal stroom van 300 mA.

Die 300 mA zou voldoende moeten zijn voor de esp?

De andere optie is dus blijkbaar een diode in serie?
Maar hoe plaats ik dat in combinatie met het protectie printje? Deze slaat af onder 2,5 V (wat voor mijn gevoel best laag is voor Li-Ion) en boven 4,2 V.
Als ik dan die diode toevoegt, die zoals gesteld bijvoorbeeld 0,6 V verschil geeft, slaat dan het protectie printje ook niet bij 0,6 V höhere spanning af, dus bij ongeveer 4,8 V, of moet ik de batterij aan de batterij-kant van het protectie printje aansluiten en de andere kant van dit printje dan in serie met de diode plaatsen?

En als ik een diode plaats, wordt het laden van de batterij dan niet tegen gehouden?

Wat zijn voor- en nadelen van de regulator en de diode, of is dit een kwestie van voorkeur?

Zou de genoemde regulator toepasbaar zijn (is het maximaal toelaatbare amperage van 300 mA voldoende voor de esp)?
En wanneer ik voor de diode optie ga, moet ik dan een specifiek soort diode uitzoeken?

Ik heb besloten een "kale" esp te gaan gebruiken, dus zonder development board.

[AlexanderB]

De diode zou tussen de protection print en de belasting (ESP) gaan, ipv een LDO. Zo beinvloed je het opladen niet, alleen de spanning die de ESP ziet.

En ja, 2.5V is rijkelijk laag voor de meeste toepassingen, je moet die chips ook niet willen gebruiken, maar meer als extra verzekering zien, 2.5V is beter dan 0V, maar beide zijn niet goed.

Het voordeel van een diode is dat de quiescent current kleiner is, het nadeel dat de spanning over de ESP niet echt stabiel is. Denk dat dat in praktijk geen probleem is, zolang de ESP een voldoende grote condensator over z'n voedingspinnen heeft.

Die LDO zou prima geschikt zijn, heeft een quiescent current van 0.5 mA, dat is.. nog steeds niet super weinig, maar prima acceptabel in deze toepassing, je hoeft geen maandenlang op een batterijlading te doen. Met als voordeel dat de spanning netjes stabiel is op 3v3.
300 mA is zat voor de ESP, piekverbruik zou iets van 140-150 mA moeten zijn.

Voor de diode, gewoon een 'normale' diode is prima. Een 1N4001 t/m 1N4007 bijvoorbeeld zijn goed verkrijgbaar, laatste cijfer staat voor de maximale spanning, die hier volstrekt irrelevant is. (ff gekeken, the 1N4001 kost 2 cent bij Reichelt)

[bnwgraaf]

@AlexanderB
Bedankt weer voor de duidelijke reactie.

Ik denk dat ik in dit geval dan toch voor het iets stabielere spanning ga met een LDO.

Daarnaast ga ik zoals jij ook al voorstelde, de spanning monitoren met de esp en wanneer deze laag dreigt te raken, kan ik bijvoorbeeld de deepsleep tijd verlengen en dus het aantal metingen per uur verlagen.
Het protectieprintje is dan inderdaad een laatste bescherming.

[S-te-fan]

Leuk project!

Ik ben zelf ook met iets vergelijkbaars bezig. Ik wil straks een ESP12F buiten hebben hangen met een DS18B20 temperatuursensor, en een BMP280.

Dit wordt straks gevoed door een 18650 3400mAh batterij met ingebouwde protectie. En die wordt bijgeladen door een 5V, 2W paneeltje middels een TP4056.

Ik heb daar een LDO XC6206 tussen zitten, welke ik weer afgekeken heb van andere low-power projecten her en der op internet.

Ook ik ga dan met een voltage divider de spanning monitoren om eventueel de deep-sleep cyclus te sturen. Maar het idee is dat ik er geen omkijken naar heb, en data kan krijgen ongeveer elke 5 minuten.

Ik wacht nog op een paar componentjes, en dan ook eerst es wat testen. Ben benieuwd naar jouw resultaten straks met toch een iets andere opzet.

Wat voor software ga je ervoor gebruiken? Ik wilde zelf eerst eens testen met Tasmota. Maar uiteindelijk wil ik zelf een minimalistisch stuk gaan (proberen) te schrijven. Zolang die maar communiceert over MQTT.

[bnwgraaf]

@S-te-fan
Leuk dat je met een soortgelijk project bezig bent!
Er is genoeg mee te leren!

Ook ik wacht op nog een aantal componenten en wil eerst verschillende dingen testen op de tafel, voordat ik alles ga inbouwen.

Voorlopig programmeer ik de esp via de Arduino software.
De esp gaat dan elke minuut of elke paar minuten de diverse sensoren uitlezen en stuurt de waardes dan naar Domoticz.
De Domoticz software draait op de NAS.

De eerste testjes met Domoticz zijn al gelukt.

Als alles goed werkt en ik heb er dan nog steeds lol in, dan ga ik misschien proberen een webpagina te maken waar alle waardes weergegeven worden.

Ik heb diverse soorten sensoren, ook voor UV en infrarood (om de temperatuur van de lucht/hemel te meten en zo kan zien of er bewolking is).
Het lastige is alleen dat deze sensoren niet achter gewoon glas werken, maar ik moet ze toch afschermen tegen weersinvloeden...

Ik ben benieuwd hoe het bij jou allemaal lukt!

[bnwgraaf]

Vandaag weer diverse antistatische zakjes binnen gekregen met allerlei leuke spulletjes!
In ieder geval ook de onderdelen binnen voor het batterij-zonnepaneel-laadcircuitje :-)

[bnwgraaf]

Ik zit eens te puzzelen met de componenten.

Ik heb een ina219 printje om spanning/stroom te meten, een LDO om de batterijspanning naar 3.3V te brengen en een protectieprintje voor bescherming tegen over- en onderladen van de batterij.

Ik wil met de esp de batterijspanning in de gaten houden.

Klopt onderstaand schema dan?
- de protectie koppel ik aan de batterij.
- deze protectie uitgangen komen in serie met de Vin+ en Vin- van de spanning/stroom sensor en de batterij aansluiting van de lader
- De system uitgang van de lader gaat via de LDO naar de Vcc en Gnd van de esp
- Ook de ina219 sensor krijgt spanning via de DO
- oh ja, niet in het schema afgebeeld, maar ik heb ook nog twee condensatoren voor de LDO

Of moet de ina219 sensor in het circuitje komen van de batterij naar de batterij protector?

En als het zo klopt, kan ik dan ook zien welke kant de stroom loopt en dus of de batterij aan het laden of ontladen is?

[Voor 5% gewijzigd door bnwgraaf op 16-03-2021 16:59]

[S-te-fan]

Je kunt ook gebruik gaan maken van een voltage divider

Als je een ESP gebruikt op een developer board, dan zit die er al in verwerkt via de ADC pin.
Op een kale chip, moet je deze dan zelf maken d.m.v. wat weerstanden.

[bnwgraaf]

Ja die voltage divider heb ik ook al een keer geprobeerd. dat werkt inderdaad ook.
Ik ga een kale esp gebruiken. Heb daar vandaag een adapterboardje voor binnen gekregen.

[bnwgraaf]

Ik ben bezig met een testopstellingkje.
Ik heb twee zonnepaneeltje van 6V, 2W

Ik heb deze in eerste instantie parallel gekoppeld, zodat de laadstroom omhoog gaat.

Maar nu merkte ik het volgende. Het is vandaag niet heel erg zonnig en ik meet een spanning van 3,5V aan de paneeltjes.

Edit: verkeerd gemeten, spanning zit tussen 5 en 5,5V.

De batterijlader heeft echter een ingangsspanning van 4,5-6V, dus die doet nu niets...

Is het wellicht gunstiger om de paneeltjes in serie te zetten? Ik besef dat het maximale leverbare amperage dan gehalveerd wordt, en onder de maximale laadspanning van de lader uitkomt. Maar beter iets minder snel laden bij bewolkt weer, dan helemaal niet laden...

Als het niet volledig zonnig is en de panelen dus niet maximaal leveren, dan neem ik aan, dat zowel de spanning als de stroom van de panelen omlaag gaat?

Dus een 6V 2W (333mA) paneel gaat dan minder dan 6V en minder dan 333mA leveren?

[Voor 3% gewijzigd door bnwgraaf op 18-03-2021 12:40]

[bnwgraaf]

Ik zie nu net dat de door mij gebruikte lader een system/load uitgang heeft van 3,7V:
Dan hoef/moet ik dus geen regulator naar de esp ertussen zetten!

[bnwgraaf]

Inmiddels ben ik weer wat verder met mijn testopstelling en hoop de komende dagen eens te kunnen zien of de zonnepanelen de batterij een stukje kunnen bijladen.

Aan mijn testopstelling heb ik de volgende zaken toegevoegd:

• Als de esp in deepsleep is, wordt ook de voeding naar de sensoren gestopt
• Wanneer de esp uit deepsleep komt, wordt de wifi gelijk uitgezet voor batterijbesparing. Dan worden de sensoren uitgelezen. Vervolgens wordt de wifi ingeschakeld en de uitgelezen waardes naar Domoticz verstuurd.
  Ik moet nog toevoegen dat de voeding naar de sensoren uitgeschakeld wordt na het uitlezen van de sensoren.
• Als ik één specifieke gpio pin verbind met ground, kont de esp in een OTA en SSH modus. De print gaat dan niet in deepsleep en dit geeft me twee mogelijkheden.
  Ik kan nu via SSh verbinding maken met de esp, zodat ik rechtstreeks op bijvoorbeeld mijn telefoon diverse waardes kan uitlezen en dit kan gebruiken als een debug optie.
  Daarnaast kan ik een "over-the-air" update doen.
• Wanneer één van de sensoren niet werkt, kan ik dit ook in Domoticz terug zien en daar eventueel een notificatie aan koppelen.
• Wanneer de batterij spanning onder een bepaalde waarde komt, wordt de deepsleep tijd langer ingesteld

Ik moet alleen eens wat nieuwe jumper wires aanschaffen, want deze klemmen niet goed, waardoor ze steeds weer los schieten. Ik heb ze helaas ook niet kunnen verbuigen...
Dit zorgt voor een onbetrouwbare opstelling.

[bnwgraaf]

Ik heb nu een testopstelling lopen met een NodMCU printje, welke ik niet voed via de usb aansluiting of VCC pin, maar gewoon direct op een 3.3V pin. Dat werkt op zich goed eigenlijk.
Het is een dergelijk boardje:


Maar ik had eigenlijk een losse ESP print willen gebruiken zonder het hele NodeMCU boardje er omheen met regulator en dergelijke. Ik heb deze op een adapterboardje gesoldeerd.


Onderstaand schema is wat ik geprobeerd heb. Vergeef me als het schema niet helemaal volgens de regels opgezet is, maar ik ben geen elektrotechnicus...

- Ik heb een CN3065 solar charger welke gevoed wordt door twee 6V zonnepanelen, welke parallel zijn geschakeld.
- De batterij aansluiting gaat via de INA219 sensor om de batterijspanning te monitoren.
- De Sys aansluitingen gaan naar de twee LDO regulatoren (3.3V) U2 en U3.
- U3 verzorgt de voeding van de EPS8266. De ESP is voorzien van 4 weerstanden (volgens diverse schema's die ik op internet heb gevonden), waarvan twee stuks al in het adapterboardje verwerkt zitten en twee drukknoppen (voor reset en flash)
- Pin RST en GPIO16 zijn verbonden om te kunnen ontwaken uit deepsleep mode
- De tweede regulator voorziet de diverse sensoren van voeding, in dit geval alleen de INA219 spanning/stroom sensor.
- Beide regulatoren zijn voorzien van een 1uF condensator zoals in de specs vermeld.



Ik loop nu tegen het volgende aan.
Wanneer ik de esp uit dit schema haal en ik meet de uitgaande spanning van regulator U2, dan meet ik 3.3V.
Plaats ik de esp terug in dit schema, dan zakt de spanning in tot onder 2V en werkt de esp dus niet....

Wanneer ik de losse esp en de weerstanden weg haal en ik sluit een esp NodeMCU board aan op de uitgaande spanning van regulator U2, dan blijft de spanning wel netjes op 3.3V
Ik sluit de spanning van U2 dan niet aan op de USB aansluiting of de 5V Vin van de esp, maar direct op een 3.3V pin en een GND pin.\

Met andere woorden, het bovenstaande voedingsgedeelte werkt wanneer ik dit gebruik in combinatie met de NodeMCU, maar niet met de losse esp met weerstanden.
Heb ik iets mis gedaan met de weestanden?

[FotoMark]

Ik heb iets soortgelijks gemaakt met een CN3065 als lader voor een 18650 batterij. Ik gebruik een ESP32 met batterij aansluiting (https://nl.aliexpress.com...042311.0.0.27424c4dYY0sTm). Werkt prima zolang de EPS32 lang genoeg in sleepmode wordt gehouden. De batterijspanning met ik via een spanningsdeler op en analoge ingang van de ESP32.

Dus eigenlijk hetzelfde deel voor de batterij, maar een ingebouwde spanningsregelaar op het bordje. En de INA219 vervangen door een spanningsdeler 1M op 1M zo uit mijn hoofd en 100nF condensator om storingen te onderdrukken. Ligt nu twee weken op het schuurtje de bodemvochtigheid te meten met een capacitieve sensor. Aangezien die vrij veel stroom trekt gaat die ook uit via een FET.

Ik denk dat je of een kortsluiting of een aansluitfoutje hebt gemaakt. Vraagje: waarom twee spannings regulatoren als ze dezelfde spanning leveren? Zonde van het vermogen.

[bnwgraaf]

@FotoMark
Dank je voor je reactie en leuk en goed om te horen dat je een vergelijkbaar iets hebt opgezet.
Ik vermoed ook dat er toch ergens iets inderdaad niet goed is aangesloten of zo....
Jij hebt wel ook een compleet esp boardje gebruikt, dus met regulator en zo er op. In mijn huidige testopstelling heb ik dat ook werkend. Alleen wanneer ik een losse esp chip gebruik, gaat er ergens iets mis... Ik begin er dan ook steeds meer aan te denken om niet een losse esp te gebruiken, maar gewoon het boardje.

De reden dat ik twee regulatoren heb is dat één regulator tot 250 mA in de specs staat. Ik heb begrepen dat de esp tot ongeveer 150 mA kan verbruiken bij wifi gebruik en soms lees ik dat dat nog wel meer kan zijn.

Ik heb diverse sensoren in mijn gedachten en ik dacht dat het misschien wel goed zou zijn voor allebei een aparte voedingscircuit te hebben, ook gezien de maximale stroom die door één regulator kan.

Of ik moet natuurlijk een andere regulator zien te vinden met een hogere toegelaten stroom.

Wat betreft de esp, vooralsnog draait het NodeMCU boardje ook best goed en misschien moet ik eens zien te meten hoeveel van het verbruik naar het boardje zelf gaat, ook in deepsleep.

[bnwgraaf]

FotoMark schreef op vrijdag 26 maart 2021 @ 20:37:

Ik denk dat je of een kortsluiting of een aansluitfoutje hebt gemaakt.

Ik ben weer een avondje aan het prutsen geweest.

Ik heb gemeten dat het systeem met de NodeMCU toch noch 2mA tijdens deepsleep trekt in plaats van de 20uA uit de specs.

Toch de losse esp chips er weer eens bij gepakt. Alle aansluitingen goed nagekeken, maar bij de ene zakte weer de spanning helemaal in wanneer ik dit aan sloot.
Maar de andere kreeg ik nu wel goed aan de gang, dus misschien is eentje toch beschadigd bij het solderen of zo.

Toen ik die andere aan de gang had de stroom maar weer eens gemeten.
Tijdens het verzenden van de data via wifi meet ik ongeveer 80mA.
Wanneer de deepsleep in gaat is de waarde niet meer meetbaar; mijn multimeter meet Ampère met 3 cijfers achter de komma.

Ziet er dus een heel stuk beter uit!

Ik heb gemeten dat het systeem toch een stuk meer stroom trekt dan voor de esp in deepsleep opgegeven staat. Wanneer mijn systeem in deepsleep is, loopt er nog ongeveer 2 mA en dat is toch wel een stukje met dan de 20uA die in de specs staat.

Ik heb dus weer mijn losse esp chips erbij gepakt en weer eens gemeten. Bij eentje zakte weer de spanning in als ik die aansloot, maar bij de andere niet. Dat ben ik dus eens mee verder gegaan en die heb ik uiteindelijk werkend gekregen!
Wanneer ik nu de stroom meet, zie ik die

[S-te-fan]

Ik lees nog altijd alleen even mee, heb inmiddels bijna al mn onderdelen binnen. Gisteren kreeg ik mn adapterbordjes eindelijk binnen. Maar (stom) heb ik ze voor de ESP32 besteld. Dus nieuwe besteld, maargoed dat duurt nog wel even voordat ze binnen zijn.

Batterijen heb ik ook nog niet binnen, maar dat is in principe niet direct nodig voor het testen..

[bnwgraaf]

FotoMark schreef op vrijdag 26 maart 2021 @ 20:37:
Aangezien die vrij veel stroom trekt gaat die ook uit via een FET.

Heb je voor mij het typenummer van de FET en een schemaatje hoe je één en ander hebt aangesloten?

De condensator heb je op de Vin en GND van de esp neem ik aan?

[Yukkie]

Hier mijn ervaring met een soort gelijke setup. Mijn setup bestaat uit een 6V paneeltje, een CN3791 MPPT solar regulator, een 18650 lithium batterij, een ESP32 en een aantal sensoren (Lux, BME280 en Soil moisture) via I2c. Overdag, als het voltage boven de 4V zit wordt de ESP iedere 10 seconde wakker om een sensormeting door te sturen via MQTT. Als de lux waarde onder de 200lx komt (oid, heb de code niet bij de hand) veranderd dat naar iedere minuut. Als het voltage onder de 4V komt, dan gaat de esp32 iedere 10 minuten in deep sleep. OVerigens is vanaf een uurtje of 3 de zon hier weg van het balkon.

Om eerlijk te zijn moet ik op zonnige dagen moeite doen de energie een beetje weg te stoken. Ook in de winter houdt deze setup het gemakkelijk uit, zonder dat de batterij leeg loopt. Ik heb heel soms een vastloper (komt door mijn knoeicode waarschijnlijk ) en als ik de ESP dan na een dag ofzo reset, is het voltage vaak niet heel ver gezakt.

FF foto'tje bijgevoegd:

[Voor 17% gewijzigd door Yukkie op 30-03-2021 08:53]

[bnwgraaf]

@Yukkie
Dank je voor je uitleg en foto!
Interessante info!

Ik heb met mijn "werkbank-testopstelling" nog wat wisselende resultaten.

Soms komt dat door brakke stekkerverbindingen. Deze klemmen niet altijd even lekker, waardoor ik ze met een tangetje moet aanpassen. Dat werkt natuurlijk al niet mee en ik heb daarom al diverse verbindingen gesoldeerd.

Maar ik vraag me ook af of het 3.3V voedingsgedeelte in orde is. Soms meet ik te lage spanning aan de esp kant; trek ik de batterij er uit en plaats deze weer terug, dan heb ik wel vaak weer netjes 3.3V.
Zou er een probleem met de Li-ion protectieprint zijn?

Heb jij de esp rechtstreeks op de uitgang van de solar charger gezet?
Ik heb daar namelijk nog een MCP1700-3302E/TO LDO regulator tussen gezet, met twee condensatoren.
Maar ik vind overal verschillende schema's voor de condensatoren....

Deze in de specs:


Maar deze kom ik ook een aantal keer tegen:


Kan iemand me daar duidelijkheid over geven?

@Yukkie
Ik zie dat jij ook net een iets andere charger hebt. Die van mij is gebaseerd op de CN3065:


Die van jou op de CN3791:


Ik zal eens kijken wat daar de verschillen in zijn.

[Voor 19% gewijzigd door bnwgraaf op 30-03-2021 09:41]

[bnwgraaf]

Ik heb toch ergens zitten te prutsen met aansluitingen en zoals gezegd wat gammele contactjes en een blijkbaar toch niet goed werkend componentje...

Na alles nog eens opnieuw te hebben aangesloten en het vervangen van het componentje, draait het nu weer testrondjes buiten op de tafel.

Het is me nu voor het eerst gelukt om het werkend te krijgen met een kale ESP, waarbij ook nog eens de spanning naar de sensoren wordt ingeschakeld vlak voor het uitlezen daarvan en direct daarna weer wordt utigeschakeld.

Waar ik eerst een spanning van 0.002 A meette tijdens deepsleep, geeft mijn multimeter nu nog maar 0.000 A aan, en lagere stromen kan ik niet meten. Dus zit onder de 1 mA in ieder geval en aangezien de esp een deepsleep spanning heeft van 20uA en de regulatoren volgens specificatie maximaal 4uA, zal het totaal dus ver onder de 1 mA zitten.

Nu maar eens een aantal uurtjes laten draaien en als dat goed gaat, een definitief boardje maken. Misschien laat ik die wel in China maken via jlcpcb of zo.
En dan de code eens goed gaan reorganiseren en optimaliseren.

Dit ziet er in ieder geval weer beter uti! :-)

[SA007]

Tip om lage stromen te meten, hangt een weerstand in serie met de voedingsspanning en meet daar overheen.
Als je bijv een 100Ohm weerstand in serie hangt kan je met je multimeter op mV en je meet 5mV dan is dat 0.05mA, kan je waarschijnlijk met dezelfde multimeter 100x zo lage stromen meten.

[bnwgraaf]

SA007 schreef op dinsdag 30 maart 2021 @ 11:26:
Tip om lage stromen te meten, hangt een weerstand in serie met de voedingsspanning en meet daar overheen.
Als je bijv een 100Ohm weerstand in serie hangt kan je met je multimeter op mV en je meet 5mV dan is dat 0.05mA, kan je waarschijnlijk met dezelfde multimeter 100x zo lage stromen meten.

Bedankt voor de goede tip, die ga ik een keer uitproberen!

[bnwgraaf]

Ondertussen ben ik ook nog aan het kijken hoe ik de spanning van de sensoren haal, als de esp in deepsleep is.

Op dit moment gebruik ik een 3570.1210.051 reed relais. Dit werkt op zich wel, maar is volgens mij eigenlijk voor 5V en iemand zei eerder al dat dit overkill is en een P channel mosfet een goede oplossing is.

Alleen ben ik helemaal nieuw in de P channel mosfets...

Ik begrijp dat ik een P channel neem, zodat de te schakelen spanning uitgeschakeld heeft wanneer er geen spanning op de mosfet staat.
Als de esp dan uit deepsleep komt en ik geeft een plus spanning via één van de GPIO's, dan schakelt de mosfet.

Kan iemand me helpen hoe de schematische aansluiting dan is?
En kan iemand me ook een goed type aanraden, welke werkt met de 3.3V spanning en natuurlijk zo min mogelijk van mijn batterij snoept?

[bnwgraaf]

Ik ben eens aan het inlezen over mosfets.

Ik kom deze FQP30N06L tegen als zijnde vaak gebruikt icm met Arduino, esp en dergelijke....

Is het volgende een werkend circuit?
GPIO12 zet ik HIGH om de stroom door de sensor te laten lopen (in dit voorbeeld een BME280).

[AlexanderB]

Zoals je het nu getekend hebt gaat het niet werken, of ja, met een n-channel mosfet zou het zo werken, maar als die sensor chip ergens anders ground vind dan gaat ie niet uit.

Voorbeeldplaatje van internet: (waar 5V staat moet je dan ff 3.3V lezen)

Links is de opstelling met een N channel mosfet, rechts de opstelling met een P channel mosfet.

N channel schakelt in als de Gate hoger is dan de Source, ofwel als je de ingang 'hoog' maakt
P channel schakelt in als de Gate lager is dan de Drain, ofwel, als je de ingang 'laag' maakt.

En maak je geen zorgen over dat diode symbooltje, dat is een impliciet onderdeel van mosfets, en een handige manier om te zien hoe om je ze aansluit.

[bnwgraaf]

AlexanderB schreef op dinsdag 30 maart 2021 @ 19:18:
Zoals je het nu getekend hebt gaat het niet werken, of ja, met een n-channel mosfet zou het zo werken, maar als die sensor chip ergens anders ground vind dan gaat ie niet uit.

Voorbeeldplaatje van internet: (waar 5V staat moet je dan ff 3.3V lezen)
[Afbeelding]
Links is de opstelling met een N channel mosfet, rechts de opstelling met een P channel mosfet.

N channel schakelt in als de Gate hoger is dan de Source, ofwel als je de ingang 'hoog' maakt
P channel schakelt in als de Gate lager is dan de Drain, ofwel, als je de ingang 'laag' maakt.

En maak je geen zorgen over dat diode symbooltje, dat is een impliciet onderdeel van mosfets, en een handige manier om te zien hoe om je ze aansluit.

Dank je, daar kan ik weer wat mee. Ik vind ze best lastig te begrijpen die mosfets, maar kom steeds een stapje verder.

Is het een goede gedachtegang van mij dat een n-channel in dit geval eigenlijk het meest logische is?
Ik wil stroom besparen door een aantal sensoren alleen gedurende een klein deel van de code van voeding te voorzien. GPIO12 bijvoorbeeld is laag bij het ontwaken van de esp.
Alleen tijdens het uitlezen van de sensoren zet ik deze pin dan korte tijd hoog en voor de rest weer laag.

Of was het nu zo dat een p-channel open staat in de uitgangssituatie ook een open stroomkring heeft en de sensoren dus geen spanning hebben?

Vraagjes:
- Is er een voorkeur voor een n- of p- channel variant?
- is de genoemde FQP30N06L inderdaad een goed bruikbare?

Oh en linksonder is gewoon weer een 10K weerstand of zo he?

[SA007]

Punt is dat een N-channel de GND kan schakelen, en een P-channel de VCC.

Als je sensoren van een schakelbare spanning wil voorzien heb je een P-channel nodig.

Probleem van de GND schakelen is dat een sensor vaak geen probleem heeft met de stroom van andere plekken halen omdat er zo weinig nodig is, en met GND is dat een stuk moeilijker te regelen dat die stroom er niet is.

[AlexanderB]

Het is zeker interessante materie, en zonder er te diep in te duiken kan je er nog heel wat dingen over leren inderdaad.

P of N is een beetje het theorie versus praktijk verhaal, in theorie zou het niet moeten uitmaken, maar in praktijk is het grotendeels conventie om alles aan de massa te aarden, dingen als sensoren met metalen behuizingen etc.
Als je die massa/0V dan gaat onderbreken dan is de kans groot dat je vroeg of laat ongewenst verbinding maakt en de n channel mosfet daarmee buitenspel zet. De voedingskant schakelen die niet aangesloten is op allerlei onvoorziene manieren is dan makkelijker. Niet dat het niet kan, maar het is gewoon makkelijker.

P channel mosfets kunnen de spanning naar de sensoren evengoed onderbreken, het enige verschil is dat de pinstate daarvoor hoog moet zijn, ipv laag bij een N channel.
Van daar ook de weerstandjes, als je de input niet aansluit, is de kans dat je statische electiciteit opbouwt, of door 'lekkage' van spanning in de microcontroller de pin half-aan gaat, en dan krijg je rare problemen. Dat weerstandje zorgt er dus voor dat de mosfet altijd uit is, tenzij je 'm actief aan (geleidend) maakt.

FQP30N06L is echt enorme overkill voor deze toepassing, maar het zal wel gewoon prima werken.
10k is prima voor deze toepassing.

Oh, en nog een term om je in te lezen, tri-state. De meeste microcontrollers, inclusief de ESP, kennen 3 pin staten. Hoog, Laag en 'alsof er niets is aangesloten'. Als je een pin als input gebruikt, dan is die in die derde staat, en veelal zijn pinnen op microcontrollers ook in die staat als ze in slaapstand staan of gereset worden.
Ook dat werkt gewoon prima met de P channel mosfet, tristate is prima, alleen active low op de IO pin van de ESP zet de mosfet aan.

[bnwgraaf]

@AlexanderB en @SA007
Tnx weer voor de uitgebreide uitleg!
Ondertussen is het einddoel van dit project niet eens zozeer het doel meer, maar de weg er naartoe is leuk en leerzaam!

[septillion]

P of N channel voor het schakelen is inderdaad meer conventie dan nut. Als je een sensor uitschakelt moet je er gewoon 100% zeker van zijn dat wat je schakelt ook niet via een andere weg te halen is. Of dat nu GND of Vcc is. Ofwel, ook alle datalijnen moet je correct zetten. In geval van (low side) N-channel zal je dus moeten zorgen dat alle data pinnen ook Vcc of float zijn. In geval van (high side) P-channel zullen ze allemaal GND of float moeten zijn.

Kijkende naar toepassingen is voor I2C devices het dus vaak makkelijker om GND te schakelen daar de rusttoestand van de lijnen toch al Vcc is. Je kan alleen niet communiceren met andere devices op de lijn. Maar voor devices met level shifters kan het makkelijker zijn Vcc te schakelen.

Maar goed, onder aan de streep blijft het schakelen van sensoren gewoon gedoe. En als het dan gaat om een BME280 is het ook echt niet waard. Ding heeft een sleep mode waarin hij maar 0,1uA pakt. Ter vergelijking, je pull down voor de mosfet pakt nu 330uA als je de mosfet inschakelt. Dus als je de sensor een minuutje inschakelt had je hem ook 55 uur in sleep kunnen houden Dat is nog zonder de gate charge die je kwijt raakt.

[bnwgraaf]

septillion schreef op woensdag 31 maart 2021 @ 09:00:
Maar goed, onder aan de streep blijft het schakelen van sensoren gewoon gedoe. En als het dan gaat om een BME280 is het ook echt niet waard. Ding heeft een sleep mode waarin hij maar 0,1uA pakt. Ter vergelijking, je pull down voor de mosfet pakt nu 330uA als je de mosfet inschakelt. Dus als je de sensor een minuutje inschakelt had je hem ook 55 uur in sleep kunnen houden Dat is nog zonder de gate charge die je kwijt raakt.

Dat is inderdaad ook een interessante kijk erop!
Eigenlijk zou ik eens van alle sensoren die ik wil toepassen moeten kijken hoeveel de rust stroom is!

Ik begreep ook dat (sommige) sensoren inderdaad in een sleep mode gezet kan worden en alleen op afroep waardes uitlezen.
Ik weet niet of dat voor elke sensor is en ik moet er eens in duiken hoe je dat instelt.

[septillion]

Omdat dingen op batterijen steeds normaler zijn hebben veel sensoren inderdaad gewoon zelf een sleep. Ga niet zeggen alle, maar het loont dus om even te zoeken naar een die het wel kan

[SA007]

Opzich als je sensoren heel erg weinig stroom gebruiken is de VCC ook aan een gpio pin hangen wellicht ook prima, dan zet je die pin gewoon naar 0. een esp8266 pin kan 12mA aan, dus als je sensor piek minder dan dat verbruikt kan je 'm ook aan een gpio pin hangen, helemaal zonder mosfet enzo.

[bnwgraaf]

Ik wil een kale esp chip gebruiken, dus heb dan niet zoveel pinnen vrij.
Tenminste, de pinnummers 6 t/m 11 zijn niet op het adapterboardje aangsloten en ik heb diverse malen gelezen dat je die beter niet kunt gebruiken. Al weet ik niet of dat om de "kale" esp gaat of om de developer boardjes.
Kan iemand mij daar duidelijkheid in geven:

The ESP8266 has 17 GPIO pins (0-16), however, you can only use 11 of them, because 6 pins (GPIO 6 - 11) are used to connect the flash memory chip.

Nog een andere vraag kan ik de GPIO's 1 en 3 tijdens het runnen van het programma gebruiken als input voor bijvoorbeeld een sensor en deze in flash mode gebruiken voor RXD) en TXDO, om de firmware te updaten, of kunnen die twee pinnen maar één functie hebben?

Aan de andere kant zou het eigenlijk alleen maar om de INA219 stroom/spanning sensor gaan en die staat inderdaad op 1mA verbruik in de specs, dus zou ik die aan de pin kunnen hangen die ik anders had gebruikt voor het inschakelen van de mosfet.

De overige sensoren verbruiken minder dan 1uA en/of hebben een sleep mogelijkheid.

[AlexanderB]

Er vanuitgaande dat je zo iets bedoelt met 'kale ESP chip' dan zijn die pinnen intern verbonden met een stukje flash geheugen waar de ESP z'n programma bewaart en dus inderdaad niet bruikbaar.

bnwgraaf schreef op woensdag 31 maart 2021 @ 15:14:
Nog een andere vraag kan ik de GPIO's 1 en 3 tijdens het runnen van het programma gebruiken als input voor bijvoorbeeld een sensor en deze in flash mode gebruiken voor RXD) en TXDO, om de firmware te updaten, of kunnen die twee pinnen maar één functie hebben?

De pinnen die normaal voor de seriële poort gebruikt worden kan je inderdaad ergens anders voor benutten, als je het een beetje handig uitkient dan kan je ze alsnog gebruiken om te programmeren zonder dingen los te hoeven maken.

bnwgraaf schreef op woensdag 31 maart 2021 @ 15:14:
Aan de andere kant zou het eigenlijk alleen maar om de INA219 stroom/spanning sensor gaan en die staat inderdaad op 1mA verbruik in de specs, dus zou ik die aan de pin kunnen hangen die ik anders had gebruikt voor het inschakelen van de mosfet.

De overige sensoren verbruiken minder dan 1uA en/of hebben een sleep mogelijkheid.

Klinkt goed

[Voor 7% gewijzigd door AlexanderB op 31-03-2021 15:34]

[septillion]

Volgens mij hebben ook de ESP12 modules een flash chip op GPIO6-11. Dus dat maakt ze inderdaad niet geschikt.

En GPIO1 en GPIO3 zijn inderdaad te gebruiken voor andere zaken. Maar zou ze alleen als uitgangen gebruiken (ofwel, aansluiten op high impedance pinnen van sensoren) zodat ze uart niet in de weg zitten met programmeren. Bedenk ook dat je dan geen uart meer hebt met debuggen. En vergeet de boot functies van GPIO0, GPIO1 en GPIO15 niet tijdens het indelen van de functies.

Bedenk voor de INA219 dan wel dat je geen I2C meer kunt doen als die uit staat (ook niet met eventuele andere devices). En als je de INA219 dus high side schakelt (ofwel, zijn Vcc schakelt) zal je ook de pull up's op de I2C uit moeten zetten als je hem uitschakelt. Maar ook voor die, waarom zou je? Hij heeft een typical quiescent current van 6uA. 1 seconde ESP met wifi (uitgaande van 200mA) is goed voor 9 uur sleep van de INA219.

Misschien kan je een totaalbeeld geven? Heb je al een eerste schema? Lijst met sensoren?
Oeps, beter kijken, pagina één. Is dat nog een beetje up to date of heb je al andere/nieuwe ideeën?

[Voor 5% gewijzigd door septillion op 31-03-2021 16:45]

[bnwgraaf]

septillion schreef op woensdag 31 maart 2021 @ 15:48:

Oeps, beter kijken, pagina één. Is dat nog een beetje up to date of heb je al andere/nieuwe ideeën?

Dank jullie wederom!
De esp is inderdaad vergelijkbaar met bovenstaande afbeelding, dus zonder developper board.

Ik heb een schema in wording.
Let op: ik ben geen elektrotechnicus en heb nog niet eerder met schema-ontwerp sotware gewerkt, dus er zal echt wel het nodige op aan te merken zijn. Ook zullen de door mij gebruikte termen niet altijd even juist zijn. sorry daar voor! :-)

Het onderstaande schema heb ik globaal nu in test draaien. Hier wat toelichting en uitleg:

• Ik heb twee regulatoren. Ik weet dat dat misschien een beetje veel is, maar ik vroeg me alleen af of de toelaatbare uitgangsspanning van dit type regulator voldoende is voor de maximale stroom van de esp en alle sensoren bij elkaar. Ik zag wel types met meer mA op de uitgang uitgangen, maar dan was de dropout voltage weer een stuk hoger. Als jullie zeggen dat eentje (met 250mA uitgang) voldoende is, of een geschikter type weten, kan ik er natuurlijk ook eentje schrappen.
• Ik vraag me ook af in hoeverre de 5 condensatoren kloppen; ik heb daar verschillende schema's van gevonden voor dezelfde regulator.
• De drie terminals aan de rechterkant zijn om diverse (externe) I2C sensoren op aan te sluiten.
• Aan de batterij heb ik ook nog een Li-Ion protectieprint gekoppeld, maar die staat niet in dit schema.
• In mijn "werkbanktest" schakel ik de voeding op de sensoren uit met een 3570.1210.051 "DIL-Reed Relay", maar als het zonder kan, dan liever!
• Er staan ook wat extra headers, zodat ik achteraf altijd nog iets met jumperdraden kan aansluiten (om te testen of uit te breiden)

De sensoren die ik heb liggen en mogelijk wil gaan toepassen:

• BME280 voor temperatuur, vochtigheid en
• EML6075 voor UV (index)
• TSL2591 licht/lux sensor
• MLX90614 ir sensor om de "hemeltemperatuur" te meten en zo te bepalen of er bewolking is
• Een regen sensor (heb even niet het type bij de hand, maar die is met zo'n plaatjes die de druppels opmerkt)
• INA219 voor stroom/spanning
• Ik heb eventueel ook nog een MQ-135 gassensor, maar buiten dat die niet echt nuttig is in deze situatie, lijkt me die ook niet praktisch, want die moet volgens mij eerst opwarmen? Dus die laat ik maar even.

[Voor 4% gewijzigd door bnwgraaf op 31-03-2021 22:08]

[Yukkie]

Over het in en uitschakelen van sensoren:
Ik heb de sensoren op een pin van de ESP32 aangesloten, welke ik hoog zet wanneer de ESP wakker wordt en laag als de ESP gaat slapen.
Eerst zat daar alleen de BME280 op, maar inmiddels zijn daar 2 sensoren bij gekomen. bij elkaar verbruiken die maximaal 8mA (volgens fabrieksopgave). Een ESP kan 12 mA aan op een digitale pin, dus ik zit nog binnen de marge. Wellicht is dat nog een mogelijkheid, als je het relay wilt weg laten?

[bnwgraaf]

Yukkie schreef op donderdag 1 april 2021 @ 09:20:
Wellicht is dat nog een mogelijkheid, als je het relay wilt weg laten?

Die kant zit ik nu wel op te denken inderdaad. Ik moet eens even goed kijken wat de opgegeven wat voor de gebruikte sensoren opgegeven wordt voor maximale stroom...

[Yukkie]

Ik zit net nog even mijn vraag in het ESP topic na te lezen. Iemand merkt daar op dat GPIO's floating zijn wanneer de ESP slaapt, dus mogelijk moet je dan wel een pull up (of Pull down? Dat principe snap ik nog niet helemaal). Die opmerking heb ik destijds over het hoofd gezien, dus daar heb ik niets mee gedaan. Wellicht is het voor jou nog niet te laat

Ook zou je als je de GPIO pin als sink gebruikt tot 20 mA kunnen gaan. Ik neem aan dat dat betekend dat je dan de GND van je sensoren dan op de GPIO pin aansluit, ipv de VCC. Maar of en hoe je dan je sensoren kunt enablen is mij even niet duidelijk.

[bnwgraaf]

Yukkie schreef op donderdag 1 april 2021 @ 09:35:
Ik zit net nog even mijn vraag in het ESP topic na te lezen. Iemand merkt daar op dat GPIO's floating zijn wanneer de ESP slaapt, dus mogelijk moet je dan wel een pull up (of Pull down? Dat principe snap ik nog niet helemaal). Die opmerking heb ik destijds over het hoofd gezien, dus daar heb ik niets mee gedaan. Wellicht is het voor jou nog niet te laat

Ook zou je als je de GPIO pin als sink gebruikt tot 20 mA kunnen gaan. Ik neem aan dat dat betekend dat je dan de GND van je sensoren dan op de GPIO pin aansluit, ipv de VCC. Maar of en hoe je dan je sensoren kunt enablen is mij even niet duidelijk.

Dat is ook interessante info.
Eerlijk gezegd moet ik mezelf ook eens op de hoogte brengen van de goede manier voor het gebruiken van de GPIO's.
Wat jij in je andere post vertelde had ik ook al eens opgemerkt in een testje: de mijn ledje ging uit toen ik een pin HIGH maakte.
Ik zal eens wat zelfstudie uitvoeren over de pins en het gebruik ervan. Maar als iemand het wil toelichten of een duidelijke link heeft is dat natuurlijk altijd welkom!

[septillion]

@Yukkie Floating IO is juist wenselijk als je de sensor uitschakelt. Je mag juist niet voeden via de IO. Ofwel, bij een I2C device mag je dus ook geen pull downs hebben als je high side de device schakelt. Immers heb je dan een pad (Vcc => pull-up => device => GND). Dus voor devices met een sleep is het all het gedoe gewoon niet waard. Effectieve code schrijven, voltage regulatie met lage ruststroom en verliezen etc doet dan zooooooooooooo veel meer.

@bnwgraaf Opmerkingen na zien van het schema:

Al het begin is puzzelen, maar als ik een tip mag geven voor het tekenen. Trek geen lijnen dwars over componenten heen En groepeer lijnen die bij elkaar horen zoals je rechts eigenlijk al gedaan hebt.

INA219 is zeker een module ipv de chip of niet? Anders mis ik de shunt.

Ik mis de pull-up's voor de I2C. Bedenk ook dat I2C niet geschikt is voor afstand. Dus prima als ze niet op het bord zitten maar verder dan een cm of 10, misschien 20, zou ik het niet rekken.

Condensatoren hangt heeeeel sterk af van de regulator. Ofwel, een duik in de datasheet. Die hebben het over 1uF ceramic aan de ingang voor 100mA. Nu verwacht je wel wat meer stroom maar heb je wel het voordeel dat je een stabiele batterij als voeding hebt. Dus daar kom je denk ik wel mee weg. Maar let op, ceramic is daarin wel belangrijk. Voor de uitgang hebben ze het weer over 1uF maar is het type niet zo kritisch ook al hebben ze graag een ESR <2Ω. Maar tot zeg 10uF verwacht ik daar niet snel een issue.

Maar buiten wat de regulator wil is eigenlijk ook belangrijk wat elke chip wil. Daar wil je eigenlijk voor elke chip (uC, sensor whatever) een 100nF ceramic (weer belangrijk) zo dicht mogelijk bij de chip hebben. Op modules zit deze er vaak al wel op maar op een bare ESP12 bijvoorbeeld niet.

Qua quiescent zit je met de de MCP1700 denk ik wel aardig. Maar het is en blijft een lineair regulator dus in bedrijf verstook je dus de rest. Let dus ook op met ledjes, deze vreten makkelijk je batterij op. De ESP is by far de grootste stroomvreter en die heeft tijdens wifi die 250mA wel nodig. Maar alle andere sensoren doen volgens mij amper iets als ik zo zie, dus ik zou het met een enkele regulator doen en wat meer capaciteit op de uitgang gooien bijvoorbeeld.

En ik kan voor programmeren alleen maar aanraden er een programming header op te zetten incl een auto-reset circuitje. Dit maakt programmeren gewoon zo veel makkelijker.

Qua sensoren, zoals gezegd heeft de INA219 een sleep. Ook de VEML6075, TSL2591 en MLX90614 kennen een sleep. Ofwel, lekker makkelijk. Regen sensor kan ook nog best uitmaken. Zeker gewoon resistive kan met regen ongunstig zijn. Ofwel, batterijduur zal heeeeel sterk afhangen van je software

[bnwgraaf]

@septillion
Super bedankt voor deze zeer uitgebreide toelichting! Daar kan ik weer heel wat stappen mee zetten!

Trek geen lijnen dwars over componenten heen

Daar liep ik al even mee te worstelen, al ziet dit schema er, naar mijn mening, al een stuk overzichtelijker uit :-)
Ik ben wel 3D CAD programma's gewend, maar had er even geen erg in dat de lengte en de routing in het elektrische schema niet de uiteindelijke routing is!

INA219 is zeker een module ipv de chip of niet? Anders mis ik de shunt.

Dat klopt! Het is een complete module.

Ik mis de pull-up's voor de I2C. Bedenk ook dat I2C niet geschikt is voor afstand. Dus prima als ze niet op het bord zitten maar verder dan een cm of 10, misschien 20, zou ik het niet rekken.

Met pull-up wordt toch een verbinding via een (10K) weerstand naar de VCC bedoeld? En moet dat dan op de SCL en SDA aansluiting?
Ik ga me toch eens inlezen over het gebruik van GPIO pinnen en pullup's en -down's!

De lengte van de bedrading tussen de esp en de sensoren zal kort zijn, in ieder geval maximaal 10 cm. De esp komt in een dichte behuizing, de sensoren daarbuiten.

Daar wil je eigenlijk voor elke chip (uC, sensor whatever) een 100nF ceramic (weer belangrijk) zo dicht mogelijk bij de chip hebben. Op modules zit deze er vaak al wel op maar op een bare ESP12 bijvoorbeeld niet.

Dan ga ik die er ook maar aan toevoegen.

De ESP is by far de grootste stroomvreter en die heeft tijdens wifi die 250mA wel nodig. Maar alle andere sensoren doen volgens mij amper iets als ik zo zie, dus ik zou het met een enkele regulator doen en wat meer capaciteit op de uitgang gooien bijvoorbeeld.

De wifi zet ik aan nadat ik eerst de sensoren heb uitgelezen en vlak voordat ik de waardes ga verzenden.

En ik kan voor programmeren alleen maar aanraden er een programming header op te zetten incl een auto-reset circuitje. Dit maakt programmeren gewoon zo veel makkelijker.

Ik had er al wel header pennen van alle ESP aansluitingen toegevoegd en de reset en flash buttons. Een autoreset had ik nog niet van gehoord, maar heb HIER info gevonden om eens in te duiken:
https://tttapa.github.io/...et%20and%20select%20'ck'.
Ik neem aan dat je dan op dezelfde manier kunt programmeren zoals bij een developer board via de usb, maar dan door gebruik te maken van een USB serial adapter (die ik nu ook gebruik)?

Qua sensoren, zoals gezegd heeft de INA219 een sleep. Ook de VEML6075, TSL2591 en MLX90614 kennen een sleep.

Moet ik de sensoren zelf via code ook in de sleep brengen, of gaan ze daar zelf in, wanneer ze niet aangesproken worden?


Ik weet dat veel ook gaat afhangen van de programmering. Ik heb een eerste opzet, maar weet ook dat daar nog veel in te optimaliseren valt.
Het zou fijn zijn als de hardware straks op orde is, dan kan ik de programmering verder oppakken.
Ik heb een stukje aan de code toegevoegd, dat als één specifieke GPIO laag is gemaakt (dmv een jumper of schakelaar), dan wordt deepsleep overgeslagen en loopt er een ander stukje code, waarbij ik toegang heb via SSH en waarbij ik een update kan doen via OTA (dit werkt op zich al). Verwijder ik de jumper weer, dan wordt de standaard loop inclusief deepsleep weer doorlopen.

[bnwgraaf]

Ik heb nog eens zitten neuzen naar een andere regulator om de 2 1700's te vervangen.

Ik weet niet of dat juist is, maar naast de output van 3.3V heb ik gekeken naar een zo laag mogelijke dropout voltage en quiescent stroom.

Zou dit iets kunnen zijn, zodat ik maar 1 regulator nodig heb?:
https://www.ti.com/lit/ds...2F%252Feu.mouser.com%252F

Ik zal er even goed voor moeten gaan zitten om deze te solderen, maar dat meot denk ik wel lukken...

Ik zit nog eens naar de specs te kijken. Maar zie ik nu goed dat de MCP1700 een veel lagere Iq heeft en 2 daarvan dus minder verbruiken dan 1x de LP38691 uit bovenstaande link?

[septillion]

Als je modules gebruikt zal je daarop ook moeten opletten of daar pull ups op zitten en of ze geen spanningsregulator bevatten. En natuurlijk, geen ledjes.

En dat is inderdaad een mooi handboek wat ik er ook nog wel eens bij pak. Auto reset en upload is erg fijn als je het kwijt kunt. Dan hoef je inderdaad niets te doen zoals bij een Wemos D1 mini etc.

Meeste sensoren zal je zelf in sleep moeten brengen. Hoe hangt dus af van de chip en/of van hoe goed de gebruikte library is.

Alleen maar SSH erop zetten voor OTA lijkt me zelf nogal heftig. Waarom niet de normale OTA? Wat gebruik je om de sensor data weg te sturen? Als het MQTT is zou je de jumper namelijk ook kunnen vervangen door een MQTT bericht.

Wat is de cut off voltage van je battery protection? Zelf zou ik denk ik voor de MCP1700 gaan omdat ze zo standaard zijn. Met een beetje extra capaciteit kan je dan de pieken van de wifi wel drukken. En dan heb je een gemiddelde van tegen de 75mA met wifi aan. Dan blijft er nog meer dan genoeg over voor de rest.


En ah, ja. Ik zag bij de LP38691 eerst alleen de off-state stroom maar daarvoor moet je de Enable laag maken. Dus ja, de MCP1700 is ook nog eens veeeel zuiniger, zelfs twee. Als je als nog de stroom van een enkele niet vertrouwd kan je altijd je PCB zo maken dat je ruimte hebt voor een tweede (+condensatoren etc) en dat je met een solder jumper / coffee bean de sensoren kunt wisselen.

[bnwgraaf]

septillion schreef op vrijdag 2 april 2021 @ 09:13:
Als je modules gebruikt zal je daarop ook moeten opletten of daar pull ups op zitten en of ze geen spanningsregulator bevatten.

Wanneer en precies waarom je de pull up's moet gebruiken is me nog niet helemaal duidelijk. Als je me daar nog eens in kan bijpraten of een duidelijke link hebt, dan hou ik me aanbevolen!
Wat betreft die regulator bedoel je natuurlijk dat die eigenlijk ook niet nodig is, vanwege de MCP1700? Nu zijn die modules voorzien van kleine componenten, maar theoretisch zou je die kunnen omzeilen?

Auto reset en upload is erg fijn als je het kwijt kunt.

Ga ik proberen toch nog toe te voegen, denk ik.

Alleen maar SSH erop zetten voor OTA lijkt me zelf nogal heftig. Waarom niet de normale OTA? Wat gebruik je om de sensor data weg te sturen? Als het MQTT is zou je de jumper namelijk ook kunnen vervangen door een MQTT bericht.

Nee, SSH had ik om direct via bijvoorbeeld Putty wat waardes en de status uit te lezen; een soort debug op afstand zeg maar. Mijn eerste esp projectje was een buiten-bewegingssensor voor een Philips Hue lamp. Die draait nu ongeveer 1,5 jaar en vooral in het begin heb ik nogal eens via SSH gekeken of de code goed werkte.
OTA heb ik een ander stukje code voor. Dat was ooit copy-paste zonder echt alle ins en outs van die code te begrijpen. Ik gebruik er onder andere de <ESP8266HTTPUpdateServer.h> library voor en als pin 12 hoog is, gaat er een ander stukje loop doorlopen worden met o.a.
httpServer.handleClient();
MDNS.update();

Het is natuurlijk veel fijner als ik niet eerst naar het kastje hoeft te lopen om een jumper te plaatsen, of schakelaar over te halen, maar dat ik gewoon zo direct kan updaten. Dat MQTT is dus weer een interessant iets om in te gaan duiken! Zat te leren nog!

De data wordt naar de Domoticz app op mijn NAS gestuurd via een aantal http commando's, met de volgende opbouw (er zit wat variatie in):

code:

/json.htm?type=command&param=udevice&idx=IDX&nvalue=0&svalue=TEMP;HUM;HUM_STAT;BAR;BAR_FOR

Wat is de cut off voltage van je battery protection?

De battery protection heeft een cutoff bij 2,5 V wat eigenlijk aan de lage kant is. Het is dan ook meer een laatste noodgreep, mocht de batterij te laag raken. Maar in de code heb ik al een stukje ingebouwd, waar onder een bepaalde spanning de deepsleep tijd verlengd wordt.

Met een beetje extra capaciteit kan je dan de pieken van de wifi wel drukken. En dan heb je een gemiddelde van tegen de 75mA met wifi aan.

Als ik terug kijk in de Domoticz geschiedenis, dan meet hij met de wifi aan zo'n 80 mA.
Wanneer de esp uit deepsleep komt, zet ik (nu nog wel) de spanning op de sensoren, lees dan alle sensoren uit, schakel de spanning op de sensoren weer uit en schakel vervolgens pas de wifi in om dan direct de waardes te verzenden. Direct daarna treedt de deepsleep in.

Als je als nog de stroom van een enkele niet vertrouwd kan je altijd je PCB zo maken dat je ruimte hebt voor een tweede (+condensatoren etc) en dat je met een solder jumper / coffee bean de sensoren kunt wisselen.

Ik denk dat ik dat ga toepassen.

Bedankt weer :-)

[bnwgraaf]

Als het MQTT is zou je de jumper namelijk ook kunnen vervangen door een MQTT bericht.

De reden dat ik trouwens met een jumper werk om de OTA in te schakelen is het feit dat de esp een groot deel van de tijd in deepsleep is.... Heb je dat probleem niet ook met een MQTT bericht?
Wanneer ik de jumper plaats, wordt de deepsleep uitgeschakeld in de code (en ook de OTA code ingeschakeld)..

[septillion]

bnwgraaf schreef op vrijdag 2 april 2021 @ 10:26:
Wanneer en precies waarom je de pull up's moet gebruiken is me nog niet helemaal duidelijk. Als je me daar nog eens in kan bijpraten of een duidelijke link hebt, dan hou ik me aanbevolen!

Als een ingang hoog impedant is kan werkelijk alles het niveau aanpassen. Een pull up (of down) trekt deze pin dan naar een stand die je weet. Nu zou je dit ook gewoon kunnen doen door direct een draad aan Vcc te hangen. Maar grote voordeel van een pull up is dat het geen harde verbinding is. In geval van een reset knop kan je bijvoorbeeld de pull up overrulen met een knop naar GND. De verbinding die je dan met de knop maakt zal het winnen van de pull up zonder dat er zo veel stroom loopt dat je sluiting hebt of een paar Watt verstookt in de weerstand. Veel simpeler dan dat je een knop nodig hebt die zelf wisselt tussen Vcc en GND. Zie een pull weerstand als een elastiek. Als je niet trekt blijft het zitten maar je ken het er makkelijk van winnen.

Dit principe wordt ook toegepast bij een I2C bus of andere open collector toepassingen. Elk device heeft alleen de mogelijkheid de lijn naar GND te trekken. De logische high / 1 state wordt gedaan door een pull up. Grote voordeel hiervan is dat de devices simpel zijn (alleen een N type transistor nodig) maar ook dat er geen sluiting kan ontstaan. Als elk device de lijn hoog of laag kon maken zou er in geval van collision (twee devices die tegelijk willen praten) anders sluiting ontstaan. Nu wint simpelweg het device dat de lijn laag trekt.

Wat betreft die regulator bedoel je natuurlijk dat die eigenlijk ook niet nodig is, vanwege de MCP1700? Nu zijn die modules voorzien van kleine componenten, maar theoretisch zou je die kunnen omzeilen?

Eigenlijk meer dat je die eraf wilt slopen Die zullen waarschijnlijk meer ruststroom hebben, hoger drop out en meer regulators is meer ruststroom. Dus ja, daar wil je dus vanaf.

Nee, SSH had ik om direct via bijvoorbeeld Putty wat waardes en de status uit te lezen; een soort debug op afstand zeg maar.

Ook daarvoor klinkt SSH als een zware (CPU cycles en programma grote) last voor iets simpels.

De data wordt naar de Domoticz app op mijn NAS gestuurd via een aantal http commando's, met de volgende opbouw (er zit wat variatie in):

code:

/json.htm?type=command&param=udevice&idx=IDX&nvalue=0&svalue=TEMP;HUM;HUM_STAT;BAR;BAR_FOR

Okay, gewoon HTTP GET dus. Ook daar zou je kunnen kijken naar MQTT. Binnen domotica wordt dat ook veel gebruikt. Zelf niet zo veel ervaring met Domoticz maar ben zelf een Home Assistant gebruiker.

De battery protection heeft een cutoff bij 2,5 V wat eigenlijk aan de lage kant is. Het is dan ook meer een laatste noodgreep, mocht de batterij te laag raken. Maar in de code heb ik al een stukje ingebouwd, waar onder een bepaalde spanning de deepsleep tijd verlengd wordt.

Oef, ja. Met 2,5V zou je hem volgens mij net zo goed weg kunnen laten, dan is je 18650 al wel toast...

bnwgraaf schreef op vrijdag 2 april 2021 @ 10:43:
De reden dat ik trouwens met een jumper werk om de OTA in te schakelen is het feit dat de esp een groot deel van de tijd in deepsleep is.... Heb je dat probleem niet ook met een MQTT bericht?
Wanneer ik de jumper plaats, wordt de deepsleep uitgeschakeld in de code (en ook de OTA code ingeschakeld)..

Ja en nee. Als de ESP in sleep is zal er niet direct iets gebeuren. Maar je de ESP subscribed op een topic, zeker als je daar QoS>0 voor pakt, zal de ESP dit bericht zelf ophalen wanneer hij wakker is. Het zal dus niet instant zijn en hangt sterk af van de sleep tijd die je wilt, maar je doet ook geen request naar je ESP moet een mogelijke time out.

[bnwgraaf]

Ondertussen is het me gelukt om de esp na het verbinden met het netwerk te laten controleren of er op mijn nas een update klaar staat en zo ja, dan wordt de update automatisch uitgevoerd.

Ik hoef alleen maar een nieuwe firmware op die locatie te zetten en in een tekstbestandje het nieuwe built nummer te zetten. Het controleren duurt maar 2/100 seconde, dus dat is geen probleem.

Wel is het zaak geen fatale fouten in de nieuwe code te hebben, waardoor de esp crasht. Eigenlijk zou ik gelijk aan het begin de firmware check en update moeten doen, maar dan heb ik daar ook al wifi nodig en die heb ik juist bewaard tot helemaal aan het einde van de code....

In Domoticz kan ik ook het built nummer zien zodat ik weet of de update gelukt is.

Met dank aan diverse websites overigens!

[Voor 30% gewijzigd door bnwgraaf op 03-04-2021 13:29]