mcHF - not moving scale of Band-Map in WinTest (contestprogram) - CAT issues ?

[dl2kuh]

mcHF - not moving scale of Band-Map in WinTest (contestprogram) - CAT issues ?

[db4ple]

Hi,

TL;DR: Try setting the "polling rate" in the WinTest CAT protocol settings from AUTO to a fixed value (which is large enough) might fix the problems.

Just to clarify how it works: the FT-817 CAT protocol does not send any data on its own to the PC, so in order to receive data from the TRX, the PC programm has to ask for it. One request from PC, one block of response data sent back.

I can only speculate, but the major difference from 1.6 to 2.11 is most likely that data is being sent back quicker after the request.
I as the main author of the CAT part of the UHSDR have not seen huge changes in the protocol implementation after initial implementation (lots of bug fixes etc, but the general way of working did not change).

As the CAT protocol works with most other PC software without major problems (including hamlib based programs), I would see the problem in how the WinTest implements the protocol, especially looking after reading the Wintests authors response in combination with the knowledge that the FT817 protocol is a strict PC request/TRX response protocol. The emulated FT817 in the UHSDR responds probably faster than a FT-817 which may need up to 200ms for a response.

Basically I would say, it should be fixed on the Wintest side. It may rely on the "slow" performance of a real FT-817.

To really understand what might be the difference for UHSDR 1.6 vs. 2.11 in combination with WinTest one would need to run both firmwares and Wintest on a PC with a USB protocol debugger software such as Wireshark or USBlyzer which show in real-time / record for later analysis the USB communication between the program of choice (WinTest) and the UHSDR.

This is how I understood most CAT issues and fixed them. Or not, as in the recent case of WSJT-X for Windows having a broken hamlib version, there was no fix possible, the fixed was to wait for a fixed WSJT-X.

[dl2kuh]

Hi DL4PLE,
I testet with all polling setting (100ms - 1.000ms) => no improvment.

I also captured the USB-Ports trafic with WireSharc (USBPcap3) the trafic UHSDR 1.6 with WinTest 4.33 and also with UHSDR 2.11 with WinTest 4.33 ! Using WireSharc first time in my life - have it capture correct data (ofcourse I selected the right COM-Port)
mcHF DJ9SN: COMport 5 (UHSDR Firmware 1.6.0)
mcHF DL2KUH: COMport 6 (UHSDR Firmware 2.11.95

The ZIP-File I uploaded to UHSDR Forum (just now), becaue I do not know how to upload a such file here in Github.
https://www.amateurfunk-sulingen.de/forum/index.php?board=19;action=display;threadid=1698

EDIT 2021-01-19: uploaded the WireShark-Files
WireShark-USB-Port-Capture-mcHF_WinTest.zip

BTW: mcHF with UHSDR 2.11. and logprogram UXClog 8.05 the freq.change at "scale of Band-Map", working fine. Just tested this evening.

73 Hagen DL2KUH

[db4ple]

@dl2kuh : Thanks! Will have a look at it. Hopefully we can see the difference. Interesting that polling time setting did not change anything.

Uploading to Github Issues: just drag the file into the comment field to upload it. It is maybe too simple but instructions are at the bottom of the comment field, see below. In case of videos, please just upload the mp4 directly, this way one does not have to download the zip and unpack it to watch it.

[dl2kuh]

Video uploded into first issue report entry, WireShark-Zipfile uploded into yesterdays entry

[db4ple]

The problem may be caused by the commit d22e4a9 , which according to the committer made the tx logic match to the way hamlib sees it. Which I AFAIR confirmed by looking at the hamlib code. This is the last CAT request in the NOK capture, and this has definitely changed since 1.6.0 . Worth a try to look into this again.

[db4ple]

But it may also be completely unrelated as it may just be where you stopped the capture...

[db4ple]

Ok, @dl2kuh : If you are interested, I could provide you with a special binary to test if this fixes the issue. Let me know here if you are willing to give it a try.

[dl2kuh]

@db4ple : yes, pls. I will test it at my mcHF.

[db4ple]

Here we are: There is only one change in the CAT driver (return to PTT_STATE in RX 0xff instead of 0x80), all the rest is stock 2.11.96

fw-mchf.zip

[dl2kuh]

mcHF_DL2KUH_wintest-OK_07032021.mp4

Hi DB4PLE, with this special version of 2.11.96 (fw-mchf.bin) the "scale of Band-Map" WinTest is solved.
I can now also try to get in contact with Olaf DK2LO - to check at this mchF. Just to have a second verification.

BTW: I saw this special version is much bigger (440.608 Kbyte fe-mchf.bin) compare to official version 2.11.96 (354.868 KByte fw-mchf.bin)

[db4ple]

Ok, so my hunch was right. I need to check with an original FT-817 (what it does return on this CAT command) to finally decide how to proceed. But AFAIR, it returns indeed 0xff. Luckily I have access to a FT-817 (the real one, not these youngsters FT-817ND or even FT-818).

The size is fine, that is not an release build. Nothing to worry about.

[db4ple]

That's it. Next release will have the fix. Thanks for reporting and providing the relevant data!