HAMLIB returns inconsistent information from FLRig

[VK5PJ Peter Sumner]

Hello,
when client software initially queries HAMLIB for a list of rigs (in my
case WSJT-X), the entry for FLRig was originally returned as "FLRig FLRig"
and this remained consistent across time.
Then at some point in the DEV cycle the list of rigs went to having an
entry as "Flrig " (note the space) but when it was selected and queried
again, the name changed dynamically to include the model of the RIG being
reported by FLRig to Hamlib. Then you end up with a radio type of "FLRig
IC-7610(FLRig)".

In the case of WSJT-X it uses this new string to write the "Rig=" data
to it's INI file as this NEW value, which seems to be innocent enough until
you restart WSJT-X and it does its initial query of Hamlib, which returns
"FLRig " and cannot match the information it has read from the INI file,
this then triggers an error state at startup reporting a HAMLIB error.

Is there any way for a setting in a JSON file to be enabled to instruct
HAMLIB not to read the extra data from FLRig so the rig type always remains
the same at all times?

I am not calling this a bug as I am sure someone wanted this
extra information for a particular reason so I will not ask for its removal
but a way to negate it for WSJT-X users like myself.

I do note the release of Hamlib from early August have updated the entry
for FLRig to be W1JHK FLRig but this entry still dynamically changes to
include the RIG type reported by FLRig

Hoping there is an answer out there as I am stuck using a quite old version
of HAMLIB until I can find the answer.
Regards,
Peter, vk5pj

[VK5PJ Peter Sumner]

As a side note,
I realise this behaviour only really relates to a very small number of
users (less than 0.5 %) and I am probably the squeaky wheel for this
situation. This is why I thought a setting in a hamlib.json file might be a
suitable solution.
Peter, vk5pj

On Tue, Aug 12, 2025 at 7:41 AM VK5PJ Peter Sumner vk5pj@users.sourceforge.net wrote:

Hello,
when client software initially queries HAMLIB for a list of rigs (in my
case WSJT-X), the entry for FLRig was originally returned as "FLRig FLRig"
and this remained consistent across time.
Then at some point in the DEV cycle the list of rigs went to having an
entry as "Flrig " (note the space) but when it was selected and queried
again, the name changed dynamically to include the model of the RIG being
reported by FLRig to Hamlib. Then you end up with a radio type of "FLRig
IC-7610(FLRig)".

In the case of WSJT-X it uses this new string to write the "Rig=" data
to it's INI file as this NEW value, which seems to be innocent enough until
you restart WSJT-X and it does its initial query of Hamlib, which returns
"FLRig " and cannot match the information it has read from the INI file,
this then triggers an error state at startup reporting a HAMLIB error.

Is there any way for a setting in a JSON file to be enabled to instruct
HAMLIB not to read the extra data from FLRig so the rig type always remains
the same at all times?

I am not calling this a bug as I am sure someone wanted this
extra information for a particular reason so I will not ask for its removal
but a way to negate it for WSJT-X users like myself.

I do note the release of Hamlib from early August have updated the entry
for FLRig to be W1JHK FLRig but this entry still dynamically changes to
include the RIG type reported by FLRig

Hoping there is an answer out there as I am stuck using a quite old version
of HAMLIB until I can find the answer.
Regards,
Peter, vk5pj

---

HAMLIB returns inconsistent information from FLRig
https://sourceforge.net/p/hamlib/discussion/25919/thread/34d98c5c7b/?limit=25#2447

---

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/hamlib/discussion/25919/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/