Hi, How i can connect microPMU by UDP? I want to test UDP protocol to see if microPMU recover the datastreaming.
Now i have 2 microPMU in openPDC with datastreaming but using TCP protocol. The connection is through routers with sim card. I don’t know why but sometimes microPMU stop streaming. Could be signal fail of SIM card, but microPMU does not recover the datastreaming. In this situation i have to reboot routers or reboot microPMU.
These are parameters that i tested unsuccessful.
Local Port: 4713 and 4614
Enable Multicast / Remote Udp: What is that?
Host IP: IP Adress of my LAN, 192.168.2.1 and 192.168.2.2
Remote Port: What remote port? command port is 8881
This command port i am using for commands through webrowser of microPMU software, with success.
Remote port is only used for multicast scenarios, where the data source sends packets to a multicast address and then the router routes those UDP packets to every device connected to it. Remote Udp allows you to specify a remote address from which you will be receiving UDP data packets. It allows you to filter incoming data for scenarios in which you have multiple sources providing data to the same endpoint.
Normally, I would expect the opposite. TCP tends to provide better reliability due to the packet ordering and retry characteristics built into the protocol. However, network congestion can induce latency in TCP connections and cause irrecoverable backlogs of packets on the network. With UDP, your network will likely be better able to recover from network congestion and keep latency low, but it will do so by dropping packets which means you may experience data loss.
Note that these things only happen during times when the network is congested. In general, you probably will not experience any backlogs or dropped packets and so the choice of protocol will not make much of a difference. In that case, it comes down to the vendor’s implementation of each protocol, and from that perspective you may well experience better reliability from UDP. My best advice would be to just try it and see.
I don’t know why mPMU not receive the configuration frame 2. The connection is good but always wait configuration frame. On wireshark i see syncrophaser send in UDP but without configuration frame on data information.
I believe, if you are using UDP and sending device commands, you will want to disable the alternate command channel and define the Remote Udp settings to identify the endpoint that the remote device will be listening for commands.
I tried that and PMU connection tester not show the graph. Another problem was in settings i have AutoStartDataParsingSequence set True and when a connect to device PMU connection Tester do not send enable real-time Data. Because of that i had to send this command manual to obtain data frames.
PMU Connection Tester only shows frequency and phase angle. It doesn’t show waves. Are you saying that it’s showing phase angle, but not frequency? Or are you referring to the fact that PMU Connection Tester does not appear to be receiving data even though you can see the data frames in Wireshark? I’m just not getting a clear understanding of the issue.
PMU Connection Tester does not receive any data, any configuration frame like mPMU Va (on left side of PMU Connection Tester), etc etc. Does not show frequency or other values. It is not working the automatic message of “Send configuration frame and Enable Real-Time data”. My parameter is True for that.
What i want is produce a configuration file to put on openPDC. But with this configuration i had the error that i said firstly.
I try to read a lot about openPDC but not understand very well to do a UDP connection in openPDC. I don’t know If i had to have a pmconnection file with configuration on PMU Connection tester, or if i have to do that configuration manually on openPDC. When i say manually is to create a input device, and after output streams. You can see on one of my figures the data of phasors, like 230V in L1MagAng, etc etc.
To read the data of UDP(my device) with openPDC i have to configure the connection on PMU Connection Tester, and next one configure on openPDC?
The connection file from PMU Connection Tester is basically a glorified connection string. It makes it easy to export the PMU Connection Tester’s settings in a format that is consumable by the openPDC Manager. However, the connection file is neither required for nor incapable of properly configuring a UDP-only communications path to a PMU. In other words, you do not need the connection file, but you can certainly use it. That said, I would definitely recommend using the PMU Connection Tester as it will be much easier to verify whether you have configured your settings correctly.
Looking back, it seems I may have caused some confusion based on the assumption that you would not be setting up a UDP-only communications path. The Remote Udp setting actually allows you to set up the endpoint to which the PMU Connection Tester should send command frames. This is how I would expect you to have to configure the PMU Connection Tester. I’m piecing together scattered information in this thread so hopefully I got it right.
Local Port: 4713 Receive From: Use Any Source (PMU IP address may also work) Enable Multicast/Remote Udp: Checked Host IP: PMU IP address (192.168.2.20?) Remote Port: PMU command port (8881? Or 47156?) Multicast Source: Use Any Source Configure Alternate Command Channel: Not Defined
Also, go to the Settings tab and make sure that AutoStartDataParsingSequence is set to True.
Yes, but i use Remote Port 4713 also because i have an answer from mPMU. In setup.ini i have port 8881 to command channel of mPMU. This 8881 is working for access to commands in webrowser but not for configuration frame in PMU Connection Tester.
Receive From and Multiacast Source yes, i tried also with mPMU IP but with the same result.
That port 47156 i think is a port variable, and every time is changing.
Your Wireshark capture shows command frames with the appropriate source and destination IP addresses. It also looks to me as though the PMU is receiving those commands. Are those command frames being transmitted over UDP from the PMU Connection Tester?
Thank you very much your answer. In PMU Connection Tester i do not use alternate command channel like you suggested. In wireshark i see that protocol used to send commands is UDP.
Yes mPMU receive those commands but not receive from PMU Connection Tester “Enable Real-time data” automatically, i had to send manual in the menu of protocol “send commands”. This is very strange because i have enable true AutoStartDataParsingSequence.
Another thing is that in Wireshark i can see the packages with phasors data and PMU Connection Tester do not display that data, like happen when i use TCP Protocol.
Another try on openPDC but the result is missing configuration frame from mPMU. Always in loop this message. But in wireshark i can see in packages the phasor data.
So the reason why the PMU Connection Tester does not send the Enable Real-time Data command automatically is because it already sent the Send Config Frame 2 command and has not received the response. Because the PMU is sending and receiving data on different endpoints, your firewalls and NATs would be unable to automatically configure port forwarding for the UDP packets coming from the PMU. Have you checked your firewall configuration? Note that Wireshark can actually see UDP packets which are blocked by Windows Firewall.
Let’s be precise. The issue is that the PMU is sending from a port which is not 4713 to port 4713 of your computer. Wireshark can see the packets, so if there are any firewalls blocking the packets, it would have to be Windows Firewall. I don’t know how you determined that PMU Connection Tester is not blocked by Windows Firewall, but I would think that an explicit incoming rule to allow traffic to either PMU Connection Tester or UDP 4713 ought to be sufficient.
With windows firewall rule i can not connect yet. I did a previously rule to Windows Firewall for that port 4713 and i think it is listenning when cmd netstats -aon. Now i do not know if the router connected through IPSec to mPMUs accept UDP ports.
An interesting thing was this result when i use the variable port to remote port:
I don’t know how, but PMU Connection Tester is seeing the package of data frames, but not display graph. You can see below the information about frames.
Further evidence that Windows Firewall is likely blocking the connection. When you told PMU Connection Tester to connect to that variable port, it sent a command frame to the 192.168.2.20:58395 endpoint. Before it sent the command frame, the firewall was blocking all the unsolicited packets from that endpoint. After sending the command frame, your firewall started treating the data frames as incoming packets for an outgoing UDP connection and stopped blocking the packets.
I’m 99.9% convinced that all you need to do is create a rule in Windows Firewall to allow incoming packets on port 4713.
