Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- software:controller:vzlogger:vzlogger_rpi_pico [2024/09/02 22:16] – tge
+++ software:controller:vzlogger:vzlogger_rpi_pico [2025/01/01 20:55] (aktuell) – DS18B20 IDs tge
@@ Zeile 10: / Zeile 10: @@
   * sehr eingeschränkter RAM sowie Flash-Memory
-Es gibt inzwischen RPi Pico 2 - damit noch keine Erfahrungen, offenbar aber nicht als "W"-Version. Den RPi Pico 1 gibt es auch als "WH" 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.
@@ 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 130: / Zeile 143: @@
 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 ===
@@ 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, in der realen Beispiel-Config 132).
+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