Header Frame response not accepted

I am using testing my PMU using the test tool. I request Header Frame from PMU but the tool reacts in a manner I do not expect,

Command “SendHeaderFrame” requested at 5/20/2021 10:22:43 PM
Exception: Attempted to divide by zero.

Nothing appears in the “Header Frame” window pane, and no Header in the “Protocol Specific” pane.

I am using the latest version of the tool, v4.6.3.

Here’s a screen shot of the Wireshark response from my PMU to the tester:

Can anyone spot an obvious error in my implementation of the Header frame response? Or could there be a configuration problem (user error)? Or maybe a bug in the tool?

What text encoding are you using for your string? I think the standard calls for ASCII.

Thanks for the prompt response! I am using standard C language characters (single wide, ASCII). The characters in the ASCII column in the Packet Bytes pane from Wireshark (the bottom panel) seem to be correct. It was unclear from the IEEE spec whether or not these fields need to be NULL-terminated, or terminated using a different character. Our Software Architect is also just learning this spec as we go and she had space char’s (32d) padding the fields, but she’s not sure if that is needed. I figured that everything between FRACSEC and CHK fields is user-specific “free form” text. So if there needs to be some terminator it probably goes onto the end, just before the CHK (CRC-CCITT), but maybe I’m wrong… We have semi-colon (’;’) characters separating text fields which apparently is for customer’s parsing. Maybe that is actually causing an issue?

Btw, I wanted to also post the following screen shot, but because I’m a ‘newbie’ I was allowed only one attachment to my original post.

image

I just upgraded your trust level. We haven’t really scrutinized the settings for the trust levels so as long as you’re not a bot, you’re okay by me.

1 Like

I am also seeing “Exception: Attempted to divide by zero” and now “Exception: Attempting to realign parsing…” (see below) in response to CFG-1 and CFG-2 queries:

image

Here is an example response to CFG-1:

image

I am really stumped. I did note that I have PMU IDCODE assigned zero (0) value. I realize it should be greater than zero, but we are using zero as default/init value to force the customer to change the value when they configure the PMU. Would that cause the “divide by zero” issue? (seems unlikely, as why would a divide by IDCODE ever be needed, unless the test tool uses some hashing algorithm??). I can change that value to one (1) and retry, but I’m thinking the root cause is elsewhere. Any suggestions?

Could it be you have multiple PMUs sending data to port 4712?

That is an interesting idea, but I do not believe it to be the case. I have only one target board (PMU) running my firmware. And the Wireshark session shows only the one set of transactions (CFG or HDR request, and corresponding response).

Is there a “debug” mode for PMU Connection Tester? I could run it and collect diags data to perhaps help us troubleshoot to see what it’s griping about?

Digging in a bit, it looks to me like your PMU’s TIME_BASE is zero. That could cause a divide by zero error.

image

From the IEEE C37.118-2005 standard:

The actual “fractional second of the data frame” = FRACSEC / TIME_BASE

Good catch! Our internal specification doc states:

Since TIME_BASE is a 4-byte field we figured that this value would be 2^24 (16777216d), or 0x01000000, meaning each the resolution of fractional second’s field is 1/(2^24)…
We are reading a UTC-64 “Clock-on-the-Wall” value from our CPLD/FPGA, which takes time signal and PPS from GPS. The upper 32-bits is the SOC (Unix timestamp). The lower 32-bits contains the Fractional second in the upper 24-bits, and we use the bottom 8-bits for Time Quality indicators. All of this can be mapped into the IEEE synchrophasor time fields of course (with some special attention to “Leap Seconds” TQ indicator bits, which we’re still working through in our PMU…). Anyway, not to be daft, but what is the value we need in our TIME_BASE field? I can see you are correct (above), but still not sure of how to map our configuration into the field…

The standard is a bit imprecise in its definition for TIME_BASE.
image

Technically, the TIME_BASE field includes all four bytes, but the highest byte is reserved for flags. So although the formula suggests the flags should be included in the calculation, the breakdown suggests you should mask out the flags. That means 2^24 is outside the range of the TIME_BASE field for the purposes of fractional second calculation.

Based on this, I’m not sure there is a way to map a fractional second value at a precision of 1/(2^24) seconds. The closest you can get is 1/(2^24-1) seconds. Perhaps the easiest thing to do to avoid potential overflow/rounding errors would be to shift off one bit of precision and use a TIME_BASE value of 2^23.

Thanks, Stephen. We might have to do just that. I will discuss with our s/w architect. I appreciate your sharing your expertise with us.

Btw, I am finding this test tool to be very helpful in my first day using it! I have already found three bugs (coding or spec interpretation), and possibly more to come. I think our Software QA group is using a purchased tool for most of their validation, but I love having a tool from a community such as this who share common interests.

1 Like

Update: after changing the TIME_BASE (i.e., ensuring lower-24 bits is not zero) the commands responses all seem to be processed by PMU Connection Tester, including the header. Thank you very much for your assistance.

I am having issue with Data Frames now, but I’ll create a new topic…