Frequency out of range when the format is floating point.

[JiaxuanHan-UoS]

Firstly, I set the format of phasors and frequency as integer. Everything is fine and I keep receiving messages about dataframe were received successfully.

When the format of frequency were changed to floating point. The error messages were shown below:

According to the suggestions of Steven, I removed exception catching and find the error location is the range filter of frequency. Row 2143 in frame.py.

However, I checked the received data with PMU connection tester, and the received FREQ is within the given range(49.9288Hz).

Thanks for all discussion!

[poledna]

I also had the same issue a while back, and my "solution" was to comment out line 2144 and 2145 in master https://github.com/iicsys/pypmu/blob/66e6c495a91efb8a6018061ff7955a6654b1404d/synchrophasor/frame.py#L2144-L2145

Not a pretty solution, but it solved for me. As freq is a number bypassing the if should solve the issue.

in the branch udp-support-v0.1 there is already the commented version, but if you're using TCP i'd suggest keeping with master as it is more up to date with community issues. https://github.com/iicsys/pypmu/blob/22b60642527c43a91513c5deb26cb8399b64f305/synchrophasor/frame.py#L2143-L2145

[JiaxuanHan-UoS]

@poledna Hi poledna, I tried your method and received the data frames. But I am pretty sure that my data is incorrect, the frequency is always floating between 50.5Hz. These are the curves of the actual frequency and the decoded frequency.

And the table in Mysql could also prove this.

So did you received the correct data?

[sstevan]

Hey @JiaxuanHan-UoS,

Would you mind sharing your configuration frame with us?

Also, there is a known issue with FREQ unpacking caused by my misinterpretation as stated here #4 Please try to switch to the bugfix branch and let us know if you are still having these issues.

[JiaxuanHan-UoS]

@sstevan

Hi Stevan,

I just read issue4 and find there could be some misunderstanding about FREQ definition. If the format of FREQ is integer, the 2-byte string represents deviation and requires the nominal frequency defined in CONFIG-2 to determine the actual frequency. However, if the FREQ is float, the 4-byte string is long enough to represent the accurate value and don't need the nominal frequency in CONFIG-2 to calculate the result. In the above picture, red part means the FREQ in float format (and blue for DFREQ). If we transfer it from hex to decimal: The result is exactly 50.168

[sstevan]

That is correct. That issue has been already fixed on bugfix branch. Have you checked the ConfigurationFrame?

If you are using tinyPDC this line will ask for ConfigurationFrame in order to unpack the values:

config = pdc.get_config() # Get configuration from PMU

Please double check your FORMAT field in configuration frame, should look like this:

Data format in data frames, 16-bit flag.
Bits 15–4: Unused
Bit 3: 0 = FREQ/DFREQ 16-bit integer, 1 = floating point
Bit 2: 0 = analogs 16-bit integer, 1 = floating point
Bit 1: 0 = phasors 16-bit integer, 1 = floating point
Bit 0: 0 = phasor real and imaginary (rectangular), 1 = magnitude and angle (polar)

So you should have Bit 3 = 1.

[JiaxuanHan-UoS]

@sstevan Yes, this is the ConfigurationFrame of my PMU. The format is 0x0009, bit 3 and bit 0 = 1. Just the same with the openPDC configuration.

[JiaxuanHan-UoS]

Thanks, the problem has been solved after using bug-fix v1.0.1 frame.py scripts