Zum Inhalt

PQopen – Juli Update

Wer die Entwicklungen auf pqopen.com folgt, wird festgestellt haben, dass sich in den letzten Wochen einiges getan hat. Weitere Messstellen haben den Betrieb aufgenommen – Mittlerweile liefern 4 (AT/Spielfeld ist durch die nähe zu Graz zähle ich nicht mit) Messgeräte laufend Daten.

Danke an dieser Stelle an alle Interessenten, die das innerhalb dieser kurzen Zeit möglich gemacht haben und sich bereit erklärt haben, ein Messgerät zu installieren.

MessstelleAnschlussIn Betrieb seit
AT/Graz1-Phasig01.07.2025
(AT/Spielfeld)3-Phasig01.07.2025
DE/Berlin3-Phasig13.07.2025
CH/Solothurn3-Phasig21.07.2025
DE/Essen1-Phasig27.07.2025

Under the Hood

Welche Daten werden erhoben in welchem Intervall?

ParameterPhaseIntervallSpeichertiefe Datenbank
Frequenz, U_rmsL1C-b-C30 Tage
Frequenz (nur L1), U_rms, U_THDL1, L2, L31smin 1 Jahr
Frequenz (nur L1), U_rms, U_THD, Harmonische, Interharmonische, FlickerL1, L2, L3600s (10 Min)mehrere Jahre

Welche Genauigkeit der Zeit- bzw. Frequenzmessung wird erreicht?

Die ersten Wochen haben gezeigt, dass die Frequenzmessung zwischen den Messstellen um ca. 1mHz abweicht. Dies konnte mittlerweile angepasst werden, und der relative Fehler liegt im Moment bei unter 0.1mHz. 

Hintergrund zur Zeit- und Frequenzmessung

Die Genauigkeit der Zeitmessung ist eng mit der Frequenzmessung verbunden. Beim PQopen-Messgerät verwende ich für die Messung der Zeitdifferenzen von Nulldurchgang zu Nulldurchgang den ADC-Takt als Basis. Dieser kann in der Konfiguration als korrigierter Wert (adc_clock_gain) hinterlegt werden, um die Grundabweichung zu eliminieren. Ein zweiter Parameter ist der Zeitstempel, zu welchem die Daten dann zugeordnet werden. Diesen errechne ich gleitend aus der Systemzeit (welche NTP-Synchronisiert ist), um Langzeitfehler auszugleichen. Dazu gibt es einen Regelkreis im daqopen-zmq-server.py, der die „interne“ Zeit an die Systemzeit angleicht.

Wie gut das funktioniert, kann man Anhand des Vergleichs der Zeitstempel der Nulldurchgänge zeigen:

Ich nehme Beispielhaft die Daten der Messstellen AT/Graz, DE/Berlin und CH/Solothurn eines definierten Zeitbereichs (es sollten jeweils die gleiche Anzahl der Einträge sein, wenn kein Datenausfall passiert ist) und bilde die Differenz der Zeitstempel und Plotte diese:

Der zeitliche Verlauf der Abstände der Nulldurchgänge kann auch als Winkel interpretiert werden. Wie es aussieht, ist die Messstelle CH/Solothurn 120° phasenverschoben, was bedeuten kann, dass hier ein „Phasendreher“ drin ist. Die Messstelle in AT/Spielfeld ist im Mittel um 90° verschoben, Diese könnte aufgrund verschiedener Schaltgruppen der beteiligten Tansformatoren liegen (sofern kein Messfehler vorliegt).

Erweiterungen am Server

Weitere Dashboards

Es sind mittlerweile weitere Dashboards zugänglich:

  • (Neu) Power Quality: Übersicht über die PQ-Parameter (1s sowie 10 Min Daten)
  • Welcome & Overview: Frequenz- und Spannungsverlauf der letzten Stunde
  • Frequency Rate of Change: Ableitung des 1s-Frequenzverlaufs (Umschaltung je Messstelle)
  • Frequency PSD: Leistungsdichtespektrum (Erweiterbar bis 3 Hz) (Umschaltung je Messstelle)

Messdatenarchiv – Download

Versuchsweise habe ich ein Downloadportal erstellt, in welchem tägliche Datensätze der C-b-C Frequenzmessung (ungeglättete Daten) je Messstelle zum Herunterladen bereitgestellt werden. Die Daten liegen im Apache Parquet Format vor und können z.B. in Python mit pyArrow eingelesen werden.

Weitere Messdaten werden dann in späterer Folge hinzukommen.

Was ist sonst noch passiert?

  • Umstellung der Datensenken (Buckets) in der Datenbank, Trennung zwischen Kurz- und Langzeitdaten.
  • Ergänzung der Namen von Graz und Spielfeld mit dem AT-Prefix

Aktueller Verlauf eines Frequenzeinbruchs (30.07.2025 16:21:28 MESZ)

Wie geht es weiter?

Zwischenzeitlich habe ich eine Anfrage außerhalb des DACH-Raums bekommen, das würde helfen, die Abdeckung auszuweiten. Bitte bewerbt euch nach wie vor, bevorzugt aus dem nicht-deutschsprachigen Raum.

Des weiteren kann es in den nächsten Wochen durch diverse Anpassungen am Server sowie an den Messgeräten immer wieder zu kurzen Datenausfällen kommen.

Auf Feature-Seite steht die Entwicklung einer REST-API zum Abrufen von beliebigen Zeitbereichen (sofern in der Datenbank vorhanden) als Ergänzung zum Archiv an.

Euer Michael

Schreibe einen Kommentar