WSJT-X 2.5.0 and MCHF: issue reading-back the VFO setting

[fpaolo63]

Issue Data goes here (please remove text above):

Your firmware version: D2.12.0 Your bootloader version: 5.0.4

Hardware

• UI Board: mcHF 0.6.3
• RF Board: mcHF 0.6.3

Describe the issue:

WSJT-X 2.5.0 and MCHF: issue reading-back the VFO setting As per wiki suggestion I set CAT for FT817

After some triage, wrong behaviour is triggered by new HamLib 4.3.1 mcHF cat emulation based on FT 817 is broken, real Yaesu ft817 is working fine.

ERROR message from hamlib: Hamlib error: Protocol error read_block(): Timed out 3.3116 seconds after 1 chars rig_get_vfo: returning -8(Protocol error 0000 00 . read_block(): Timed out 3.3116 seconds after 1 chars read_block(): Timed out 3.3116 seconds after 1 chars)rig.c(2809):rig_get_vfo return(-8) while testing getting current VFO

W.A. use FT847 instead.

My observation, working setting vs sw version: wsjtx 2.4.0 (it use Hamlib 4.2) -> set CAT for FT817 or FT847 wsjtx 2.5.0rc5 (it use Hamlib 4.3) -> set CAT for FT817 or FT847 wsjtx 2.5.0 + Hamlib 4.3.1 -> set CAT for FT847 (no UNI) wsjtx 2.5.0 + Hamlib 4.3 -> set CAT for FT817 or FT847

NOTE HamLib guru is going to add new rig definition for mcHf. (pls ref to https://wsjtx.groups.io/g/main/message/29902 messages posted on wsjtx forum on thread topic https://wsjtx.groups.io/g/main/topic/86442076)

---

73 IU2OMT

[db4ple]

Thanks for the report. Interesting. There is no relevant change between 4.3.1 and 4.3 to be seen in the source code of hamlib. There was a change in 4.2 to 4.3 which added get_vfo to ft817. However, the UHSDR firmware implements the required code so that hamlib should be happy. So the question is what is different between 4.3.1 and 4.3 . Will investigate.

[db4ple]

Ok, now looked a bit deeper. HAMLIB wants to read EEPROM 0x55. Which our emulation supports, e.g. as it is used by the HRD program and others. FT817 returns from EEPROM read always 2 bytes, and any address is permitted as first byte. Hence all programs so far used 0x55 as address to get vfo settings. However, contrary to all other programs, HAMLIB reads always EEPROM from even address and then returns either first (if requested address is even) or second byte (if requested address is odd). That breaks our emulation. But we can fix this relatively easily.

[db4ple]

The committed fix should make HAMLIB 4.3.x happy. @df8oe will provide new build on download page.

@fpaolo63: Please report success or problems here

[fpaolo63]

... Well .... just test the last commit done by Hamlib guys, they add a new RIG entry for MCHF. It is based on 847 and seems working fine. So we have 2 solutions :) Any way, I stressed the cat (IDIOT TESTs) and I got the RIG hang.

I will test the new RIG SW.

PS. better to coordinate effort with Hamlib guys

73 IU2OMT paolo

[fpaolo63]

Hi all, just load the new FW D2.12.1. We are in the same failure condition with FT817 emulation.

see msg

73 IU2OMT paolo

[db4ple]

Fixed in 2.12.2 , see #1922 Close this now since @fpaolo63 reported success on his rig