Elektroniktokig
· Nårrrje ;-)
· 138 inlägg
Litiumbatteriet har vel relativt stor indre motstand, så det vil uansett måtte støttes av en stor kondensator. Det vil ikke alene kunne levere så kraftige strømpulser. Enkleste løsning er nok en stor superkondensator med lav ESR (equivalent serial resistance). Dette siste er viktig; man kan ikke bruke de som er beregnet på å erstatte et batteri.B Bo Berglund skrev:
Vi benytter denne: http://www.cda-cap.com/userfiles/202051319838778.pdf
Elektroniktokig
· Nårrrje ;-)
· 138 inlägg
Firmwaren i din enhet kan ikke påvirke det, men i prinsippet kan jo firmwaren i elmätaren endres - og det kan _muligens_ påvirke hvor "nervøs" elmätaren er, dvs hvordan den reagerer på kraftige strømpulser.B Bo Berglund skrev:
Men det blir jo bare spekulasjon. Det beste holdepunktet vi har er de relativt detaljerte kravene i spesifikasjonen: https://www.netbeheernederland.nl/_upload/Files/Slimme_meter_15_a727fce1f1.pdf
Om man sørger for at enheten man kobler til holder seg innenfor grenseverdiene gitt i speccen skal man være "home and dry". Men man trenger god måleutrustning for å se hva som skjer dynamisk. Nordic Power Profiler Kit II er en strålende løsning for slike målinger som dette. (Man kan trolig få til noe lignende med en liten shuntmotstand og oscilloskop.)
https://www.nordicsemi.com/Products/Development-hardware/Power-Profiler-Kit-2
Intressant läsning.pacman42 skrev:
Man undrar ifall det helt enkelt räcker med ett anrop delay(1); i loop() i stället för som de skriver att sätta det efter varje anrop till handleClient().
I min version av githubprojektet har jag följande liknande anrop inne i loop():
void loop()
{
ArduinoOTA.handle();
delay(1); //Added to reduce power drain.
...
HandleWebConfigServer();
delay(1); //Added to reduce power drain.
...
httpServer.handleClient();
delay(1); //Added to reduce power drain.
...
}
Frågan är ifall man helt enkelt bara kan slänga in en enda som anropas längst upp eller längst ner?
Idén är väl att låta CPU:n räkna mikrosekunder för det mesta och inte spendera tid på att kolla IP-stacken efter eventuella meddelanden...
Elektroniktokig
· Nårrrje ;-)
· 138 inlägg
Poenget er at den skal gjøre "noe" mens den venter - og at det "noe" skal være en delay.B Bo Berglund skrev:
Da trengs det kun èn delay(1); i hver loop.
Skulle säga att för mycket delay gör stacken ostabil med när jag testat det. Främst på esp8266.
Om elmätarens P1 port stöder DSMR ver 5 ska den kunna leverera 250 mA kontinuerligt, men ver 4 behöver bara leverera 100 mA vilken är mindre än de ca 130 mA som Wi-Fi modulerna drar när de sänder.
Så om mätaren har en äldre version av DSMR protokollet (eller egen avart) så behövs en (extra stor) kondensator för att laga energin för den strömspik som uppstår då Wi-Fi paket sänds. Eller så levererar elmätaren tillräckligt även med äldre standard.
Från 1000 upp till 4700 uF tycks fungera för de äldre varianterna, men beror många faktorer.
Men med stor kondensator blir de ju stor startström som aktiverar strömbegränsningen.
Krav i version 5…
Så utgången kommer att leverera mindre ström om den belastas för hårt , främst vid uppstart.
Vid normal drift bör man ju undvika att strömbegränsningen slår till.
En delay på 1-10 ms efter wifi handlern reducerar strömförbrukningen med ca 60% enligt länk utan att webbservern får märkbart längre svarstider.
Längre tider tex 100 ms fördröjer svaret motsvarande tid.
Hur mycket ström som behövs beror ju på applikationen hur många datapaket som sänds över Wi-Fi .
Lyssna drar lite ström, sända paket drar ”mycket” ström.
Sen genereras det lite extra trafik för IP/Wi-Fi (connect till SSID/arp/rarp och radiogränssnittet) utöver mätdatat.
Här vet jag inget om hur IP stacken arbetar i bakgrunden med bakgrundstrafik eller bara arbetar då den blir anropad.
Delay vid uppstart låter klokt.
Först så att den stora kondensatorn är fullt uppladdad innan programvaran startar, så att det finns energi nog att starta Wi-Fi/TCP/IP protokollstack.
Och sen löpande för datapaket med mätdata.
En delay i main-loopen kanske räcker men är nog inte optimalt för att hålla nere strömpeakar i alla lägen.
Att det blev en sån soppa av HAN/P1 ”standarden” berodde på att branchen själva skulle få specificera protokollet…
Det gick ju Inge vidare. Samma mätare kan ha olika protokoll i olika länder eller hos olika elbolag, men version 5 av (tyska) DSMR tycks gå att använda utan speciella hyss och hack för att strömförsörja en Wi-Fi mätdata adapter.
Eller om man vänder på det, så har tillverkarna varit duktiga på att leverera olika versioner HAN portar beroende på vad deras kunder beställer…
SmartGateways.nl hade en diger lista över svenska elmätare och vilka versioner av protokollet elmätarna använde, men de tycks ha tagit bort den. 😢
Så om mätaren har en äldre version av DSMR protokollet (eller egen avart) så behövs en (extra stor) kondensator för att laga energin för den strömspik som uppstår då Wi-Fi paket sänds. Eller så levererar elmätaren tillräckligt även med äldre standard.
Från 1000 upp till 4700 uF tycks fungera för de äldre varianterna, men beror många faktorer.
Men med stor kondensator blir de ju stor startström som aktiverar strömbegränsningen.
Krav i version 5…
Så utgången kommer att leverera mindre ström om den belastas för hårt , främst vid uppstart.
Vid normal drift bör man ju undvika att strömbegränsningen slår till.
En delay på 1-10 ms efter wifi handlern reducerar strömförbrukningen med ca 60% enligt länk utan att webbservern får märkbart längre svarstider.
Längre tider tex 100 ms fördröjer svaret motsvarande tid.
Kod:
void loop(void)
{
server.handleClient();
delay(1);
}Hur mycket ström som behövs beror ju på applikationen hur många datapaket som sänds över Wi-Fi .
Lyssna drar lite ström, sända paket drar ”mycket” ström.
Sen genereras det lite extra trafik för IP/Wi-Fi (connect till SSID/arp/rarp och radiogränssnittet) utöver mätdatat.
Här vet jag inget om hur IP stacken arbetar i bakgrunden med bakgrundstrafik eller bara arbetar då den blir anropad.
Delay vid uppstart låter klokt.
Först så att den stora kondensatorn är fullt uppladdad innan programvaran startar, så att det finns energi nog att starta Wi-Fi/TCP/IP protokollstack.
Och sen löpande för datapaket med mätdata.
En delay i main-loopen kanske räcker men är nog inte optimalt för att hålla nere strömpeakar i alla lägen.
Att det blev en sån soppa av HAN/P1 ”standarden” berodde på att branchen själva skulle få specificera protokollet…
Det gick ju Inge vidare. Samma mätare kan ha olika protokoll i olika länder eller hos olika elbolag, men version 5 av (tyska) DSMR tycks gå att använda utan speciella hyss och hack för att strömförsörja en Wi-Fi mätdata adapter.
Eller om man vänder på det, så har tillverkarna varit duktiga på att leverera olika versioner HAN portar beroende på vad deras kunder beställer…
SmartGateways.nl hade en diger lista över svenska elmätare och vilka versioner av protokollet elmätarna använde, men de tycks ha tagit bort den. 😢
Kan vara det som händer hos mig för det har verkat så oberäkneligt...
Jag har 1000 uF efter 2 dioder som droppar till c:a 3.5 V. Har funkat fint ända tills nu.
Hur kan man få till en "lagom" belastning vid start så att inte överströmsfunktionen triggas? Men så att det inte blir problem längre fram med WiFi-sändning? Seriemotstånd är ju inte så bra för då tappas spänning vid WiFi-sändning.
(Jag skall sätta dit en regulator när jag kommer hem igen och då tar jag bort dioderna...)
Min f/w sänder meddelanden direkt vid start:
- Först anropas ett webbscript på min server med data som IP-adress, hostnamn mm. Detta skickas sen med epost till mig av servern.
- Sedan postas data om uppstarten med hostnamn, f/w-version, temperatur och WiFi signalstyrka till en MQTT-broker på mitt LAN.
Därefter startar själva monitoreringen den normala driften:
Där sänds ett MQTT-telegram var 60:e sekund med data som lästs senast och ett anrop till ett script på webbservern varje hel timme.
Men det är all WiFi-aktivitet som förekommer.
Redigerat:
Den modulen kan peaka 0,5A enligt databladet.B Bo Berglund skrev:
Jag skulle satt 1000uF på 5V, bytt dioderna mot en 3,3V LDO regulator och sen 10-100uF på 3,3V matningen. (Typ LDO i TO-92 kapsel, men denna klarar olyckligtvis också bara 250mA, så en i TO220 kapsel blir bättre).B Bo Berglund skrev:
Med en regulator skulle 5volten på 1000uF kodningen kunna sjunka några volt isf några hundra millivolt och CPUn fortsätta snurra iaf.
Men det kan nog gå att trixa med delayer så strämspikarna inte blir för många under kort tid också.
Edit: länk till kraftigare regulator.
Redigerat:
Elektroniktokig
· Nårrrje ;-)
· 138 inlägg
_Stor_ kondensator på 3,3V (se mine tidligere innlegg lengre oppe).blackarrow skrev:
LDO med en liten motstand på input-siden som strømbegrensning, slik at både inrush og short peak strømmer holdes nede.
Jag har beställt en sån här från electro:kit
Hoppas att den funkar.
Vad är det för motstånd du rekommenderar som strömbegränsning?
Hoppas att den funkar.
Vad är det för motstånd du rekommenderar som strömbegränsning?
Elektroniktokig
· Nårrrje ;-)
· 138 inlägg
Den er sikkert OK, men vær oppmerksom på at den har veldig høy dropout spenning sammenlignet med mer moderne regulatorer. Å kalle den "LDO" er det vi i Norge kaller en "tilsnikelse" - og gjøres vel kun fordi i "gamle dager" var 1V ansett som lav dropout.B Bo Berglund skrev:
Dette er dropout spenningen på din regulator (fra databladet):
Dette blir nok ikke et problem når du regulerer ned fra 5V til 3,3V, men allerede ved inngangsspenning ca 4,4V begynner denne å få problemer med å regulere.
Sammenlign for eksempel med TPS73633 som er en mer moderne LDO:
Du må nesten bare prøve deg frem med små motstander (størrelsesorden 10-20 ohm) for å se resultatet sammen med den kondensatoren du velger å benytte.
Utfordringen din blir antakelig å få til gode målinger av de transiente strømmene. Jeg bruker en Nordic Power Profiler Kit II til slike målinger.
https://www.nordicsemi.com/Products/Development-hardware/Power-Profiler-Kit-2
Om du har et oscilloskop kan du i stedet visualisere dynamisk strømtrekk ved å sette inn en liten shunt-motstand som du måler over.
