hamlib-developer — hamlib developers forum

Re: [Hamlib-developer] WSJT-X build error with latest hamlib version

[Nate B. <n0...@n0...>]

* On 2025 04 Aug 03:16 -0500, Uwe, DG2YCB via Hamlib-developer wrote:
> Hi Nate,
> 
> Yes, that broke it. According to my tests, changing “gcc-mingw” to “gcc” is
> sufficient to get it back working. It would be great if you could change
> your build scripts accordingly. Otherwise, we would have to see if we can
> add an exception rule for this in our file FindHamlib.cmake.

I've reverted the directory name change so it is just 'lib\gcc' now in
both builds.  That's not a deal breaker for me.  I'll be committing
those changes to Hamlib master at a later time as some other pull
requests are pending.

> Meanwhile, Roger has found a solution for line 336 of our
> HamlibTransceiver.cpp module. With this, WSJT-X compiles correctly again on
> both Linux and Windows, at least for me. Let's see if it is backward
> compatible with the older hamlib versions.
> 
> These two measures could therefore solve the problem. However, we still need
> to test all of this on the many other operating systems (and also with Qt6).
> Not that it still causes problems somewhere.

I would advise that you or someone on the main team subscribe to our
mailing list to see what we're discussing and committing to master.  We
do have a number of necessary changes that will be made after 4.7.0 is
released in preparation for the planned 5.0.0 release.

I realize what you're trying to achieve, but this is the dance card of
following a project on its development branch rather than stable
releases.  That said, I'd rather these issues be worked out sooner than
at the last minute, so thank you.  Welcome to the dance.  😉

73, Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819

Re: [Hamlib-developer] WSJT-X build error with latest hamlib version

[Uwe, D. <dg...@gm...>]

Hi Nate,

Yes, that broke it. According to my tests, changing “gcc-mingw” to “gcc” 
is sufficient to get it back working. It would be great if you could 
change your build scripts accordingly. Otherwise, we would have to see 
if we can add an exception rule for this in our file FindHamlib.cmake.

Meanwhile, Roger has found a solution for line 336 of our 
HamlibTransceiver.cpp module. With this, WSJT-X compiles correctly again 
on both Linux and Windows, at least for me. Let's see if it is backward 
compatible with the older hamlib versions.

These two measures could therefore solve the problem. However, we still 
need to test all of this on the many other operating systems (and also 
with Qt6). Not that it still causes problems somewhere.

In any case, thanks for your help and efforts!

73 de DG2YCB,
Uwe
________________________________________
German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg...@gm...
Info: www.qrz.com/db/DG2YCB


Am 03.08.2025 um 23:39 schrieb Nate Bargmann:
> I just double-checked and compared the Windows binary archives between
> the 4.6.4 release and 4.7~git.
>
> The only changes are:
>
> ~/tmp/hamlib-w64-4.6.4
> $ tree lib/
> lib/
> ├── gcc
> │   └── libhamlib.dll.a
> └── msvc
>      ├── libhamlib-4.def
>      └── libhamlib-4.lib
>
> 3 directories, 3 files
>
>
> ~/tmp/hamlib-w64-4.7~git
> $ tree lib/
> lib/
> ├── gcc-mingw
> │   ├── libhamlib-4.lib
> │   └── libhamlib.dll.a
> └── msvc
>      └── libhamlib-4.def
>
> 3 directories, 3 files
>
> If this is where the issue lies it should be possible to direct the
> build system to try one and then the other.  If this is not the issue,
> then I am at a loss at the moment.
>
> 73, Nate
>

Re: [Hamlib-developer] WSJT-X build error with latest hamlib version

[Nate B. <n0...@n0...>]

I just double-checked and compared the Windows binary archives between
the 4.6.4 release and 4.7~git.

The only changes are:

~/tmp/hamlib-w64-4.6.4 
$ tree lib/
lib/
├── gcc
│   └── libhamlib.dll.a
└── msvc
    ├── libhamlib-4.def
    └── libhamlib-4.lib

3 directories, 3 files


~/tmp/hamlib-w64-4.7~git 
$ tree lib/
lib/
├── gcc-mingw
│   ├── libhamlib-4.lib
│   └── libhamlib.dll.a
└── msvc
    └── libhamlib-4.def

3 directories, 3 files

If this is where the issue lies it should be possible to direct the
build system to try one and then the other.  If this is not the issue,
then I am at a loss at the moment.

73, Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819

Re: [Hamlib-developer] WSJT-X build error with latest hamlib version

[Nate B. <n0...@n0...>]

* On 2025 03 Aug 13:57 -0500, Uwe, DG2YCB wrote:
> Hi Nate, George, Roger and all,
> *
> 2. Nate's changes to his build environment.*
> Over the past few years, I have always used the binaries from
> https://n0nb.users.sourceforge.net/ to create the official Windows packages
> for WSJT-X and WSJT-X Improved. However, this no longer works because Hamlib
> can no longer be found with the module provided for this purpose in WSJT-X
> (/CMake/Modules/FindHamlib.cmake). That's very bad! All works well
> immediately if I go back to Hamlib 4.6.3.
> CMake Error at CMake/Modules/LibFindMacros.cmake:263 (message):
>   REQUIRED PACKAGE NOT FOUND
> 
>   We only found some files of Hamlib, not all of them.  Perhaps your
>   installation is incomplete or maybe we just didn't look in the right
> place?
>   This package is REQUIRED and you need to install it or adjust CMake
>   configuration in order to continue building wsjtx.
> 
>   Relevant CMake configuration variables:
> 
> Hamlib_INCLUDE_DIR=C:/JTSDK64-Tools/tools/hamlib/qt/5.12.12/include
> Usb_INCLUDE_DIR=C:/JTSDK64-Tools/tools/libusb/1.0.24/include/libusb-1.0
>     Hamlib_LIBRARY=<not found>

What specific file is being checked?

