hamlib-developer — hamlib developers forum

[Hamlib-developer] serial_setup: tcsetattr failed: No error

[<fam...@ao...>]

Hello,

 

There's a problem with Hamlib w64-4.6.2. The serial port is recognized but not working. I get this message:

 

C:\Program Files\hamlib-w64-4.6.2\bin>rotctld.exe -m 202 -r COM4 -s 9600 -T 127.0.0.1 -t 4533 -vvv

serial_setup: tcsetattr failed: No error

rot_open: error = Report bugs to < <mailto:ham...@li...> ham...@li...>

 

rot_init called

initrots4_easycomm called

rot_register (201)

rot_register (202)

rot_register (204)

rot_open called

serial_open: serial port COM4 is OK

serial_open: COM4

serial_setup: tcgetattr

serial_setup: cfsetispeed=9600,0x000d

serial_setup: cfsetospeed=9600,0x000d

serial_setup: data_bits=8

serial_setup: stopbits=1

serial_setup: parity=0

serial_setup: Handshake=None

serial_setup: tcsetattr TCSANOW

serial_setup: tcsetattr failed: No error

Invalid configuration

 

 

C:\Program Files\hamlib-w64-4.6.2\bin>

 

Nom de l'appareil DESKTOP-3HCNLPN

Processeur  Intel(R) Core(TM) i7-8665U CPU @ 1.90GHz   2.11 GHz

Mémoire RAM installée   16,0 Go (15,8 Go utilisable)

ID de périphérique      1D549E56-3766-44B9-9743-889BF51E8248

ID de produit     00330-53173-72831-AAOEM

Type du système   Système d’exploitation 64 bits, processeur x64

Stylet et fonction tactile    Prise en charge du stylet et de la fonction tactile avec 10 points de contact

 

Édition     Windows 11 Professionnel

Version     24H2

Installé le ‎29/‎01/‎2025

Build du système d’exploitation     26100.4061

Expérience  Pack d’expérience de fonctionnalités Windows 1000.26100.84.0

 

Best regards,

 

Alain

 

[Hamlib-developer] Bandwidths and Filters

[Stefan J. <DK...@da...>]

Hi dear hamlib experts,

Sorry for my maybe stupid question. But I have to say that I am not familiar with the internals ofhamlib, I am only using it to develop some rig control software. :-)

When I look at the output of the rigctl —dump-caps option for my Elecraft KX2 transceiver, I can see that hamlib seems to support setting filters and bandwidths. Yes, I know that my KX2 has some predefined filters, for example the audio peek filter APF. And I can apply change the center frequency and bandwidth of the IF passband. That’s fine.

But what about the bandwidth? I suppose that the bandwidth should affect the HF signal when transmitting and should also affect demodulation. So for CW, I find bandwidths of 600Hz (normal), 300Hz (narrow) and 2400Hz (wide). But I never found a way to control the bandwidth from the keys and knobs of the KX2 itself.

Does anybody know what hamlib does to set this? Or how I could figure out? I guess without knowing anything about the structure of hamlib backends I might get stuck without any hints where to get started.



Vy 73 de Stefan, DK7STJ

--
Stefan Jansen    ***    E-Mail: DK...@da...

[Hamlib-developer] Python bindings and tests

[Daniele F. <iu...@gm...>]

Hello,

I'm working on using the Python bindings to add regression tests to
Hamlib. While adding proper unit tests would be nice, we would still
need to test all language bindings, so using the bindings allows us to
also test some parts of Hamlib.

The first step is creating tests to document the current behavior of
the Dummy backends and in future detect regressions:
https://github.com/Hamlib/Hamlib/pull/1726
It is mostly ready for Hamlib 4.7.0 but I might still rebase and/or
force push and there are 2 functions that need fixing.
This has shown a bug (PR #1727) and a missing check for NULL (first
commit of PR #176)) so it has been useful.

The next step could be modifying the bindings that currently are void
functions (which means return None to Python callers) to return
RIG_OK/RIG_E* as appropriate. This could also be for 4.7.0 because it
is backward compatible if we keep the rig_error property.

There are open issues about adding some functionality (to Python),
these could go in Hamlib 4.8.0.

Then the bindings could be changed to be more Pythonic or maybe the
other language bindings could need changes.

Comments and opinions are welcome. Do you know of other projects that
have language bindings that could serve as an example?

-- 
73 de IU5HKX Daniele

Re: [Hamlib-developer] Issue with latest pull and building WSJT-X 2.7.0 [ clock_gettime64 could not be located in the DLL ]

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

* On 2025 19 May 10:17 -0500, George Baltz wrote:
> I noticed 'Build_OS is mingw32' yet something is looking for a 64 bit
> routine. Is that OK?

When I do a DDG for clock_gettime64 the first hit is:

https://www.gnu.org/software/libc/manual/html_node/64_002dbit-time-symbol-handling.html

I wonder if this is some sort of macro that MSYS2 is looking for?  Or,
that MinGW supplies from the C library.

Using objdump on an older 64 bit DLL I get:

$ objdump -p libhamlib-4.dll | grep clock_gettime
	bae924	   13  clock_gettime

And on today's 32 bit DLL:

$ objdump -p libhamlib-4.dll | grep clock_gettime
	a6823c	   13  clock_gettime

Searching for clock_gettime64 in either file returned zero results each.

Undoubtedly this has to do with Y2038 mitigation.

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] Issue with latest pull and building WSJT-X 2.7.0 [ clock_gettime64 could not be located in the DLL ]

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

I noticed 'Build_OS is mingw32' yet something is looking for a 64 bit 
routine. Is that OK?

