This project has moved. For the latest updates, please go here.

Accepting data streams with different sampling rate?

Mar 5, 2015 at 4:27 PM
Edited Mar 5, 2015 at 4:28 PM
Hi, Guys,

Hope all is well in Chattanooga!

We are currently accepting input streams of 30 Hz PMU data. We are looking into accepting other input streams of 60 Hz PMU data, and output all data to downstream applications.

Is that a problem? Will there be any complications? Anything we need to pay attention to? E.g., it seems to me that I will need to create two output streams if I want to preserve their own sampling rate. What happens if I shovel them into one output stream, automatic upsampling/downsampling?

Please advice.

Thanks,
Frankie
Coordinator
Mar 5, 2015 at 5:49 PM
Hi Frankie,

It sounds like you already have an idea of the types of complications to expect.

Creating two output streams
This would allow downstream applications to handle the different sample rates however they needed to, but you would lose some of the benefits of concentration. Each of the output streams will be properly concentrated, but any application that receives both streams will need to time-align the two separate streams.

Creating one 60 Hz output stream
The openPDC will receive one frame of data from its 30 Hz input sources for every two frames of data it sends from its output stream. The 30 Hz data will be sorted into the most appropriate 60 Hz frame. In all other frames, 30 Hz data will be treated as missing. This will mean that phasor measurements will assume the value of double.NaN and status flags, frequency, df/dt, analogs, and digitals will all assume a value of 0. Downstream applications will have to validate the data in each frame in order to sort this out.

Creating one 30 Hz output stream
The openPDC will receive two frames of data from its 60 Hz input sources for every one frame of data it sends from its output stream. The 60 Hz data will be sorted into the most appropriate 30 Hz frame, meaning that each 30 Hz frame will have two measurements for every 60 Hz signal. The openPDC will need to downsample the two measurements before sending the 30 Hz frame from the output stream. The downsampling method used by the openPDC is configurable per output stream in the openPDC Manager (Outputs > Concentrator Output Streams > Advanced Properties > Downsampling). The openPDC Manager also has a help button for that parameter to help determine which downsampling method is best based on your scenario. Additionally, I can provide this information about the four different downsampling methods.
/// <summary>
/// Down-samples to the last measurement received.
/// </summary>
/// <remarks>
/// Use this option if no down-sampling is needed or the selected value is not critical.
/// This is the fastest option if the incoming and outgoing frame rates match.
/// </remarks>
LastReceived
/// <summary>
/// Down-samples to the measurement closest to frame time.
/// </summary>
/// <remarks>
/// This is the typical operation used when performing simple down-sampling.
/// This is the fastest option if the incoming frame rate is faster than the outgoing frame rate.
/// </remarks>
Closest
/// <summary>
/// Down-samples by applying a user-defined value filter over all received measurements to anti-alias the results.
/// </summary>
/// <remarks>
/// This option will produce the best result but has a processing penalty.
/// </remarks>
Filtered
/// <summary>
/// Down-samples to the measurement that has the best quality closest to frame time.
/// </summary>
/// <remarks>
/// This option chooses the measurement closest to the frame time with the best quality.
/// </remarks>
BestQuality
Gateway Exchange Protocol (pub/sub)
Using the Gateway Exchange protocol, it's possible to send data to downstream applications without the need for concentration, thus requiring only one data stream and eliminating most of the concerns I mentioned above. Concentration is optional, and can be requested by the downstream application at runtime. GEP may also provide additional benefits such as metadata synchronization and a subscription mechanism for upstream data filtration. The Gateway Exchange Protocol API is available as part of the Grid Solutions Framework, and versions of the subscriber API have been written for C#, C++, and Java. The openPDC supports both publication and subscription.

Thanks,
Stephen
Mar 6, 2015 at 7:52 PM
Hi, Stephen,

Thanks for the detailed explanation :) We'll probably downsample it to 30 Hz then.

Appreciate it!
Frankie
Mar 9, 2015 at 2:58 PM
Edited Mar 9, 2015 at 3:00 PM
Hi, Stephen,

I have a follow up question about the "Filtered" downsampling option:

I understand that the default algorithms are:

Analog: simple average
Angle: wrapped-angle average
Digital: majority value

Do you know where can I find the code?

Is the default only available filter algorithm, or there are other filter options, or user has to code other filter options?

Thanks,
Frankie
Coordinator
Mar 9, 2015 at 3:39 PM
Hi Frankie,

The code for each of those downsampling algorithms can be found in the following locations.

Analog
Assembly: GSF.TimeSeries.dll
Type: GSF.TimeSeries.Measurement
Method: AverageValueFilter

Angle
Assembly: GSF.PhasorProtocols.dll
Type: GSF.PhasorProtocols.PhasorValueBase
Method: AverageAngleValueFilter

Digital
Assembly: GSF.TimeSeries.dll
Type: GSF.TimeSeries.Measurement
Method: MajorityValueFilter

I believe these are the only available filter algorithms, however it is possible to write code to specify your own filter algorithms. The IMeasurement interface has a property called MeasurementValueFilter that is used by the concentrator to select the right downsampling algorithm when the Filtered downsampling method is used. You would need to write your algorithms and then modify your input adapters to set the MeasurementValueFilter property to the appropriate algorithm when they create new IMeasurements.

Thanks,
Stephen
Mar 9, 2015 at 7:15 PM
Got it! Thx!
Frankie