Hallo. Wie viele solcher Anfragen anfangen möchte wir auch zunächst erwähnen, dass wir Anfänger sind, was die Mikrocontroller angeht. Unser kleines Grüppchen macht eine Projektarbeit zum Thema Energiemonitoring. Wir müssen nun unserere Ergebnisse auf eine kleine Schlatung übertragen. Und zwar geht es folgendes: Es wird eine Steckdosenleiste an die, wer hätte es gedacht, Steckdose (~230V) angeschlossen. An die Steckdose kommen Verbraucher. Wir messen Spannung und Strom und analysiieren das Spektrum. Für uns sind die ersten 10 Harmonischen (also die ersten 10 vielfachen der Grundfrequenz, 50 Hz, 100 Hz, 150 Hz ... 500 Hz) interessant. Das errechnen wir zZ mit Matlab mittles der FFT. Durch u.a. dieser Analyse erhoffen wir uns die einzelnen Verbraucher aus einer Summenmessung unterscheiden zu können. Nu geht es darum das ganze auf der Mikrocontrollerebene zu realisieren. Uns wurde der ATmega 60 bzw 128 empfohlen, bzw nutz einen solchen Controller ein mit uns im Zusammenarbeit steher Lehrstuhl. Unsere Frage wäre eben, was man alles an Hardware dazu bräuchte und ob der ATmega die FFT ohne Schwierigkeiten schafft. Also noch einmal: Eingang: Spannung 220V (muss runtertransformiert werden) Strom (mittels einer Stromzange in Spannung transformiert) FFT der beiden Messsignale->Betrag der ersten 10 Harmonischen, Phasenwinkel zwischen Strom und Spannung. Die Messungen der einzelnen Verbraucher werden gespeichert. Ausgang: Der identifizierter Verbraucher: Bezeichnung (zB 001 für TV) und aktueller Verbrauch. Würde uns sehr über Tipps freuen :) Gruß PG TU Dortmund
hm 10.Oberwelle..., dann brauchst du eine wieviel-Punkte-FFT?? Mind. 8192, oder? Weiss ich jetzt nicht genau. Aber selbst das dürfte schnell die RAM-Kapazitäten überfordern. Mit 8bit-Auflösung wird das gnaze wahrscheinlich auch nichts sinnvolles -> schwups hat sich der RAM-Bedarf verdoppelt. Ich würde da eher in Richtung 16/32bit-Controller gehen. Noch besser DSP, falls es auch auf die Rechenzeit ankommt. Mal zum Vergleich, 2048-Punkte-Integer-FFT auf einem M16C mit 24MHz dauert rund 1,5s, ziemlich optimierter Code. Denk an ausreichend RAM, nur mit internem Speicher wird das i.a. nichts.
@ crazy horse Also einer von uns liegt jetzt komplett falsch... Ich tendiere eher zu einem ATmega16 oder ATmega32 - z.B. in einem STK500. Der Speicherbedarf für die FFT ist lächerlich: Fensterdauer liegt bei
1 | 1 / 50 Hz = 20 ms |
Fenstergröße liegt bei achtfacher Überabtastung der höchsten Frequenz (ist eigentlich schon viel zu viel) bei
1 | 500 Hz * 20 ms * 8 = 80 Samples |
Bei einer 16-Bit-Speicherung von Strom und Spannung liegen wir damit bei 320 Bytes. Über die Rechenzeit brauchen wir dabei gar nicht reden - der Controller wird sich zu Tode langweilen. Oder habe ich was übersehen?
>Oder habe ich was übersehen?
Ja, dass sich nicht jeder mit Signaltheorie und Algorithmik auskennt.
Wenn man weniger denken will, nimmt man einfach einen Großrechner.
@Vladimir: Das Projekt hört sich wirklich interesannt an. Mich würde es zwar wundern, wenn man reproduzierbare Ergebnisse erhält (dafür sind z.B. verschiedene TV-Geräte zu unterschiedlich aufgebaut), aber vielleicht hat das ja doch Erfolg. Folgende Seite könnte weiterhelfen: http://elm-chan.org/works/akilcd/report_e.html Mich würden die Ergebnisse mal interessieren, falls diese veröffentlicht werden. Gruß, SIGINT
Ich finde das Projekt auch sehr interessant. Ich gehe wie Sigint auch nicht davon aus, dass eine eindeutige Unterscheidung möglich ist, aber auf die Messreihen bin ich trotzdem gespannt!
Das mit dem Ram ist ne gute Frage. Die FFT von der Spannnung wird man sich wohl sparen können. Das interessante ist der Strom. Über den Speicherbedarf habe ich mir wirklich noch nicht so viele Gedanken gemacht. Na ja, es ist eher der Auswertungsalgorithmus, der dahinter steckt, nicht einfach nur die Ergebnisse der FFT g Den müssen wa noch ausarbeiten. Die Analye mit Matlab geht ganz gut vorran. Wir wollen auch nicht gleich mit komplizierten Geräten anfagen. Zudem ist das schon so aufgebaut, dass man durchaus reproduzierbare bzw nützliche Sachen erhält. Auf der Hannovermesse gab es schon Ansätze, aber in einem viel zu uninteressanten Ausmass. Wir melden uns natürlich, falls das Erfolg hat und veröffentlich wird. Es ist ne Arbeit von drei Lehrstuhlen und ist schon ein wenig breiter ausgelegt. Bisher haben wir für die Abtastung den Oszilloskop mit Fs=10KHz genutzt. Die Abtastfrequenz sollte ja min. das doppelte der vorkommenden Frequenz betragen. Es gibt insgesamt 50 Harmonischen, wovon wir die ersten 10 brauchen. Entweder muss man das ganze cutten oder mit min. 5KHz abtasten. Eine Sekunde liefert bereits 10000 Werte. Na ja, eigentlich müssen wir das noch kürzer als eine Sekunde betrachten, besonders für Geräte wie eine Lötstation oder eben el. Heizgeräte. Das mit dem Speicher ist echt eine gute Frage.
>Eine Sekunde liefert bereits 10000 Werte. Die Grundfrequenz beträgt aber konstant 50 Hz, weshalb es völlig ausreicht 10000 / 50 = 200 Werte zu speichern und diese 50 mal pro Sekunde auszuwerten. Wenn ihr immer 10000 Werte am Stück nehmt verlagern sich zu viele Signalinformationen in die höheren Obertöne, die ihr aber nicht auswerten wollt/sollt. Ihr müsst ohnehin einen Tiefpass vorschalten. Den kann man bei bekanntem Frequenzgang (was er für euer Projekt haben sollte) evtl. auch noch was enger ziehen und die Dämpfung der Oberwellen im Ergebnis wieder rausrechnen. Damit könnte man das Signal bei Bedarf noch langsamer abtasten und den Speicherbedarf weiter reduzieren. Über die FFT würde ich mir keine Sorgen machen. >Der identifizierter Verbraucher: Bezeichnung (zB 001 für TV) und >aktueller Verbrauch. Das stelle ich mir kniffliger vor und ich empfehle das zuvor auf einem Rechner mit genug Freiheiten (RAM und CPU) auszutesten. Hier kann ich zumindest den Resourcenbedarf nicht abschätzen, weil ich den Algorithmus nicht kenne. Bei der FFT ist das einfacher. Ihr solltet zum Testen des Erkennungsalgorithmus auf jeden Fall dieselbe FFT wählen wie die, die später auf dem Mikrocontroller implementiert wird, sonst fangt ihr u.U. nochmal von vorne an. >Die FFT von der Spannnung wird man sich wohl sparen können. Wie wollt ihr dann den oben erwähnten Phasenwinkel zwischen Strom und Spannung bestimmen (den ich im Übrigen besonders interessant finde)? Schöne Grüße Kai
Stimmmt, mit 200 Werten und 50 Mal pro Sek auswerten ist eine gute Idee. Wir müssen ohnehin öfter als ein Mal pro Sekunde auswerten. Das mit dem Phasenwinkel ist mir vorhin entfallen, sollte nicht posten, wenn ich müde bin. D.h. es werden 50 Mal pro Sek zwei FFTs ausgeführt. Den Speicherbedarf könnte man doch gut drücken bei der Spannungsfft, da interessiert uns ja nur die Phaseninformation. Gut, wir werden erst einmal weiter an dem Algorithmus arbeiten, dann könnte man auch eher abschätzen, was alles gebraucht wird. Danke für die Tipps.
Kai Giebeler wrote: > Ich finde das Projekt auch sehr interessant. Ich gehe wie Sigint auch > nicht davon aus, dass eine eindeutige Unterscheidung möglich ist, aber > auf die Messreihen bin ich trotzdem gespannt! Sehe ich auch so. Man kann höchtens die Verbrauchertypen unterscheiden, aber weniger am Spektrum, sondern eher an Stromverlauf und Phasenwinkel. Z.B. ohmsche Last, induktive Last, kapazitive Last, Graetzbrücke mit Elko, Schaltnetzteil mit oder ohne PFC, Phasenanschnitt. Der Stromverlauf läßt sich zwar indirekt über das Spektrum ermitteln, ist aber erhöhter Rechenaufwand. Es gibt aber Überlegungen, in den Geräten Modulatoren einzubauen, die einen digitalen Code versenden können. Dabei geht es darum, den Gewinn der Energieversorger zu steigern (Verbraucher kauft Zusatzgeräte für Lastverteilung oder zahlt mehr). Peter
Ihr denkt teilweise ein wenig zu weit nach vorn. Ist aber nicht schlimm. Wir können leider nicht all zu viel verraten, aber es sollte machbar sein ;)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.