On 5/19/25 8:59 AM, Nate Bargmann wrote:
> * On 2025 19 May 07:38 -0500, Hamlib Developer wrote:
>> Hi Folks,
>>
>> An issue has been encountered with Hamlib pulled from master as of UTC
>> 2025-05-18 @ 08:00:00 .
>>
>> The development environment is a fully clean and deployed JTSDK
>> 4.0.1u1 (see https://sourceforge.net/projects/hamlib-sdk/ ) and has
>> worked perfectly up until the time that Mike W9MDB became SK (and of
>> course he is therefore of no help to us now ☹)
>>
>> “Fully updated” means that the deployed MSYS2 environment is FULLY
>> updated with pacman -Syuu,
>>
>> LibUSB is the supplied 1.0.28 version that is known to work, and a
>> known-to-work Boost 1.88.0 environment has also been deployed with the
>> kit. The Qt environ is publicly-available Qt version being Qt 5.15.2.
>>
>> These are known facts:
>>
>>    *   Hamlib pulls the latest code from GIT, updates and compiles cleanly.
>>    *   WSJT-X pulls the latest code from GIT and compiles cleanly.
>>
>> But on execution of a freshly built WSJT-X 2.7.0 the following message
>> is displayed:
>>
>> The procedure entry point clock_gettime64 could not be located in the
>> dynamic link library c:\wsjt\wsjtx\bin\libhamlib4-dll
> I'm not familiar with the SDK or building WXJT-X, etc.  I can state that
> "clock_gettime64" is not found in the Hamlib repository as 'git grep
> clock_gettime64' returns nothing.
>
> I presume the issue exists outside of Hamlib.  Sorry.
>
> 73, Nate
>
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer

Re: [Hamlib-developer] Issue with latest pull and building WSJT-X 2.7.0 [ clock_gettime64 could not be located in the DLL ]

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

* On 2025 19 May 07:38 -0500, Hamlib Developer wrote:
> Hi Folks,
> 
> An issue has been encountered with Hamlib pulled from master as of UTC
> 2025-05-18 @ 08:00:00 .
> 
> The development environment is a fully clean and deployed JTSDK
> 4.0.1u1 (see https://sourceforge.net/projects/hamlib-sdk/ ) and has
> worked perfectly up until the time that Mike W9MDB became SK (and of
> course he is therefore of no help to us now ☹)
> 
> “Fully updated” means that the deployed MSYS2 environment is FULLY
> updated with pacman -Syuu,
> 
> LibUSB is the supplied 1.0.28 version that is known to work, and a
> known-to-work Boost 1.88.0 environment has also been deployed with the
> kit. The Qt environ is publicly-available Qt version being Qt 5.15.2.
> 
> These are known facts:
> 
>   *   Hamlib pulls the latest code from GIT, updates and compiles cleanly.
>   *   WSJT-X pulls the latest code from GIT and compiles cleanly.
> 
> But on execution of a freshly built WSJT-X 2.7.0 the following message
> is displayed:
> 
> The procedure entry point clock_gettime64 could not be located in the
> dynamic link library c:\wsjt\wsjtx\bin\libhamlib4-dll

I'm not familiar with the SDK or building WXJT-X, etc.  I can state that
"clock_gettime64" is not found in the Hamlib repository as 'git grep
clock_gettime64' returns nothing.

I presume the issue exists outside of Hamlib.  Sorry.

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] Issue with latest pull and building WSJT-X 2.7.0 [ clock_gettime64 could not be located in the DLL ]

[Hamlib D. <ham...@ou...>]

Hi Folks,

An issue has been encountered with Hamlib pulled from master as of UTC 2025-05-18 @ 08:00:00 .

The development environment is a fully clean and deployed JTSDK 4.0.1u1 (see https://sourceforge.net/projects/hamlib-sdk/ ) and has worked perfectly up until the time that Mike W9MDB became SK (and of course he is therefore of no help to us now ☹)

“Fully updated” means that the deployed MSYS2 environment is FULLY updated with pacman -Syuu,

LibUSB is the supplied 1.0.28 version that is known to work, and a known-to-work Boost 1.88.0 environment has also been deployed with the kit. The Qt environ is publicly-available Qt version being Qt 5.15.2.

These are known facts:

  *   Hamlib pulls the latest code from GIT, updates and compiles cleanly.
  *   WSJT-X pulls the latest code from GIT and compiles cleanly.

But on execution of a freshly built WSJT-X 2.7.0 the following message is displayed:

The procedure entry point clock_gettime64 could not be located in the dynamic link library c:\wsjt\wsjtx\bin\libhamlib4-dll

The environment here is:

  *   A fully updated JTSDK 4.0.0.1u2 and previously functional Hamlib build environment (including pacman updates of the embedded MSYS2 environment)
  *   LibUSB 1.0.28
  *   Boost 1.88.0
  *   Windows 11 25H4 [ Fully updatesd ]

This issue has been replicated on a number of machines.

Any suggestions? Remember the aim of this kit is to be able to build everything from scratch !

What further information do you require?

73

Hamlib SDK Developers

Ps:

If one drops in the DLL's from https://n0nb.users.sourceforge.net/ (i.e. https://n0nb.users.sourceforge.net/hamlib-w64-4.7~git-20250518-ad824fa85.zip ) then the WSJT-X 2.7.0 that we have just built works !

The issue is building from the LATEST GIT Pull with the VERY LATEST MSYS2 packages. All should just work !

................................................................................................................



$ build-hamlib

________________________________

   JTSDK64 Tools MSYS2 Hamlib Build Script v4.0.0.1

________________________________

  *   This script compiles Hamlib Libraries for the JTSDK build system.

________________________________
COMPILE INFORMATION [ Hamlib ]

Script Option(s) ...: None (Default = Dynamic with LibUSB)

Date ...............: 18-05-2025
Package ............: Hamlib
User ...............: stepheni
CPU/Job Count ......: 1
Compiler ...........: /mingw64/bin/gcc
Platform ...........: MINGW64
Source Dir .........: /home/stepheni/
Build Dir ..........: /home/stepheni/src/hamlib/build
LibUSB Include .....: /c/JTSDK64-Tools/tools/libusb/1.0.28/include
LibUSB DLL .........: /c/JTSDK64-Tools/tools/libusb/1.0.28/bin
Package Config......: /c/JTSDK64-Tools/tools/hamlib/qt/5.15.2/lib/pkgconfig/hamlib.pc

Install Prefix .....: /c/JTSDK64-Tools/tools/hamlib/qt/5.15.2

________________________________
CHECKING TOOL-CHAIN [ QT 5.15.2 ]

ar .................: OK
nm .................: OK
ld .................: OK
gcc ................: OK
g++ ................: OK
ranlib .............: OK
Compiler ...........: gcc.exe (Rev4, Built by MSYS2 project) 15.1.0
Compiler Path ......: /mingw64/bin
Bin Utils ..........: GNU ranlib (GNU Binutils) 2.44
Libtool ............: libtool (GNU libtool) 2.5.4
Pkg-Config .........: 2.3.0
Tool-Chain .........: OK

________________________________
CLONING GIT REPOSITORY [ MASTER ]

Already up to date.

________________________________
PERFORM BOOTSTRAP [ Hamlib ]

  *   Performing bootstrap

Running 'autoreconf -i' to process configure.ac
and generate the configure script.

________________________________
CONFIGURING [ Hamlib ]

  *   Running configure script: This may take a several minutes to complete

--> Build Type: Shared/Dynamic built with LibUSB
-->
configure: loading site script /etc/config.site
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether the compiler supports GNU C... yes
checking whether gcc accepts -g... yes
checking for gcc option to enable C11 features... none needed
checking whether gcc understands -c and -o together... yes
checking for stdio.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for strings.h... yes
checking for sys/stat.h... yes
checking for sys/types.h... yes
checking for unistd.h... yes
checking for wchar.h... yes
checking for minix/config.h... no
checking whether it is safe to define EXTENSIONS... yes
checking whether _XOPEN_SOURCE should be defined... no
checking for a BSD-compatible install... /usr/bin/install -c
checking whether sleep supports fractional seconds... yes
checking filesystem timestamp resolution... 0.01
checking whether build environment is sane... yes
checking for a race-free mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports the include directive... yes (GNU style)
checking whether make supports nested variables... yes
checking xargs -n works... yes
checking dependency style of gcc... gcc3
checking for gcc... (cached) gcc
checking whether the compiler supports GNU C... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to enable C11 features... (cached) none needed
checking whether gcc understands -c and -o together... (cached) yes
checking for g++... g++
checking whether the compiler supports GNU C++... yes
checking whether g++ accepts -g... yes
checking for g++ option to enable C++11 features... none needed
checking dependency style of g++... gcc3
checking how to run the C preprocessor... gcc -E
checking for gawk... (cached) gawk
checking whether ln -s works... no, using cp -pR
checking for g++... yes
checking for ar... ar
checking the archiver (ar) interface... ar
checking for inline... inline
checking AM_CFLAGS for maximum warnings... -Wall
checking AM_CXXFLAGS for maximum warnings... -Wall
checking for errno.h... yes
checking for fcntl.h... yes
checking for getopt.h... yes
checking for limits.h... yes
checking for locale.h... yes
checking for malloc.h... yes
checking for netdb.h... no
checking for sgtty.h... no
checking for stddef.h... yes
checking for termio.h... no
checking for termios.h... no
checking for values.h... no
checking for arpa/inet.h... no
checking for dev/ppbus/ppbconf.hdev/ppbus/ppi.h... no
checking for linux/hidraw.h... no
checking for linux/ioctl.h... no
checking for linux/parport.h... no
checking for linux/ppdev.h... no
checking for netinet/in.h... no
checking for sys/ioccom.h... no
checking for sys/ioctl.h... no
checking for sys/param.h... yes
checking for sys/socket.h... no
checking for sys/stat.h... (cached) yes
checking for sys/time.h... yes
checking for sys/select.h... no
checking for glob.h... no
checking build system type... x86_64-w64-mingw32
checking host system type... x86_64-w64-mingw32
checking for ws2tcpip.h... yes
checking for wspiapi.h... yes
checking for library containing nanosleep... none required
checking for pthread.h... yes
checking for sys/types.h... (cached) yes
checking for windows.h... yes
checking for winioctl.h... yes
checking for winbase.h... yes
checking for getopt... yes
checking for getopt_long... yes
checking for usleep... yes
checking for sleep... yes
checking for nanosleep... yes
checking for gettimeofday... yes
checking for struct timezone... yes
checking for ssize_t... yes
checking for getopt... (cached) yes
checking for getopt_long... (cached) yes
checking for usleep... (cached) yes
checking for gettimeofday... (cached) yes
checking for Sleep... yes
checking for the pthreads library -lpthreads... no
checking whether pthreads work without any flags... yes
checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
checking if more special flags are required for pthreads... no
checking for PTHREAD_PRIO_INHERIT... yes
checking POSIX termios... no
checking for size_t... yes
checking for siginfo_t... no
checking for sig_atomic_t... yes
checking for sin... yes
checking for connect... no
checking for main in -lsocket... no
checking for accept... no
checking for gethostbyname... no
checking for main in -lnsl... no
checking for gethostbyname... (cached) no
checking for main in -lws2_32... yes
checking for timeBeginPeriod... no
checking for main in -lwinmm... yes
checking for gcc options needed to detect all undeclared functions... none needed
checking for struct addrinfo... yes
checking whether gai_strerror is declared... yes
checking for getaddrinfo... (cached) yes
checking for cfmakeraw... no
checking for floor... yes
checking for getpagesize... yes
checking for getpagesize... (cached) yes
checking for gettimeofday... (cached) yes
checking for inet_ntoa... no
checking for ioctl... no
checking for memchr... yes
checking for memmove... yes
checking for memset... yes
checking for pow... yes
checking for rint... yes
checking for select... no
checking for setitimer... no
checking for setlocale... yes
checking for sigaction... no
checking for signal... yes
checking for snprintf... yes
checking for socket... no
checking for sqrt... yes
checking for strchr... yes
checking for strdup... yes
checking for strerror... yes
checking for strncasecmp... yes
checking for strrchr... yes
checking for strstr... yes
checking for strtol... yes
checking for glob... no
checking for socketpair... no
checking for working alloca.h... no
checking for alloca... yes
checking how to print strings... printf
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for ld used by gcc... C:/JTSDK64-Tools/tools/msys64/mingw64/x86_64-w64-mingw32/bin/ld.exe
checking if the linker (C:/JTSDK64-Tools/tools/msys64/mingw64/x86_64-w64-mingw32/bin/ld.exe) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /mingw64/bin/nm -B
checking the name lister (/mingw64/bin/nm -B) interface... BSD nm
checking the maximum length of command line arguments... 8192
checking how to convert x86_64-w64-mingw32 file names to x86_64-w64-mingw32 format... func_convert_file_msys_to_w32
checking how to convert x86_64-w64-mingw32 file names to toolchain format... func_convert_file_msys_to_w32
checking for C:/JTSDK64-Tools/tools/msys64/mingw64/x86_64-w64-mingw32/bin/ld.exe option to reload object files... -r
checking for file... file
checking for objdump... objdump
checking how to recognize dependent libraries... file_magic ^x86 archive import|^x86 DLL
checking for dlltool... dlltool
checking how to associate runtime and link libraries... func_cygming_dll_for_implib
checking for ranlib... ranlib
checking for archiver @file<https://github.com/file> support... @
checking for strip... strip
checking command to parse /mingw64/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for a working dd... /usr/bin/dd
checking how to truncate binary pipes... /usr/bin/dd bs=4096 count=1
checking for mt... no
checking if : is a manifest tool... no
checking for dlfcn.h... no
checking for as... as
checking for dlltool... (cached) dlltool
checking for objdump... (cached) objdump
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -DDLL_EXPORT -DPIC
checking if gcc PIC flag -DDLL_EXPORT -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (C:/JTSDK64-Tools/tools/msys64/mingw64/x86_64-w64-mingw32/bin/ld.exe) supports shared libraries... yes
checking whether -lc should be explicitly linked in... yes
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking how to run the C++ preprocessor... g++ -E
checking for ld used by g++... C:/JTSDK64-Tools/tools/msys64/mingw64/x86_64-w64-mingw32/bin/ld.exe
checking if the linker (C:/JTSDK64-Tools/tools/msys64/mingw64/x86_64-w64-mingw32/bin/ld.exe) is GNU ld... yes
checking whether the g++ linker (C:/JTSDK64-Tools/tools/msys64/mingw64/x86_64-w64-mingw32/bin/ld.exe) supports shared libraries... yes
checking for g++ option to produce PIC... -DDLL_EXPORT -DPIC
checking if g++ PIC flag -DDLL_EXPORT -DPIC works... yes
checking if g++ static flag -static works... yes
checking if g++ supports -c -o file.o... yes
checking if g++ supports -c -o file.o... (cached) yes
checking whether the g++ linker (C:/JTSDK64-Tools/tools/msys64/mingw64/x86_64-w64-mingw32/bin/ld.exe) supports shared libraries... yes
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate
checking for windres... windres
checking whether C99 struct/array initializers are supported... yes
checking whether to build USB dependent backends... yes
checking for libusb_init in -lusb-1.0... yes
checking for libusb.h... no
checking for libusb-1.0/libusb.h... yes
checking whether to use readline in rigctl/rotctl... yes
checking for a readline compatible library... -lreadline
checking for readline.h... no
checking for readline/readline.h... yes
checking whether readline supports history... yes
checking for history.h... no
checking for readline/history.h... yes
checking whether to use INDI in rigctl/rotctl... checking whether to build HTML rig feature matrix... check
checking for gd.h... no
checking whether to build rigmem XML support... no
checking whether to build USRP backend... no
checking whether to build C++ binding... no
checking whether to build perl binding... no
checking whether to build python binding... no
checking Whether to build Tcl bindings... no
checking whether to build lua binding... no
checking whether to build bindings... no
checking whether to build winradio backend... yes
checking whether to build parallel port devices... yes
checking for dlopen in -ldl... no
configure: WARNING: dlopen was not found in libdl--linradio backend will be disabled
checking whether g++ supports C++11 features with -std=c++11... yes
Build_OS is mingw32
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating macros/Makefile
config.status: creating include/Makefile
config.status: creating lib/Makefile
config.status: creating src/Makefile
config.status: creating security/Makefile
config.status: creating c++/Makefile
config.status: creating bindings/Makefile
config.status: creating doc/Makefile
config.status: creating doc/hamlib.cfg
config.status: creating rotators/amsat/Makefile
config.status: creating rotators/apex/Makefile
config.status: creating rotators/ars/Makefile
config.status: creating rotators/celestron/Makefile
config.status: creating rotators/cnctrk/Makefile
config.status: creating rotators/grbltrk/Makefile
config.status: creating rotators/easycomm/Makefile
config.status: creating rotators/ether6/Makefile
config.status: creating rotators/flir/Makefile
config.status: creating rotators/fodtrack/Makefile
config.status: creating rotators/gs232a/Makefile
config.status: creating rotators/heathkit/Makefile
config.status: creating rotators/ioptron/Makefile
config.status: creating rotators/m2/Makefile
config.status: creating rotators/meade/Makefile
config.status: creating rotators/prosistel/Makefile
config.status: creating rotators/rotorez/Makefile
config.status: creating rotators/sartek/Makefile
config.status: creating rotators/saebrtrack/Makefile
config.status: creating rotators/spid/Makefile
config.status: creating rotators/ts7400/Makefile
config.status: creating rotators/indi/Makefile
config.status: creating rotators/satel/Makefile
config.status: creating rotators/skywatcher/Makefile
config.status: creating rotators/radant/Makefile
config.status: creating rigs/adat/Makefile
config.status: creating rigs/alinco/Makefile
config.status: creating rigs/aor/Makefile
config.status: creating rigs/barrett/Makefile
config.status: creating rigs/codan/Makefile
config.status: creating rigs/commradio/Makefile
config.status: creating rigs/dorji/Makefile
config.status: creating rigs/drake/Makefile
config.status: creating rigs/dummy/Makefile
config.status: creating rigs/elad/Makefile
config.status: creating rigs/flexradio/Makefile
config.status: creating rigs/icmarine/Makefile
config.status: creating rigs/icom/Makefile
config.status: creating rigs/jrc/Makefile
config.status: creating rigs/kachina/Makefile
config.status: creating rigs/kenwood/Makefile
config.status: creating rigs/kit/Makefile
config.status: creating rigs/lowe/Makefile
config.status: creating rigs/pcr/Makefile
config.status: creating rigs/prm80/Makefile
config.status: creating rigs/racal/Makefile
config.status: creating rigs/rft/Makefile
config.status: creating rigs/rs/Makefile
config.status: creating rigs/skanti/Makefile
config.status: creating rigs/tapr/Makefile
config.status: creating rigs/tentec/Makefile
config.status: creating rigs/tuner/Makefile
config.status: creating rigs/uniden/Makefile
config.status: creating rigs/winradio/Makefile
config.status: creating rigs/wj/Makefile
config.status: creating rigs/yaesu/Makefile
config.status: creating rigs/gomspace/Makefile
config.status: creating rigs/mds/Makefile
config.status: creating rigs/anytone/Makefile
config.status: creating rigs/motorola/Makefile
config.status: creating tests/Makefile
config.status: creating scripts/Makefile
config.status: creating android/Makefile
config.status: creating amplifiers/elecraft/Makefile
config.status: creating amplifiers/gemini/Makefile
config.status: creating amplifiers/expert/Makefile
config.status: creating simulators/Makefile
config.status: creating hamlib.pc
config.status: creating include/hamlib/config.h
config.status: include/hamlib/config.h is unchanged
config.status: executing depfiles commands
config.status: executing libtool commands

________________________________

Hamlib Version 4.7~git configuration:

Prefix /c/JTSDK64-Tools/tools/hamlib/qt/5.15.2
Preprocessor gcc -E -I/c/JTSDK64-Tools/tools/libusb/1.0.28/include
C Compiler gcc -g -O2
C++ Compiler g++ -std=c++11 -g -O2

Package features:
With C++ binding no
With Perl binding no
With Python binding no
With TCL binding no
With Lua binding no
With rigmem XML support no
With Readline support yes
With INDI support no

Enable HTML rig feature matrix  no

Enable WinRadio                 yes

Enable Parallel                 yes

Enable USRP                     no

Enable USB backends             yes

Enable shared libs              yes

Enable static libs              no

________________________________
________________________________
RUNNING MAKE CLEAN [ Hamlib ]

  *   /c/JTSDK64-Tools/config/hlclean flag not set

________________________________
INSTALLING [ Hamlib ]

  *   Clearing out old /c/JTSDK64-Tools/tools/hamlib/qt/5.15.2: Complete

,,,, (etc)

Re: [Hamlib-developer] Moving rig_cache out of rig_state into private storage

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

On 5/17/25 4:44 AM, Daniele Forsi wrote:
> Hello,
>
>> I think the rig_cache structure should be completely internal to Hamlib, and not visible to the calling application.
> that's a good thing

                ^

             very

>
>> I hope there's no big use of this data elsewhere.
> how external software would be using the current cache API?
Strange are the ways of application programmers
>
> I grepped for "rig_cache" in the sources that I have locally (mostly
> from Debian) and I found it only in Hamlib
>
> I searched on github for
> language:C symbol:rig_cache NOT (path:rig.h OR path:cache.h OR path:cache.c)
>
> and found 15 results unrelated to Hamlib; a search that doesn't
> exclude the files above returns more than 3000 results, including
> various copies of Hamlib

Given that there were no other responses, I'll go ahead and finish 
tidying up the code, and create a PR for master.

Re: [Hamlib-developer] Moving rig_cache out of rig_state into private storage

[Daniele F. <iu...@gm...>]

Hello,

> I think the rig_cache structure should be completely internal to Hamlib, and not visible to the calling application.

that's a good thing

> I hope there's no big use of this data elsewhere.

how external software would be using the current cache API?

I grepped for "rig_cache" in the sources that I have locally (mostly
from Debian) and I found it only in Hamlib

I searched on github for
language:C symbol:rig_cache NOT (path:rig.h OR path:cache.h OR path:cache.c)

and found 15 results unrelated to Hamlib; a search that doesn't
exclude the files above returns more than 3000 results, including
various copies of Hamlib
-- 
73 de IU5HKX Daniele

Re: [Hamlib-developer] Strange problem with response from IC-7300

[Sakari N. <sak...@ni...>]

Hi!

As said I gave up with two TCP connection to rigcontrol. With one TCP 
connection and a command stack where next command is spooled out only if 
answer for the previous one is received it seems that RPRT -11 never 
happens. (or passes by without notification)

It is also hard to dig out if it just passes by in short moment. But 
I'll keep my debugs running always when I operate with my Ham PC.

-- 
Saku
OH1KH

George Baltz kirjoitti 16.5.2025 klo 20.29:
> Can either of you capture a full debug log of the rigctld with debug 
> level = 5(rigctld -vvvvv)?  Usually RPRT = -11 means hamlib thinks 
> that it can't get the information the app requested, for hardware or 
> configuration reasons.  Since it works mostly, it might be something 
> transient, or it might just be confused.
>
> Anyway, a debug log should at least narrow down the possibilities.
>
> 73 n3gb
>
>
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer

Re: [Hamlib-developer] Strange problem with response from IC-7300

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

Can either of you capture a full debug log of the rigctld with debug 
level = 5(rigctld -vvvvv)?  Usually RPRT = -11 means hamlib thinks that 
it can't get the information the app requested, for hardware or 
configuration reasons.  Since it works mostly, it might be something 
transient, or it might just be confused.

Anyway, a debug log should at least narrow down the possibilities.

73 n3gb

Re: [Hamlib-developer] Strange problem with response from IC-7300

[Sakari N. <sak...@ni...>]

Hi Steve!

I have seen similar, but very seldom.
When I was rewriting CqrlogAlpha rigcontrol that uses simple text based 
TCP connections to Hamlib (no direct library access).
I start rigctld always via script before any other ham program and then 
use rig model #2 "Net Hamlib rigctld" for all my program settings.
That way there is only one USB serial user; rigctld started by script 
and running on background. No collisions in serial line usage.

So my goal was to create one TCP connection for FMV polling (frequency, 
mode, vfo) as timer based and another TCP connection for direct
user commands like change band, tune, rit, split etc.
Third TCP connection is made for hamlib CW keying.

It did not succeed by the way I was planing. The main problem was not 
with Hamlib, but my code that mixed receive events between those two TCP 
connections.
But while testing I found few times similar RPRT -11 responses. Thought 
then it was just caused by my code.
Returned back to one TCP connection for rig control and mixed poll + 
user command stack with timer spooling that seems to be more stable, but 
has slower response.

Do you start rigctld with "--vfo" or without? That changes the command 
structure. It can be checked with \chk_vfo at the beginning of program.
Depending on answer you need to use "f" or "f currVFO" for frequency query.
And then comes the nasty part. If you need "f currVFO" but issue only 
"f" you may expect very weird responses for following other commands
until rigctld gets back to right track again (may take few commands).
And there are many commands, but not all (that are not listed), 
requiring "currVFO" addition if the startup parameter --vfo is used.

What really is needed is a "flush" byte that could be sent before any 
new command to ensure that last issued command, succeeded or not, is 
completely forgotten.

Or better error handling for command interpreter in case where wrong 
formatted command is issued and ended with linefeed that should trigger 
the command format checking.

I.E. if you send "f" when "f currVFO" is needed the response should be 
RPRT -8. Now there is no response at all and next command will be added 
to already sent "f" causing a weird combined command and also unexpected 
response and RPRT.

These are just my thoughts...

-- 
Saku
OH1KH

Stephen Pattinson via Hamlib-developer kirjoitti 16.5.2025 klo 9.32:
> Hi,
>
> I have a python program that starts rigctld in the background and then 
> interrogates my IC-7300 by using the TCP access to rigctld. This works 
> 100% reliably and retrieves the frequency, tx state and mode of the 
> radio every second.
>
> Whilst experimenting with the "wfview" program which connects to the 
> IC-7300 and allows the radio to be controlled by a PC, I have come 
> across an odd problem. If I run the run the wfview program (which 
> works just fine) and then exit the program and then execute by Python 
> program as described above, my program intermittently malfunctions. 
> Note I'm not trying to do these things at the same time. They both 
> require access to the IC-7300 USB port.
>
> To be specific, the response to the "get_freq" command using the 
> extended protocol is for example as follows (in a python byte array)
>
>     b'get_freq:|Frequency: 14243000|RPRT 0\n'
>
> However, if I had previously run (and terminated) the wfview program, 
> the response to the "get_freq" command is occasionally as follows
>
>     b'get_freq:|RPRT -11\n'
>
> Ie the actual frequency message is missing and back end code -11 is 
> returned.
>
> The analogous thing happens for "get_ptt" and "get_mode" commands 
> every once in a while, although the error code is different.
>
> If I cycle the power on the radio, the problem goes away, so clearly 
> the wfview has changed something in the radio, but I have been unable 
> so far to see any config that  it has changed that might have a 
> bearing on this issue. I'm hoping that either the "-11" error code 
> might convey a clue to the problem, or that someone might have come 
> across this as well.
>
> I get the same malfunction if I use the "simple" protocol instead.
>
> I don't believe this is a hamlib error, but I'm hoping that someone 
> here might have a suggestion for me to try.
>
> Thanks de VK3SPX (Steve)
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer

[Hamlib-developer] Strange problem with response from IC-7300

[Stephen P. <st...@bi...>]

Hi,

I have a python program that starts rigctld in the background and then 
interrogates my IC-7300 by using the TCP access to rigctld. This works 
100% reliably and retrieves the frequency, tx state and mode of the 
radio every second.

Whilst experimenting with the "wfview" program which connects to the 
IC-7300 and allows the radio to be controlled by a PC, I have come 
across an odd problem. If I run the run the wfview program (which works 
just fine) and then exit the program and then execute by Python program 
as described above, my program intermittently malfunctions. Note I'm not 
trying to do these things at the same time. They both require access to 
the IC-7300 USB port.

To be specific, the response to the "get_freq" command using the 
extended protocol is for example as follows (in a python byte array)

     b'get_freq:|Frequency: 14243000|RPRT 0\n'

However, if I had previously run (and terminated) the wfview program, 
the response to the "get_freq" command is occasionally as follows

     b'get_freq:|RPRT -11\n'

Ie the actual frequency message is missing and back end code -11 is 
returned.

The analogous thing happens for "get_ptt" and "get_mode" commands every 
once in a while, although the error code is different.

If I cycle the power on the radio, the problem goes away, so clearly the 
wfview has changed something in the radio, but I have been unable so far 
to see any config that  it has changed that might have a bearing on this 
issue. I'm hoping that either the "-11" error code might convey a clue 
to the problem, or that someone might have come across this as well.

I get the same malfunction if I use the "simple" protocol instead.

I don't believe this is a hamlib error, but I'm hoping that someone here 
might have a suggestion for me to try.

Thanks de VK3SPX (Steve)

[Hamlib-developer] [Hamlib/Hamlib] 0b68dc: Also check the "name" parameter

[dforsi <no...@gi...>]

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: 0b68dc588539e0d53bdb758fdf1639e5808f010e
      https://github.com/Hamlib/Hamlib/commit/0b68dc588539e0d53bdb758fdf1639e5808f010e
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-05-08 (Thu, 08 May 2025)

  Changed paths:
    M src/conf.c

  Log Message:
  -----------
  Also check the "name" parameter

Avoids a segfault if calling strtol(NULL, NULL, 0).


  Commit: dcf4b7a4e0c03a02396694479a5069108b3555e2
      https://github.com/Hamlib/Hamlib/commit/dcf4b7a4e0c03a02396694479a5069108b3555e2
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-05-08 (Thu, 08 May 2025)

  Changed paths:
    M include/hamlib/rig.h

  Log Message:
  -----------
  Fix syntax of #define

It was invalid C syntax, but it is currently unused.


  Commit: b73f64f49865ca2d2006f6ef21c6013a57152d7d
      https://github.com/Hamlib/Hamlib/commit/b73f64f49865ca2d2006f6ef21c6013a57152d7d
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-05-08 (Thu, 08 May 2025)

  Changed paths:
    M bindings/Makefile.am

  Log Message:
  -----------
  Remove redundant dependencies

All *.swg files are in $(SWIGDEP) via $(SWGFILES).


  Commit: 5c05881e0ed0b9fc440bc64f6b60b369f4109139
      https://github.com/Hamlib/Hamlib/commit/5c05881e0ed0b9fc440bc64f6b60b369f4109139
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-05-08 (Thu, 08 May 2025)

  Changed paths:
    M bindings/Makefile.am
    M c++/Makefile.am
    M simulators/Makefile.am
    M src/Makefile.am
    M tests/Makefile.am

  Log Message:
  -----------
  Add rules to build dependencies of libhamlib.la in other directories

This makes it possible to run "make -C src/" or "make -C tests/ rigctl"
or "make -C bindings/ check" (and so on) in a clean tree, but it doesn't
rebuild those targets if libhamlib.la is changed; for this run make from
the top directory as usual, to rebuild all SUBDIRS if needed.


  Commit: 23a54a7bdf088394e73182d7a2b911e01ca326a7
      https://github.com/Hamlib/Hamlib/commit/23a54a7bdf088394e73182d7a2b911e01ca326a7
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-05-08 (Thu, 08 May 2025)

  Changed paths:
    M security/Makefile.am

  Log Message:
  -----------
  Remove unneeded dependency


  Commit: 56eea198beb22db9aa4f0a1447282e14d4ce7ea3
      https://github.com/Hamlib/Hamlib/commit/56eea198beb22db9aa4f0a1447282e14d4ce7ea3
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-05-08 (Thu, 08 May 2025)

  Changed paths:
    M c++/Makefile.am

  Log Message:
  -----------
  Remove unneeded test script testcpp.sh

Library directory ../dummy/.libs doesn't exist anymore and ../c++/.libs
(a.k.a. .libs) is already used by the libtool wrapper script that runs
the testcpp program.


  Commit: 1e7b1a628eefad3114e2d484ff18bc441552adb5
      https://github.com/Hamlib/Hamlib/commit/1e7b1a628eefad3114e2d484ff18bc441552adb5
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-05-08 (Thu, 08 May 2025)

  Changed paths:
    M rigs/dummy/aclog.c
    M rigs/dummy/flrig.c
    M rigs/dummy/sdrsharp.c
    M rigs/dummy/tci1x.c
    M rigs/yaesu/newcat.c
    M src/rig.c

  Log Message:
  -----------
  Fix error return values

All constant error values RIG_E* should be negated when returned.
Found with:
grep -nrE RETURNFUNC.?.RIG_E.+ --include=*.{c,h} | grep -v \-


  Commit: de01821c5121c1097695ff3d783dc0b88ddf95d3
      https://github.com/Hamlib/Hamlib/commit/de01821c5121c1097695ff3d783dc0b88ddf95d3
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-05-08 (Thu, 08 May 2025)

  Changed paths:
    M src/debug.c

  Log Message:
  -----------
  Fix typo


  Commit: da60d2d38324bb1d090f6a0d7bf46fa1f01315bd
      https://github.com/Hamlib/Hamlib/commit/da60d2d38324bb1d090f6a0d7bf46fa1f01315bd
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-05-09 (Fri, 09 May 2025)

  Changed paths:
    M src/Makefile.am

  Log Message:
  -----------
  Replace non-portable make rule with one that is also easier to understand

Fixes:
warning: '%'-style pattern rules are a GNU make extension


  Commit: c7ba4f5384bad446be7bf392539576dd1c572bd2
      https://github.com/Hamlib/Hamlib/commit/c7ba4f5384bad446be7bf392539576dd1c572bd2
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-05-09 (Fri, 09 May 2025)

  Changed paths:
    M c++/Makefile.am
    M configure.ac

  Log Message:
  -----------
  Fix --without-cxx-binding being ignored

Do not build the C++ bindings if the configure script was called
with the option --without-cxx-binding.


  Commit: ad824fa85e42fbf185addef24526427803056f1e
      https://github.com/Hamlib/Hamlib/commit/ad824fa85e42fbf185addef24526427803056f1e
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-05-09 (Fri, 09 May 2025)

  Changed paths:
    M c++/Makefile.am

  Log Message:
  -----------
  Remove duplicated assignment of compilation flags

Fixes a double "-g -O2 -g -O2" in compiler invocation.


Compare: https://github.com/Hamlib/Hamlib/compare/6dfa118dace1...ad824fa85e42

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

[Hamlib-developer] Moving rig_cache out of rig_state into private storage

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

A large portion of the code I have added to Hamlib over the past year+ 
has been to enable moving some fixed structures out of rig_struct into 
somewhat more flexible calloc'ed structures.  Now I've gotten back to 
implementing those, starting with rig_cache(Issue #1420).  After 
thinking about it quite a while, I'd like to do this a bit differently.

I think the rig_cache structure should be completely internal to Hamlib, 
and not visible to the calling application.  Deprecating the definitions 
in rig.h and adding the new declaration to src/cache.h allows us 
complete freedom to modify/enhance/rework the caching operations without 
worrying about outside effects.

Also -

  * This is much closer to current programming techniques.  Data and
    implementation details should be hidden from the outside world, and
    only the API (external interface) should be seen. Even within Hamlib
    the cache won't be visible without '#include "cache.h"'.
  * Reduces the possibility of the app/library mis-match in definitions
    or allocations.
  * In the event of major changes, removes the need for extra
    programming to satisfy older data accesses.
  * And the big technical impact - if Hamlib ever going to handle rigs
    that send unsolicited data (Auto Information in Kenwood speak), then
    the whole notion of cache needs to change - STATE(rig) should always
    be up to date, commands sent to the rig should be confirmed
    automatically, and cache timeouts should no longer be a factor. 
    There may not even be a rig_cache buffer in that case.

I have been running a version of these changes for about a week now, 
using CQRLOG and WSJT-X-improved with no ill effects; I hope there's no 
big use of this data elsewhere. If so, I can add something to freshen up 
the deprecated space in rig_struct, but I reallllllllly hope we can put 
that practice behind us.

Comments and opinions please (to the list).

-- 

73 n3gb

Re: [Hamlib-developer] Question about a native hamlib protocol?

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

* On 2025 10 May 20:46 -0500, William Gaylord wrote:
> I am working on a project that I hope to add rigctl support to. (As in
> buidling a homebrew radio) Is there a 'native' / generic rigctl protocol
> that I van implement as its cat interface or should I just pretent to be an
> existing radio?

In the past the Kenwood protocol has been recommended.  It is well
understood and well supported by both Hamlib and other software.  In my
opinion, that doesn't mean you should limit yourself to a particular
Kenwood model as a custom backend could easily support your radio.  The
benefit of the Kenwood protocol is that it is human readable as it is
ASCII on the wire which makes things a bit easier.  Even Yaesu switched
from its proprietary binary protocol to the Kenwood style around the
turn of the Century.

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] Question about a native hamlib protocol?

[William G. <wga...@jw...>]

I am working on a project that I hope to add rigctl support to. (As in
buidling a homebrew radio) Is there a 'native' / generic rigctl protocol
that I van implement as its cat interface or should I just pretent to be an
existing radio?

KD9KCK

[Hamlib-developer] [Hamlib/Hamlib] 49b0be: Update the directory tree

[dforsi <no...@gi...>]

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: 49b0be5be2cb40e565da74a8ba7a393747d48cb4
      https://github.com/Hamlib/Hamlib/commit/49b0be5be2cb40e565da74a8ba7a393747d48cb4
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-05-04 (Sun, 04 May 2025)

  Changed paths:
    M README.developer

  Log Message:
  -----------
  Update the directory tree


  Commit: 7a466c779ac1bbe0427429670899f82e6c63787f
      https://github.com/Hamlib/Hamlib/commit/7a466c779ac1bbe0427429670899f82e6c63787f
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-05-04 (Sun, 04 May 2025)

  Changed paths:
    M README.developer

  Log Message:
  -----------
  Remove old version numbers


  Commit: 6f789b60ecdd19a4ebd6f1a5e17805c665d51073
      https://github.com/Hamlib/Hamlib/commit/6f789b60ecdd19a4ebd6f1a5e17805c665d51073
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-05-04 (Sun, 04 May 2025)

  Changed paths:
    M README.developer

  Log Message:
  -----------
  Update copyright year


  Commit: fb8abe93bb3805127d457be3c11d1e6d87789f1e
      https://github.com/Hamlib/Hamlib/commit/fb8abe93bb3805127d457be3c11d1e6d87789f1e
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-05-04 (Sun, 04 May 2025)

  Changed paths:
    M README.developer

  Log Message:
  -----------
  List more optional dependencies


  Commit: f4b95826d490bd033c7fb87e849c0edc428775d2
      https://github.com/Hamlib/Hamlib/commit/f4b95826d490bd033c7fb87e849c0edc428775d2
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-05-04 (Sun, 04 May 2025)

  Changed paths:
    M README.developer

  Log Message:
  -----------
  Explain how to use the simulators


  Commit: 584ddb001d5ba15bb3047a566adbd242fa4710ff
      https://github.com/Hamlib/Hamlib/commit/584ddb001d5ba15bb3047a566adbd242fa4710ff
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-05-04 (Sun, 04 May 2025)

  Changed paths:
    M simulators/simid5100.c

  Log Message:
  -----------
  Fix compilation error in simid5100.c

Fixes:
simid5100.c:90:35: error: ‘errno’ undeclared (first use in this function)


  Commit: e5d8dc0f07bd0de56b87430811f549e3f2e2a1f1
      https://github.com/Hamlib/Hamlib/commit/e5d8dc0f07bd0de56b87430811f549e3f2e2a1f1
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-05-04 (Sun, 04 May 2025)

  Changed paths:
    M simulators/simicr8600.c

  Log Message:
  -----------
  Fix compilation error in simicr8600.c

Fixes:
simicr8600.c:445:5: warning: ‘main’ is normally a non-static function [-Wmain]


  Commit: 6dfa118dace16c3fff039d071ca87a4210c91793
      https://github.com/Hamlib/Hamlib/commit/6dfa118dace16c3fff039d071ca87a4210c91793
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-05-04 (Sun, 04 May 2025)

  Changed paths:
    M README.developer

  Log Message:
  -----------
  Describe the use of simulators


Compare: https://github.com/Hamlib/Hamlib/compare/12cc40f4f77c...6dfa118dace1

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

Re: [Hamlib-developer] 4.6.3 and 4.7.0 releases plan

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

* On 2025 03 May 13:19 -0500, Daniele Forsi wrote:
> Hello,
> 
> I'm also ok with a 4.6.3 now. I have 3 PRs in draft which are more
> suitable for 4.7 or later because they involve changes in the builds.

Ack.

> > Yes, I plan to create a 4.6.3 branch off master.  In the future I hope
> > to get back to having a branch such as "4.7"
> 
> creating a stable branch makes it easier for contributors to send pull
> requests to fix small bugs, being small, they are probably easy to
> cherry-pick in the development branch.

Agreed.  Cherry-picking can work the other way as well so long as the
file in master hasn't diverged too much from stable.  In that case a new
commit is likely needed.

> > This is probably an area that could be improved so I'm open to ideas on
> > how best to have PRs integrate into an existing stable branch and the
> > master development branch.
> 
> one possible workflow is to accept in the stable branch only fixes
> that improve stability (eg. parameter checking or error handling);
> changes to the documentation could also go in stable if they improve
> the life of downstream maintainers or users; changes related to
> firmwares probably need a decision on a case by case basis.

Agreed.  That has always been my intent.  The last few releases have
been somewhat chaotic and it didn't work, or rather it was too much
work, to work through what seemed to be a series of commits that
happened each time a file was saved and then a series of corrections and
such.  Better, IMO, is to edit, save, test, and then when mostly
satisfied commit.  Or, if the workflow of an editor demands a commit
each time a file is saved, then rebase to make a single or a couple of
commits.  As Seve, AI4QR, once quipped, "Rebase allows me to look like I
know what I'm doing," or something close to that!  Over time I came to
really appreciate that comment.

> What would be the name of the development branch? I have a slight
> preference for a fixed name such as devel or next (o something else)
> versus a numbered name, because it can create ambiguity until it's
> released (eg. if we had Hamlib-4.6.23 and Hamlib-4.7 it wouldn't be
> clear if 4.7 is stable or not)

The development branch has always been "master".  Admittedly, this got a
bit clouded over the past several months, at least since the 4.6
release.  The version string in 'configure.ac' is an indicator of the
next milestone target.  For example, it will remain "4.7~git" for a
while, at least until 4.7.0 is released and then it could advance to
"4.8~git" or "5.0~git" depending on the plan for incompatible C ABI
changes, i.e. if the ABI is not backward compatible then the major
number should be advanced, but the version string in master will always
have '~git' appended as in indicator that it is from the development
branch.

After the 4.6.3 branch is created, I will merge more substantial changes
into master such as new device families or new device models and some
other things that others have expressed an interest in contributing.
Some of these decisions as to what will be ported to a stable branch
will remain ad hoc to retain some level of flexibility.

Hope that helps.

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] 4.6.3 and 4.7.0 releases plan

[Daniele F. <iu...@gm...>]

Hello,

I'm also ok with a 4.6.3 now. I have 3 PRs in draft which are more
suitable for 4.7 or later because they involve changes in the builds.

> Yes, I plan to create a 4.6.3 branch off master.  In the future I hope
> to get back to having a branch such as "4.7"

creating a stable branch makes it easier for contributors to send pull
requests to fix small bugs, being small, they are probably easy to
cherry-pick in the development branch.

> This is probably an area that could be improved so I'm open to ideas on
> how best to have PRs integrate into an existing stable branch and the
> master development branch.

one possible workflow is to accept in the stable branch only fixes
that improve stability (eg. parameter checking or error handling);
changes to the documentation could also go in stable if they improve
the life of downstream maintainers or users; changes related to
firmwares probably need a decision on a case by case basis.

What would be the name of the development branch? I have a slight
preference for a fixed name such as devel or next (o something else)
versus a numbered name, because it can create ambiguity until it's
released (eg. if we had Hamlib-4.6.23 and Hamlib-4.7 it wouldn't be
clear if 4.7 is stable or not)

-- 
73 de IU5HKX Daniele

Re: [Hamlib-developer] 4.6.3 and 4.7.0 releases plan

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

* On 2025 03 May 12:17 -0500, George Baltz wrote:
> I'm OK with that.  Will you keep a 4.6.x branch for anything urgent, or just
> a 4.7(master) ?

Yes, I plan to create a 4.6.3 branch off master.  In the future I hope
to get back to having a branch such as "4.7" and release 4.7.0, 4.7.1, etc
from it by applying fixes either with pull requests that directly
reference that branch or doing cherry-picks as needed.

This is probably an area that could be improved so I'm open to ideas on
how best to have PRs integrate into an existing stable branch and the
master development branch.

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] 4.6.3 and 4.7.0 releases plan

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

