Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- software:controller:vzlogger:vzlogger_rpi_pico [2024/09/02 21:59] – tge
+++ software:controller:vzlogger:vzlogger_rpi_pico [2025/01/01 20:55] (aktuell) – DS18B20 IDs tge
@@ Zeile 1: / Zeile 1: @@
 ==== Vorwort ====
-Die Portierung des vzloggers auf den Raspberry Pico W war/ist ein "Bastelprojekt" insb mit der Motivation "das müsste doch gehen" und der aktuelle Zustand ist "funktioniert mit ein paar kleinen, noch zu behebenden Schönheitsfehlern" (siehe ganz unten TODO), wozu jede Hilfe willkommen ist.
+Die Portierung des vzloggers auf den [[https://www.raspberrypi.com/documentation/microcontrollers/pico-series.html|Raspberry Pico W]] war/ist ein "Bastelprojekt" insb mit der Motivation "das müsste doch gehen" und der aktuelle Zustand ist "funktioniert mit ein paar kleinen, noch zu behebenden Schönheitsfehlern" (siehe ganz unten TODO), wozu jede Hilfe willkommen ist.
 Weitere Motivation war die Verfügbarkeit von analogen GPIO Ports (on-board ADC), also analogen Sensoren (s.u.), sowie geringerer Stromverbrauch (batterietauglich?) und Anschaffungskosten.
@@ Zeile 10: / Zeile 10: @@
   * sehr eingeschränkter RAM sowie Flash-Memory
-Es gibt inzwischen RPi Pico 2 - damit noch keine Erfahrungen, offenbar auch auch nicht als "W"-Version verfügbar. Den RPo Pico 1 gibt es auch als "WH", also mit bereits angelöteten Pins - macht es nochmal einfacher.
+Es gibt inzwischen RPi Pico 2 - insb noch sparsamer (hat auch mehr RAM u Flash-Speicher, mehr Schnittstellen usw usf - alles bisher nicht benötigt).
+Die RPi Pico gibt es auch als "WH" mit bereits angelöteten Pins - macht es nochmal einfacher, aber auch etwas teurer.
 Versuche, libcurl zu portieren, hatten sich als sehr aufwändig herausgestellt und wurden abgebrochen.
-Statt dessen wird eine IP Implementierung "lwip" genutzt (sowie bei Bedarf sogar "mbedtls" als TLS Implementierung, bisher nicht genutzt).
+Statt dessen wird eine IP Implementierung [[https://www.nongnu.org/lwip|lwIP]] genutzt (sowie bei Bedarf sogar "mbedtls" als TLS Implementierung, bisher nicht genutzt).
 In der Konsequenz heisst das (nur, wenn entspr compiliert):
@@ Zeile 19: / Zeile 20: @@
   * Logging nach stdout, über USB sichtbar, solange der Pico an einem "richtigen" Computer am USB-Anschluss hängt (gleichzeitig Stromversorgung)
   * Ersetzen von pthreads durch main-loop Konzept
-  * Minimale Implemetierung (kein embedded httpd, kein Push-Server, kein MQTT, keine SML/S2/D2/mbus/... Protokolle - diese könnten aber vermutlich noch hinzugefügt werden, zumindestens teilweise)
+  * Minimale Implementierung (kein embedded httpd, kein Push-Server, kein MQTT, keine SML/S2/D2/mbus/... Protokolle - diese könnten aber vermutlich noch hinzugefügt werden, zumindestens teilweise)
   * Ersetzen von Curl durch lwip-API
 Dies wiederum erforderte ein paar Umstrukturierungen - der resultierende Code ist aber sowohl auf dem RPi Pico als auch einem normalen RPi lauffähig (muss natürlich separat gebaut werden).
+Mittlerweile läuft der u.g. EmonLib-basierte "Stromzähler" ununterbrochen seit mehreren Monaten ohne jegliche Komplikationen.
 === Install PICO Dev-Kit ===
@@ Zeile 66: / Zeile 69: @@
   $ cp ../EmonLib-vz/* .
+=== Update Dez 2024 ===
+Neu:
+  * Neue Sensoren: HC-SR04 Entfernungsmesser und w1therm DS18B20 (basierend auf GPIO) - die dazu verwendeten externen libs müssen ggf wie oben heruntergeladen werden, es sind aber wenigstens keine Anpassungen nötig.
+  * Verschiedene Energiesparmassnahmen - siehe ganz unten.
+  * kontinuierliche Abfrage und Ausgabe von RAM, Betriebsspannung, benötigte Rechenzeit in verschiedenen Modi (damit Hochrechnung Energieverbrauch möglich)
+  * Pico2 W getestet - minimale Änderungen notwendig, funktioniert noch besser
 === Bauen ===
-Zuerst muss die "embedded config" in src/vzlogger_pico.cpp angepasst werden, insb die VZ Server URL, WiFi Zugangsdaten, meters und channels - wie üblich, nur eben embedded.
+Zuerst muss die "embedded config" in einem eigenen Header-File (Beispiel vz_pico_inline_config.h) angepasst werden, insb die VZ Server URL, WiFi Zugangsdaten, meters und channels - wie üblich, nur eben embedded.
+Mit einem Pico2 W beim cmake Kommando als Board "pico2_w" angeben.
   $ cd ~/projects/vzlogger/pico
   $ mkdir build
   $ cd build
-  $ cmake -DPICO_BOARD=pico_w ..
+  $ cmake -DPICO_BOARD=pico_w -DVZ_BUILD_ON_PICO=1 ..
   ...
   $ make
@@ Zeile 106: / Zeile 119: @@
 {{:software:controller:vzlogger:rpi_pico:signal-2024-09-02-181804_002-1.jpeg?nolink&400|}}
-Die Grundidee ist nun, dass vzlogger kontinuierlich beide Sensoren abfragt (via EmonLib) und aus U und I sowohl Wirk- als auch Scheinleistung berechnet (bei PV Einspeisung sogar negativ).
+Die Grundidee ist nun, dass vzlogger kontinuierlich beide Sensoren (U und I) via EmonLib abfragt und daraus sowohl Wirk- als auch Scheinleistung berechnet (bei PV Einspeisung sogar negativ).
 Sieht dann so aus (bereits mit 2 Phasen, braun L1 und schwarz L2):
@@ Zeile 112: / Zeile 125: @@
 Ein Messzyklus mit EmonLib calcVI() misst 20 volle Sinuswellen (dauert bei 50Hz immer reichlich 200ms), dabei werden vom RPi Pico bis zu ~6000 Messwerte gewonnen.
-D.h. pro einzelner Sinuswelle gibt es Hunderte von einzelnen Messwerten, womit sich die Kurve gut rekonstruieren (auch wenn in der Realität verzerrt) und
+D.h. pro einzelner Sinuswelle gibt es Hunderte von einzelnen Messwerten, womit sich die Kurve gut rekonstruieren (selbst wenn in der Realität verzerrt) und
 auch die "Richtung" des Stroms (Bezug oder Einspeisung) ermitteln lässt.
 All dies ist sehr gut erklärt auf o.g. Seite, dort auch die Adapterschaltung:
 https://docs.openenergymonitor.org/electricity-monitoring/ct-sensors/interface-with-arduino.html
-Die EmonLib Erweiterung hat sich als notwendig entpuppt, da der o.g. kl Trafo eine hohe Phasenverschiebung (eingebaute Komponenten?) zwischen U und I erzeugte, d.h. U hat nicht mehr zu I gepasst, selbst und inbs. mit rein ohmschen Lasten (Toaster), wo genau dies eigtl nicht passiert.
+Die EmonLib Erweiterung hat sich als notwendig entpuppt, da der o.g. kl Trafo eine hohe Phasenverschiebung (eingebaute Komponenten?) zwischen U und I erzeugte, d.h. U passte nicht mehr zu I, selbst und inbs. mit rein ohmschen Lasten (Toaster), wo genau dies eigtl nicht passiert.
 Zum anderen ist in der Erweiterung die Möglichkeit enthalten, die tatsächlichen ADC Messwerte auszugeben, um diese dann in ein Spreadsheet zu laden und damit die echten Sinuskurven anzuzeigen.
 Beispiel (U und I verschoben, P aber korrigiert):
@@ Zeile 127: / Zeile 140: @@
 Idee hierbei ist es, im {{ :software:controller:vzlogger:rpi_pico:phasecal-generic.ods |Simulations-Spreadsheet}} die Stichproben-Reihen zu ermitteln die für U und I jeweils am nächsten bei Null sind (ohne Phasenverschiebung und mit rein ohmscher Last (!!) wäre dies exakt die gleiche Stichprobe) und
 quasi softwaremäßig wieder zurück zu verschieben, d.h. passend zu U Reihe 44 und für I Reihe 18, macht 44-18=26.
-Heisst, U ist I etwa 26 Stichproben voraus und ein korrekter Wert für P wird ermittelt, indem für jedes V[i] ein I[i - 26] verwendet wird.
+Heisst, I ist U etwa 26 Stichproben voraus und ein korrekter Wert für P wird ermittelt, indem für jedes U[i] ein I[i - 26] verwendet wird.
 All dies passiert innerhalb EmonLib - es muss nur der "phaseCalibration" Config-Wert eingestellt werden.
-Die resultierende config sieht dann so aus (bereits mit 2 gemessenen Phasen s.u.):
+Die resultierende config sieht dann so aus (bereits mit 2 gemessenen Phasen s.u. - dies hatte übrigens den Effekt,
+dass die L1 Phasenverschiebung nochmal etwas anders war: 35 statt 26.
+Möglicherweise Interferenz der beiden SCT013?):
   static const char * inlineConfig =
@@ Zeile 210: / Zeile 225: @@
   * delay - in Microsecs, Verlangsamung der Messschleife
   * numSamples - wie viele Sinuswellen messen
+Der "delay" entspricht einem "sleep(100us)", damit kommen "nur" ~1500 Stichproben pro Messzyklus heraus,
+hat aber den Vorteil, dass der L2 Phasecal-Wert mit 132 bedeutet, dass in EmonLib nicht mehr als 256 Stichproben
+aufgehoben werden müssen - diese Anzahl Stichproben ist immer noch viel mehr als genug um die Sinuskurve rekonstruieren zu können).
 === 3-Phasen ===
-Im Moment wird nur ein Phase gemessen - erstmal sehen, ob das überhaupt alles so klappt.
 Um mehrere Phasen zu messen, gibt es die folgenden Möglichkeiten:
@@ Zeile 218: / Zeile 237: @@
   * pro Phase ein SCT013 + nur ein Trafo an einer Phase.
-Variante 2 scheint ausreichend genau zu sein, d.h. U scheint für die verschiedenen Phasen ausreichend gleich. Es muss aber die gleiche Phasenkorrektur zwischen U und I wie oben stattfinden - wenn U und I an verschiedenen Phasen gemessen werden (dabei dann aber mit einer erheblich grösseren Differenz).
+Variante 2 scheint ausreichend genau zu sein, d.h. U scheint für die verschiedenen Phasen ausreichend gleich.
+Es muss aber die gleiche Phasenkorrektur zwischen U und I wie oben stattfinden - wenn U und I an verschiedenen Phasen gemessen werden (dabei dann aber mit einer erheblich grösseren Differenz, in der realen Beispiel-Config 132).
 === Simulation ===
@@ Zeile 231: / Zeile 251: @@
 Ein paar Erfahrungen, die man nicht alle nochmal selbst machen muss:
-  * Die SCT013 in Spannungsvariante liefern AC max 1V, kann man also einfach mit einem Multimeter testen - um *eine* Kabelader clippen, Strom durchfliessen lassen, messen. 30A macht 1V, also 3A == 100mV usw. Dabei gibt es *keine* Richtung. SCT013 in Stromvariante geht genauso, erfordert aber eine Lastwiderstand.
+  * Die SCT013 in Spannungsvariante liefern AC max 1V, kann man also einfach mit einem Multimeter testen - um *eine* Kabelader clippen, Strom durchfliessen lassen, messen. 30A macht 1V, also 3A == 100mV usw. Dabei gibt es *keine* Richtung. SCT013 in Stromvariante geht genauso, erfordert aber einen Lastwiderstand.
   * Der RPi Pico hat 3 (evtl 4) ADC Eingänge und genau einen ADC_GND (andere GND führen zu dubiosen Messwerten), d.h. alle Sensoren teilen sich den gleichen ADC_GND
+  * Die ADC Rohwerte lassen sich auch interpretieren. Der Pico ADC mit 12bits liefert also Messwerte zwischen 0..4094 (weil 2^12), d.h. mit einem 9V AC Netzteil (Leerlauf gern 11-12V, die dann mit der Adapterschaltung auf max 3V AC gebracht werden, mit 0 bei 1.5V) sind Rohwerte zwischen 500 und 3500 zu erwarten. Für I gilt prinzipiell das Gleiche, hier ist aber die Amplitude meist viel kleiner, die ADC Werte bewegen sich im 2000er Bereich.
   * Der vzlogger output geht über den USB Anschluss und lässt sich anzeigen, indem man den RPi Pico gleichzeitig per USB von Laptop mit Strom versorgt und dann, sobald der RPi Pico bootet:
   $ sudo screen -L /dev/ttyACM0
-  Das gibt alles nach stdout aus, sowie gleichzeitig in ein File screenlog.0, was man dann später analysieren kann (enthält auch den CALIBRATION output). Alternativ zum Laptop tut es auch ein "normaler "RPi". Vorteil: Im Dauerbetrieb kann der Laptop wieder ab. Das Logdatenvolumen kann per log-level in der embedded config gesteuert werden. Wenn alles klappt, als Stromversorgung ein einfaches USB Netzteil.
+Das gibt alles nach stdout aus, sowie gleichzeitig in ein File screenlog.0, was man dann später analysieren kann (enthält auch den CALIBRATION output). Alternativ zum Laptop tut es auch ein "normaler RPi". Vorteil: Im Dauerbetrieb kann der Laptop wieder ab. Das Logdatenvolumen kann per log-level in der embedded config gesteuert werden. Wenn alles klappt, als Stromversorgung ein einfaches USB Netzteil.
-  *
+Die DS18B20 w1 thermal Sensoren haben IDs, die in der config mit den channels verknüpft werden müssen. Anfangs sind diese IDs aber nicht bekannt - dann:
+  * Config mit irgendwelchen IDs Strings erstellen, Interval möglichst kurz (10s, sonst muss man solange warten)
+  * Loglevel auf 15 setzen, bauen und uf2 auf den Pico kopieren
+  * mittels USB Console den output protokollieren und auf folgende Ausgaben warten:
+  [Jan 01 19:54:07][mtr0] Querying meter ...
+  [Jan 01 19:54:07][]     Reading oneWire object 20012498 ...
+  [Jan 01 19:54:07][]     Have 2 oneWire devices.
+  [Jan 01 19:54:07][]     Adding ID[0]: 10D0F2BC020800A0
+  [Jan 01 19:54:07][]     Adding ID[1]: 280FB18600000068
+=== Energiesparmöglichkeiten ===
+Mit einem USB-Meter kann man messen, wieviel ein Gerät eigtl verbraucht. Der Pico W ("eins" übrigens, derweil gibt es V2 - noch nicht getestet)
+verbraucht ohne irgendwelche Anpassungen ~200mW (also ~40mA). Genauere Analysen zeigen: 40mA mit verbundenem WiFi, ohne WiFi ~20mA, während "connect WiFi" sogar 60mA -
+da ursprünglich WiFi dauerhaft verbunden war, resultieren daraus die ~40mA.
+Für Netzbetrieb gar nicht schlecht gut, für Batteriebetrieb aber noch viel zuviel.
+In der neuesten Version gibt es daher ein paar Config-Schalter, die Folgendes ermöglichen:
+  * Trennen WiFi wenn nicht benötigt
+  * Erst Daten sammeln, dann gesammelt schicken (Interval gesondert einstellbar, z.B. Messen alle 1min, senden nur alle 5min)
+  * Optimierung: Geteilte Netzwerk-Verbindung, wenn möglich (bisher jeder channel eigene Verbindung - obwohl eigtl gleicher Server:Port)
+  * CPU clock speed reduzieren, wenn weder Messen noch Senden (normalerweise 125MHz, gedrosselt 6MHz) - damit nur noch 9mA, dies aber fast die gesamte Zeit
+Mit all dem (und einer Config mit 1x HC-SR04 und 2x DS18B20) verbraucht der Pico W nur noch ~40mW (~8mA), der Pico2 W sogar nur ~25mW (~5mA).
+Mit einer 10000mAh Powerbank müsste dies also mindestens 8d reichen ...
+TODO:
+  * Powerbanks haben oft eine Abschaltung bei zu geringer Last - meine bei <100mA, geht also nicht.
+  * Es gibt Adaptermodule, die gleichzeitig ein PV-Modul und einen Akku ermöglichen - bestellt und unterwegs
+  * Es gibt noch einen lightsleep und deepsleep mode, womit nochmal erheblich weniger Stromverbrauch möglich sein könnte