Projekt vorgestellt: Strommessung im Haushalt bis 30A mit Arduino

[influencer]

wäre es (softwareseitig) nicht einfacher nicht nach jeder messung rumzurechnen, sondern einfach waerend der messung nur zu vergleichen ob sich der anstieg der stromkurve ändert und so den maimalwert i^ zu bestimmen. ebenso v^ (was ja bereits vorgeschlagen wurde) und diese messwerte (samt dem zeitlichen offset zwischen spannungs- und strompeak) zu übertragen und die ganze umrechnung von dem machen zu lassen der die daten per I2C empfangt ?
der kann in der regel besser/schneller/genauer float rechnen.
wäre das soviel ungenauer als die momentane 'manuelle' integration ?

[avr_racer]

und diese messwerte (samt dem zeitlichen offset zwischen spannungs- und strompeak)

Welchen zeitlichen Offset meinst du ? Der Offset der ensteht weil zu unterschiedlichen Zeitpunkten I und U gemessen werden oder der Offset = Phasenverschiebung der real zwischen U und I besteht woraus dann Phi errechnet werden kann ?
Zum ersteren bleibt es falsch weil du nicht wirklich zurückrechnen kannst.
Die Genauigkeit hängt davon ab zum richtigen Zeitpunkt die richtigen Daten zu erfassen da hilft auch kein Mehr an Rechenleistung des Empfängers.

Bei 8 Mhz dauert ein Takt 125ns und wenn ich jetzt mal annehme das im Durchschnitt eine Befehl 2takte braucht, bei 1ms Abstastung, sind immerhin 4000 Befehle die ausgeführt werden können.

Die momentane 'manuelle' Intergration ist ja nicht verkehrt, wenn aber Strom und Spannung zu unterschiedlichen Zeitpunkten aufgenommen werden und daraus der Phasenwinkel berechnet wird ist die Rechnung rechnerisch richtig aber nicht zum Zeitpunkt der Datenerfassung!!

Am besten zu verstehen indem man mal 2 mal sich ein Digaramm erstellt, gerne mit Excel und es durchrechnet mal zu Fuß wieviel die Leistung sowie der Phasenwinkel bei nur 1mm Unterschied zum ersten Diagramm abweicht

[White_Fox]

@influencer:
Man muß da überhaupt nicht mit Floats herumoperieren, außer im letzten Schritt bei der Ausgabe. Bis dahin geht alles genausogut mit 8/16 Bit Integer. Wie soll es auch anders sein, du kannst die Daten nicht genauer rechnen als sie reinkommen. Wenn man sowieso schon einen Mikrocontroller in der Messkette drinhat ist eine Vorverarbeitung fast immer sinnvoller als eine monolithische Datenverarbeitung. Was man bei der Messung nicht berechnet geht sonst für den Kommunikationsaufwand drauf (da ist meist der Flaschenhals).

Die Punkte von avr_racer sind alle völlig richtig, wobei ich angesichts des ganzen Schaltnetzteilkrams heutzutage noch die Oberwellen (wenigstens die erste Handvoll) mit ins Rennen schicken will. Mit einer schnellen Fourieranalyse (das als Google-Stichwort, da gibt es garantiert selbst für Arduino schon fertige Bibliotheken). Die mathematischen Beschreibungen sehen für Nichteingeweihte oft erstmal gruselig aus, was man damit aber eigentlich macht ist relativ simpel.

@stfan: Im Übrigen vielen Dank für deine Beschreibung, genau das wollte ich in meinem Post vorher wissen.

[stfan1409]

Also "FFT" – Fast Fourier Transformation ist mit dem Arduino möglich und es gibt auch eine Library dafür, wie White_Fox schon richtig vermutet hat. Hier z.B. http://shelvin.de/eine-einfache-fft-...m-arduino-uno/
Aber ist es nicht sinnvoll, erst das Problem mit der Messung/Phasenverschiebung in den Griff zu bekommen? FFT würde doch mit dem Ergebniss weiterarbeiten, oder mach ich einen Denkfehler...?
Wie kann ich denn die Phasenverschiebung zwischen Strom und Spannung ermitteln?

[avr_racer]

Wie kann ich denn die Phasenverschiebung zwischen Strom und Spannung ermitteln?

Seite 3 erster Post von mir mal querlesen...

[stfan1409]

Seite 3 erster Post von mir mal querlesen...

danke, ich war zu sehr auf die Formeln (oben) fixiert...

3. Nun muss als nächstes die Differenzzeit (Delta t) zwischen Spannung und Strom ermittelt werden wobei die Spannung dein Bezugspunkt ist....

[influencer]

Hallo, ich nochmal.