I'm OK with that.  Will you keep a 4.6.x branch for anything urgent, or 
just a 4.7(master) ?


On 5/3/25 11:56 AM, Nate Bargmann wrote:
> Quite a few fixes have been applied over the past couple of weeks, so,
> are there any objections to my releasing 4.6.3 from the current master
> or does anyone have a work in progress that I should wait a bit longer?
>
> 73, Nate
>
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer

Re: [Hamlib-developer] 4.6.3 and 4.7.0 releases plan

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

Quite a few fixes have been applied over the past couple of weeks, so,
are there any objections to my releasing 4.6.3 from the current master
or does anyone have a work in progress that I should wait a bit longer?

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] [Hamlib/Hamlib] 12cc40: Fix IC-705 filter selection and bandwidth handling...

[Kenji R. <no...@gi...>]

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: 12cc40f4f77c5dea54d03b39c8657e8a6038a05f
      https://github.com/Hamlib/Hamlib/commit/12cc40f4f77c5dea54d03b39c8657e8a6038a05f
  Author: Kenji Rikitake <ken...@ac...>
  Date:   2025-05-03 (Sat, 03 May 2025)

  Changed paths:
    M rigs/icom/frame.c
    M rigs/icom/ic7300.c
    M rigs/icom/icom.c

  Log Message:
  -----------
  Fix IC-705 filter selection and bandwidth handling for FM and WFM

