Hello, it seems users of FLRIg and WSJT-X / Improved are not too common, what I have found so far is, when WSJT-X starts, it queries the list of rigs from the HAMLIB DLL (lib-hamlib-4.dll) to create its rig list. This list of rigs appears to be a dynamic array as when HAMLIB finds any updated information it then presents that updated information to WSJT-X and the list of rigs when the pulldown list is viewed next.
In WSJT-X 2.61 and before, the HAMLIB DLL that is part of the package provides only the 'basic' information from FLRig and in this way provides a stable RigName during use in the lrig list and in the WSJT-X.INI file. This version from WSJT-X v2.61 shows up as being: "HamLib 4.5~git Mon Jun 13 14:51:03 2022" At some point HAMLIB was changed to pass through extra information from FLRig, in this case it is the type of Rig that FLRig is connected to that is now passed through to WSJT-X. In my case, it is an Icom IC-7610. Initially the list of Rig types has a Rig type of "FLRig FLRig" in the earlier version of the DLL that came with WSJT-X 2.61 but the Release candidates of WSJT-X v2.7x all came with an updated HAMLIB that includes the extra information being passed through to it and ultimately defective for WSJT-X user that have FLRig in use. I have had a response from one of the HAMLIB team (Nate N0NB) that he had an update in play to correct the name for FLRig in the list to be: Manufacturer to "W1HJK" and the Model to "FLrig". which means all new HAMLIB DLL's with have the entry for FLRig as "WIHJK FLRig" Unfortunately this is just a cosmetic change for my needs as even this new DLL still gets the actual name of the Rig from FLFRig and dynamically changes the list from this: "W1HKJ FLRig" to this: "W1HKJ IC-7610(FLRig)" One could say this is all just cosmetic BUT the information in the Rig List is used to write data into the WSJT-X.INI for the next startup or to define other WSJT-X configurations. This then means what rig type in the INI file does not match the initial list of rigs queried from HAMLIB and then WSJT-X has a hissy fit and I get a world of hurt. For 99.9% of you, this probably will never happen but for me it's chaos. I can avoid all this by replacing the lib-hamlib-4.dll file with an older one each time WSJT-X gets an update but eventually there will be a critical change that stops me doing this. While this is primarily not a WSJT-X error and seems to live in the HAMLIB arena, I thought I would round out this topic as this is where it started and will pursue this with the HAMLIB team via their 'sourceforge' help forum. Regards, Peter, vk5pj
_______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