eins voraus: ich bin neu hier und eher programmierer (asm/c/c++) denn hardwarebastler.
das projekt finde ich aber spannend und daher mal einen dank an alle die sich hier beteiligen/beteiligt haben.
ich habe am wochenende lange ueber dem problem gebruetet:
im kern bin ich auf der Suche nach zwei verschiedenen loesungen fuer meine wohnung:
I) will ich zentral im sicherungskasten (weil man da gut an alles ran kommt / sich vor oder hinter die sicherungen schalten kann) die verbraeuche an allen sicherungen sekundengenau aufzeichnen.
II) haette ich gern die moeglichkeit mit moeglichst wenig aufwand an einzelnen steckdosen mit einem zwischenstecker die (wechselstrom-)verbraeuche aufzuzeichnen.

fuer II) denk ich mir inzwischen das es am einfachsten sein duerfte einen der gaengigen leistungsmesser (fuer die steckdose als zwischenstecker, in der regel mit display) zu 'hacken' und da einen bus (I2C/SPI/onewire/can/ethercat/ethernet) dranzubasteln und die vorhandene messtechnik zu 'missbrauchen'.
wenn die teile so 5-10eu und die busanbindung genauso teuer wird, klingt das noch finanzierbar.

fuer ideen dazu bin ich aufgeschlossen

aber wir reden ja hier eher von einer loesung fuer I), und dazu ein paar anmerkungen:
1) ja, ich wollte i^, u^ und den zeitlichen offset zwischen ihnen (also zwischen deren maxima, minima oder den flankengleichen null-durchgaengen) uebertragen.
da man zur leistungsberechnung dann mit wurzeln und mit irrationalen zahlen rechnen muss, fuerchte ich das ueberfordert die paar dutzend megahertz eines microcontrollers der seinen einen kern auchnoch zum messen und daten raushauen braucht.
2) das mit dem gleichzeitig messen habe ich verstanden und halte ich auch fuer wichtig. aber nichtmehr wenn man genau genug misst um ^-werte sicher zu finden und den (zeitlichen) offset zwischen strom und spannung damit auch.
abgesehen davon hat bei der aktuellen loesung das 'gleichzeitige' messen ein systemisches problem: ueber den SPI kann ich nur nacheinander werte abrufen (und damit messungen ausloesen), d.h. zwischen zwei messungen habe ich auf jeden fall den timeout von SPI und die antwortzeit des ADC.

als ich am wochenende ueber loesungen gegruebelt habe, habe ich folgendes verworfen:
raspi mit adc-shield (alle die ich gefunden habe, bezahlbar waren und genug kanaele geliefert haben, haben bei 12bit nurnoch dreistellige messwert-anzahlen/sekunde geliefert).
propeller fuer ca 8EU: https://elmicro.com/de/propeller.html
immerhin drei unanhaengige cpu's um 8kanaele mit hoher aufloesung abzutasten, aber dann brauchts immernoch passende flinke und genaue ADC's

die loesung die mir tragfaehiger erscheint:
beagle bone black (BBB) bei Reichelt ab ca 60EU, sonst gerne auch mal 90:
das teil bringt 8 ADC mit vernuenftiger geschwindigkeit mit, aber vor allem:
neben den 8 cpu's fuer linux, das man auch mit realtime-patches aufm raspi nicht auf harte echtzeit kriegt:
https://www.elektronikpraxis.vogel.d...6&type=article
bringt das teil noch zwei cpu's mit auf die man code laden kann, der in harter echtzeit (unabhaengig vom linux auf den anderen 8cores) auf die 8 ADC zugreifen und messwerte ueber shared memory miteinander und den linux-cpus teilen kann:
https://www.researchgate.net/publica...aglebone_Black

was ich mir vorstelle:
mit 3 ADC die spannungen L1-L3 messen, mit den restlichen 5 ADC fuer 0.5s die stroeme fuer 5verbraucher (= 5sicherungen in meinem fall) und fuer nochmal 0.5s die stroeme fuer 5andere verbraucher (=die restlichen meiner 10sicherungen) messen.
weiss noch nicht ob man das umkonfigurieren kann (wo adc-pins liegen solle) und wie lange das dauert.
aber in den 0.5s kann ein dedizierter core sicher problemlos die 25perioden auf seinen 8 ADC hochaufgeloest erfassen.
mit dem zweiten dedzierten core wuerde ich dann im 0.5s rhytmus die messwerte der letzten 25perioden auswerten.
im ergebnis kommt dann die durchschnittlich integrierte leistung fuer eine periode/verbraucher, frequenz, u^, i^, t(u^), t(i^), 3x t(0) [=zeitpunkte der nulldurchgaenge] und meinetwegen noch die effektivwerte raus + vielleicht der durchschnitt der messwerte also eine durchschnittskurve.
das alles sollen die beiden dedzierten cpu's machen.
die 8 nicht-echtzeit-cpus koennen sich dann darum kuemmern die daten ueber eine der schnittstellen des BBB zur verfuegung zu stellen, oder, z.b. ueber hdmi die (rekonstruierten) wellenformen darstellen oder differenz der integrierten leistung zu der unter einer perfekten sinus mit den entsprechenden ^-werten.

