OPAL-RT C37.118 multi-PMU issues: constant FREQ/DFREQ behavior +

GPA Products
1

Hi all,

We are integrating a Software that has a pipeline with OPAL-RT - PMU streams and are seeing two recurring C37.118 issues.

Environment

  • OPAL-RT PMU source (IEEE C37.118)
  • 6 PMU streams from same host IP OF OPAL-RT on ports:
    7056, 7062, 7058, 7070, 7060, 7064
  • PMU IDs: 1001..1006
  • Python client (pypmu-based) + web dashboard for validation + synchrophasor library to connect and print values.
  • Direct Internal network testing (same IP-of-OPAL/ports as above)

Issue : Frequency fields appear static

During tests (including expected disturbance windows):

  • phasors update normally
  • but frequency-based signals remain effectively constant
  • observed examples:
    • raw FREQ around 50.0
    • decoded library FREQ around 50.05
    • DFREQ/ROCOF near zero
      This prevents reliable event detection from frequency/ROCOF.

We tried instead testing with the Phasors, because i could see the phasor values changing on each PMU. I use a formula to calculate the Power of the whole System for the 6 PMUs, but when my colleague triggers a fault on OPAL-RT simulation he implemented, the phasors values do not change, they stay static.

We are trying to figure out if this is a connection problem or an OPAL-RT configuration of the environment problem.

What we already verified

  • PMU channel mapping and IDs checked against OPAL config exports
  • phasor-to-power calculations validated independently
  • issue is specifically in stream behaviour and frequency field interpretation.
  • I used PMU Connection Tester to connect to each PMU individually and exported the cfg file of each PMU in order to get the configurations of each, to check if I’m using the correct mappings for the Phasors. The PMU Connection Tester also had static values when connecting to each PMU. I can provide screenshots, logs e.t.c.

Questions

  1. For OPAL C37.118 output, should FREQ be transmitted as:
    • absolute frequency, or
    • deviation from nominal (and in Hz or mHz)?
  2. If we test it with ethernet it should work more reliably? I don’t think this is a connection issue, as more of a configuration. If you want more details i can ask colleague to give me more info of his/her enviroment.

If helpful, we can share sanitized logs (CFG2/start timeline, per-port behavior, raw FREQ/DFREQ snapshots).
Thanks.

image
image1553×806 184 KB

2

My experience with OPAL-RT is limited, but it looks this is a configuration issue in the OPAL-RT platform.

1 Like