Option to upload raw Synchrophasor data from Phasor Measurement Unit

Is there any option available (other than comtrade) to import/upload raw synchrophasor data from the phasor measurement unit?.

I have captured the xx.pmuCapture file from PMU connection tester and tried to create a new device in OpenHistorian selecting xx.PmuCapture file. But i am not able to see all the phasor data except status and freq. Could you please advice if i am missing any settings. What is the supported protocol used in .PmuCapture file. Is it support ICE 61850_90_5 standard.

My PMU sends data to connection tester as per IEC 61850 90_5 standard. I captured the .PmuCapture and tried to see the phasor data in OpenHistorian. But i am not able to make it successful in openHistorian.
But i could able to replay it in connection tester itself.
Could you please guide me how to use the data from .pmuCapture file in OpenHistorian.

Hi Ritchi and Stephen,
I could able to create a device with configuration and pmu capture captured from connection tester successfully. i could able to see the changes in phasor values. But though the time stamp shows the older time, it is still shown as real time. Is there any way to see the phasor data instead of playing the pmu capture file?.
Also how can we decode pmu capture file to understand how data is encoded?. Please guide me.

Hi amalorpavam,

The PMU capture files are created by literally taking bytes from the network protocol and writing them to a file. These files have the same format as the network stream they were captured from. This makes them ideal for replaying a real-time data stream, but perhaps unwieldy as a file format. Their primary purpose is for testing and troubleshooting.

Databases and historians are designed for long-term storage and queries. They have a fundamentally different format, optimized for this different purpose. openHistorian will not be able to read the PMU capture files except to replay the network stream as an input adapter. Therefore, the capture data can be streamed into the archive, but it cannot be queried directly.


Thanks Stephen.
In this case, though i feed .pmucapture file to open Historian, i can only replay them but will not be able to query to get any useful data from it. Is my understanding correct.

I am actually trying to take backup of pmu output when the connection between PMU and PDC is lost. Later i will have to feed the phasor backup to openHistorian to understand what had happened when the connection is lost. If .pmuCapture is not helping me to feed the backup data to openhistorian, will back phasor data in comtrade format will help me?. Please suggest me what could be be the useful format to feed the backup of phasor data to Openhistorian.


Hi Stephen,
I have tried few things today in open historian with the data captured (.PmuCapture file) using connection tester. I am able to set the alarm on phasor data. Also i am able to query on phasor data in Grafana Dashboard ex: maximum, add etc.

I am new to open historian. Could you please explain me what exactly cannot be achieved in OpenHistorian when we use the data stream in file with some real time example to help me understand the issue.


Hi amalorpavam,

If what you need is a secondary archive, I recommend setting up a short-term historian archive on the PDC’s local network. Use GEP/STTP to move the data between the PDC and openHistorian, and then make sure you configure data gap recovery in the openHistorian’s subscriber. If you are not using openPDC as your PDC, you can deploy substationSBG to the PDC’s local network for exactly this purpose.

See: https://www.youtube.com/watch?v=wcUWMv2iCyk

As you said, the PMU capture files are only really useful for replaying streaming data. On top of that, there are a few limitations that make the format rather unwieldy.

  1. Existing processes for capturing and replaying PMU capture data require manual intervention. An automated processes would need to be developed for capturing. Replay likely could remain as a manual process, but the process should be refined for the sake of usability.
  2. Some of the typical features of a proper archival process would need to be reproduced in order for this strategy to be successful. This includes automatically partitioning the data into separate PMU capture files, timestamping the partitions, and automatically truncating the archive.
  3. All the frame-based synchrophasor protocols use configuration frames to define the metadata that is required by a decoder to properly interpret the data frames. In order for any given PMU capture file to work, the configuration frame must be captured with the data. The automated capture process would need to identify configuration frames, hold them in memory, and write them into each PMU capture file. The decoder typically has to read ahead to find the configuration file before going back to the start of the file and reading the data frames.


Hi Stephen,

Actually my problem is that there is a PMU and it is constantly producing phasor data with some sampling rate defined. But No PDC connected to it.

I need to do the following two steps.

  1. Capture the PMU output (both configuration and data frames) and store it in a file continuously for few hours.
  2. Later Give the stored file (in step 1) to OpenHistorian to see the phasor details/its waveforms.

Kindly suggest me a way to achieve this.


Hi Amala,

If you are connecting an app to the PMU to capture the data in a PMU capture file, then you should be able to replace that app connection with an openHistorian instance to save archive files directly. You’ll be storing the data to your disk either way. Can you explain why you feel you specifically need the PMU capture?


Hi Stephen,
In my customer site, when the PMU is not connected with PDC, I want to save the PMU output in a file. In this scenario, there wont be pmu connection tester to capture the pmu output. I will have to write a code in my device to capture the pmu output.
You have mentioned that .PmuCapture file is the bytes from network protocol. Also it is an acceptable format to play the stream in open historian. Hence i feel that i can store the PMU output from my device in the same format (as .PmuCapture) in a file when the connection is lost with PDC. Later, this file can be downloaded from the customer site and it can be played in OpenHistorian to check for phasor details.

Hope I have mentioned the details to give you more clarity. Kindly provide your feedback on my approach.

Thanks in advance.

It sounds like you are creating an app on the PMU itself, is that correct? If there truly is a way you can determine whether the PDC is connected to the PMU in order to start capturing data into a PMU capture file, and also a way for you to retrieve the raw bytes that would have been sent to the PDC if it were connected, then your approach could work. Assuming you have solved those problems and produced the PMU capture file, here’s what you need to know from our end in order to replay it.

Fundamentally, TransportProtocol=File is used to read data from a PMU capture file. It’s used in connection strings to configure the frame parser. See: https://github.com/GridProtectionAlliance/openPDC/blob/master/Source/Documentation/wiki/Getting_Started.md#configuring-a-connection-string

The most straightforward way to import data from a PMU capture file is to create a new input device using the input device wizard in the openHistorian Manager. The problem is, the wizard will create all new measurements to associate with the data. That is to say, it will not be merged with the rest of your data associated with the same measurements. Fundamentally, the PhasorMeasurementMapper adapter that normally handles all the frame-based network streaming protocols supported by the openHistorian does not share its input measurements. However, you may be able to get around this by using the SharedMapping=ACRONYM connection string parameter to associate the file-based input with the real-time device’s configuration.

Therefore, your strategy should be to use the Inputs > Add New Device Based Input page in the openHistorian Manager. The connection string should be something like file=C:\Projects\openHistorian\Build\Output\Debug\Applications\openHistorian\Sample1344.PmuCapture; definedframerate=30; simulatetimestamp=false; autorepeatfile=false; transportprotocol=file; sharedMapping=SHELBY, making sure to use the appropriate PMU capture file path as well as the appropriate real-time device’s acronym in the shared mapping. Fill in the appropriate values for the ID Code, Protocol, and Historian fields. Check the Enabled flag and then Save.

Good luck!

Thank you so much Stephen.

Could you please explain me how do we manage to supply the configuration frames to openHistorian in this case.


You can serialize the config frame to the PMU capture file alongside the data frames, or you can serialize it to an XML format and load it using the configurationFile=C:\path\to\configurationFile.xml connection string parameter.

Thanks Stephen for the valuable information.
I will try and get back to you.