js8call: hamlib issues

[dotemup]

Describe the bug

js8call unable to talk to FLRig built with different hamlib verisons due to patch applied for hamlib3 in build "unknown mode requested: DIG"

Steps To Reproduce

Steps to reproduce the behavior:

1. Set radio in JS8Call to FLRig and configure to point to flrig server.
2. In JS8Call using CAT, Data/Pkt (radio has specific user-digital settings), Rig split mode.
3. When JS8Call tries to communicate with rig, errors produced unable to TX.
4. Instead of using DIG setting, will default to PKT instead, which will not work.
5. IF set to USB mode in JS8Call no output on TX (settings on radio most likely for mic gain etc. as configured differently for digital modes vs traditional SSB)

Expected behavior

JS8 Should be able to communicate with latest hamlib4x versions to resolve issue. Built from source on raspi and also in vanilla debian without issue to communicate with other apps using latest hamlib version.

Screenshots

If applicable, add screenshots to help explain your problem.

Additional context

Same settings as WSJTX, same settings used on other installs of JS8Call. I know there's weird issues with hamlib and the wsjtx-data folder on other distros installed through apt or scripts like Jason's Build-a-pi, usually build from source on other installs because of those reasons.

Notify maintainers

@mattmelling

Metadata

Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.

 - system: `"x86_64-linux"`
 - host os: `Linux 6.1.56, NixOS, 23.05 (Stoat), 23.05.4172.bd1cde45c778`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.13.5`
 - channels(root): `"nixos-23.05"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

[mattmelling]

Just tested this in 2 configurations:

1. hamlib rigctl against rigctld 4.5.5
2. FLrig 2.0.04 directly connected to rig

Both working with an ICOM 7300.

What rig/interface are you using?

Does wsjtx from nixpkgs work with a similar configuration?

[mattmelling]

Also, js8call does not build with hamlib 4. That would need to be resolved upstream. However, I have not personally experienced issues using Hamlib NET rigctl from js8call to talk to hamlib 4.

[dotemup]

FT-818ND, works with wsjtx from nixpkgs using same settings, just not in js8call. Haven't been able to get js8 working since switching from Debian for my ham radio OS.

Likely a profile discrepancy between versions?

[dotemup]

Also, js8call does not build with hamlib 4. That would need to be resolved upstream. However, I have not personally experienced issues using Hamlib NET rigctl from js8call to talk to hamlib 4.

I'm not sure that's entirely accurate... doesn't the source fetch the latest source from git for hamlib?

https://bitbucket.org/widefido/js8call/src/24677a00343c2f3cc53f6762466a4b11893094f8/INSTALL#lines-11

The odd wsjtx installer fetches the fork for hamlib 3 with the patches for wsjtx hamlib patches. https://bitbucket.org/widefido/js8call/src/24677a00343c2f3cc53f6762466a4b11893094f8/INSTALL-WSJTX?at=js8call#lines-68

[mattmelling]

I'm not sure that's entirely accurate... doesn't the source fetch the latest source from git for hamlib, and the hamlib-wsjtx patches they apply as well?

You are correct, I was thinking in terms of swapping hamlib for hamlib_4 in the buildInputs which does not work.

The WSJT-X uses a super tarball which contains the hamlib fork source. It might be worth extracting the hamlib fork to another package that could be shared between WSJT-X and js8call.

Any thoughts @lasandell, @numinit ?

[numinit]

I definitely ran into something like this. hamlib compat issues were the bane of my existence messing with my Xiegu G90 (back when I had an antenna up). I think this package is worth unvendoring somehow if only to have a hamlib that is much more compatible.

[dotemup]

So doing a little hacking, swapping to use hamlib_4 in the libs/buildInputs the build fails but not for hamlib releated issues. The build failed on a qt related item. Added a patch to fix that:

Then ran into a "hamlib" related issue but only because the cmake.patch had defined to use hamlib3 caused errors for multiple definitions from this file. https://bitbucket.org/widefido/js8call/src/24677a00343c2f3cc53f6762466a4b11893094f8/HamlibTransceiver.hpp#lines-21

So I removed the definition from the patch: add_definitions (-DJS8_USE_HAMLIB_THREE)

Updating that patch with those changes seems to build... something. Haven't had a chance to test it on my ham radio pc only a VM that fails with more QT issues which I hope are just because it's a virtualbox vm.

I think we can probably use hamlib_4 with the right patches to fix the issues from the qt libs and remove the definition that tries to build against hamlib 3.

[dotemup]

Also tried reversing the order, removing the first patch applied and only commenting out the USB_HAMLIB_THREE line, also seems to build with the same error as above when ran in VM. So may only need to solve the qtlib issues for this to work

[mattmelling]

Ok, this is all looking positive. Rolled up the changes you described in to #265897. Not seeing any runtime issues with qt so it might be to do with the vm as suggested.

Let me know if it works for you. If not, we might need to use the wsjtx hamlib fork, which I am looking at.

[dotemup]

Some good news and some bad.

Good news, built and launched fine on my ham radio desktop. Issue with QT was definitely from virtualbox, seems to be well documented issue so not super concerned about that.

More good news, once js8call was launched it didn't complain about the DIG mode or any other hamlib related messages.

However, the bad news, when trying to TX or test PTT from settings there is a very bad delay in communication to FLRig where it's unusable. For example a heartbeat or CQ would start it's procedure, stop the waterfall like it normally should when transmitting, however the transmit on the rig wouldn't start until 5-10 seconds later, and by that point the waterfall had already started running again while it was still transmitting due to the delay.

I only had time to try my two builds, I'll try your patch changes a little later today to see if there's any different result. But at first glance it looks nearly identical to my hacked patch I described so I don't see why it would be any different. I also confirmed FLRig was working normally for other applications (wsjtx, direwolf) and had no issues with the delay.

Not sure what would cause that delay in communication. Tried resetting all of the js8call radio settings to see if that might fix it but no change. Maybe the QT SerialPort patches are causing the issue, not super sure. All builds, including the original hamlib3 version throw warnings around qt calls.

I've been poking around js8call groups.io to see any other threads about build issues or hamlib issues but not finding much other than those referencing 2.2.1-dev but it's not a proper tag in bitbucket and I don't see any real changes in the source for that commit. Bitbucket public is odd... private it's great just frustrating to see how different it is for consumers vs private orgs.

Any ideas?

[mattmelling]

The key is definitely to use the wsjtx hamlib fork. I got the same delay with js8call+flrig. Packaged the wsjtx hamlib fork and the delay is gone. I've pushed the latest changes up to #265897, let me know if you see any difference.