Can't interface with WSJT-X 2.2.1

[ofadam]

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

Describe the issue:

With WSJT-X 2.2.1, I've set the appropriate rig control settings and keep getting the error "Hamlib error: Target VFO unaccessible while getting current frequency." I've used the exact same settings with fldigi and js8call, both of which interface perfectly with the McHF.

Here are my settings: Rig: Yaesu FT-817 Serial Port: COM3 Baud rate: 115200 Data bits: Eight Stop bits: Two Handshake: None PTT mode: CAT Mode: USB Split operation: None

[df8oe]

Sorry - cannot reproduce. If it works using other software it is not an issue of UHSDR but of the settings and/or the external software... I can work using WSJTX 2.2.2. Have you found a solution?

[lilo-chita]

Hi guys.

Same issue here with wsjt-x 2.2.2. "Hamlib error: Target VFO unaccessible while getting current frequency" Looks like it has hamlib compiled in and that hamlib version has issues.

All other software js8call (builtin hamlib), fldigi (external hamlib 3.3), flrig work just fine.

No solution yet, using wsjtx->flrig->mchf as temporary workaround.

[G3WKW]

I believe there is a known defect in the WSJT release and suggest you try selecting FT 857 as the rig. The 897 selection Certainly has an issue And I believe I read that the 817 is also wrong but the 857 is an effective work around. 8x7 all have the same CAT protocol afaik.

[G3WKW]

Confirmation at this link https://wsjtx.groups.io/g/main/message/12843?

[df8oe]

For me it is working with FT-847UNI. That may differ between the distributions. I am using Arch Linux.

[lilo-chita]

I've already tried 857, 847, 847uni. No luck. So flrig is the only option for me atm.

[df8oe]

It would be interesting to hear what operating system / version you are using, and if you use precompiled WSJTX (what source?) or if you build it by yourself... This is definitely not a problem of UHSDR but of hamlib.

[lilo-chita]

Ubuntu 18.04 64bit wsjtx 2.2.2 apt package from their official page No doubt it's a problem of hamlib they used building a package.

Sure I could try to recompile it from sources with proper hamlib version. But I'm too lazy, flrig works fine for me )

[G3WKW]

Having re-read the thread on wsjt group https://wsjtx.groups.io/g/main/topic/75072994#12843 There is a note to check (or rather uncheck) “. OK, make sure the rig is not in memory mode. Also with any of the FT-817/857/897(D) models you need to leave "Settings->General->Allow Tx frequency changes while transmitting" unchecked.“ Might be worth a look. I believe the issue only started with 2.2.1.

[df8oe]

UHSDR is never in memory mode and you cannot enter this mode at UHSDR... UHSDR is always in straight-and-simple-CAT.

[martinling]

I ran into this problem yesterday setting up WSJT-X 2.2.2 on a Windows 10 machine. I also tried selecting FT-857 without success. I worked around the problem by downgrading that machine to 2.1.2. Both binary versions from the official site.

On my Debian machine however, using the WSJT-X 2.2.2 packages from the Debian repositories, everything works. Those packages however will be using the current hamlib version in the Debian repositories (currently 3.3-10+b1 for me) which may differ from what the Windows binaries got built in.

I'm not able to test the deb packages from the official site at the moment - they have dependencies that don't seem to be easily satisfiable on a non-Ubuntu system.

Although this seems fixable by use of different WSJT-X/hamlib versions, I do think there may be a UHSDR bug involved.

Most WSJT-X users will be on Windows and there must be plenty of people running 2.2.2 (released June) with an FT-817 by now. I've not seen anyone reporting problems with an actual FT-817.

If UHSDR is claimed to be protocol compatible with the FT-817, and hamlib is working with that model, then hamlib seeing a difference on UHSDR which causes it to fail seems like something that ought to be fixed on the UHSDR side if possible.

[df8oe]

UHSDR is NOT protcol compatible with FT-817. UHSDR is using some CAT commands FT-817 (and other FT-8xx) use the same way. There is not the same hardware as in Yaesu devices so many of the commands will not work (e.g. direct memory accesses). But if the used software uses the CAT commands in the correct way UHSDR will work with FT-8xx settings.