* Enable `.fm_filters` in `IC705_priv_caps`
* `icom_get_mode_without_data()`: activate FM filter selection code if `RIG_IS_IC705`
* `icom2rig_mode()`: activate FM filter fixed width code if `RIG_IS_IC705`
* TODO: cases in WFM should be solved independently
* `icom2rig_mode()`: handle FM and WFM separately and correctly at least for IC-705, no changes for IC-7300 and IC-9700
* `icom_get_mode_without_data()`: add WFM to the code assuming that values from `icom2rig_mode()` is correct
* icom.c: A partial rollback for https://github.com/Hamlib/Hamlib/pull/1719/commits/a395b91be6bd19d760e57005ecb8079b15af9ede
* The workaround to use `icom_set_mode_without_data()` is not necessary
* The later experiments showed CI-V command 0x26 worked OK too for WFM
* Add WFM freq to ic705_caps.filters
* Fix icom_set_mode_x26() FM behavior

`icom_set_mode_x26()` did not pass the correct command value
for FM or PKTFM modes when width is set to
`RIG_PASSBAND_NORMAL` (i.e., 0 (zero)).
With this source code change,
the command value `buf[2]` is forcefully set to 1
when `RIG_PASSBAND_NORMAL` or `RIG_PASSBAND_NOCHANGE` are
passed to the parameter `width`.

