Running Multiple PMUSimulators on same Computer


I tried running two PMUSimulators at the same time on the same Computer. With respect to processing power, there is no trouble. I have run 20 simultaneous instances of PMUSimulator with no processing trouble. However, when i used Wireshark (free network packet sniffer software) to determine when each packet actually left the computer, I have some problems. Ideally, two packets with the same timestamp should leave the computer at nearly the same time. However, the PMUSimulators seem to be operating independently of each other. For example one PMU will send time FSOC=0 at one time, and the other PMU will send FSOC=0, 5 milliseconds later. The delay between each packet changes throughout time. When I try to autocorrect the frame rate the problem becomes even worse.

Real PMU's typically only have 1 or 2 outputs. The PMUSimulator is certainly capable of having multiple outputs but data frames need to leave the computer at the same time. I have attached the Wireshark file that I captured. I had two identical PMUSimulator config files running. One was using UDP port 4567, and the other was using UDP port 4568. The port numbers are needed to distinguish between the two PMUSimulators. Note: Wireshark is extremely useful because you can decode the packets as Synchrophasors.

I'm not sure exactly how the packets are compiled, but it is necessary to send similar packets at the same time in order to simulate the interoperability of real PMU's. There should be a way to generate the data frame with a particular timestamp and send it at the same time as another instance of PMUSimulator. Any suggestions?

file attachments


pipkguitar wrote Feb 17, 2012 at 5:27 PM

Also, I forgot to mention that the frame rate is 60 frames per second so the time between packets should be 16.666ms in the attached Wireshark file

pipkguitar wrote Feb 24, 2012 at 3:30 PM

I think I found a way to solve this problem as well as the frame rate. I'm still working on getting the code to work properly, but I think that instead of having a usleep(1/fps) or trying to autocorrect having an average that equates to the fps rate, the program could calculate the time remaining until the next interval that it should send the packet and then usleep that amount. For instance, a packet containing the data frame will be sent at specific times instead of specific intervals of time. So a packet would be sent at real time fsec=0 at the turn of the SOC. When the program determines that the ntp_gettime() is fsec~1/fps it will send the next frame and wait until the real time is fsec=2/fps to send the next packet. This works very well for the frame rate and the drifting offset between packet arrival times are consistent with a real PMU. I'll post the code if I can get it to work consistently and properly.