I am very sorry - but it is a hamlib bug. There are many different hamlib versions out in the wilderness, and some are buggy. It seems that for Windows the buggy versions are in the majority.

We do not have the time to reverse engineer faulty hamlib versions and see what is going on. We took the datasheet of the FT-817 CAT protocol and use the commands we need. And this runs without any changes from the beginning of CAT implementation...

[martinling]

Then it seems to be time for hamlib to get UHSDR as a separate radio selection, and for the UHSDR documentation to stop telling people to select FT-817 as the radio type.

It's going to be hard to convince hamlib developers that there is a bug in their FT-817 protocol code, when it works with an actual FT-817 and the problem only occurs with a completely different radio.

[db4ple]

@martinling I don't agree with Andreas, @df8oe. We are claiming to support the FT-817 CAT protocol. And we fully do this on the CAT protocol side. What we don't do is to respond to all protocol messages exactly in the same way as a real FT-817 would do it, especially in terms of timing but also in support of all features of the FT-817. What the goal was, was to emulate the CAT interface well enough to be able to be used with mainstream programs and normal operation concepts. Why not define our own protocol? Not to have to built in support into all of the tools, for not much gain. So I would think, we should try to identify the root cause AND then decide the course of action (fixing UHSDR or hamlib). BTW, it seems that the uBitx is also having issues with its FT-817 emulation and the hamlib did include some workarounds for it, see https://wsjtx.groups.io/g/main/message/12902. I would not rule out a fix in the hamlib as the best solution.

I will have a look at it tonight. And see what I can see there.

[db4ple]

OK, here comes my report: My "real" FT-817 (yes, THE FT-817, not that new FT-817(N)D or FT-818 stuff ;-) ) does exactly what the UHSDR firmware does: It does not cooperate with WSJT-X 2.2.2 on Windows. I get exactly the same error message when testing the CAT and (with the help of an USB analyzer I also verified that the same data is exchanged over the serial CAT): First a 00 00 00 00 88 (PTT OFF) to which both respond 0xF0, which means transceiver is unkeyed, i.e. PTT is off. Second and last is 00 00 00 00 F7 (GET TX STATE) to which the FT-817 responds 0xFF and the UHSDR responds 0x80. Here only the highest bit is relevant, since if TX is off, bit 7 == 1 indicates this state and all other bits are not meaningful if not in transmit mode. The result is the same in both cases:

So I would think, that less FT-817 user than expected are using WSJT-X 2.2.x as it seems not to work at least for the original FT-817 connected via USB. But I don't think that the USB is of any relevance here.

My verdict: I would think it is a WSJT-X bug which should be fixed, it may be caused by the Hamlib version linked to WSJT-X 2.2.x Windows or just by the wrong use of it.

[G3WKW]

This has been discussed on the WSJT groups and the work around is to select FT857 which fixed it for me with the 897 which has the same issue. I have not tried with my mcHF and won’t be able to before the weekend.

[db4ple]

@G3WKW: Should have mentioned that I tried that workaround for the UHSDR (selected FT-857 in WSJT-X), did not work for me. It gave a different error, something with protocol error. Haven't tried if it would have worked for the real FT-817, though.

[martinling]

Yes I looked further into this too, there are a few issue reports on the hamlib repo e.g https://github.com/Hamlib/Hamlib/issues/357. Seems like the problem is fixed on their side, so the WSJT-X team just need to ship new binaries built against the fixed version...

[lilo-chita]

It looks like get_vfo command was removed from ft817 backend in recent hamlib versions. That could be the cause.

[db4ple]

@lilo-chita: That would match the error message we get. So it is a Hamlib / WSJT-X interaction regression due to a change in the recent hamlib releases. And we can't do anything on the UHSDR firmware side to resolve it.

[lilo-chita]

Sorry I was wrong. Actually get_vfo never was there in ft817 backend. But apparently something has changed in hamlib that gives us the vfo error.

Anyway I'm too lazy to dig into all those source codes. So I closed the issue for myself building the wsjtx 2.2.2 .deb package from source code dynamically linked with external hamlib 3.3. Works just fine.

[shepting]

I was able to work around this problem with my mcHF by updating to WSJT-X v2.3.0-rc1

[db4ple]

The new wsjt-x 2.3 fixes this issue.