Issues with Hamlib and WSJT-X

[phaethon]

I have been debugging issues with wsjt-x, which sometimes disconnects (requiring reconnection and re-enablement of TX). Also, there is an issue with frequency, which sometimes jumps.

I have submitted some patches to hamlib (which are incorporated in last version), but there are some issues, which seem to be at least partly on UHSDR side:

• hamlib tries to read eeprom from address 0x0065 and gets no response from UHSDR
• when in tx mode hamlib uses tx status (command 0xf7) to determine if rig is in split mode. UHSDR in tx mode returns 0x00 always, disregarding split status
• after switching from PTT ON to OFF, there is a delay on UHSDR side. hamlib expects immediate switching, which sometimes leads to a situation that hamlib thinks it is disconnected

I have patched wsjt-x/hamlib to work. Patches are easy (when you find out what to do). More complex is the question what to do on UHSDR and what on hamlib side. Which requires discussion.

[db4ple]

Hi,

EEPROM@0x65: according to http://www.ka7oei.com/ft817_meow.html and after looking into the Hamlib Github the bits of interest to Hamlib are the bits defining the digital mode. Not sure exactly how we do this but I think we can at least return USER-L or USER-U. Not sure how relevant it is to report other modes. FT817 does not differentiate between RTTY-L and RTTY-U as we do in the UHSDR. So it may be better to report the sideband instead of not doing. Someone has to figure out what is better. Anyway, I'll fix that, no problem.

F7 -> Easy to fix.

PTT ON to OFF -> not much we can do on that on our side. It takes the time it takes. I don't think we should report the false status. Looking at the code, I don't see how long they are waiting for us to respond with the expected status (I can see that the request sent multiple times if we not return the expected outcome). I think, Hamlib should wait a little longer to fix this issue. Not much harm on the Hamlib side. But of course, it would be a fix for a device which just pretends to be a FT817 so these guys may reject it and we could not blame them for that. But worth a try.

[phaethon]

It is important to return at least something to 0x65 read, otherwise hamlib is waiting for response, which causes all sorts of wrong effects. Actually, it might be good idea to respond by default with 0x00 to any eeprom read.

On Hamlib side an option could be identifying UHSDR and then acting correspondingly. I am just not sure how actual FT817 would respond to cmd 0x42 (which returns 'UHSDR'), and if it wouldn't break something for owners of those rigs (and other clones). Implementing some more safe method would be good. May be returning some specific version reading eeprom 0x04?

I will send a patch to hamlib to wait 0.1 sec after coming from tx (which works for me).

[db4ple]

Responding with 0x00 -> not a good idea I think. We'll never figure out what is really read by programs and it may cause all sorts of additional issues if we return nonsense instead of an "valid" error message. I am quite aware of the fact the most FT817 aware programs would not expect to get an error message when reading the eeprom but at least in theory they could handle it as what it is (a problem).

I think part of the problem of Hamlib is that they simply issue multiple reads of the tx state back to back in a loop. Obviously the FT817 has not an issue with this but for us adding a carefully timed delay would make it work. BTW, do you have an mcHF? I think this also might be linked to the relatively slow response to the switching back under heavy load for the SMT32F4 since I haven't seen these issue on the F7 or H7 AFAIR.

[phaethon]

Yes, I have original mcHF v0.5

[db4ple]

Regarding command F7: Interesting, our implementation does not work as Hamlib expects and also not as the KA7OEI site says it should but the comment also says that our behavior was tested AND it was probably me who tested it. But I guess, I was wrong. I'll implement it as the documentation says and we'll see if this works (which I think it will).

[miek]

PTT doesn't work at all for me using WSJT-X 2.0.0-rc3 (and rc2) since the change in #1595. As far as I can see, the Hamlib code matches the previous logic where bit 7 unset means TX active and bit 7 set means TX inactive (contrary to the KA7OEI docs). https://github.com/Hamlib/Hamlib/blob/master/yaesu/ft817.c#L585

I've swapped the logic back around in #1596 to match Hamlib and it works again (though still has the issue of sometimes reconnecting when turning PTT off)

[db4ple]

So I was right with my original code and I was not able to read the Hamlib code correctly. Shame on me. Anyway, Mike, could you please also revert the if IsTxDisabled() condition below to return 0xFF as it was previously.

[db4ple]

@miek: I can't remember, do you also run a STM32F4 based machine (i.e. a mcHF)?

[miek]

Yep, it's an mcHF v0.6 with an STM32F439

[db4ple]

Okay, that could hint the disconnect problem to be related to a too long delay in responding is not happening on the F7 and H7 simply because they are (much) faster.

[phaethon]

The issue I mentioned earlier with tx status was about split status (I was not suggesting reversing the logic with 0x80 bit). The code line from hamlib ft817_get_split_vfo when in tx mode: *split = (p->tx_status & 0x20) ? RIG_SPLIT_ON : RIG_SPLIT_OFF;

[db4ple]

That's clear (now). I was confused and should have more carefully looked at the hamlib code instead of KA7OEI page. And of course I should have tested the code properly before submitting the change (always a good idea). The pull request #1596 brings everything in order (or at least aligned with the Hamlib code).

[phaethon]

I have submitted PR to Hamlib: https://github.com/Hamlib/Hamlib/pull/56 with a delay. It uses delay only before 2nd try, thus PTT off is actually sent twice. This works and does not change the way it works for rigs, which switch faster. Thanks @db4ple for the fix.

[phaethon]

My PR was accepted into Hamlib. Next version of WSJT-X will likely fetch latest Hamlib. Together with fixes by @db4ple it should be more stable now (at least it seems to be so on my MCHF).