I did move just *one* file to s different location in the Windows binary
archive and that is libhamlib-4.lib which is now placed in the
lib/gcc-mingw directory of the archive.  This change was made on
recommendation of the MinGW project where their dlltool only creates a
.lib file suitable for use by MinGW's gcc.  Placing it in the msvc
directory was misleading to MSVC developers.  Now instructions have been
added to (hopefully) allow such developers to create their own .lib file
for use with MSVC/VS.

> Usb_LIBRARY=C:/JTSDK64-Tools/tools/hamlib/qt/5.12.12/bin/libusb-1.0.dll
> 
>   You may use CMake GUI, cmake -D or ccmake to modify the values. Delete
>   CMakeCache.txt to discard all values and force full re-detection if
>   necessary.
> 
> Call Stack (most recent call first):
>   CMake/Modules/FindHamlib.cmake:23 (libfind_process)
>   CMakeLists.txt:1009 (find_package)

Looking at:

https://sourceforge.net/p/wsjt/wsjtx/ci/master/tree/CMake/Modules/FindHamlib.cmake

I don't see what CMake is looking for that has changed in the archive.
It would be helpful to know exactly what file is being searched for as
the only one I see there is rig.h and it is in the same place.

73, Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819

Re: [Hamlib-developer] WSJT-X build error with latest hamlib version

[George B. <geo...@gm...>]

What error did you get when changing rig_get_conf to rig_get_conf2?  
rig_get_conf() has a serious problem in that it does no checking on the 
length of the output - rig_get_conf2 adds the length of the output 
buffer to the parameter list so no overrun.  It was added by Mike B. in 
Jan 2022, so I hope everyone has it by now.

73 n3gb

On 8/3/25 2:56 PM, Uwe, DG2YCB wrote:
> Hi Nate, George, Roger and all,
>
> Okay, let me summarize again the current situation:
> Today I noticed that the latest *Hamlib v4.7 is no longer* (fully) 
> *compatible with WSJT-X*. *This is a severe issue* for us, especially 
> since a new v3.0.0 is planned soon! The problems result from the 
> following two changes in Hamlib:
>
> *1. Hamlib commit 20eeb96:*
> These changes lead to an incompatibility with WSJTX module 
> HamlibTransceiver.cpp. On my Linux MInt 22.1 machine, it leads to the 
> following compilation error:
> [ 82%] Built target jt9
> [ 82%] Building CXX object 
> CMakeFiles/wsjt_qt.dir/Transceiver/HamlibTransceiver.cpp.o
> /home/uwe/jt/wsjtx/Transceiver/HamlibTransceiver.cpp: In member 
> function ‘QByteArray HamlibTransceiver::impl::get_conf(const char*)’:
> /home/uwe/jt/wsjtx/Transceiver/HamlibTransceiver.cpp:336:33: error: 
> ‘int rig_get_conf(RIG*, hamlib_token_t, char*)’ is deprecated 
> [-Werror=deprecated-declarations]
>   336 |       error_check (rig_get_conf (rig_.data (), token, 
> value.data ()), tr ("getting a configuration item"));
>       | ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> In file included from 
> /home/uwe/jt/wsjtx/Transceiver/HamlibTransceiver.cpp:15:
> /home/uwe/jt/hamlib/include/hamlib/rig.h:2971:1: note: declared here
>  2971 | rig_get_conf HAMLIB_PARAMS((RIG *rig,
>       | ^~~~~~~~~~~~
> Changing rig_get_conf to rig_get_conf2 in HamlibTransceiver.cpp 
> doesn't fix it, and changing the entire code would lead to loosing 
> backwards compatibility. Keep in mind, that it must also work with 
> macOS, Raspberry Pi 32-bit/64-bit, etc., and that not all these 
> systems offer the latest hamlib versions. Thus, loosing backwards 
> compatibility would end up in a mess!
>
> Compilation worked when I disabled the (red) line 336 in 
> HamlibTransceiver.cpp, however, at best, it's a poor workaround. And 
> who knows how it will behave on other operating systems when this line 
> is disabled.
> QByteArray HamlibTransceiver::impl::get_conf (char const * item)
> {
>   token_t token = rig_token_lookup (rig_.data (), item);
>   QByteArray value {128, '\0'};
>   if (RIG_CONF_END != token)    // only get if valid for rig model
>     {
> //      error_check (rig_get_conf (rig_.data (), token, value.data 
> ()), tr ("getting a configuration item"));
>     }
>   return value;
> }
> *
> 2. Nate's changes to his build environment.*
> Over the past few years, I have always used the binaries from 
> https://n0nb.users.sourceforge.net/ to create the official Windows 
> packages for WSJT-X and WSJT-X Improved. However, this no longer works 
> because Hamlib can no longer be found with the module provided for 
> this purpose in WSJT-X (/CMake/Modules/FindHamlib.cmake). That's very 
> bad! All works well immediately if I go back to Hamlib 4.6.3.
> CMake Error at CMake/Modules/LibFindMacros.cmake:263 (message):
>   REQUIRED PACKAGE NOT FOUND
>
>   We only found some files of Hamlib, not all of them.  Perhaps your
>   installation is incomplete or maybe we just didn't look in the right 
> place?
>   This package is REQUIRED and you need to install it or adjust CMake
>   configuration in order to continue building wsjtx.
>
>   Relevant CMake configuration variables:
>
> Hamlib_INCLUDE_DIR=C:/JTSDK64-Tools/tools/hamlib/qt/5.12.12/include
> Usb_INCLUDE_DIR=C:/JTSDK64-Tools/tools/libusb/1.0.24/include/libusb-1.0
>     Hamlib_LIBRARY=<not found>
> Usb_LIBRARY=C:/JTSDK64-Tools/tools/hamlib/qt/5.12.12/bin/libusb-1.0.dll
>
>   You may use CMake GUI, cmake -D or ccmake to modify the values.  Delete
>   CMakeCache.txt to discard all values and force full re-detection if
>   necessary.
>
> Call Stack (most recent call first):
>   CMake/Modules/FindHamlib.cmake:23 (libfind_process)
>   CMakeLists.txt:1009 (find_package)
>
> But also here: Any changes to the code used for years in WSJT-X will 
> most likely lead to chaos, because of the many OS and GCC versions the 
> users have, if we loose backwards compatibility.
>
> For testing purposes, I just compiled 64-bit binaries of the latest 
> Hamlib source code myself using the JTDSK64 kit. This worked and I was 
> able to compile WSJT-X 3.0.0 with it on Windows. At least that's 
> something. Strangely enough, the compilation error I encountered with 
> Linux did not occur there. But that shows us how different it can be. 
> I don't want to be confronted with hundreds of complaints from all 
> those people with their various RPi OSs or the different x86_64 or 
> M1/M2/M3 variants of macOS!
> But I also need 32-bit binaries for the 32-bit versions of WSJT-X and 
> WSJT-X Improved. Unfortunately, compiling with my JTSDK always leads 
> to errors when trying to compile 32-bit Hamlib binaries. It was so 
> nice that we could always use the reliable binaries from the 
> https://n0nb.users.sourceforge.net/ site. It would be very 
> disappointing if that were no longer possible in the future. This 
> complicates every new version of WSJT-X.
>
> *I sincerely hope that solutions can be found for the problems 
> identified.* I would really regret it if Hamlib were no longer 
> considered reliable enough in the future. Then we would have to 
> completely change course for WSJT-X in the long term when it comes to 
> CAT control.
>
> I would also greatly appreciate it if such serious changes in Hamlib 
> were coordinated with us WSJT-X developers beforehand. The repeated 
> Hamlib problems of recent years have already severely damaged its 
> reputation in the eyes of many. Of course, we always tried to argue it 
> away objectively. Unfortunately, there are few to no alternatives on 
> Linux and macOS. Therefore, I repeat my request: Please resolve these 
> issues so that WSJT-X can continue to use Hamlib for CAT control of 
> the rigs in the future.
>
> 73 de DG2YCB,
> Uwe
> ________________________________________
> German Amateur Radio Station DG2YCB
> Dr. Uwe Risse
> eMail: dg...@gm...
> Info: www.qrz.com/db/DG2YCB
>
>
> Am 03.08.2025 um 19:24 schrieb Nate Bargmann:
>> * On 2025 03 Aug 08:01 -0500, DG2YCB, Uwe wrote:
>>> Hi Roger, hi Nate,
>>>
>>> I have just tried to build WSJT-X on Linux with the latest Hamlib version
>>> 4.7~git-20250803-989623ec5, but it resulted in the build error listed below.
>>> It builds fine with Hamlib 4.6.3. Any idea where this new compilation error
>>> comes from?
>>>
>>> @Nate: Has anything been changed in Hamlib in this regard? Because we don't
>>> have anything changed in our WSJT-X code regarding Hamlib.
>> Yes, this commit by George:
>>
>> https://github.com/Hamlib/Hamlib/commit/20eeb96787a1e2dd67e158b52337f64ab47517e7
>>
>> This is in reference to Issue #924
>>
>> https://github.com/Hamlib/Hamlib/issues/924
>>
>>
>> Finally,  please do not email me only on questions like these.  Such
>> questions should be posted toh...@li...
>> that way all developers can be involved.  Unfortunately, I now have a
>> long thread in my mail box with questions I'm unable to answer directly
>> so get get suitable answers this should be reposted to our mailing list.
>>
>> Thank you.
>>
>> 73, Nate
>>
>

