I configured the value of 60 in Outputstream for the “Frames per second” and “Nominal frequency” parameters, but I am only receiving 8~10.xx frames/sec in the Connection Tester.
Any ideas on how to improve this sampling?
Hello LuizFreire,
Something seems a bit weird with your output stream statistics. It seems to be receiving way more data than it expects to receive, and the excess is being discarded. Maybe the change you made to framerate hasn’t been applied. Have you tried initializing the output stream after you made the change?
Thanks,
Stephen
If you did initialize the output stream and you are still having this problem, then please use openPDC Console to issue the list 14 command and post the output of the command here.
Okay, I can clearly see Defined frame rate: 60. I double-checked how the computation for Expected measurements works, and it takes the input measurement key count (21 / frame) and multiplies that by the number of published frames. In this case, we’re only publishing 10 frames per second, so it makes sense that the expected count is too low.
From the statistics, it seems clear that 83% of your measurements are being discarded. However, it’s not because they are arriving late because Missed sorts by timeout: 0 would be larger. It could be due to the timestamp reasonability check, but I’m not sure why it would be consistently publishing 10 fps.
My best suggestions would be to examine your timestamps carefully. Maybe you could try getting a CSV capture of your input data from PMU Connection Tester to see if the timestamps look reasonable? You could use the Graph Measurements page in openPDC Manager to try to compare measurement timestamps to your local clock to see if there are any significant deviations. You can also try unchecking Perform Timestamp Reasonability Check in your Output Stream configuration to see if that makes any difference.
Thanks,
Stephen
@StephenCWills , thanks for your answer!
Starting at the end: I tried unchecking Perform Timestamp Reasonability, but it had no effect.
Regarding the timestamp, my PMU (RPV311) is configured with UTC-3 (via IRIG-B), but in the reading carried out by the PMU Connection Tester it appears in UTC.
Could this be the cause of the problem? Is there a way to fix this?
I was replying in the other thread (How to Sync Time with PMU Device - #25 by ritchiecarroll) about this too.
Any ideas?
No, the time zone shouldn’t have any effect. If the PDC thought your data was three hours old, it would discard all of it. You need to figure out why it’s only dropping 83% of it.
I already see one potential problem in your Graph Measurements screenshot. The Time Tag column underneath the graph reads 21:12:32.102. Normally, at 60 fps with aligned timestamps, you should expect to see the following timestamps…
21:12:32.000
21:12:32.016
21:12:32.033
21:12:32.050
21:12:32.066
21:12:32.083
21:12:32.100
21:12:32.116
...
You may notice that your timestamp is not in this list, which suggests your timestamps are not properly aligned to the top of the expected intervals. Try capturing a CSV file to see what your timestamps look like.
Thanks,
Stephen
Try this: on your “Concentrator Output Stream” instance, open the “Advanced Properties” section, then ensure that “Round to Nearest Timestamp” is checked, “Perform Timestamp Reasonability Check” is unchecked, and “Use Local Clock as Real-time” is unchecked. Next, click “Save”, then click “Initialize”.
The rounding to nearest timestamp may help with source timestamps that are not properly aligned to normal 60fps timestamps. This may not 100% solve your issue as two timestamps that round to the same timestamp may still get discarded - but it hopefully improves your output.
Additionally, you can try increasing your lag and lead time as an experiment, start with 5 and 5, then go up. Although your local clock looks very accurate as compared to incoming data, it is still possible that data is coming in out of order - which could explain all the “discarding”. So, waiting longer may help ensure incoming data has the needed time to get sorted into proper output frames.
Also, per Stephen’s comment, getting a data dump of the incoming data would be very useful. One easy way to do this is to connect to the data source with the PMU Connection Tester – note that since your connection is UDP, you will need to temporarily disable device in openPDC in order to make that connection. Once you are connected with PMU Connection Tester, select “File > Capture > Start Stream Debug Capture…” and select a target CSV file. You should only need a few seconds of data to get a better picture of the incoming timestamps.
Thanks!
Ritchie
@ritchiecarroll , I tried both suggestions but nothing changed. Unfortunately…
I configured the Lag and Lead Time by increasing 5 seconds at a time until it reached 60 seconds, but I didn’t notice a difference.
@StephenCWills , i think that timestamp looks good:
2024-12-19 16:21:19.066
2024-12-19 16:21:19.083
2024-12-19 16:21:19.100
2024-12-19 16:21:19.116
2024-12-19 16:21:19.133
2024-12-19 16:21:19.150
2024-12-19 16:21:20.000
2024-12-19 16:21:20.016
2024-12-19 16:21:20.033
2024-12-19 16:21:20.050
2024-12-19 16:21:20.066
2024-12-19 16:21:20.083
2024-12-19 16:21:20.100
2024-12-19 16:21:20.116
2024-12-19 16:21:20.133
2024-12-19 16:21:20.150
2024-12-19 16:21:21.000
2024-12-19 16:21:21.016
2024-12-19 16:21:21.033
2024-12-19 16:21:21.050
2024-12-19 16:21:21.066
2024-12-19 16:21:21.083
2024-12-19 16:21:21.100
2024-12-19 16:21:21.116
2024-12-19 16:21:21.133
2024-12-19 16:21:21.150
2024-12-19 16:21:22.000
Any other ideas?
Thanks!
Yes - your input rate is 10 per second. The openPDC will not generate artificial frames to fill in the blanks for a 60 frames per second output.
You will need to use an adapter to generate signals like this…
Thanks,
Ritchie
Did you do a CSV capture of your output stream? Try capturing data directly from your input device.
@ritchiecarroll , thanks for your answear!
However, it is possible to observe that the configured PMU is sending at a rate of 60 fps. Wouldn’t there be some configuration in the openPDC Manager (v2.9.342.0) itself that could be limiting the output?
@StephenCWills , yes, i did. Here is the input device timestamp:
17:06:53.000,40,
17:06:53.016,40,
17:06:53.033,40,
17:06:53.050,40,
17:06:53.066,40,
17:06:53.083,40,
17:06:53.100,40,
17:06:53.116,40,
17:06:53.133,40,
17:06:53.150,40,
17:06:53.166,40,
17:06:53.183,40,
17:06:53.200,40,
17:06:53.216,40,
17:06:53.233,40,
17:06:53.250,40,
17:06:53.266,40,
17:06:53.283,40,
17:06:53.300,40,
17:06:53.316,40,
17:06:53.333,40,
17:06:53.350,40,
17:06:53.366,40,
17:06:53.383,40,
17:06:53.400,40,
17:06:53.416,40,
17:06:53.433,40,
17:06:53.450,40,
17:06:53.466,40,
17:06:53.483,40,
17:06:53.500,40,
17:06:53.516,40,
17:06:53.533,40,
17:06:53.550,40,
17:06:53.566,40,
17:06:53.583,40,
17:06:53.600,40,
17:06:53.616,40,
17:06:53.633,40,
17:06:53.650,40,
17:06:53.666,40,
17:06:53.683,40,
17:06:53.700,40,
17:06:53.716,40,
17:06:53.733,40,
17:06:53.750,40,
17:06:53.766,40,
17:06:53.783,40,
17:06:53.800,40,
17:06:53.816,40,
17:06:53.833,40,
17:06:53.850,40,
17:06:53.866,40,
17:06:53.883,40,
17:06:53.900,40,
17:06:53.916,40,
17:06:53.933,40,
17:06:53.950,40,
17:06:53.966,40,
17:06:53.983,40,
17:06:54.000,40,
That capture doesn’t appear to match what the openPDC is seeing. I mentioned before that the openPDC Manager shows a Time Tag of 21:12:32.102. It’s also pretty clear from the Last discarded measurement in your openPDC Console output, which shows a timestamp of 18:54:03.043. Your CSV capture appears to have aligned timestamps that don’t include *.102 or *.043.
From your PMU Connection Tester screenshot, it looks like you’re capturing data from UDP port 4715, but openPDC is receiving data on port 4714. What’s the reason for the different ports? Is it possible that 4714 is configured differently from 4715 on the PMU itself?
Thanks,
Stephen
I really don’t know why this is happening…
I just connected it to another port because openPDC Manager was connected to port 4714. However, I also tested using the other port (4715) and got the same result.
Can you provide the connection string for the PMU as configured in the openPDC? Also, can you provide a screen shot from the screen for “System > View Iaon Tree”?
Connection string to PMU:
transportprotocol=Udp;localport=4714; server=PMU_IP; remoteport=4714; interface=VM_IP; receiveFrom=PMU_IP
To remove a variable from the puzzle, I suggest disabling the PMU_TIME_SYNC adapter (uncheck “Enabled”, then click “Save” and “Initialize” for the adapter in “Actions > Manage Custom Actions”)
PMU_TIME_SYNC Disabled!
I’m not sure if this will actually help us determine what’s going on, but if you want to get a better look at how openPDC is interpreting the input device’s timestamps, you can set up a simple CSV adapter under Outputs > Manage Custom Outputs. You can set it up to capture just the frequency measurement and enable it only for a few seconds. When configuring the CSV adapter, make sure the openPDC service account has permissions to write to the directory!
The last 7 digits of the Timestamp field correspond to the subsecond portion of the timestamp. Here is what my CSV export looks like after setting up the sample data set.
