This project has moved and is read-only. For the latest updates, please go here.

Sample Frame - Data Content

Feb 28, 2012 at 8:05 PM


I am a new member to the CodePlex community and new user of openPDC.  My question is regarding the "capture sample frame" command, and the data that it is capturing.  I was under the impression that the capture sample frame command was obtaining an actual data frame from the PMU.  However I tried this command three separate times and the "DATA" segments of the big endian binary image were always the same.  What is the significance of this?

What is the simplest way for one to examine actual frames from my PMU data stream and step through them IEEE C37.118-2005 frame by frame?  The capture stream debug data appears to be a built in function to parse and interpret the data which is nice, but I also want to look at the FRACSEC and other bits in binary or hex directly and I am having trouble figuring out the best method to do that.

Thank you,

Micah Houtz

Electrical Engineer

Feb 29, 2012 at 6:45 PM

If your PMU data is transmitted over the network (TCP or UDP), you can use Wireshark to examine the packets.



Mar 1, 2012 at 2:58 PM

In Wireshark, "Decode as" appears in the Analyze menu, or you can right click on a captured frame to or from your synchrophasor device and select "decode as".

In the "Transport" tab select "Source", "Destination" or "both" (my usual choice) and then pick Synchrophasor from the list on the right. You can just type an "s" and a "y" on the keyboard, then click "Synchrophasor". Or you can scroll down to "Synchrophasor".

In my experience, for this to work it depends on Wireshark having already captured a config2 frame. If you're using spontaneous UDP there should be a config2 frame transmitted every so often, but if you're using TCP/UDP, you might have to stop the stream, start the Wireshark capture session, then restart the stream.

There must be better approaches to this, but this is what has worked for me.

I'd like to know who wrote that Synchrophasor decoder. My hat is off to him or her or them (same for Wireshark itself, and so many others).

Mar 6, 2012 at 8:08 PM

Slsturgi, thank you very much for the details on that.  I can see that Wireshark is becoming a key piece of software in electrical protection and controls.  When I attended an SEL IEC 61850 training course they also strongly recommended Wireshark for troubleshooting and commissioning.  I will try to install this software and get familiar with the process you are listing.  I may have to do it on my home PC initially.

As a followup question, do you happen to know what the "Status" column in the stream debug capture *.csv file represents?  Someone told me that a "0" means that the FRACSEC bits are all zero (time is ok), and locked.  Is that true?  What do other numbers in this column mean? (such as "2000"?)

Thanks again,


Mar 7, 2012 at 8:44 PM

My pleasure.

I'm at a loss regarding the .csv file with the Status column. How did you generate that file, or access it? I'll follow your lead and pass on whatever I'm able to make of it once I'm able to see it.

In the meantime, I think I've seen two different statuses. I think one of them is a TCP or IP flag, while the other is the PMU status bits, but I don't think you see those explicityly. Is this what you're asking about?

I meant to mention, in case you're not aware of it, that you can turn off name resolution in the View > Name Resolution menu. I usually turn off name resolution because I'm better able to recognize port numbers than port names, which I don't think generally apply to synchrophasors. If I've forgotten to turn off name resolution before my capture session, I finally learned that I can turn it off after the fact, and then reload the capture.


Mar 16, 2012 at 9:29 PM

I note with some embarassment that I have posted on the OpenPDC site while what I am actually using just the PMU Connection Tester program which is a different animal (another codeplex project).  The *.csv file is created by PMU Connection Tester by creating a stream debug capture.  I guess what is happening is that the PMU Connection Tester has a built in function that is parsing the C37.118 messages from the TCP/IP stream and writing the data into csv format.  So I am attempting to find out how to interpret what the PMU Connection Tester is doing with that "status" column and what it represents.  The link you gave me does appear that it would be very helpful with the OpenPDC stuff.  slsturgi, I wonder if you know anything about the PMU Connection Tester such as anyone that works on that project.  Thank you very much for your help, I don't think your advice will go to waste because I notified the IT person who administers the OpenPDC software of this thread and he is probably following it.

Best regards,


Mar 27, 2012 at 8:28 PM

No worries - the PMU Connection Tester actually uses the openPDC libraries for protocol parsing, so thery are related.

I think the status column is the raw value of the IEEE C37.118 status bits that comes from the protocol so you can check the state in an export.

Hope that helps!