Re: [Hamlib-developer] Yaesu FTX-1

[Michael M. <cmo...@gm...>]

I figured out the issue.  I had to adjust FTX1_POST_WRITE_DELAY from 2 to 5

> On Aug 3, 2025, at 11:38 AM, Michael Morgan <cmo...@gm...> wrote:
> 
> I got my radio on Friday and just got around to tinkering with it today.  I’m not sure if someone else is working on this, but I saw the initial code was committed.  Initially when connecting to the rig I would get frequency but couldn’t change the frequency.  I found the issue with that.  But now for some reason it keeps just hanging at times.  Look at this debug - 4053ms when WSJT is setting the frequency.  I am using WSJT to test connection to a rigctld instance.  It don’t always do that just sometimes.  But often enough it is problematic. - Michael, AA5SH
> 
> write_block(): TX 3 bytes
> 0000    46 41 3b                                            FA;             
> read_string_generic(): RX 12 characters, direct=1
> 0000    46 41 30 31 38 31 30 30 30 35 35 3b                 FA018100055;    
> newcat_get_cmd: read count = 12, ret_data = FA018100055;
> *****5:newcat.c(11436):newcat_get_cmd returning(0) 
> newcat_get_freq: freq = 18100055 Hz for vfo VFOA
> ****4:newcat.c(1508):newcat_get_freq returning(0) 
> rig_get_band called
> ***3:rig_get_freq: elapsed=10ms
> rig_lock: client lock disengaged
> ***3:rig.c(2752):rig_get_freq returning(0) 
> newcat.c(1150)newcat_set_freq: checking VFOA for band change 
> newcat_band_index: freq=1.81e+07, band=6
> newcat_band_index: freq=1.81001e+07, band=6
> newcat_set_freq: VFO_A band changing=0
> newcat_valid_command BS
> newcat.c(8271):newcat_valid_command returning2(1) 
> newcat_set_freq: is_ft991=0, CACHE(rig)->split=0, vfo=VFOA
> newcat_set_freq:1398 cmd_str = FA018100000;
> ***3:newcat.c(11695):newcat_set_cmd entered
> cmd_str = FA018100000;
> ****4:newcat.c(11452):newcat_set_cmd_validate entered
> newcat_set_cmd_validate: priv->cmd_str=FA018100000;
> write_block(): TX 12 bytes
> 0000    46 41 30 31 38 31 30 30 30 30 30 3b                 FA018100000;    
> write_block(): TX 3 bytes
> 0000    46 41 3b                                            FA;             
> ****4:newcat.c(11630):newcat_set_cmd_validate returning(0) 
> newcat_set_cmd: cmd_validate OK
> ***3:newcat.c(11712):newcat_set_cmd returning(0) 
> newcat_band_index: freq=1.81e+07, band=6
> newcat_band_index: freq=1.81001e+07, band=6
> newcat_band_index: freq=1.81e+07, band=6
> newcat_band_index: freq=1.81001e+07, band=6
> newcat_set_freq: band changing? old=6, new=6
> **2:newcat.c(1424):newcat_set_freq returning(0) 
> rig_set_freq: vfo=VFOA, save=VFOA
> *1:rig_set_freq: elapsed=4053ms
> 
> 
> 