This fix solves the bug for IC-705 with rigctl when
entering the command `M FM 0` after `M WFM 0` *did not*
change the mode properly to (narrow) FM.



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

[Hamlib-developer] [Hamlib/Hamlib] d89397: Fix IC-705 COMP, VD, and ID meter calibration values

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

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: d893974b3d3fb26cfb46e3f85adaa1b0f9da9ac2
      https://github.com/Hamlib/Hamlib/commit/d893974b3d3fb26cfb46e3f85adaa1b0f9da9ac2
  Author: Kenji Rikitake <ken...@ac...>
  Date:   2025-05-02 (Fri, 02 May 2025)

  Changed paths:
    M rigs/icom/ic7300.c

  Log Message:
  -----------
  Fix IC-705 COMP, VD, and ID meter calibration values

* Define IC-705-specific values ported from flrig-2.0.05.93


  Commit: fa2520c894c91f23c1c7be58e7ee4566e1dc102c
      https://github.com/Hamlib/Hamlib/commit/fa2520c894c91f23c1c7be58e7ee4566e1dc102c
  Author: Nate Bargmann <n0...@n0...>
  Date:   2025-05-02 (Fri, 02 May 2025)

  Changed paths:
    M rigs/icom/ic7300.c

  Log Message:
  -----------
  Merge pull request #1723 from jj1bdx/jj1bdx-ic705-meters

Fix IC-705 COMP, VD, and ID meter calibration values


Compare: https://github.com/Hamlib/Hamlib/compare/fe3bb8b84a47...fa2520c894c9

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