Hi,
I have a system which send the C37-118-2005 to openPDC as input stream. Can I configure PDC to send the same data as C37-118-2011 as an output steam. Thanks in advance.
Rabi
You certainly can, yes.
However, if you are sending data between two openPDCs, I recommend using IEEE 2664 (STTP) for simplicity. Then you can still create your C37.118-2001 output stream as desired.
Navigate to “Inputs > Subscription Based Inputs > Create Internal Subscription” on the receiving PDC to setup an STTP connection that will receive all data from the source PDC.
I suggest unchecking “Use Source Prefix” if this is going to be the only input stream.
Thanks!
Ritchie
Thank you ritchiecarroll for the reply.
I was trying to do the setup but I think I missed something. Let me share the details of my setup.
Our input is from SEL 411L to openPDC, which is streaming correctly (UDP connection is local in LAN).
Now, in our output stream, we are trying to send the data to WAN. We are trying to set it up as a TCP connection. But I am not sure how can we have UDP as the input using LAN connection and TCP as the output PDC to WAN.
Thanks,
Rabi Kar.
Sure thing. If you have an existing PMU input in the openPDC that is operational, regardless of protocol (transport, phasor, or otherwise), start the openPDC Manager UI application and navigate to “Outputs > Concentrator Output Streams”. Click the “Add New (+)” button on the middle, right side of the screen, and type in a name for the output in the “Acronym” field, e.g., “TESTOUT”. From the “Protocol” drop-down, select “IEEE C37.118-2011”. Next, click the icon that looks like three-blocks with a pencil that is to the right of the TCP Channel text box, enter the desired port number for the TCP connection, the default 4712 is fine if nothing else on the system is already listening on that port, then click “Save”. Enter “5” into the “Lag Time” and “Lead Time” fields, representing +/-5 seconds of time tolerance for measurements sorted into this output stream. Click the “Enabled” checkbox, then click the “Save” button on the middle, right side of the screen.
You now have defined a new output stream in the IEEE C37.118-20011 protocol format listening on TCP port 4712.
Next, you need to add your existing PMU to the output stream. In the table of outputs at the bottom of the screen, make sure “TESTOUT” is the selected record. Note: it may be necessary to navigate to the last page if there are multiple pages of output streams defined, newest output will always be the last record.
With the “TESTOUT” record selected, click the “Device Wizard” link in the table row. From the pop-up list of devices, select your input PMU (the one reporting via UDP and IEEE C37.118-2005, for example). At the bottom left, select if you want analogs and digitals from the input to be included in the output. Finally. with desired devices selected for the output stream, click the “Add Selected” button. The screen will now show a summary of devices that exist in the output stream. Click the green “back arrow” at the top-right of the manage application to go back to the output stream setup.
Verifying the “TESTOUT” record is selected, you can now click “Initialize” to start the output stream. You can now connect to the “IEEE C37.118-2011” output stream, e.g., with a tool like PMU Connection Tester.
Thanks,
Ritchie
Thank you ritchiecarroll for the reply.
I tried the steps you provided. With this, I can detect the phasor variables, but I cannot see any data. I have attached the screenshot of my output from the PMU tester and my settings. Since I can send only one figure, I am adding the settings pic in another reply.
It is possible that the timestamps in the incoming device stream are not synchronized to GPS, or your local clock time is way off. In either case, you can set the output stream to use the PMU timestamps as the real-time clock source and generally ignore bad time.
To do this, on the output stream screen on the openPDC Manager, with the “TESTOUT” device selected, open the “Advanced Properties” and check or uncheck the following settings accordingly:
- Disable “Perform Timestamp Reasonability Check”
- Disable “Use Local Clock as Real-time”
- Enable “Ignore Bad Timestamps”
- Enable “Round to Nearest Timestamp”
Then click the “Save” and “Initialize” buttons.
Let me know if that helps.
Thanks,
Ritchie
FYI - in your images above, the timestamp on incoming data has an hour of 16:00 and the PMU connection tester shows an hour of 15:00, so it is likely that there is a device / local clock discrepancy of at least one hour. The settings changes I suggested above should assist with making sure data is published even if timestamps are otherwise considered unreasonable.
In a production system where all incoming time is measured according to GPS, these default reasonability settings make more sense - not always so much in a test environment.
Thanks,
Ritchie
Yes, I see that. By ignoring the errors in advanced settings, I can send out data correctly, and I see that both times are synchronized. The time shown is UTC time, which comes from the SEL satellite clock.
I will need to check why, in the previous settings, the time is one hour different.
Thank you so much for your help.
Rabi Kar.