Hallo, ich sitze gerade an den ersten Überlegungen einer Periodenerkennung eines zeitdiskreten Signals. Ich habe einen AD Wandler und messe hier eine Spannung, die in der Frequenz variiert. Für anschließende Berechnung der Leistung muss ich zuvor die Periode des Signals ermitteln. Der Verlauf des angeschlossenen Signals ist jedoch völlig unbekannt. Ich muss erkennen, wann eine Periode abgeschlossen ist und eine neue beginnt, auch wenn sich die Frequenz des Signals ändert. Erste Überlegungen zur FFT und Autokorrelation habe ich erstmal verworfen, da ich bereits zum Ende der ersten Periode diese erkannt haben muss. Möglicherweise mithilfe der Nulldurchgänge? Wird jedoch auch etwas ungenau... Ich messe mit dem ADC mit 500kHz ein Signal, das zwischen 0 und mindestens 1000 HZ, möglicherweise auch mehr, veränderlich ist. Vielen Dank schon mal! Grüße Julian
:
Bearbeitet durch User
Julian B. schrieb: > Für anschließende Berechnung der Leistung muss ich zuvor die Periode des > Signals ermitteln. Eigentlich nicht... Denn die Leistung ist ja punktuell definiert mit P=U*I. Da kommt keine Zeit oder Periode drin vor. > Möglicherweise mithilfe der Nulldurchgänge? Wird jedoch auch etwas > ungenau... Definiere "genau". > Erste Überlegungen zur FFT und Autokorrelation habe ich erstmal > verworfen, da ich bereits zum Ende der ersten Periode diese erkannt > haben muss. Wenn du nicht weißt, wie lange ein Periode ist, wie willst du denn wissen, wann sie anfängt und aufhört? Wie wäre es, wenn du das eigentliche Problem beschreibst und nicht deine Lösungsansätze? Und was hat das mit FPGAs zu tun? Für mich sieht das bisher nach Systematik zur Signalverarbeitung aus...
Julian B. schrieb: > Erste Überlegungen zur FFT und Autokorrelation habe ich erstmal > verworfen, da ich bereits zum Ende der ersten Periode diese erkannt > haben muss. Kniffelig bis unmöglich. Da muss man schon wissen, dass das kommende nur eine Wiederholung ist. Dies wäre nur möglich, wenn man das Signal im Voraus ziemlich genau kennt -- etwa wenn man weiß, dass es sich um einen ziemlich reinen Sinus mit einer Frequenz in einem bestimmten Bereich handelt.
> Wie wäre es, wenn du das eigentliche Problem beschreibst und nicht deine > Lösungsansätze? > > Und was hat das mit FPGAs zu tun? Für mich sieht das bisher nach > Systematik zur Signalverarbeitung aus... danke für eure Antworten. Ich habe ein MicroZed-Board und habe hier zwei ADCs angeschlossen die besagte 500S/s an Messwerten liefern. Aus dem gemessenen Signal muss nun bestimmt werden: -Scheinleistung Wirkleistung cos(phi) -mittlere Leistung -RMS (spätestens hier ist die Periode wichtig) die errechneten Werte sollen am Ende der Periode den Messwerten angefügt werden. Das ganze soll in VHDL in der PL im Zynq passieren. Ich habe einen AXIS Stream der einzelnen Messwerte + errechneten Werte die dann über einen DMA in den RAM geschrieben werden und über TCP/IP ausgegeben werden (funktioniert soweit alles, nur mit berechnungen im FPGA tu ich mich etwas schwer)
Julian B. schrieb: > -RMS (spätestens hier ist die Periode wichtig) Musst du die Effektivleistung tatsächlich in jedem Zyklus neu berechnen? Oder willst du es nur, weil die Formel so dasteht? Alte Effektivwertmessgeräte haben nämlich einfach das Integral so lang gemacht, dass der Fehler durch die "falsche Periodenlänge" kleiner war als der spezifizierte Messfehler. Julian B. schrieb: > Der Verlauf des angeschlossenen Signals ist jedoch völlig unbekannt. Woher kommt das Eingangssignal? Ist das tatsächlich ein glockenklarer Sinus oder hast du da beliebige, evtl. sogar zufällige Oberwellen? Was ist mit Störungen auf dem Signal? Kannst du auf dem Oszi eine eindeutige Periode erkennen? Kannst du mal einen Screenshot vom Oszi posten?
Angehängte Dateien:
-
Verlauf.png
15 KB -
Verlauf2.png
21 KB
Lothar M. schrieb: > Julian B. schrieb: >> -RMS (spätestens hier ist die Periode wichtig) > Musst du die Effektivleistung tatsächlich in jedem Zyklus neu > berechnen? Oder willst du es nur, weil die Formel so dasteht? > Alte Effektivwertmessgeräte haben nämlich einfach das Integral so lang > gemacht, dass der Fehler durch die "falsche Periodenlänge" kleiner war > als der spezifizierte Messfehler. > nein nicht wegen der Formel. Ich möchte tatsächlich nach einer Periode oder um die Datenmenge zu reduzieren nach n Perioden. > Julian B. schrieb: >> Der Verlauf des angeschlossenen Signals ist jedoch völlig unbekannt. > Woher kommt das Eingangssignal? > Ist das tatsächlich ein glockenklarer Sinus oder hast du da beliebige, > evtl. sogar zufällige Oberwellen? Was ist mit Störungen auf dem Signal? > Kannst du auf dem Oszi eine eindeutige Periode erkennen? Kannst du mal > einen Screenshot vom Oszi posten? Das Signal kommt vom Frequenzumrichter. Glockenklar ist da leider nichts, Oberwellen sind massiv vorhanden. Anbei der Verlauf, gemessen nicht mit dem Oszi sondern dem ADC. Hier ist das Signal nun konstant, am Frequenzumrichter ist eine konstante Frequenz eingestellt. Diese kann aber auch variieren!
Das sieht ja aus wie ausgekotzt. Mach es doch einfach so: Wirkleistung=
Scheinleistung=
Musst halt nur lang genug sampeln. damit wie Lothar Miller schon geschrieben hat der Fehler klein wird.
:
Bearbeitet durch User
Julian B. schrieb: > Ich habe einen AD Wandler und messe hier eine Spannung, die in der > Frequenz variiert. Für anschließende Berechnung der Leistung muss ich > zuvor die Periode des Signals ermitteln. Wenn ich mir die Signale so ansehe und mir eine induktive Last vorstelle, dann solltest du zur Berechnung der Leistung aber schon auch den Strom haben. Denn allein aus der Spannung kannst du an einer induktiven Last nicht auf die Leistung schließen... Julian B. schrieb: > Anbei der Verlauf, gemessen nicht mit dem Oszi sondern dem ADC. Wenn ich mir die Signale so ansehe, dann musst du da mit dem großen Signalverarbeitungshammer namens "Autokorrelation" draufhauen, um irgendwas herauszufinden. Das macht in VHDL aber nicht wirklich Spass. Setze doch einfach einen Prozessor-Core auf, rechne in C und hoffe, dass das Ding schnell genug ist (bei 500Hz Datenrate stehen deine Chancen sehr gut).
Lothar M. schrieb: > Wenn ich mir die Signale so ansehe und mir eine induktive Last > vorstelle, dann solltest du zur Berechnung der Leistung aber schon auch > den Strom haben Mist das habe ich übersehen. Aber wie soll den die Leistung ohne Strom "gemessen" werden. Vor allem da das ganze hier scheinbar doch deutlich von einem Perfekt rein ohmschen Verlauf abweicht. Und selbst da währe das alles nur grobes schätzen. Wenn es dir tatsächlich um die Periodizität geht könntest du auch Wavelet Transformation verwenden.
:
Bearbeitet durch User
Benedikt S. schrieb: > Transformation Lothar M. schrieb: > Julian B. schrieb: >> Ich habe einen AD Wandler und messe hier eine Spannung, die in der >> Frequenz variiert. Für anschließende Berechnung der Leistung muss ich >> zuvor die Periode des Signals ermitteln. > Wenn ich mir die Signale so ansehe und mir eine induktive Last > vorstelle, dann solltest du zur Berechnung der Leistung aber schon auch > den Strom haben. Denn allein aus der Spannung kannst du an einer > induktiven Last nicht auf die Leistung schließen... > > Julian B. schrieb: >> Anbei der Verlauf, gemessen nicht mit dem Oszi sondern dem ADC. > Wenn ich mir die Signale so ansehe, dann musst du da mit dem großen > Signalverarbeitungshammer namens "Autokorrelation" draufhauen, um > irgendwas herauszufinden. Das macht in VHDL aber nicht wirklich Spass. > Setze doch einfach einen Prozessor-Core auf, rechne in C und hoffe, dass > das Ding schnell genug ist (bei 500Hz Datenrate stehen deine Chancen > sehr gut). Strom wird über einem Shunt gemessen. Liefert dann indirekt auch eine Spannung, mit Kenntniss des Widerstands hat man den Strom. Habe also zwei ADCs. Nun sind es 500kHz und nicht 500Hz da wird eine Signalverarbeitung in der CPU nicht mehr möglich sein. Die CPU ist noch für andere Dinge zuständig, unter anderem der eigene TCP/IP Stack benötigt einiges an Performance. Wenn ich zu viel rechne kann ich nichtmehr senden, dann ist die ganze Anwendung hinfällig ;)
Julian B. schrieb: > Strom wird über einem Shunt gemessen. Liefert dann indirekt auch eine > Spannung, mit Kenntniss des Widerstands hat man den Strom. > Habe also zwei ADCs. > Alles klar dachte ich mir, stand da aber nicht so offensichtlich oder ich habe es überlesen Julian B. schrieb: > Nun sind es 500kHz und nicht 500Hz da wird eine Signalverarbeitung in > der CPU nicht mehr möglich sein. Die CPU ist noch für andere Dinge > zuständig, unter anderem der eigene TCP/IP Stack benötigt einiges an > Performance. Wenn ich zu viel rechne kann ich nichtmehr senden, dann ist > die ganze Anwendung hinfällig ;) Wenn du meine Methode verwendest hast du überhaupt keine Probleme das kann man alles wunderbar im FPGA erledigen. 1.Du berechnest für jeden ADC-wert I mit dem bekannten Shunt Widerstand. 2.Du Berechnest P für jeden ADC-wert 3 Gleitender Mittelwert für P U und I Berechnen 4 Aus den gleitenden Mittelwerten von U und I S berechen 5 Cos(phi) berechnen fertig.
Julian B. schrieb: > Nun sind es 500kHz und nicht 500Hz Hoppala, ein Zeichen übersehen und drei Zehnerpotenzen ignoriert. Jetzt wirds aber sehr sportlich, denn allein, wenn die Frequenz runter gehen soll bis 0Hz, dann brauchst du schon einen arg (theoretisch unendlich) großen Speicher für eine Korrelation/Periode... Julian B. schrieb: > Ich möchte tatsächlich nach einer Periode Möchtest du das oder ist es verlangt? Wofür brauchst du diesen Effektivwert? Muss der tatsächlich sofort ausgegeben werden? > oder um die Datenmenge zu reduzieren nach n Perioden. Definiere eine "ausreichende Genauigkeit" und eine "hinreichend schnelle Messung", wobei du berücksichtigst, dass ein Messergebnis bei 0Hz niemals ermittelt werden kann. Mach n ausreichend groß, erlaube, dass n auch Nachkommastellen haben darf und du kannst das locker "nebenher" berechnen indem du z.B. das Messintegral für deine Effektivwertermittlung auf ca. 1s setzt. Dazu ist dann nur ein Ringbuffer mit 512k Worten nötig, der jeweils die letzte Sekunde U und I speichert.
Benedikt S. schrieb: > Julian B. schrieb: >> Strom wird über einem Shunt gemessen. Liefert dann indirekt auch eine >> Spannung, mit Kenntniss des Widerstands hat man den Strom. >> Habe also zwei ADCs. >> > Alles klar dachte ich mir, stand da aber nicht so offensichtlich oder > ich habe es überlesen > > Julian B. schrieb: >> Nun sind es 500kHz und nicht 500Hz da wird eine Signalverarbeitung in >> der CPU nicht mehr möglich sein. Die CPU ist noch für andere Dinge >> zuständig, unter anderem der eigene TCP/IP Stack benötigt einiges an >> Performance. Wenn ich zu viel rechne kann ich nichtmehr senden, dann ist >> die ganze Anwendung hinfällig ;) > > Wenn du meine Methode verwendest hast du überhaupt keine Probleme das > kann man alles wunderbar im FPGA erledigen. > 1.Du berechnest für jeden ADC-wert I mit dem bekannten Shunt Widerstand. > 2.Du Berechnest P für jeden ADC-wert > 3 Gleitender Mittelwert für P U und I Berechnen > 4 Aus den gleitenden Mittelwerten von U und I S berechen > 5 Cos(phi) berechnen fertig. Benedikt S. schrieb: > 4 Aus den gleitenden Mittelwerten von U und I S berechen Wie hoch sollte ich dann N wählen? Wenn ich das richtig verstanden habe muss ich ja über mehrere Perioden hinweg die Liestung berechnen. Nun kann ich ein Signal mit 1kHz haben, dann habe ich 500S/Periode. Dann fasse ich 2500S zusammen habe über 5 Perioden gemittelt. Nun verändert sich das Signal auf 1Hz und ich habe nurnoch über eine halbe Periode gemessen. Und was ist mit U_Effektiv? Danke bis hierhin auf jeden Fall schon mal! :)
Julian B. schrieb: > Wenn ich das richtig verstanden habe muss ich ja über mehrere Perioden > hinweg die Liestung berechnen. Merkst du, dass Benedikt und ich in die selbe Kerbe hauen? Und deshalb eigentlich auch Antworten auf die gestellten Fragen brauchen? > Wenn ich das richtig verstanden habe muss ich ja über mehrere Perioden > hinweg die Liestung berechnen. Weil du sowieso keine einzelnen Perioden mehr anschaust, dann bleibt nur noch eine Zeit übrig. Wenn deine Aufgabe z.B. eine Anzeige ist, dann musst du nur 3-4x pro Sekunde einen Messwert bereitstellen. Ergo ist dein Integrationsintervall genau so lang... Und wenn deine Frequenz jetzt niedriger wird als die Anzeigefrequenz, dann zappelt die Anzeige halt (das ist etwas vereinfacht gesprochen, Artefakte treten schon vorher auf, weil die Forderung "mindestens 100 Perioden für +-0,5% Genauigkeit" schon ab 300 Hz nicht mehr erfüllt ist).
nochmal vielen Dank für deine Antwort! :) Lothar M. schrieb: > Weil du sowieso keine einzelnen Perioden mehr anschaust, dann bleibt nur > noch eine Zeit übrig. Wenn deine Aufgabe z.B. eine Anzeige ist, dann > musst du nur 3-4x pro Sekunde einen Messwert bereitstellen. Ergo ist > dein Integrationsintervall genau so lang... > Und wenn deine Frequenz jetzt niedriger wird als die Anzeigefrequenz, > dann zappelt die Anzeige halt (das ist etwas vereinfacht gesprochen, > Artefakte treten schon vorher auf, weil die Forderung "mindestens 100 > Perioden für +-0,5% Genauigkeit" schon ab 300 Hz nicht mehr erfüllt > ist). ok wie viele Perioden tatsächlich für eine hohe Genauigkeit notwendig sind erfahre ich nun erst. Angenommen ich spucke alle 250ms meine errechneten Werte aus, dann habe ich bei einer Signalfrequenz von 1000Hz immerhin 250 Perioden. Super, ist ausreichend. Jetzt kann die Signalfrequenz aber wie gesagt auch nur 100Hz sein => schon sind es nur noch über ~25 Perioden gemittelt. Wenn die Signalfrequenz weiter sinkt wirds noch übler. Ich möchte damit keine Anzeige zum blinken bringen, sondern einen Plot erzeugen. Die Messwerte und berechneten Werte sollen in einem Diagramm dargestellt werden und von dort exportiert werden können. Daher ist die Anforderung auch nach jeder Periode die berechneten Werte bereit zu stellen, nicht erst alle 100 Perioden.
:
Bearbeitet durch User
Julian B. schrieb: > Daher ist die > Anforderung auch nach jeder Periode die berechneten Werte bereit zu > stellen, nicht erst alle 100 Perioden. "Nach jeder Periode Werte bereit stellen" klingt so, als müssten die Werte sofort nach der Periode verfügbar sein (keine bzw. minimale Latenz). Das passt aber imho überhaupt nicht zu der eigentlichen Aufgabenstellung: Julian B. schrieb: > Die Messwerte und berechneten Werte sollen in einem Diagramm > dargestellt werden und von dort exportiert werden können. Du willst das Diagramm ja wohl nicht nach sofort nach jeder Periode exportieren, oder? Du willst nur, dass der jeweilige Auswertungszeitraum genau zur Periodendauer passt, aber es gibt bei dabei keine Anforderung, dass das Ergebnis auch sofort nach dem Ende einer Periode verfügbar ist. Also kannst du nach (erst mal unbekannten) Ende der Periode den weiteren Signalverlauf aufzuzeichnen (oben wurde schon beschrieben, wie du die Daten in einen Ringpuffer zwischenspeicherst). Dann bestimmst du im aufgezeichneten Signal, wie groß die jeweilige Periodendauer im Signalverlauf war. Z.B. wählst du sinnvolle Blockgrößen für einen ersten Analyseschritt aus, bestimmst in den aufgezeichneten Daten in jedem Block, wie groß die "dominante" Periode ist (FFT). Dann berechnest du die benötigten Kenngrößen mit einer Mittelungsdauer, die sich aus der zuvor festgestelten Periodendauer ergibt, "löschst" die bereits verarbeiteten Daten aus deinem Ringpuffer und beginnst mit dem Rest der Daten die nächste Analyserunde. Damit kennst du zu allen Perioden die gewünschten Kenngrößen, du hast das Ergebnis nur mit etwas Verzögerung (also nicht sofort nachdem die Periode abgelaufen ist). Für die Erstellung eines Diagramms dürfte die Verzögerung aber egal sein. Wie du die Blockgrößen des ersten Analyseschritts sinnvoll wählst und wie die diese Blöcke zu Datenblöcken einer anderen Größe für den zweiten Analyseschritt aufteilst, erfordert noch etwas Hirnschmalz. Ziemlich aufwändig? Na ja, du willst es ja so :-) Wenn ich mir deine Messergebnisse oben anschaue habe ich übrigens den Eindruck, dass deine Kurve (neben hochfrequenten Rauschen) im wesentlichen aus zwei Frequenzanteilen zusammengesetzt ist, die keine Harmonsichen zuseinander sind. Wenn das tatsächlich der Fall ist, dann hat das Signal zwei unabhängige Periodendauern und du solltest dir erst mal darüber im Klaren sein, was genau du mit der Periode des Signals meins (immer die langsamere von beiden?) Meine eigentliche Empfehlung wäre aber, nicht beliebig viel Aufwand in eine schlecht definierte Datenanalyse zu stecken sondern zuerst zu überlegen, woher die wechselnden Periodendauern deines Signals eigentlich kommen. Sind das irgendwelche wechselnden Schaltfrequenzen? Oder siehst du die Kommutierung von Motorwicklungen bei wechselnder Drehzahl? Oder was sonst? Vielleicht lässt sich ja beim "Verursacher" der wechselnden Periodendauern ein Synchronisierungssignal abgreifen, aus dem du die jeweils wechselnde Periodendauer direkt abmessen kannst. Damit wären die notwendigen Rechnungen für deine Kenngrößen ein Klacks, und du hättest die Ergebnisse sogar wirklich direkt nach dem Ende jeder Periode (d.h. immer kurz nach der Flanke des Synch-Signals) verfügbar.
Julian B. schrieb: > Ich möchte damit keine Anzeige zum blinken bringen, sondern einen Plot > erzeugen. Die Messwerte und berechneten Werte sollen in einem Diagramm > dargestellt werden und von dort exportiert werden können. Also doch eine reine Anzeige-Geschichte? Denn dann sehe ich keinen unmittelbaren Zwang, das möglichst brutal in harter Echtzeit zu machen. Logge einfach alle Daten mit, übertrage sie mit einem hinreichend schnellen Interface zu einem entsprechend potenten Rechner/PC und mache dort die Auswertung. Dort kannst du dann ganz einfach die gewünschten Werte ermitteln und anzeigen. Es gibt sogar fertige Software dafür...
Achim S. schrieb: > Vielleicht lässt sich ja beim "Verursacher" der wechselnden > Periodendauern ein Synchronisierungssignal abgreifen... Oder Augenblicksleistung berechnen und durch einen digitalen Tiefpass schicken. Aus den Nulldurchgängen sollte sich die Periode bestimmen lassen. Ließe sich der cos φ dann eventuell aus dem Verhältnis der aufsummierten positiven zur aufsummierten negativen Augenblicksleistung bestimmen? Das wäre rechnerisch nicht aufwendig? Ciao, Martin
Martin H. schrieb: > Aus den Nulldurchgängen sollte sich die Periode bestimmen > lassen. Wenn es denn eine definierte Periode geben würde. Wie oben schon geschrieben: für mich sieht das gemessene Beispielignal so aus, als gäbe es verschiedene Frequenzanteile, die mir nicht mal als Harmonische der selben Grundfrequenz erscheinen. Spätestens dann kann es mit Nulldurchgängen schwierig werden. Martin H. schrieb: > Ließe sich der cos φ dann eventuell aus dem Verhältnis der aufsummierten > positiven zur aufsummierten negativen Augenblicksleistung bestimmen? Wenn es sinusförmige Kurven wären, dann dürfte sowas gehen. Das liegt hier aber nicht vor. Deswegen ist ein cos(phi) im Sinne eines Wirkfaktors ohnehin nicht anwendbar. Einen Leistungsfaktor (Betrag Wirkleistung dividiert durch Scheinleistung) kann man aber immer noch angeben.
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.