search

df8oe / UHSDR

SDR firmware and bootloader with configuration files for use with Eclipse, EmBitz and Makefile
Other
356 stars 186 forks source link

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

Closed dl2kuh closed 3 years ago

dl2kuh commented 3 years ago

Hello

issue: not moving scale of Band-Map in WinTest - CAT issues ?

Environement:

OS: Window 10 64bit WinTest: 4.33.0

Hardware / Software

DL2KUH mcHF: (not moving scale Band-Map issue) UI Board: mcHF 0.4 RF Board: mcHF 0.4 Bootloader: 5.04 UHSDR: 2.11.95 (or 2.10.0) CAT Running in Sandbox: OFF CAT-DIG-FREQ-XLAT: ON

DK2LO mcHF: (not moving scale Band-Map issue), same issues at different Laptop with different WinTest version 4.25.0. UI Board: mcHF 0.6.3 RF Board: mcHF 0.6.3 Bootloader: no info UHSDR 2.11.88

DJ9SN mcHF: (moving scale Band-Map working OK), tested at DL2KUH environment/Laptop/USB-cable) UI Board: mcHF 0.4 RF Board: mcHF 0.4 Bootloader: very old UHSDR: 1.6.0 (he did not change to new Firmware, because the issues is not happen) CAT Mode: ON CAT Running in Sandbox: OFF CAT-DIG-FREQ-XLAT: ON

Describe the issue:

WinTest using "FT-817" to control mcHF via USB. Band-Map of window "Radio1" show the frequency at VFO-A from mcHF (digital value is changing). If I change the freq. band at mcHF also the band and freq. is changing at show correct value in window "Radio1".

BUT the scale of Band-Map of window "Radio1" ist not moving.

DJ9SN and DL2KUH build both mcHF together in 2016. Same Hardware and same Hardware modifications.

I checked the mcHF-DJ9SN CAT setting and adapted accordingly the mcHF-DL2KUH setting. This does not help.

Linked zip-File (videos/pictures) show the issues (not moving scale of Band-Map) at mcHF-DL2KUH (incl. configuration) and also working/moving scale Band-Map of mcHF-DJ9SN (incl. configuration).

LINK Video in UHSDR Forum: https://www.amateurfunk-sulingen.de/forum/attachments/mcHF-DJ9SN-DL2KUH-Wintest.zip

We were already in contact with WinTest autor and got following infos (translated to Englisch): It looks the problem is "FT-817". It looks the FT-817 send contineously, uninterrupted data to WinTest. WinTest feature "freq-display" in Band-Map" is working like this: digital number view of freq. (obove) will be imediately changed, after new data from TRX arrived. The "scale of Band-Map" will be changed with other datas (Spots, closed segments, .....). But if already next new data from TRX already arriving before the update "scale of Band-Map" can be finished, then the output for "scale of Band-Map" wil be interruped (not finished) and will be started from the beginning again.

Kontakt zu den Wintest-Autor ergibt diesen Kentnissstand: Es deutet darauf hin, dass das Problem bei dem FT-817 liegt. Es scheint, dass der FT-817 ununterbrochen Daten zum Wintest sendet. Wintest Funktion der Freq.-Anzeige in der Bandmap. Es laueft so, dass die digitale Anzeige (oben) sofort nach dem Eingang der Daten vom TRX aktualisiert wird. Der Zeiger in der Bandmap aber erst mit den sonstigen Daten (Spots, gesperrte Bereiche u.a.). Wenn jetzt aber schon die naechsten Daten ankommen bevor die Aktualisierung fertig ist, dann wird die Ausgabe unterbrochen und es wird wieder von vorn angefangen.

1) maybe the CAT (FT-817 protocoll emulation) implementation is different between UHSDR firmware 1.6.0 and UHSDR firmware 2.11.95/2.11.88 ? i.e. setting "CAT Mode" ON/OFF not availalbe in Firmare 2.11.95 anymore.

2) are the other CAT settings of UHSDR-Firmware, which could cause this issues ?

Issues was reported in UHSDR-Forum: at 07. Januar 2021, 21:56:42 https://www.amateurfunk-sulingen.de/forum/index.php?board=19;action=display;threadid=1698 Issues was confirmed from DK2LO in UHSDR-Forum at 14. Januar 2021, 13:55:04

EDIT 2021-01-19: uploaded here both videos

https://user-images.githubusercontent.com/17462566/105081283-425c4380-5a92-11eb-8632-9e89a20acc89.mp4

https://user-images.githubusercontent.com/17462566/105081317-51db8c80-5a92-11eb-9fe8-c47dfa976ee7.mp4

73 Hagen DL2KUH

db4ple commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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

db4ple commented 3 years ago

The problem may be caused by the commit d22e4a95c0365b5fa1d1b16771be4bd93b47c0fa , 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 commented 3 years ago

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

db4ple commented 3 years ago

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 commented 3 years ago

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

db4ple commented 3 years ago

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 commented 3 years ago

https://user-images.githubusercontent.com/17462566/110250043-9d31f780-7f79-11eb-98cb-0d4ea2db5037.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 commented 3 years ago

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 commented 3 years ago

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