[Hamlib-developer] WSJT-X build error with latest hamlib version

[Uwe, D. <dg...@gm...>]

Hi Nate, George, Roger and all,

Okay, let me summarize again the current situation:
Today I noticed that the latest *Hamlib v4.7 is no longer* (fully) 
*compatible with WSJT-X*. *This is a severe issue* for us, especially 
since a new v3.0.0 is planned soon! The problems result from the 
following two changes in Hamlib:

*1. Hamlib commit 20eeb96:*
These changes lead to an incompatibility with WSJTX module 
HamlibTransceiver.cpp. On my Linux MInt 22.1 machine, it leads to the 
following compilation error:
[ 82%] Built target jt9
[ 82%] Building CXX object 
CMakeFiles/wsjt_qt.dir/Transceiver/HamlibTransceiver.cpp.o
/home/uwe/jt/wsjtx/Transceiver/HamlibTransceiver.cpp: In member function 
‘QByteArray HamlibTransceiver::impl::get_conf(const char*)’:
/home/uwe/jt/wsjtx/Transceiver/HamlibTransceiver.cpp:336:33: error: ‘int 
rig_get_conf(RIG*, hamlib_token_t, char*)’ is deprecated 
[-Werror=deprecated-declarations]
   336 |       error_check (rig_get_conf (rig_.data (), token, 
value.data ()), tr ("getting a configuration item"));
       | ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from 