vermutlich waeren da noch kondensatoren zum glaetten hochfrequenter stoerungen sinnvoll um die (digitale) auswertung des gemessenen analogen grauens zu vereinfachen bzw. robuster zu machen.


moeglich das ich das alles viel zu naiv angehe, aber wuerde mich ueber rueckmeldung/kritik/rat freuen.
werde aber wegen arbeitsstress erst um weihnachten rum dazu kommen mich wirklich handfest mit dem thema zu beschaeftigen.

- - - Aktualisiert - - -

ein naiver nachtrag noch:
aus der ausbildung erinnere ich mich das ein widerstandsnetzwerk an digitalen pins einen brauchbaren und beliebig schnellen adc ergeben.
gibts sowas fertig zu kaufen ? ist das zu ungenau ? mit einem digitalen mux sollte man so ja krass viel oder schnell adc-werte bekommen koennen..

[influencer]

https://github.com/google/prudaq/wiki

gibts schon..

[White_Fox]

aber wir reden ja hier eher von einer loesung fuer I), und dazu ein paar anmerkungen:
1) ja, ich wollte i^, u^ und den zeitlichen offset zwischen ihnen (also zwischen deren maxima, minima oder den flankengleichen null-durchgaengen) uebertragen.
da man zur leistungsberechnung dann mit wurzeln und mit irrationalen zahlen rechnen muss, fuerchte ich das ueberfordert die paar dutzend megahertz eines microcontrollers der seinen einen kern auchnoch zum messen und daten raushauen braucht.
2) das mit dem gleichzeitig messen habe ich verstanden und halte ich auch fuer wichtig. aber nichtmehr wenn man genau genug misst um ^-werte sicher zu finden und den (zeitlichen) offset zwischen strom und spannung damit auch.
abgesehen davon hat bei der aktuellen loesung das 'gleichzeitige' messen ein systemisches problem: ueber den SPI kann ich nur nacheinander werte abrufen (und damit messungen ausloesen), d.h. zwischen zwei messungen habe ich auf jeden fall den timeout von SPI und die antwortzeit des ADC.

Ein paar Kleinigkeiten:
Nur die Spitzenwerte zu messen bringt dir absolut nichts. Da versaut dir das Rauschen des AD-Wandlers und der Vorbeschaltung schon den Tag. Zweitens funktioniert das nur mit dem idealen Sonderfall "sinusförmige Größen". Die hast du zumindest beim Strom nicht, nichtmal annähernd.

Der zeitliche Versatz zwischen Messung und Berechnung ist kein Problem. Das Ergebnis ist dann halt etwas später da, aber immer noch richtig. Auch wenn da ein lahmer SPI-Bus dazwischen ist (aber auch mit SPI kann man einige MBit/s übertragen).
Was dir Ungenauigkeiten reinzieht ist, daß bestimmt nicht mehrere ADCs hast, sondern EINEN ADC mit allenfalls mehreren Kanälen. Du kannst auf acht Kanälen nicht acht Messungen auf einmal durchführen, da mußt du zwischendurch umschalten.

Ein paar STM32-Controller haben z.B. drei ADCs drin (die jeweils auch über mehrere Kanäle messen können), die kann man sogar synchronisieren. Sowas ist für solche Messungen gut geeignet, wobei ich den zeitlichen Versatz bei den üblichen Netzfrequenzen nicht allzu kritisch sehe. Das geht mit einem AVR noch.

[stfan1409]

..., wobei ich den zeitlichen Versatz bei den üblichen Netzfrequenzen nicht allzu kritisch sehe. Das geht mit einem AVR noch.

Ich habe mal eine Exceltabelle gemacht, um zu klären, in wie weit sich das zeitversetzte Messen bemerkbar macht.
Die Tabelle macht einen Sinus mit je 200 Einzelwerten. Genau wie bei dem Arduino wird Strom und Spannung multipliziert, addiert und durch die Anzahl der Messungen geteilt.

Ergebnis der Leistungsmessung:
Bei 230V und 100A und einer Phasenverschiebung von 100uS(zeitversetztes messen) entsteht ein Messfehler von 0,049%.

Die Phasenverschiebung durch den Verbraucher muss natürlich beachtet werden. Bei einer Leuchtstofflampe sind das immerhin schon 5mS.

bringt das teil noch zwei cpu's mit auf die man code laden kann, der in harter echtzeit (unabhaengig vom linux auf den anderen 8cores) auf die 8 ADC zugreifen und messwerte ueber shared memory miteinander und den linux-cpus teilen kann:
https://www.researchgate.net/publica...aglebone_Black

über den Link komme ich zu einer PDF-Datei. Suche ich nach adc ist die Rede von einem MCP3008, welcher nen adc auf 8 Kanäle muxt - genau wie White_Fox schon vermutet hat. Da ist nix mit gleichzeitig messen.