I believe I now have the CFG, HDR, and Transmission Enable/Disable commands working with sensible data being returned (perhaps with a tweak or two to come). Now I’m sending Data Frames to the PMU Connection Tester over UDP to the tester’s UDP port number, but the tool does not seem to recognized the data.
Here is a Wireshark capture at the PC on which the PMU Connection Tester (PDC) is running:
Note the steady stream of Data Frames, ~10/sec, to UDP port 4712. Here is the test tool screen:
The tool obviously does not receive, or accept, the data frames that Wireshark indicates are present at the designated port number. I have run the data through my on-line CRC calculator and verified the Data Frames are correct. I believe 0xAA01 is the correct Sync value for Data. What am I missing? I assume this is user error again. 
I notice the data is coming from a different port than the one you entered for Remote Udp. That’s not necessarily a problem, but did you use the Receive From link on the far left to set up your connection? It may be filtering by port number based on that setting.
I did not use the “Receive From” set-up. The tool is still set to the default, “Use Any Source”. That said, I will see if I can choose my PMU’s UDP source port in sending the Data Frames and will reply with update. Thank you!
I am not a socket programming expert. But for some reason when I bind() the PMU UDP client’s source port to 4713 then the PMU’s UDP server does not respond to the PMU Connection Tester’s command’s to the PMU. Maybe it’s because both source and destination are bound to 4713, but I thought with UDP it should not matter. Anyway, unless and until I can resolve that my UDP Data frames are going out on an ephemeral port number. If we are certain the PMU Connection Tester needs to receive these frames on a particular port number then it seems I will need to resolve the above issue. Otherwise, could there be a different plausible explanation as to why the tester is apparently not processing these frames?
I asked previously if there is a debug log that could point us in a helpful direction, and maybe it would help for the phasor data frames?
I can’t speak to how your PMU handles its UDP communications, but UDP is typically fairly hardcoded. You may be able to bind to local port 4713 and send commands to remote port 5000, but the device could still be sending responses back to local port 4712, or else ignoring them altogether. There may be a setting in the PMU that changes the remote UDP port. Regardless, I don’t think that’s what you need to do in this case. Wireshark confirms that the data is arriving on local port 4712, so the issue must be local to the system running PMU Connection Tester.
If the tool is configured to receive from any source, then there should be no issues on the application side. Do you have Windows Firewall enabled on that system? Can you try configuring Windows Firewall to allow incoming traffic on UDP 4712?
I agree with you in that the Data frames should be reaching the tool given the tool’s eth interface/port configuration. It’s kind of cool now that I’m using our intended PMU’s server port number, 4713, that with the PDC/tool at 4712 now Wireshark dissector “knows” the Synchrophasor packets…
Your suggestion regarding the firewall is a good one. The thought had crossed my mind, although I’m not sure how Wireshark would “see” these packets if that were the case, unless the firewall actually runs at a “higher” level than the ‘pcap’ interface used by Wireshark. Since our IT department controls the firewall settings on our PC’s (where PMU Conn Tester is running) I need to inquire with them. I’ll report back those findings. Thank you again!
I can’t really speak to the levels in which pcap and Windows Firewall run, but I do recall a situation I encountered like this one at a time when I was experimenting with how UDP packets interact with firewalls. I seem to recall that Wireshark can indeed see the packets before they reach Windows Firewall for filtering. That said, for a more definitive answer, I turned to Google.
So I think Windows Firewall is definitely worth looking into.
Very nice, Stephen. Thanks! The IT wheels turn slowly here (unless it’s a customer outage or production stoppage, of course) so I’m still waiting for my ticket to be assigned. Will follow up when I have the answer, hopefully an “easy” answer. 
That seems to have done the trick. I figured out that I already am in the proper security group on my own PC to change Windows Defender’s firewall settings, so I added PMU Connection Tester to the list of valid applications (i.e., no blocking ports). Now you can see the results,
Happy Days. 
Thank you very much, for this very helpful test tool and for your amazing support!
Thank you very much, for this very helpful test tool and for your amazing support!