/home/uwe/jt/wsjtx/Transceiver/HamlibTransceiver.cpp:15:
/home/uwe/jt/hamlib/include/hamlib/rig.h:2971:1: note: declared here
  2971 | rig_get_conf HAMLIB_PARAMS((RIG *rig,
       | ^~~~~~~~~~~~
Changing rig_get_conf to rig_get_conf2 in HamlibTransceiver.cpp doesn't 
fix it, and changing the entire code would lead to loosing backwards 
compatibility. Keep in mind, that it must also work with macOS, 
Raspberry Pi 32-bit/64-bit, etc., and that not all these systems offer 
the latest hamlib versions. Thus, loosing backwards compatibility would 
end up in a mess!

Compilation worked when I disabled the (red) line 336 in 
HamlibTransceiver.cpp, however, at best, it's a poor workaround. And who 
knows how it will behave on other operating systems when this line is 
disabled.
QByteArray HamlibTransceiver::impl::get_conf (char const * item)
{
   token_t token = rig_token_lookup (rig_.data (), item);
   QByteArray value {128, '\0'};
   if (RIG_CONF_END != token)    // only get if valid for rig model
     {
//      error_check (rig_get_conf (rig_.data (), token, value.data ()), 
tr ("getting a configuration item"));
     }
   return value;
}
*
2. Nate's changes to his build environment.*
Over the past few years, I have always used the binaries from 
https://n0nb.users.sourceforge.net/ to create the official Windows 
packages for WSJT-X and WSJT-X Improved. However, this no longer works 
because Hamlib can no longer be found with the module provided for this 
purpose in WSJT-X (/CMake/Modules/FindHamlib.cmake). That's very bad! 
All works well immediately if I go back to Hamlib 4.6.3.
CMake Error at CMake/Modules/LibFindMacros.cmake:263 (message):
   REQUIRED PACKAGE NOT FOUND

   We only found some files of Hamlib, not all of them.  Perhaps your
   installation is incomplete or maybe we just didn't look in the right 
place?
   This package is REQUIRED and you need to install it or adjust CMake
   configuration in order to continue building wsjtx.

   Relevant CMake configuration variables:

Hamlib_INCLUDE_DIR=C:/JTSDK64-Tools/tools/hamlib/qt/5.12.12/include
Usb_INCLUDE_DIR=C:/JTSDK64-Tools/tools/libusb/1.0.24/include/libusb-1.0
     Hamlib_LIBRARY=<not found>
Usb_LIBRARY=C:/JTSDK64-Tools/tools/hamlib/qt/5.12.12/bin/libusb-1.0.dll

   You may use CMake GUI, cmake -D or ccmake to modify the values. Delete
   CMakeCache.txt to discard all values and force full re-detection if
   necessary.

Call Stack (most recent call first):
   CMake/Modules/FindHamlib.cmake:23 (libfind_process)
   CMakeLists.txt:1009 (find_package)

But also here: Any changes to the code used for years in WSJT-X will 
most likely lead to chaos, because of the many OS and GCC versions the 
users have, if we loose backwards compatibility.

For testing purposes, I just compiled 64-bit binaries of the latest 
Hamlib source code myself using the JTDSK64 kit. This worked and I was 
able to compile WSJT-X 3.0.0 with it on Windows. At least that's 
something. Strangely enough, the compilation error I encountered with 
Linux did not occur there. But that shows us how different it can be. I 
don't want to be confronted with hundreds of complaints from all those 
people with their various RPi OSs or the different x86_64 or M1/M2/M3 
variants of macOS!
But I also need 32-bit binaries for the 32-bit versions of WSJT-X and 
WSJT-X Improved. Unfortunately, compiling with my JTSDK always leads to 
errors when trying to compile 32-bit Hamlib binaries. It was so nice 
that we could always use the reliable binaries from the 
https://n0nb.users.sourceforge.net/ site. It would be very disappointing 
if that were no longer possible in the future. This complicates every 
new version of WSJT-X.

*I sincerely hope that solutions can be found for the problems 
identified.* I would really regret it if Hamlib were no longer 
considered reliable enough in the future. Then we would have to 
completely change course for WSJT-X in the long term when it comes to 
CAT control.

I would also greatly appreciate it if such serious changes in Hamlib 
were coordinated with us WSJT-X developers beforehand. The repeated 
Hamlib problems of recent years have already severely damaged its 
reputation in the eyes of many. Of course, we always tried to argue it 
away objectively. Unfortunately, there are few to no alternatives on 
Linux and macOS. Therefore, I repeat my request: Please resolve these 
issues so that WSJT-X can continue to use Hamlib for CAT control of the 
rigs in the future.

73 de DG2YCB,
Uwe
________________________________________
German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg...@gm...
Info: www.qrz.com/db/DG2YCB


Am 03.08.2025 um 19:24 schrieb Nate Bargmann:
> * On 2025 03 Aug 08:01 -0500, DG2YCB, Uwe wrote:
>> Hi Roger, hi Nate,
>>
>> I have just tried to build WSJT-X on Linux with the latest Hamlib version
>> 4.7~git-20250803-989623ec5, but it resulted in the build error listed below.
>> It builds fine with Hamlib 4.6.3. Any idea where this new compilation error
>> comes from?
>>
>> @Nate: Has anything been changed in Hamlib in this regard? Because we don't
>> have anything changed in our WSJT-X code regarding Hamlib.
> Yes, this commit by George:
>
> https://github.com/Hamlib/Hamlib/commit/20eeb96787a1e2dd67e158b52337f64ab47517e7
>
> This is in reference to Issue #924
>
> https://github.com/Hamlib/Hamlib/issues/924
>
>
> Finally,  please do not email me only on questions like these.  Such
> questions should be posted toh...@li...
> that way all developers can be involved.  Unfortunately, I now have a
> long thread in my mail box with questions I'm unable to answer directly
> so get get suitable answers this should be reposted to our mailing list.
>
> Thank you.
>
> 73, Nate
>

[Hamlib-developer] Yaesu FTX-1

[Michael M. <cmo...@gm...>]

I got my radio on Friday and just got around to tinkering with it today.  I’m not sure if someone else is working on this, but I saw the initial code was committed.  Initially when connecting to the rig I would get frequency but couldn’t change the frequency.  I found the issue with that.  But now for some reason it keeps just hanging at times.  Look at this debug - 4053ms when WSJT is setting the frequency.  I am using WSJT to test connection to a rigctld instance.  It don’t always do that just sometimes.  But often enough it is problematic. - Michael, AA5SH

write_block(): TX 3 bytes
0000    46 41 3b                                            FA;             
read_string_generic(): RX 12 characters, direct=1
0000    46 41 30 31 38 31 30 30 30 35 35 3b                 FA018100055;    
newcat_get_cmd: read count = 12, ret_data = FA018100055;
*****5:newcat.c(11436):newcat_get_cmd returning(0) 
newcat_get_freq: freq = 18100055 Hz for vfo VFOA
****4:newcat.c(1508):newcat_get_freq returning(0) 
rig_get_band called
***3:rig_get_freq: elapsed=10ms
rig_lock: client lock disengaged
***3:rig.c(2752):rig_get_freq returning(0) 
newcat.c(1150)newcat_set_freq: checking VFOA for band change 
newcat_band_index: freq=1.81e+07, band=6
newcat_band_index: freq=1.81001e+07, band=6
newcat_set_freq: VFO_A band changing=0
newcat_valid_command BS
newcat.c(8271):newcat_valid_command returning2(1) 
newcat_set_freq: is_ft991=0, CACHE(rig)->split=0, vfo=VFOA
newcat_set_freq:1398 cmd_str = FA018100000;
***3:newcat.c(11695):newcat_set_cmd entered
cmd_str = FA018100000;
****4:newcat.c(11452):newcat_set_cmd_validate entered
newcat_set_cmd_validate: priv->cmd_str=FA018100000;
write_block(): TX 12 bytes
0000    46 41 30 31 38 31 30 30 30 30 30 3b                 FA018100000;    
write_block(): TX 3 bytes
0000    46 41 3b                                            FA;             
****4:newcat.c(11630):newcat_set_cmd_validate returning(0) 
newcat_set_cmd: cmd_validate OK
***3:newcat.c(11712):newcat_set_cmd returning(0) 
newcat_band_index: freq=1.81e+07, band=6
newcat_band_index: freq=1.81001e+07, band=6
newcat_band_index: freq=1.81e+07, band=6
newcat_band_index: freq=1.81001e+07, band=6
newcat_set_freq: band changing? old=6, new=6
**2:newcat.c(1424):newcat_set_freq returning(0) 
rig_set_freq: vfo=VFOA, save=VFOA
*1:rig_set_freq: elapsed=4053ms

[Hamlib-developer] [Hamlib/Hamlib] f8c3d6: Fix error messages

[Nate B. <no...@gi...>]

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: f8c3d6b614597b8cc24c3b443a9fd1984ebf16a6
      https://github.com/Hamlib/Hamlib/commit/f8c3d6b614597b8cc24c3b443a9fd1984ebf16a6
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-07-28 (Mon, 28 Jul 2025)

  Changed paths:
    M simulators/simyaesu.c

  Log Message:
  -----------
  Fix error messages


  Commit: 5f78c54bae8502b3ec1e0f1c43643b7857b6e62f
      https://github.com/Hamlib/Hamlib/commit/5f78c54bae8502b3ec1e0f1c43643b7857b6e62f
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-07-30 (Wed, 30 Jul 2025)

  Changed paths:
    M rigs/gomspace/gs100.c
    M src/register.c

  Log Message:
  -----------
  Remove DECLARE_INITRIG_BACKEND()

Breaks rig_probe() for rigs probed later (eg. Kenwood).


  Commit: 6af3b3a94e55d69aad55f4a36818f41dec0aef05
      https://github.com/Hamlib/Hamlib/commit/6af3b3a94e55d69aad55f4a36818f41dec0aef05
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-07-30 (Wed, 30 Jul 2025)

  Changed paths:
    M rigs/commradio/commradio.c
    M src/register.c

  Log Message:
  -----------
  Remove DECLARE_INITRIG_BACKEND()

This code is uneeded.


  Commit: 200b2aaecc89cfcfdce416d7f7a9439bd8758c2b
      https://github.com/Hamlib/Hamlib/commit/200b2aaecc89cfcfdce416d7f7a9439bd8758c2b
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-07-30 (Wed, 30 Jul 2025)

  Changed paths:
    M simulators/simelecraft.c
    M simulators/simelecraftk4.c
    M simulators/simkenwood.c
    M simulators/simpowersdr.c
    M simulators/simtmd700.c
    M simulators/simtmd710.c

  Log Message:
  -----------
  Remove unneeded typedef

It's only used by Yeasu simulators.


  Commit: 094b5e741a63c7310983ee6e77da6d46de73c819
      https://github.com/Hamlib/Hamlib/commit/094b5e741a63c7310983ee6e77da6d46de73c819
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-07-30 (Wed, 30 Jul 2025)

  Changed paths:
    M simulators/simic7000.c
    M simulators/simtmd710.c

  Log Message:
  -----------
  Remove unused variables


  Commit: 0c57ccad264d0f1b54a943795ab47ac199a08f27
      https://github.com/Hamlib/Hamlib/commit/0c57ccad264d0f1b54a943795ab47ac199a08f27
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-07-30 (Wed, 30 Jul 2025)

  Changed paths:
    M simulators/Makefile.am

  Log Message:
  -----------
  Add missing include file

Otherwise it isn't added to the distribution archive created by
"make distcheck".


  Commit: b4eb1bdb12bd475927ec1c05d25a539eae5fa3df
      https://github.com/Hamlib/Hamlib/commit/b4eb1bdb12bd475927ec1c05d25a539eae5fa3df
  Author: Nate Bargmann <n0...@n0...>
  Date:   2025-08-01 (Fri, 01 Aug 2025)

  Changed paths:
    M rigs/kenwood/kenwood.c

  Log Message:
  -----------
  Quell warning from clang

This warning was seen on MacOS and on Debian 12 and 13 using clang:

CC       kenwood.lo
kenwood.c:2293:9: warning: absolute value function 'abs' given an argument of type 'shortfreq_t' (aka 'long') but has parameter of type 'int' which may cause truncation of value [-Wabsolute-value]
 2293 |     if (abs(rit) > 9999) { RETURNFUNC(-RIG_EINVAL); }
      |         ^
kenwood.c:2293:9: note: use function 'labs' instead
 2293 |     if (abs(rit) > 9999) { RETURNFUNC(-RIG_EINVAL); }
      |         ^~~
      |         labs
1 warning generated.

Closes issue #1806 on GitHub


  Commit: 989623ec511e6f428aa8998e88df3f69f9e11d79
      https://github.com/Hamlib/Hamlib/commit/989623ec511e6f428aa8998e88df3f69f9e11d79
  Author: Nate Bargmann <n0...@n0...>
  Date:   2025-08-01 (Fri, 01 Aug 2025)

  Changed paths:
    M rigs/commradio/commradio.c
    M rigs/gomspace/gs100.c
    M simulators/Makefile.am
    M simulators/simelecraft.c
    M simulators/simelecraftk4.c
    M simulators/simic7000.c
    M simulators/simkenwood.c
    M simulators/simpowersdr.c
    M simulators/simtmd700.c
    M simulators/simtmd710.c
    M simulators/simyaesu.c
    M src/register.c

  Log Message:
  -----------
  Merge GitHub PR #1824


Compare: https://github.com/Hamlib/Hamlib/compare/a9ecd503294b...989623ec511e

To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications

[Hamlib-developer] [Fwd: Re: RFC #1588--Icom echo code]

[Nate B. <n0...@n0...>]

----- Forwarded message from Sakari Nylund <sak...@ni...> -----

Date: Fri, 1 Aug 2025 17:42:53 +0300
From: Sakari Nylund <sak...@ni...>
To: Nate Bargmann <n0...@n0...>
Reply-To: sak...@ni...
Subject: Re: [Hamlib-developer] RFC #1588--Icom echo code
User-Agent: Mozilla Thunderbird

I think he meant detection of rig setting TRN  (Tranceive) ON/OFF what ICOM is
using to echo the received command back to CI-V bus.

With my rigctld Hamlib 4.7~git 2025-06-09T09:26:07Z SHA=93434b 64-bit  it
seems still to be allergic to Tranceive ON setting (IC7300)  at least when
polling faster than 1000ms. So better to keep it OFF state always either there
is echo detection or not.

-- 
Saku
OH1KH

Nate Bargmann kirjoitti 1.8.2025 klo 2.36:
> https://github.com/Hamlib/Hamlib/issues/1588
> 
> Icom echo is now dynamically detected in frame.c
> We can remove the echo off testing elsewhere
> 
> -------------
> 
> I've no idea what Mike was talking about here.
> 
> 73, Nate
> 
> 
> 
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer

----- End forwarded message -----

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819

[Hamlib-developer] [Hamlib/Hamlib] a9ecd5: Sanitize radio model names and manufacturers

[Nate B. <no...@gi...>]

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: a9ecd503294b60aed1874cd962c23a9655f3432d
      https://github.com/Hamlib/Hamlib/commit/a9ecd503294b60aed1874cd962c23a9655f3432d
  Author: Nate Bargmann <n0...@n0...>
  Date:   2025-08-01 (Fri, 01 Aug 2025)

  Changed paths:
    M rigs/dummy/flrig.c
    M rigs/dummy/gqrx.c
    M rigs/kenwood/flex6xxx.c
    M rigs/yaesu/ft1000mp.c

  Log Message:
  -----------
  Sanitize radio model names and manufacturers

Reference GitHub issue #1013.



To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications

Re: [Hamlib-developer] Old issues in the GitHub issue tracker

[Nate B. <n0...@n0...>]

I've completed wading through the list and adding the "type" flag to all
open issues.  Along the way I was able to pare the list down to 174.
Still about 150 more than I would like to see, but, oh well.

The biggest group by far is the Feature type at 122 while the Bug type
are at 49.  I placed the Release Goals issues into the Tasks category.

I presume that bug hunters can more easily get a list of bugs to work on
and those looking for a challenge can investigate the Features category.
Mike opened enough issues that are an enhancement to keep us busy for
years to come.  Some are clearly wishlist items while others should be
considered seriously.  A few of the ones he gave the label "Enhancement"
I classified as a Bug as it seemed to me they fall more into that
category although it would be new code.

Anyway, I hope this effort proves fruitful.  🤔

73, Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819

[Hamlib-developer] RFC #1588--Icom echo code

[Nate B. <n0...@n0...>]

https://github.com/Hamlib/Hamlib/issues/1588

Icom echo is now dynamically detected in frame.c
We can remove the echo off testing elsewhere

-------------

I've no idea what Mike was talking about here.

73, Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819

Re: [Hamlib-developer] RFC #1353--PARM_BAND_SELECT

[George B. <geo...@gm...>]

This seems to vary by manufacturer - many references in rigs/yaesu/, a 
few in rigs/icom/, only flex6xxx in rigs/kenwood/ and nothing else.  
Still more work to do.


On 7/30/25 10:47 PM, Nate Bargmann wrote:
> https://github.com/Hamlib/Hamlib/issues/1353
>
> Implement PARM_BAND_SELECT for Icom and Kenwood rigs
>
> 0x1a 0x01 for Icom rigs (7300).
>
> ----------
>
> Mike included three commits that referenced this issue:
>
> Add parm BANDSELECT for Yaesu rigs      ...  d7d450d
> Fill out BANDSELECT frequency table     ...  1f50b88
> Add BANDSELECT to PowerSDR              ...  fb3d83a
>
> ----------
>
> I'm not sure if this is complete.
>
> 73, Nate
>
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer

[Hamlib-developer] RFC #1353--PARM_BAND_SELECT

[Nate B. <n0...@n0...>]

https://github.com/Hamlib/Hamlib/issues/1353

Implement PARM_BAND_SELECT for Icom and Kenwood rigs

0x1a 0x01 for Icom rigs (7300).

----------

Mike included three commits that referenced this issue:

Add parm BANDSELECT for Yaesu rigs      ...  d7d450d
Fill out BANDSELECT frequency table     ...  1f50b88
Add BANDSELECT to PowerSDR              ...  fb3d83a

----------

I'm not sure if this is complete.

73, Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819

[Hamlib-developer] RFC #1019--enum meter_level_e needs to be removed

[Nate B. <n0...@n0...>]

https://github.com/Hamlib/Hamlib/issues/1019

It's only used in two rigs and has been replaced by individual meter calls

find . -name "*.c" -exec grep RIG_METER {} \; -print
        case RIG_METER_SWR:
        case RIG_METER_COMP:
        case RIG_METER_ALC:
            val->i = RIG_METER_SWR;
            val->i = RIG_METER_COMP;
            val->i = RIG_METER_ALC;
            val->i = RIG_METER_NONE;
./rigs/kenwood/ts480.c
        case '1': val->i = RIG_METER_ALC; break;
        case '2': val->i = RIG_METER_SWR; break;
        case '3': val->i = RIG_METER_COMP; break;
        case '4': val->i = RIG_METER_IC; break;
        case '5': val->i = RIG_METER_VDD; break;
        default: val->i = RIG_METER_NONE; break;
./rigs/kenwood/ts990s.c
        case RIG_METER_ALC: SNPRINTF(priv->cmd_str, sizeof(priv->cmd_str), format, 1);
        case RIG_METER_PO:
        case RIG_METER_SWR:  SNPRINTF(priv->cmd_str, sizeof(priv->cmd_str), format, 3);
        case RIG_METER_COMP: SNPRINTF(priv->cmd_str, sizeof(priv->cmd_str), format, 0);
        case RIG_METER_IC:   SNPRINTF(priv->cmd_str, sizeof(priv->cmd_str), format, 4);
        case RIG_METER_VDD:  SNPRINTF(priv->cmd_str, sizeof(priv->cmd_str), format, 5);
            if (tuner && meter.i != RIG_METER_SWR)
                     && meter.i == RIG_METER_SWR) ? '2' : '6',
        case '0': val->i = RIG_METER_COMP; break;
        case '1': val->i = RIG_METER_ALC; break;
        case '2': val->i = RIG_METER_PO; break;
        case '3': val->i = RIG_METER_SWR; break;
        case '4': val->i = RIG_METER_IC; break;     /* ID CURRENT */
        case '5': val->i = RIG_METER_VDD; break;    /* Final Amp Voltage */
./rigs/yaesu/newcat.c

-----------------

Turns out Mike truncated the output from newcat.c so it's likely that more 
radio backends depend on this enumeration.  Also not shown is that the
ts2000.c file contains these values as well.

If the enum values can be replaced by better functions, then that should
be the path to take.

73, Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819

Re: [Hamlib-developer] RFC #1018--conditional builds for radio classes

[George B. <geo...@gm...>]

I might consider it, but not any time soon.  I only have 1 radio (plus 
the dummys) so it might be worth it since I seem to do a lot of compiles 
:-(  Maybe a "sorta interesting project"

On 7/30/25 7:51 PM, Nate Bargmann wrote:
> https://github.com/Hamlib/Hamlib/issues/1018
>
> Concept is:
>
> ./configure --with-yaesu --with-icom
>
> Which would build the main parts required by all and only radio types in
> the yaesu and icom radio classes.
>
> Hamlib takes an eternity to build (particularly on an SOC) and most
> users have one or two brands of radios and don't need all the rest.
>
> Also, consider --with-rotator, --with-antenna for those who need them,
> and then the rest of us can avoid the 'noid.
>
> I don't expect any feedback. I figure if you find the idea worth doing,
> you'll just do it. ;)
>
> ---------
>
> My opinion is that with 40 radio backends at present that this might
> exceed the command line limit on some OS.  I can appreciate the idea and
> especially the long compile time on an SOC, but most will use a
> distribution's precompiled package (Linux).  The gain seems minimal for
> the pain.
>
> 73, Nate
>
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer

[Hamlib-developer] RFC #1018--conditional builds for radio classes

[Nate B. <n0...@n0...>]

https://github.com/Hamlib/Hamlib/issues/1018

Concept is:

./configure --with-yaesu --with-icom

Which would build the main parts required by all and only radio types in
the yaesu and icom radio classes.

Hamlib takes an eternity to build (particularly on an SOC) and most
users have one or two brands of radios and don't need all the rest.

Also, consider --with-rotator, --with-antenna for those who need them,
and then the rest of us can avoid the 'noid.

I don't expect any feedback. I figure if you find the idea worth doing,
you'll just do it. ;)

---------

My opinion is that with 40 radio backends at present that this might
exceed the command line limit on some OS.  I can appreciate the idea and
especially the long compile time on an SOC, but most will use a
distribution's precompiled package (Linux).  The gain seems minimal for
the pain.

73, Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819

Re: [Hamlib-developer] RFC #807--Change rig ptr checks to function to check valid rig ptr in list

[George B. <geo...@gm...>]

I think the first half of this is done - rig_open() builds a list of 
opened rig_structs, but nobody checks it on each rig_*() call. Overhead 
problem?

On 7/30/25 6:55 PM, Nate Bargmann wrote:
> https://github.com/Hamlib/Hamlib/issues/807
>
> Requires adding a linked list and inserting the rig ptr during open and
> removing it during close.
>
> Replaces #785[1]
>
> ---------
>
> 73, Nate
>
> [1] https://github.com/Hamlib/Hamlib/issues/785
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer

[Hamlib-developer] RFC #807--Change rig ptr checks to function to check valid rig ptr in list

[Nate B. <n0...@n0...>]

https://github.com/Hamlib/Hamlib/issues/807

Requires adding a linked list and inserting the rig ptr during open and
removing it during close.

Replaces #785[1]

---------

73, Nate

[1] https://github.com/Hamlib/Hamlib/issues/785
-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819

Re: [Hamlib-developer] RFC #674--simicom improvements

[Nate B. <n0...@n0...>]

* On 2025 30 Jul 17:26 -0500, George Baltz wrote:
> I think this one was directed more towards making a generic Iom simulator
> where you could pick-and-choose which features were present in any Icom
> rig.  I think this might be what simicgeneric.c was supposed to be.
> 
> I did a little of this when I was hacking on simic705.c about a month ago,
> but didn't follow through.
> 
> This might go in the "interesting projects" category.

Another label type!

Rushes off...

73, Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819

Re: [Hamlib-developer] RFC #674--simicom improvements

[George B. <geo...@gm...>]

I think this one was directed more towards making a generic Iom 
simulator where you could pick-and-choose which features were present in 
any Icom rig.  I think this might be what simicgeneric.c was supposed to be.

I did a little of this when I was hacking on simic705.c about a month 
ago, but didn't follow through.

This might go in the "interesting projects" category.


On 7/30/25 6:11 PM, Nate Bargmann wrote:
> https://github.com/Hamlib/Hamlib/issues/674
>
> Improve simicom to emulate all Icom rigs by command line options.
> satmode, 0x25/0x26 command,
> Also get it working on Windows.
>
> ---------------
>
> This is one of those that may have fallen through the cracks insofar as
> getting updated/closed.  It's possible that these commands are working.
> Or not.
>
> 73, Nate
>
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer

[Hamlib-developer] RFC #674--simicom improvements

[Nate B. <n0...@n0...>]

https://github.com/Hamlib/Hamlib/issues/674

Improve simicom to emulate all Icom rigs by command line options.
satmode, 0x25/0x26 command,
Also get it working on Windows.

---------------

This is one of those that may have fallen through the cracks insofar as
getting updated/closed.  It's possible that these commands are working.
Or not.

73, Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819

[Hamlib-developer] RFC #661--Remove usrp and gnuradio support

[Nate B. <n0...@n0...>]

https://github.com/Hamlib/Hamlib/issues/661

The rig model USRP0 & USRP should be removed, as well as any GNURADIO
code.

The actual code is using a deprecated library (libusrp), and is a
maintenance burden for no use (e.g. #355).
The extra/gnuradio is not maintained anymore, and such features are
generally implemented in a separate SDR application.

Should USRP support be wanted, it's better to rewrite support for UHD[1]
which is more versatile anyway.

--------------

73, Nate

[1] https://github.com/EttusResearch/uhd

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819

[Hamlib-developer] RFC #498

[Nate B. <n0...@n0...>]

This will be the first of  a number of followups in this thread where I
will request comments on a specific issue.  First up is issue 498 that
concerns replacing the ITU frequency ranges with more generic frequency
ranges in the backends:

https://github.com/Hamlib/Hamlib/issues/498

73, Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819