+ AA6QY comments below
Hmmmmm... Guess I didn't do a very good job with the terminology, so I'll give it another try. I said UDP not based on personal knowledge, but based on the fact that to get the communications to work between WSJT-X and Commander I went to the reporting tab of WSJT-X settings and entered the UDPServer IP address (127.0.0.1) and the UDP server port number (2237) and checked off three boxes that had to do with UDP requests. Then, in a panel called Secondary UDP Server, I checked a box saying "Enable logged contact ADIF broadcast" and again plugged in an IP address and server port number. The box up the page aways that said "Use TCP/IP" address was NOT checked.
+ That section of WSJT-X controls governs the routing of UDP messages containing QSOs to be logged. It has nothing to do with transceiver control.
The N4PY Icom software is basically the same as the Pegasus software for all the other brands. N4PY told me that the technique I referred to was special for communications with DXLab, but maybe that's not true either?
+ A TenTec Pegasus is essentially a PC peripheral. If Commander is installed on that PC, it controls the Pegasus frequency and mode by writing a record in a file named Pegasus.in in a specified "Control folder". To switch a Pegasus between RX and TX, Commander writes either PTTOFF or PTTON into a file named Pegasus.aux in the same "Control folder".
Anyway, in Commander config, General Tab, Radio panel, I selected Pegasus_N4PY as the model and then specified the location of a "control folder". In the N4PY program settings, I specified the name of that same folder, which they call the "Transfer folder". And, N4PY and Commander were able to successfully communicate via that folder.
+ Pegasus_N4PY is a "Pegasus Emulator".
And, what I tried to tell you is this: When I use that means of communications between N4PY and Commander, Commander no longer responds to the request from WSJT-X to turn on PTT when I run the PTT test in WSJT-X.
+ If you have Commander's Radio Model set to Pegasus_N4PY, then when Commander is directed switch from RX to TX, it writes PTTON in the Pegasus.aux file in the "Control folder". I've just verified that this works correctly; you can do so yourself by using Notepad to open the Pegasus.aux file in the "Control folder". If you have N4PY's Pegasus Emulator controlling your IC-7610, and you're saying that the IC-7610 is not being switched between RX and TX, then the question to ask is why the Pegasus Emulator is not responding to a PTTON in the Pegasus.aux file by directing the IC-7610 to switch from RX to TX.
+ Perhaps the Pegasus emulator is responding -- but far too slowly for WSJT-X. Commander opening a file, writing PTTON or PTTOFF in it, and then closing that file is not a slow operation - even if the file is hosted on a solid state drive (which I would think it would quickly wear out!). The Pegasus Emulator must periodically open/read/close the Pegasus.in and Pegasus.aux files to see if new frequencies and modes have been specified, or RX/TX changes have been specified respectively. The time from Commander receiving an RX=>TX or TX=>RX directive from WSJT-X to the Pegasus Emulator learning that it's to switch the transceiver's RX/TX would likely be hundreds of milliseconds, if not seconds.
Getting back to Commander and my WSJT-X problem: If I specify the radio as an IC-7610 (with direct connection to the 7610 USB CAT port), then a box appears in the radio panel below the model area that says "Verify CI-V command acceptance". If I fail to check that box, then the WSJT-X PTT test fails in exactly the same manner as when I'm using the control folder with the port controlled by N4PY. I check that box, and then the WSJT-X PTT fest completes properly.
+ When you have Commander configured to control your IC-7610 directly, to what do you have the "Command interval" set in the Radio panel on the Configuration window's General tab?
+ If the "Command interval" is too short, Commander's outgoing "report status" commands can collide with the radio's responses to previous "report status" commands, because the Icom CI-V bus conveys commands and responses on a single conductor. Enabling "Verify CI-V command acceptance" forces Commander to not send a new "report status" command until it has received the radio's response to the previous "report status" command. By setting the "Command interval" to a small value and enabling "Verify CI-V command acceptance", Commander and the radio can interoperate at the maximum possible speed without collisions; I run my IC-7300 with a "Command interval" of 10 ms - with "Verify CI-V command acceptance" enabled.
+ If you specify a short "Command interval" but do not enable "Verify CI-V command acceptance", then outgoing commands can be garbled by CI-V bus collisions. Either increase the "Command interval", or enable "Verify CI-V command acceptance"; I recommend the latter.
So, that's the story. If it still doesn't make sense, I'll just have to find another way to makes things work.
+ I now understand what you're doing. However, the scheme of conveying commands from Commander to a Pegasus Emulator through files and then from the Pegasus Emulator to your IC-7610 is likely far too slow for WSJT-X.
+ And if WSJT-X interoperates correctly with Commander when you enable "Verify CI-V command acceptance", then you have Commander configured for optimal control of your IC-7610.