hamlib-developer — hamlib developers forum

Re: [Hamlib-developer] Building Python bindings

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

It's looking for python, you probably only have python3. You need to add
PYTHON_VERSION=3 to the command.

On Tue, Apr 8, 2025, 1:32 AM Phil <phi...@gm...> wrote:

>
> On 7/4/25 17:29, Nate Bargmann wrote:
>
> Hi Phil.
>
> I presume you're on Linux, which distribution?
>
> Xubuntu 24.10
>
> Thank you Nate for taking the time to answer.
>
> Running configure this time the result is : (previously I ran "env
> PYTHON=/usr/bin/python3 ./configure --with-python-binding" which did find
> python)
>
> /phil@phil-ThinkPad-X1-Carbon-Gen-11:~/Downloads/Hamlib$ ./configure --with-python-binding
> checking for gcc... gcc
> checking whether the C compiler works... yes
> checking for C compiler default output file name... a.out
> checking for suffix of executables...
> 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 build environment is sane... yes
> checking for a race-free mkdir -p... /usr/bin/mkdir -p
> checking for gawk... no
> checking for mawk... mawk
> checking whether make sets $(MAKE)... yes
> checking whether make supports the include directive... yes (GNU style)
> checking whether make supports nested variables... yes
> checking dependency style of gcc... gcc3
> checking whether make supports nested variables... (cached) yes
> 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) mawk
> checking whether ln -s works... yes
> 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... yes
> checking for sgtty.h... yes
> checking for stddef.h... yes
> checking for termio.h... yes
> checking for termios.h... yes
> checking for values.h... yes
> checking for arpa/inet.h... yes
> checking for dev/ppbus/ppbconf.hdev/ppbus/ppi.h... no
> checking for linux/hidraw.h... yes
> checking for linux/ioctl.h... yes
> checking for linux/parport.h... yes
> checking for linux/ppdev.h... yes
> checking for netinet/in.h... yes
> checking for sys/ioccom.h... no
> checking for sys/ioctl.h... yes
> checking for sys/param.h... yes
> checking for sys/socket.h... yes
> checking for sys/stat.h... (cached) yes
> checking for sys/time.h... yes
> checking for sys/select.h... yes
> checking for glob.h... yes
> checking build system type... x86_64-pc-linux-gnu
> checking host system type... x86_64-pc-linux-gnu
> checking for ws2tcpip.h... no
> checking for wspiapi.h... no
> checking for library containing nanosleep... none required
> checking for pthread.h... yes
> checking for sys/types.h... (cached) yes
> checking for windows.h... no
> checking for winioctl.h... no
> checking for winbase.h... no
> 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... no
> 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... yes
> checking for size_t... yes
> checking for siginfo_t... yes
> checking for sig_atomic_t... yes
> checking for sin... no
> checking for connect... yes
> checking for gethostbyname... yes
> checking for gethostbyname... (cached) yes
> checking for timeBeginPeriod... no
> checking for main in -lwinmm... no
> 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... yes
> checking for floor... no
> checking for getpagesize... yes
> checking for getpagesize... (cached) yes
> checking for gettimeofday... (cached) yes
> checking for inet_ntoa... yes
> checking for ioctl... yes
> checking for memchr... yes
> checking for memmove... yes
> checking for memset... yes
> checking for pow... no
> checking for rint... no
> checking for select... yes
> checking for setitimer... yes
> checking for setlocale... yes
> checking for sigaction... yes
> checking for signal... yes
> checking for snprintf... yes
> checking for socket... yes
> checking for sqrt... no
> 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... yes
> checking for socketpair... yes
> checking for working alloca.h... yes
> 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... /usr/bin/ld
> checking if the linker (/usr/bin/ld) is GNU ld... yes
> checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
> checking the name lister (/usr/bin/nm -B) interface... BSD nm
> checking the maximum length of command line arguments... 1572864
> checking how to convert x86_64-pc-linux-gnu file names to x86_64-pc-linux-gnu format... func_convert_file_noop
> checking how to convert x86_64-pc-linux-gnu file names to toolchain format... func_convert_file_noop
> checking for /usr/bin/ld option to reload object files... -r
> checking for file... file
> checking for objdump... objdump
> checking how to recognize dependent libraries... pass_all
> checking for dlltool... no
> checking how to associate runtime and link libraries... printf %s\n
> checking for archiver @FILE support... @
> checking for strip... strip
> checking for ranlib... ranlib
> checking command to parse /usr/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... mt
> checking if mt is a manifest tool... no
> checking for dlfcn.h... yes
> checking for objdir... .libs
> checking if gcc supports -fno-rtti -fno-exceptions... no
> checking for gcc option to produce PIC... -fPIC -DPIC
> checking if gcc PIC flag -fPIC -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 (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
> checking whether -lc should be explicitly linked in... no
> checking dynamic linker characteristics... GNU/Linux ld.so
> 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++... /usr/bin/ld -m elf_x86_64
> checking if the linker (/usr/bin/ld -m elf_x86_64) is GNU ld... yes
> checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
> checking for g++ option to produce PIC... -fPIC -DPIC
> checking if g++ PIC flag -fPIC -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 (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
> checking dynamic linker characteristics... (cached) GNU/Linux ld.so
> checking how to hardcode library paths into programs... immediate
> checking for windres... no
> 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... no
> configure: WARNING: readline support not found, using internal input handling.
> 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... yes
> checking whether to build perl binding... no
> checking whether to build python binding... yes
> checking for python... no
> configure: error: Cannot find python in your system path
>
> This all looks good, except for python not found.
>
> I have the latest hamlib from github, I wonder if that differs from the
> version that you have?
>
> git clone https://github.com/Hamlib/Hamlib.git
>
> --
> Regards,
> Phil
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer
>

Re: [Hamlib-developer] Building Python bindings

[Phil <phi...@gm...>]

On 7/4/25 17:29, Nate Bargmann wrote:
> Hi Phil.
>
> I presume you're on Linux, which distribution?

Xubuntu 24.10

Thank you Nate for taking the time to answer.

Running configure this time the result is : (previously I ran 
"|envPYTHON=/usr/bin/python3 ./configure --with-python-binding" which 
did find python) |

> /phil@phil-ThinkPad-X1-Carbon-Gen-11:~/Downloads/Hamlib$ ./configure --with-python-binding
> checking for gcc... gcc
> checking whether the C compiler works... yes
> checking for C compiler default output file name... a.out
> checking for suffix of executables...
> 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 build environment is sane... yes
> checking for a race-free mkdir -p... /usr/bin/mkdir -p
> checking for gawk... no
> checking for mawk... mawk
> checking whether make sets $(MAKE)... yes
> checking whether make supports the include directive... yes (GNU style)
> checking whether make supports nested variables... yes
> checking dependency style of gcc... gcc3
> checking whether make supports nested variables... (cached) yes
> 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) mawk
> checking whether ln -s works... yes
> 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... yes
> checking for sgtty.h... yes
> checking for stddef.h... yes
> checking for termio.h... yes
> checking for termios.h... yes
> checking for values.h... yes
> checking for arpa/inet.h... yes
> checking for dev/ppbus/ppbconf.hdev/ppbus/ppi.h... no
> checking for linux/hidraw.h... yes
> checking for linux/ioctl.h... yes
> checking for linux/parport.h... yes
> checking for linux/ppdev.h... yes
> checking for netinet/in.h... yes
> checking for sys/ioccom.h... no
> checking for sys/ioctl.h... yes
> checking for sys/param.h... yes
> checking for sys/socket.h... yes
> checking for sys/stat.h... (cached) yes
> checking for sys/time.h... yes
> checking for sys/select.h... yes
> checking for glob.h... yes
> checking build system type... x86_64-pc-linux-gnu
> checking host system type... x86_64-pc-linux-gnu
> checking for ws2tcpip.h... no
> checking for wspiapi.h... no
> checking for library containing nanosleep... none required
> checking for pthread.h... yes
> checking for sys/types.h... (cached) yes
> checking for windows.h... no
> checking for winioctl.h... no
> checking for winbase.h... no
> 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... no
> 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... yes
> checking for size_t... yes
> checking for siginfo_t... yes
> checking for sig_atomic_t... yes
> checking for sin... no
> checking for connect... yes
> checking for gethostbyname... yes
> checking for gethostbyname... (cached) yes
> checking for timeBeginPeriod... no
> checking for main in -lwinmm... no
> 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... yes
> checking for floor... no
> checking for getpagesize... yes
> checking for getpagesize... (cached) yes
> checking for gettimeofday... (cached) yes
> checking for inet_ntoa... yes
> checking for ioctl... yes
> checking for memchr... yes
> checking for memmove... yes
> checking for memset... yes
> checking for pow... no
> checking for rint... no
> checking for select... yes
> checking for setitimer... yes
> checking for setlocale... yes
> checking for sigaction... yes
> checking for signal... yes
> checking for snprintf... yes
> checking for socket... yes
> checking for sqrt... no
> 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... yes
> checking for socketpair... yes
> checking for working alloca.h... yes
> 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... /usr/bin/ld
> checking if the linker (/usr/bin/ld) is GNU ld... yes
> checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
> checking the name lister (/usr/bin/nm -B) interface... BSD nm
> checking the maximum length of command line arguments... 1572864
> checking how to convert x86_64-pc-linux-gnu file names to x86_64-pc-linux-gnu format... func_convert_file_noop
> checking how to convert x86_64-pc-linux-gnu file names to toolchain format... func_convert_file_noop
> checking for /usr/bin/ld option to reload object files... -r
> checking for file... file
> checking for objdump... objdump
> checking how to recognize dependent libraries... pass_all
> checking for dlltool... no
> checking how to associate runtime and link libraries... printf %s\n
> checking for archiver @FILE support... @
> checking for strip... strip
> checking for ranlib... ranlib
> checking command to parse /usr/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... mt
> checking if mt is a manifest tool... no
> checking for dlfcn.h... yes
> checking for objdir... .libs
> checking if gcc supports -fno-rtti -fno-exceptions... no
> checking for gcc option to produce PIC... -fPIC -DPIC
> checking if gcc PIC flag -fPIC -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 (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
> checking whether -lc should be explicitly linked in... no
> checking dynamic linker characteristics... GNU/Linux ld.so
> 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++... /usr/bin/ld -m elf_x86_64
> checking if the linker (/usr/bin/ld -m elf_x86_64) is GNU ld... yes
> checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
> checking for g++ option to produce PIC... -fPIC -DPIC
> checking if g++ PIC flag -fPIC -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 (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
> checking dynamic linker characteristics... (cached) GNU/Linux ld.so
> checking how to hardcode library paths into programs... immediate
> checking for windres... no
> 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... no
> configure: WARNING: readline support not found, using internal input handling.
> 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... yes
> checking whether to build perl binding... no
> checking whether to build python binding... yes
> checking for python... no
> configure: error: Cannot find python in your system path

This all looks good, except for python not found.

I have the latest hamlib from github, I wonder if that differs from the 
version that you have?

|git clonehttps://github.com/Hamlib/Hamlib.git |

-- 
Regards,
Phil

Re: [Hamlib-developer] Building Python bindings

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

* On 2025 06 Apr 23:25 -0500, Phil wrote:
> Thank you for reading this.
> 
> The recent discussion about using rigctl within Python code has rekindled my
> interest in this subject. I don't remember ever being able to build the
> Python bindings and so I had used rigctl instead, which is still working. I
> decided to try to build the bindings today but without success.
> 
> I do have hamlib-utils installed which gives me rigctl.
> 
> This is what I'd tried:
> 
> git clone https://github.com/Hamlib/Hamlib.git
> cd Hamlib
> 
> ./bootstrap
> ./configure --with-python-binding
> 
> This ends with "cannot find python".

Hi Phil.

I presume you're on Linux, which distribution?

I just tried it here on Debian 12 and everything works as expected.  I
have the 'python3-dev' package installed which *should* pull in
everything else (header files, etc.).  Here is my 'configure' excerpt:

../hamlib/configure --prefix=$HOME/local --with-python-binding

...

checking whether to build python binding... yes
checking for python... /usr/bin/python
checking for a version of Python >= '2.1.0'... yes
checking for a version of Python >='2.1'... yes
checking for the sysconfig Python package... yes
checking for Python include path... -I/usr/include/python3.11
checking for Python library path... -L/usr/lib/x86_64-linux-gnu -lpython3.11
checking for Python site-packages path... /home/nate/local/lib/python3.11/site-packages
checking for Python platform specific site-packages path... /home/nate/local/lib/python3.11/site-packages
checking python extra libraries... -ldl -lm
checking python extra linking flags... -Xlinker -export-dynamic -Wl,-O1 -Wl,-Bsymbolic-functions
checking consistency of all components of python development environment... yes
checking whether /usr/bin/python version is >= 2.1... yes
checking for /usr/bin/python version... 3.11
checking for /usr/bin/python platform... linux
checking for GNU default /usr/bin/python prefix... ${prefix}
checking for GNU default /usr/bin/python exec_prefix... ${exec_prefix}
checking for /usr/bin/python script directory (pythondir)... ${PYTHON_PREFIX}/lib/python3.11/site-packages
checking for /usr/bin/python extension module directory (pyexecdir)... ${PYTHON_EXEC_PREFIX}/lib/python3.11/site-packages

...

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

...

Then 'make' and 'make install'.

And since I am installing into my home directory I have the following
file:

$HOME/.local/lib/python3.11/site-packages/home_local.pth

which contains:

/home/nate/local/lib/python3.11/site-packages

I successfully ran 'py3test.py' from the bindings directory.

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] Building Python bindings

[Phil <phi...@gm...>]

Thank you for reading this.

The recent discussion about using rigctl within Python code has 
rekindled my interest in this subject. I don't remember ever being able 
to build the Python bindings and so I had used rigctl instead, which is 
still working. I decided to try to build the bindings today but without 
success.

I do have hamlib-utils installed which gives me rigctl.

This is what I'd tried:

git clone https://github.com/Hamlib/Hamlib.git
cd Hamlib

./bootstrap
./configure --with-python-binding

This ends with "cannot find python".

I also tried "env PYTHON=/usr/bin/python3 ./configure 
--with-python-binding". This resulted in a configuration table that 
showed  "With Python binding yes" amongst other listings.

"make" followed by "sudo make install" didn't generate any errors, 
however, Python cannot find either the "Hamlib" or "hamlib" module.

I've spent hours searching the internet for an answer and my AI friend, 
although helpful, wasn't able suggest anything that solved the problem.

-- 
Regards,
Phil

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

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

* On 2025 06 Apr 13:04 -0500, George Baltz wrote:
> On 4/5/25 5:11 PM, Nate Bargmann wrote:
> > Hi all.
> > 
> > Over the past several days I've been looking over the issue tracker on
> > GitHub and doing a little bit of triage that Mike was unable to get to.
> I also spent some time going through the issues, and picked out a couple to
> work on.  There are also some duplicates, and some that might be complete
> except for verification.

Hi George.

Thanks for looking through the list.  I've been going through it a bit
and have assigned some to myself that interest me.

I invite anyone who chooses to work on an issue to assign themself to
it.  Doing so doesn't set your name in stone, it is just merely an alert
to others browsing the list that someone has taken an interest in that
particular issue.  Also, if an issue is of interest and someone shows as
assigned, contact that person and collaborate!

> > I know Mike had a vision of a future release timeline.  It's not set in
> > stone so I'm not suggesting that the project hold itself rigidly to it.
> > For example, he envisioned 5.0 by late 2026.  As I recall, bumping the
> > major version is only necessary if the C ABI changes to such an extent
> > that recompilation of client programs is necessary, so, for now, I don't
> > foresee 5.0 being imminent.
> Good.  The ones that I saw that could benefit from a 5.0 are the rig
> structure changes (1445, 1420, 536 and 487); see my comments in 1445.   None
> of them will be ready soon.

Would it help to have a feature branch that your work can be pushed to
that could also track master?  Would that assist in parallel development
and perhaps shorten the time from where we are now to 5.0?

> > What I would like to do is ask that everyone take a look at the issue
> > tracker:
> > 
> > https://github.com/Hamlib/Hamlib/issues
> > 
> > and look for something that you can help with.  Some are getting to be
> > quite old with the oldest at almost five years.  Some require some
> > testing with certain hardware to see if an issue still exists.  It's
> > impossible for anyone to have all of the hardware Hamlib supports so the
> > project has always depended on help from those with hardware.  To that
> > end I would like to see the number of issues reduced by month's end, if
> > possible.
> OK.  Will try to bring the numbers down.

Thanks!

> > This leads to my plan for the next release.  I would like to roll up the
> > current master branch into a 4.6.3 release by the end of April.  As all
> > of the commits since 4.6.2 appear to be fixes and not new features,
> > please limit Pull Requests (PRs) to fixes including closing issues.
> > Upon release, 4.6.3 will be dedicated to the memory of Mike.
> > 
> > After the next release, master will be open to new features and be
> > planned as a 4.7.0 release.  I've been a bit lax in adding the '.0' to
> > the initial minor release in a series and I think that has resulted in
> > some confusion over the years.  Hopefully 4.7.0 can be released in a few
> > months.
> Great.  If we decide to work toward a 5.0 release, I think I can make it
> possible to build a 4.7 client that will be API-compatible with both pre-4.7
> and 5.0 libraries.

I'm intrigued.

> > At one time I proposed to have a release cadence of late winter
> > and late summer to stay ahead of the Ubuntu release cycle.  I'm not sure
> > if this is still a reasonable release strategy as I'm unsure if Ubuntu
> > is still the amateur radio favorite it once was.  It's likely best that
> > we make releases when it is the best timing for this project, i.e. when
> > it's ready.
> Definitely.  I don't see a 4.7 coming together before the end of the year.

Before we go any further, I'll explain what I see as my role in the
project.

First, I joined the project in early 2001.  While I have contributed
code in the past I am not nor will I ever be the lead developer.  I'm
the old guy that was here and took on the admin role on SourceForge when
Stephane stepped away and Set up the initial project on GitHub.  I've
done work wrangling with the build system and documentation.

Second, I also don't have much of a vision for Hamlib except for the
project to be accessible and to help keep the project active and viable
as best I can.  APIs change over time and I think all of the projects
that use Hamlib understand and are accepting of that so long as changes
are communicated well in advance.  Also, advancing the major number,
i.e. 4.x.x to 5.x.x, and so on, communicates that change.

Third, in light of the above, I see my role as being a facilitator for
those that write the actual Hamlib code.  Unlike Mike and many others, I
lack the experience and knowledge to engage in a discussion such as that
in issue 1445, though I find it fascinating.  As a project, Hamlib is
nearing its 25th anniversary--quite a milestone!  Along the way best
practices have changed and Hamlib should change to match and I defer to
those with the knowledge to lead that effort.

My pledge to the project is to merge pull requests and patches and make
sure that all contributors get credit for commits.  I'll also do what I
can to answer questions here and in our forums though everyone is
welcome to chime in.  It's not too likely that I'll get deeply involved
in technical discussions as I'll leave that to those with a better
vision of how Hamlib should be interested.  My inbox is always open.

I will continue to do releases when we determine the code is ready.

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...>]

On 4/5/25 5:11 PM, Nate Bargmann wrote:
> Hi all.
>
> Over the past several days I've been looking over the issue tracker on
> GitHub and doing a little bit of triage that Mike was unable to get to.
I also spent some time going through the issues, and picked out a couple 
to work on.  There are also some duplicates, and some that might be 
complete except for verification.
> I know Mike had a vision of a future release timeline.  It's not set in
> stone so I'm not suggesting that the project hold itself rigidly to it.
> For example, he envisioned 5.0 by late 2026.  As I recall, bumping the
> major version is only necessary if the C ABI changes to such an extent
> that recompilation of client programs is necessary, so, for now, I don't
> foresee 5.0 being imminent.
Good.  The ones that I saw that could benefit from a 5.0 are the rig 
structure changes (1445, 1420, 536 and 487); see my comments in 1445.   
None of them will be ready soon.
> What I would like to do is ask that everyone take a look at the issue
> tracker:
>
> https://github.com/Hamlib/Hamlib/issues
>
> and look for something that you can help with.  Some are getting to be
> quite old with the oldest at almost five years.  Some require some
> testing with certain hardware to see if an issue still exists.  It's
> impossible for anyone to have all of the hardware Hamlib supports so the
> project has always depended on help from those with hardware.  To that
> end I would like to see the number of issues reduced by month's end, if
> possible.
OK.  Will try to bring the numbers down.
> This leads to my plan for the next release.  I would like to roll up the
> current master branch into a 4.6.3 release by the end of April.  As all
> of the commits since 4.6.2 appear to be fixes and not new features,
> please limit Pull Requests (PRs) to fixes including closing issues.
> Upon release, 4.6.3 will be dedicated to the memory of Mike.
>
> After the next release, master will be open to new features and be
> planned as a 4.7.0 release.  I've been a bit lax in adding the '.0' to
> the initial minor release in a series and I think that has resulted in
> some confusion over the years.  Hopefully 4.7.0 can be released in a few
> months.
Great.  If we decide to work toward a 5.0 release, I think I can make it 
possible to build a 4.7 client that will be API-compatible with both 
pre-4.7 and 5.0 libraries.
>
> At one time I proposed to have a release cadence of late winter
> and late summer to stay ahead of the Ubuntu release cycle.  I'm not sure
> if this is still a reasonable release strategy as I'm unsure if Ubuntu
> is still the amateur radio favorite it once was.  It's likely best that
> we make releases when it is the best timing for this project, i.e. when
> it's ready.
Definitely.  I don't see a 4.7 coming together before the end of the year.
>
> Thoughts?
>
> 73, Nate
>
-- 

73

n3gb

[Hamlib-developer] 4.6.3 and 4.7.0 releases plan

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

Hi all.

Over the past several days I've been looking over the issue tracker on
GitHub and doing a little bit of triage that Mike was unable to get to.

I know Mike had a vision of a future release timeline.  It's not set in
stone so I'm not suggesting that the project hold itself rigidly to it.
For example, he envisioned 5.0 by late 2026.  As I recall, bumping the
major version is only necessary if the C ABI changes to such an extent
that recompilation of client programs is necessary, so, for now, I don't
foresee 5.0 being imminent.

What I would like to do is ask that everyone take a look at the issue
tracker:

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

and look for something that you can help with.  Some are getting to be
quite old with the oldest at almost five years.  Some require some
testing with certain hardware to see if an issue still exists.  It's
impossible for anyone to have all of the hardware Hamlib supports so the
project has always depended on help from those with hardware.  To that
end I would like to see the number of issues reduced by month's end, if
possible.

This leads to my plan for the next release.  I would like to roll up the
current master branch into a 4.6.3 release by the end of April.  As all
of the commits since 4.6.2 appear to be fixes and not new features,
please limit Pull Requests (PRs) to fixes including closing issues.
Upon release, 4.6.3 will be dedicated to the memory of Mike.

After the next release, master will be open to new features and be
planned as a 4.7.0 release.  I've been a bit lax in adding the '.0' to
the initial minor release in a series and I think that has resulted in
some confusion over the years.  Hopefully 4.7.0 can be released in a few
months. 

At one time I proposed to have a release cadence of late winter
and late summer to stay ahead of the Ubuntu release cycle.  I'm not sure
if this is still a reasonable release strategy as I'm unsure if Ubuntu
is still the amateur radio favorite it once was.  It's likely best that
we make releases when it is the best timing for this project, i.e. when
it's ready.

Thoughts?

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] Mailing list attachment limit

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

Hi all.

A recent message was held by Mailman for having an attachment too large
for the list.  Unfortunately, while I received a notice to approve the
message, Mailman, apparently helpfully, lost it.  🤬

As a result I have raised the limit considerably but I ask that
attachments be limited to 500k or less as it's likely we have list
members on slow links.  Oft times a screenshot is better than several
paragraphs and are welcome.

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] Python API

[Adrian <vk...@gm...>]

I added a question on rigctld comp meter for the FTDX101 as well, which 
does not appear covered.

The get level COMP just provided the proc setting and not the COMP meter.

In the end I used

msg.payload = "W RM3;\n";

with a string node and range node to get a COMP meter output on ssb TX


Everything above works via a rigctld server on windows.

73

vk4tux

On 3/4/25 19:30, Nate Bargmann wrote:
> This dropped into my administrator queue on Tuesday but Mailman never
> gave me a message to approve.
>
> 73, Nate
>
> ----- Forwarded message fro...@li... -----
>
> Date: Tue, 1 Apr 2025 14:58:15 +1000
> From: Adrian<vk...@gm...>
> To: Stephen Pattinson<st...@bi...>,  Dave Baxter
>   <g8k...@go...>,n0...@n0..., Erik Icket<run...@gm...>
> Cc:ham...@li...
> Subject: Re: [Hamlib-developer] Python API
> User-Agent: Mozilla Thunderbird
>
> Just to add, node-red works well <> with hamlib, and it is how
>
> I access my windows FTDX101MP serial connected rigctld bat process from the
> lan with node-red running on Debian ;
>
> Then other flows like the SPE amp flow can be linked in/out to auto control
> drive power, and temperature protection.
>
> In node-red settings.js
>
>   **/
> process.env.RIGADDRESS = '192.168.0.2'
> process.env.RIGPORT = '4532'
> process.env.RIGADDRESS1 = '192.168.0.32'
> process.env.RIGPORT1 = '4532'
> module.exports = {
>
>
> Covers two rigs I have connected using hamlib rigctld. The other is lan
> connected to macos running rigctld connected to a FT-747GX.
>
> 73
>
>
> vk4tux
>
>
> On 1/4/25 14:36, Stephen Pattinson wrote:
>> Hi Dave, Erik, Adrian & Nate,
>>
>> Thanks for your help guys. I now have my Python app talking to rigctld via
>> TCP and getting frequency, mode and tx status, which as was pointed out is
>> probably the preferred way to go. Of course, I could just use rigctl if
>> all I wanted to do was send the odd command to the radio, but the main
>> purpose was to have rigctld running so I could get multiple processes to
>> talk to my radio.
>>
>> Dave, your code snippet was most helpful - thanks.
>> Eric, I am starting rigctld from Popen(). The whole idea was to develop a
>> little app to start and stop rigctld in a window (tkinter) without having
>> to resorts to the command line.
>>
>> It does expose another issue however in that I seem to have a reliability
>> problem with the IC7300 USB interface which results in the rigctld daemon
>> getting into a state where it doesn't respond and using up 25% of the PCs
>> CPU. I don't have physical access to the system at present, so I'll wait
>> till I do and maybe ask another question.
>>
>> Anyway - thanks guys.
>> 73 Steve
>>
>> PS Sad news about W9MDB - I was very sorry to hear that.
>>
>>
> ----- End forwarded message -----
>
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer

Re: [Hamlib-developer] Python API

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

This dropped into my administrator queue on Tuesday but Mailman never
gave me a message to approve.

73, Nate

----- Forwarded message from ham...@li... -----

Date: Tue, 1 Apr 2025 14:58:15 +1000
From: Adrian <vk...@gm...>
To: Stephen Pattinson <st...@bi...>,  Dave Baxter
 <g8k...@go...>, n0...@n0..., Erik Icket <run...@gm...>
Cc: ham...@li...
Subject: Re: [Hamlib-developer] Python API
User-Agent: Mozilla Thunderbird

Just to add, node-red works well <> with hamlib, and it is how

I access my windows FTDX101MP serial connected rigctld bat process from the
lan with node-red running on Debian ;

Then other flows like the SPE amp flow can be linked in/out to auto control
drive power, and temperature protection.

In node-red settings.js

 **/
process.env.RIGADDRESS = '192.168.0.2'
process.env.RIGPORT = '4532'
process.env.RIGADDRESS1 = '192.168.0.32'
process.env.RIGPORT1 = '4532'
module.exports = {


Covers two rigs I have connected using hamlib rigctld. The other is lan
connected to macos running rigctld connected to a FT-747GX.

73


vk4tux


On 1/4/25 14:36, Stephen Pattinson wrote:
> Hi Dave, Erik, Adrian & Nate,
> 
> Thanks for your help guys. I now have my Python app talking to rigctld via
> TCP and getting frequency, mode and tx status, which as was pointed out is
> probably the preferred way to go. Of course, I could just use rigctl if
> all I wanted to do was send the odd command to the radio, but the main
> purpose was to have rigctld running so I could get multiple processes to
> talk to my radio.
> 
> Dave, your code snippet was most helpful - thanks.
> Eric, I am starting rigctld from Popen(). The whole idea was to develop a
> little app to start and stop rigctld in a window (tkinter) without having
> to resorts to the command line.
> 
> It does expose another issue however in that I seem to have a reliability
> problem with the IC7300 USB interface which results in the rigctld daemon
> getting into a state where it doesn't respond and using up 25% of the PCs
> CPU. I don't have physical access to the system at present, so I'll wait
> till I do and maybe ask another question.
> 
> Anyway - thanks guys.
> 73 Steve
> 
> PS Sad news about W9MDB - I was very sorry to hear that.
> 
> 

----- 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

Re: [Hamlib-developer] FTDX101.. Compression Level

[Adrian <vk...@gm...>]

On further reading I realized I needed RM3;

so with W RM3; I get intermittent results

"RM3000000;"
4/2/2025, 3:33:02 PMnode: debug 65 
<http://192.168.0.3:1880/#>msg.payload : string[7]
//"RPRT 0↵"
4/2/2025, 3:33:06 PMnode: debug 65 
<http://192.168.0.3:1880/#>msg.payload : string[11]
"RM3163000;"
4/2/2025, 3:33:06 PMnode: debug 65 
<http://192.168.0.3:1880/#>msg.payload : string[7]
//"RPRT 0↵"
4/2/2025, 3:33:08 PMnode: debug 65 
<http://192.168.0.3:1880/#>msg.payload : string[11]
"RM5030000;"
4/2/2025, 3:33:08 PMnode: debug 65 
<http://192.168.0.3:1880/#>msg.payload : string[7]
//"RPRT 0↵"
4/2/2025, 3:33:10 PMnode: debug 65 
<http://192.168.0.3:1880/#>msg.payload : string[11]
"RM3000000;"


Would be great if it could be passed to a hamlib cmd for a numeral result.

Can filter above with node-red for now.


73


vk4tux

On 2/4/25 14:55, Adrian wrote:
>
> Using
>
> msg.payload = "l COMP\n";
>
> I am getting a return that appears to match the set proc level/100, 
> rather than the level matching and/or tracking the comp meter , as 
> show below when I adjust proc 76 to 74.
>
> 4/2/2025, 2:51:50 PMnode: debug 65 
> <http://192.168.0.3:1880/#>msg.payload : string[5]
> "0.76↵"
> 4/2/2025, 2:51:51 PMnode: debug 65 
> <http://192.168.0.3:1880/#>msg.payload : string[5]
> "0.75↵"
> 4/2/2025, 2:51:52 PMnode: debug 65 
> <http://192.168.0.3:1880/#>msg.payload : string[5]
> "0.75↵"
> 4/2/2025, 2:51:53 PMnode: debug 65 
> <http://192.168.0.3:1880/#>msg.payload : string[5]
> "0.74↵"
> 4/2/2025, 2:51:54 PMnode: debug 65 
> <http://192.168.0.3:1880/#>msg.payload : string[5]
> "0.74↵"
> 4/2/2025, 2:51:55 PMnode: debug 65 
> <http://192.168.0.3:1880/#>msg.payload : string[5]
> "0.74↵" Is there a rigctld method to read the comp meter ? Using W PL; 
> is not working for me. ? Thankyou 73 vk4tux

[Hamlib-developer] FTDX101.. Compression Level

[Adrian <vk...@gm...>]

Using

msg.payload = "l COMP\n";

I am getting a return that appears to match the set proc level/100, 
rather than the level matching and/or tracking the comp meter , as show 
below when I adjust proc 76 to 74.

4/2/2025, 2:51:50 PMnode: debug 65 
<http://192.168.0.3:1880/#>//msg.payload : string[5]
//"0.76↵"
4/2/2025, 2:51:51 PMnode: debug 65 
<http://192.168.0.3:1880/#>msg.payload : string[5]
//"0.75↵"
4/2/2025, 2:51:52 PMnode: debug 65 
<http://192.168.0.3:1880/#>msg.payload : string[5]
//"0.75↵"
4/2/2025, 2:51:53 PMnode: debug 65 
<http://192.168.0.3:1880/#>msg.payload : string[5]
//"0.74↵"
4/2/2025, 2:51:54 PMnode: debug 65 
<http://192.168.0.3:1880/#>msg.payload : string[5]
//"0.74↵"
4/2/2025, 2:51:55 PMnode: debug 65 
<http://192.168.0.3:1880/#>msg.payload : string[5]
//"0.74↵" Is there a rigctld method to read the comp meter ? Using W PL; 
is not working for me. ? Thankyou 73 vk4tux

[Hamlib-developer] [Hamlib/Hamlib] a9ce0b: Update README.developer

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

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: a9ce0b07dd8730bc901f11ca3008230b1606633d
      https://github.com/Hamlib/Hamlib/commit/a9ce0b07dd8730bc901f11ca3008230b1606633d
  Author: brianjester <bri...@pr...>
  Date:   2025-03-30 (Sun, 30 Mar 2025)

  Changed paths:
    M README.developer

  Log Message:
  -----------
  Update README.developer

fix typo


  Commit: d8a3aac62587e7e73cc27d165115a5ee3833baa8
      https://github.com/Hamlib/Hamlib/commit/d8a3aac62587e7e73cc27d165115a5ee3833baa8
  Author: Nate Bargmann <n0...@n0...>
  Date:   2025-04-01 (Tue, 01 Apr 2025)

  Changed paths:
    M README.developer

  Log Message:
  -----------
  Merge pull request #1688 from brianjester/patch-1

Update README.developer


Compare: https://github.com/Hamlib/Hamlib/compare/44014b914ea6...d8a3aac62587

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

Re: [Hamlib-developer] Mike, W9MDB SK

[Glenn <ve...@na...>]

Such sad news. Mike was a hamlib hero!
RIP my friend.

Glenn VE9GJ 

On March 31, 2025 8:38:57 p.m. ADT, Nate Bargmann <n0...@n0...> wrote:
>Thanks to Phil, GM3ZZA for pinging me on this.
>
>I am sad to report that Mike, W9MDB, has become a silent key.
>
>There is a thread dedicated to his memory at QRZ.com:
>
>https://forums.qrz.com/index.php?threads/mike-black-w9mdb-sk.949794/
>
>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] Mike, W9MDB SK

[David B. <da...@ba...>]

This is sad news. Mike was always very helpful responding to API questions and fixing bugs.

RIP

73 de David M0DGB/G8FKH

-----Original Message-----
From: Nate Bargmann <n0...@n0...> 
Sent: 01 April 2025 00:39
To: Hamlib Developers <ham...@li...>
Subject: [Hamlib-developer] Mike, W9MDB SK

Thanks to Phil, GM3ZZA for pinging me on this.

I am sad to report that Mike, W9MDB, has become a silent key.

There is a thread dedicated to his memory at QRZ.com:

https://forums.qrz.com/index.php?threads/mike-black-w9mdb-sk.949794/

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] Python API

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

Hi George,

That is probably what I was looking for, but in the mean time, I've had 
some help and been pointed in the direction of just sending TCP messages 
strait to the rigctld port. I'm unclear what would be gained by using 
the bindings, and in any event, I like to avoid having to build Hamlib. 
I guess it just avoids having to deal with the rigctld default or 
extended protocols directly?

Cheers
Steve


On 31/03/2025 19:44, George Baltz wrote:
> What you are looking for is the Python binding for Hamlib.  On Linux 
> it's usually a separate package, installed along with the main 
> library.  Example code is available in the source tree, or at 
> https://github.com/Hamlib/Hamlib/blob/master/bindings/py3test.py
>
> Creating the Python bindings is a build-time option - I don't know if 
> it is available in the stock packages.  If you build Hamlib yourself, 
> it is pretty simple to add it.
>
> Using rigctl or rigctld is an option, but that means re-inventing a 
> lot of code.
>
> On 3/29/25 4:06 AM, Stephen Pattinson via Hamlib-developer wrote:
>> Hi,
>> I have written a Python (3.12.3) to talk to my IC7300 via Hamlib 
>> (V4.6.2) in a Windows 10 environment, but I'm just issuing "rigctl" 
>> commands and capturing the response. This works fine, but it's rather 
>> crude.
>> Of course I would like to use the API which I believe is available, 
>> but I cannot find how to download the necessary additional software 
>> or library, or find the documentation for the Python API.
>> I have looked at 
>> "https://hamlib.sourceforge.net/manuals/4.3/index.html", but this 
>> seems exclusively C
>> Ironically, the most pertinent info I retrieved from a search is from 
>> the Google AI (Sigh!) which suggests I need "hamlib-python", but I 
>> can't find where the AI has scooped up this information.
>> If anybody can point me at installation instructions and 
>> documentation for the API, I would be grateful.
>> Thanks/73
>> Steve VK3SPX
>>
>>
>> _______________________________________________
>> Hamlib-developer mailing list
>> Ham...@li...
>> https://lists.sourceforge.net/lists/listinfo/hamlib-developer
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer

Re: [Hamlib-developer] Python API

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

Hi Dave, Erik, Adrian & Nate,

Thanks for your help guys. I now have my Python app talking to rigctld 
via TCP and getting frequency, mode and tx status, which as was pointed 
out is probably the preferred way to go. Of course, I could just use 
rigctl if all I wanted to do was send the odd command to the radio, but 
the main purpose was to have rigctld running so I could get multiple 
processes to talk to my radio.

Dave, your code snippet was most helpful - thanks.
Eric, I am starting rigctld from Popen(). The whole idea was to develop 
a little app to start and stop rigctld in a window (tkinter) without 
having to resorts to the command line.

It does expose another issue however in that I seem to have a 
reliability problem with the IC7300 USB interface which results in the 
rigctld daemon getting into a state where it doesn't respond and using 
up 25% of the PCs CPU. I don't have physical access to the system at 
present, so I'll wait till I do and maybe ask another question.

Anyway - thanks guys.
73 Steve

PS Sad news about W9MDB - I was very sorry to hear that.

Re: [Hamlib-developer] Mike, W9MDB SK

[David R. <ham...@tr...>]

Wow... this is terrible news!  His 6,755 commits to the Hamlib project ( 
https://github.com/Hamlib/Hamlib/graphs/contributors ) alone is 
astounding.  RIP de W9MDB.

--David
KI6ZHD





On 03/31/2025 04:38 PM, Nate Bargmann wrote:
> Thanks to Phil, GM3ZZA for pinging me on this.
>
> I am sad to report that Mike, W9MDB, has become a silent key.
>
> There is a thread dedicated to his memory at QRZ.com:
>
> https://forums.qrz.com/index.php?threads/mike-black-w9mdb-sk.949794/
>
> 73, Nate
>
>
>
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer

[Hamlib-developer] Mike, W9MDB SK

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

Thanks to Phil, GM3ZZA for pinging me on this.

I am sad to report that Mike, W9MDB, has become a silent key.

There is a thread dedicated to his memory at QRZ.com:

https://forums.qrz.com/index.php?threads/mike-black-w9mdb-sk.949794/

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] Python API

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

Good question, Dave

 From my point of view, I see three major plusses -

1. You get stability. In the time I've been working on Hamlib(about 2.5 
years), I've seen more changes/tweaks to the rigctl commands than to the 
Hamlib API, and more emphasis on API continuity.  And I don't know of 
any hard-and-fast definition of the rigctld protocol.

2. You get flexibility. Using the API means you can use rigctld if you 
like, connect directly to the rig via USB or serial, or even use TCP/IP 
directly to those rigs that support it.  No changes to app code, just 
configure the connection.

3. You get (limited) portability. Using code from other apps in your own 
app means transliterating, not writing from scratch.

Just my 2 cents

73 N3GB


PS: replies to the list, please

On 3/31/25 8:46 AM, Dave Baxter wrote:
>
> Hi George.
>
> For those of us who have not used the Hamlib API (for any language.)  
> What advantage and/or other features does it give, over using rigctld 
> for example for anyone developing an application for their own, or 
> other's use?
>
> Why would it be preferable* to using rigctld via TCP/IP?
>
> (* I can see that if you expose a rigctld port to, "the world"!  That 
> is probably not a safe thing to do, as from past traffic on this list 
> I suspect rigctld is not hardened to anyone attempting to find an 
> exploitable hole in it!  But hiding it behind a properly configured 
> VPN is likely OK, for such a remote usage case.)
>
> Not criticising in any way, Just curious and would like to know more...
>
> 73.
>
> Dave G0WBX
>
>
> On 31/03/2025 09:44, George Baltz wrote:
>> What you are looking for is the Python binding for Hamlib.  On Linux 
>> it's usually a separate package, installed along with the main 
>> library.  Example code is available in the source tree, or at 
>> https://github.com/Hamlib/Hamlib/blob/master/bindings/py3test.py
>>
>> Creating the Python bindings is a build-time option - I don't know if 
>> it is available in the stock packages.  If you build Hamlib yourself, 
>> it is pretty simple to add it.
>>
>> Using rigctl or rigctld is an option, but that means re-inventing a 
>> lot of code.
>>
>> On 3/29/25 4:06 AM, Stephen Pattinson via Hamlib-developer wrote:
>>> Hi,
>>> I have written a Python (3.12.3) to talk to my IC7300 via Hamlib 
>>> (V4.6.2) in a Windows 10 environment, but I'm just issuing "rigctl" 
>>> commands and capturing the response. This works fine, but it's 
>>> rather crude.
>>> Of course I would like to use the API which I believe is available, 
>>> but I cannot find how to download the necessary additional software 
>>> or library, or find the documentation for the Python API.
>>> I have looked at 
>>> "https://hamlib.sourceforge.net/manuals/4.3/index.html", but this 
>>> seems exclusively C
>>> Ironically, the most pertinent info I retrieved from a search is 
>>> from the Google AI (Sigh!) which suggests I need "hamlib-python", 
>>> but I can't find where the AI has scooped up this information.
>>> If anybody can point me at installation instructions and 
>>> documentation for the API, I would be grateful.
>>> Thanks/73
>>> Steve VK3SPX
>>>
>>>
>>> _______________________________________________
>>> Hamlib-developer mailing list
>>> Ham...@li...
>>> https://lists.sourceforge.net/lists/listinfo/hamlib-developer
>>
>>
>> _______________________________________________
>> Hamlib-developer mailing list
>> Ham...@li...
>> https://lists.sourceforge.net/lists/listinfo/hamlib-developer

Re: [Hamlib-developer] Python API

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

What you are looking for is the Python binding for Hamlib.  On Linux 
it's usually a separate package, installed along with the main library.  
Example code is available in the source tree, or at 
https://github.com/Hamlib/Hamlib/blob/master/bindings/py3test.py

Creating the Python bindings is a build-time option - I don't know if it 
is available in the stock packages.  If you build Hamlib yourself, it is 
pretty simple to add it.

Using rigctl or rigctld is an option, but that means re-inventing a lot 
of code.

On 3/29/25 4:06 AM, Stephen Pattinson via Hamlib-developer wrote:
> Hi,
> I have written a Python (3.12.3) to talk to my IC7300 via Hamlib 
> (V4.6.2) in a Windows 10 environment, but I'm just issuing "rigctl" 
> commands and capturing the response. This works fine, but it's rather 
> crude.
> Of course I would like to use the API which I believe is available, 
> but I cannot find how to download the necessary additional software or 
> library, or find the documentation for the Python API.
> I have looked at 
> "https://hamlib.sourceforge.net/manuals/4.3/index.html", but this 
> seems exclusively C
> Ironically, the most pertinent info I retrieved from a search is from 
> the Google AI (Sigh!) which suggests I need "hamlib-python", but I 
> can't find where the AI has scooped up this information.
> If anybody can point me at installation instructions and documentation 
> for the API, I would be grateful.
> Thanks/73
> Steve VK3SPX
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer

Re: [Hamlib-developer] Python API

[Erik I. <run...@gm...>]

Hi Steve,

I am picking up your message in an attempt to guide you with ideas that others have also suggested.

1. You may start the rigctld in the background using subprocessPopen() , but you may also start it up from a command prompt as in :

C:\>\WSJT\wsjtx\bin\rigctld-wsjtx.exe -m 3070 -s 19200 -r com10 -c 136 -vvv

The rigctld daemon runs on the host where your rig is physically connected.

2. Now from Python you open a socket to the remote (or local if everything runs local) host and port 4532 (the default port for the rigtld wsjtx daemon).

3. Write "f\n" to the socket and you should receive a string with the frequency. So no need to launch rigctl for every command you use.

If you want to find out which rig commands are implemented and what the command options are, use :
rigctld-wsjtx.exe -?
or
rigctl-wsjtx.exe -?

Hope this sets you on a good course, and remember that WSJTX contains the lastest Hamlib distribution.

73's and our thoughts to Mike, W9MDB -- who made most of this magic happen.
Erik ON4PB.








 



-----Original Message-----
From: Stephen Pattinson <st...@bi...> 
Sent: Sunday, 30 March 2025 09:54
To: Erik Icket <run...@gm...>; ham...@li...
Subject: Re: [Hamlib-developer] Python API

Hi Erik,
Thanks for responding.
My Python 3 app is starting rigctld effectively in the background using the subprocessPopen()  mechanism. Then to retrieve parameters from the radio, it is running subprocess.Run() which effectively executes "rigctl -m 2 f" for example to get the VFO frequency by capturing the response, but firing off a windows EXE program every second is pretty awful. I assumed I could via the API I assumed was available, open a channel/pipe/whatever and effectively do what ever rigctl is doing internally.
I've looked at the API references and web pages, but they seem convulsively C. I see tantalizing references to python bindings (I'm not sure what that means) and in the Debian world I see a python3-hamlib library, but of course I'm looking for a Windows solution.
Am I looking for something that doesn't exist Erik?
73 Steve
VK3SPX


On 30/03/2025 18:32, Erik Icket wrote:
> Hi Steve,
>
> One way to obtain a better segregation between your Python app and the 
> rig, is to go via the rigctld daemon.
> Once the daemon runs (local or remote), you may open a socket to it 
> and issue your commands.
> For example, to know the frequency, just issue a write to socket with "f\n"
> contents.
>
> It is not a straight program to rig interface, as you are looking for.
> However, it does not require to launch the rigctl app each time you 
> issue a command.
>
> g'day !
> Erik
> ON4PB
>
> -----Original Message-----
> From: Stephen Pattinson via Hamlib-developer 
> <ham...@li...>
> Sent: Saturday, 29 March 2025 09:06
> To: ham...@li...
> Subject: [Hamlib-developer] Python API
>
> Hi,
> I have written a Python (3.12.3) to talk to my IC7300 via Hamlib
> (V4.6.2) in a Windows 10 environment, but I'm just issuing "rigctl"
> commands and capturing the response. This works fine, but it's rather crude.
> Of course I would like to use the API which I believe is available, 
> but I cannot find how to download the necessary additional software or 
> library, or find the documentation for the Python API.
> I have looked at
> "https://hamlib.sourceforge.net/manuals/4.3/index.html", but this 
> seems exclusively C Ironically, the most pertinent info I retrieved 
> from a search is from the Google AI (Sigh!) which suggests I need 
> "hamlib-python", but I can't find where the AI has scooped up this information.
> If anybody can point me at installation instructions and documentation 
> for the API, I would be grateful.
> Thanks/73
> Steve VK3SPX
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer
>

Re: [Hamlib-developer] Python API

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

* On 2025 30 Mar 07:20 -0500, Adrian wrote:
> Isn't rigctl a rigctld client ? It works for me that way..

It can be, but mostly for testing.

Opening a TCP socket is the preferred way of interacting with rigctld.

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] Python API

[Dave B. <g8k...@go...>]

Hi again.

I've just had a play with rigctl on Linux, with my ancient FT-736r.

*dave@hp-sfdt*:*~*$ rigctl --version
rigctl Hamlib 4.5.4 Jan 10 01:31:41Z 2023 SHA=921cc5

Invoking it from a command line thus:

*dave@hp-sfdt*:*~*$ rigctl -m1010 -r /dev/ttyFT736 -s 4800

Rig command: f
Frequency: 0

Rig command: F 144428500

Rig command: f
Frequency: 144428500

Rig command:

As you can see, that invokes the program, and I can then control the 
radio just fine (such as it can be) without first launching rigctld.

You get a "Rig command:" prompt and a box cursor.

As is evidenced by not finding rigctld listed in the output of "htop*" 
filtering on "rig", it only shows rigctl running.

I then issued the command:  F 144428500

And I'm now listening to the GB3VHF beacon keying away to itself.

Issuing a single 'f' command, and I get the last known set frequency 
back just fine.  (Frequency in Hz of course.)

(* htop is a linux tool, that shows what's running in memory) when it's 
output is filtered by "rig", only lists rigctl on it's own, no rigctld 
daemon invoked at all.

Check with your multiple invocation from your Python program, that you 
are not filling RAM with multiple copies of it!   As I can cause by 
launching multiple copies of it from a command line with the exact same 
invocation!

I suspect you'd be better off using rigctld on it's own communicating 
with it from your code, via a TCP/IP session, if you can't find the 
Python API anywhere.

What do others think?

73.

Dave G0WBX.



On 30/03/2025 13:19, Adrian wrote:
>
> Isn't rigctl a rigctld client ? It works for me that way..
>
> On 30/3/25 21:27, Dave Baxter via Hamlib-developer wrote:
>>
>> Steve.
>>
>> If you've already got "rigctld" open as a daemon in the background, 
>> you do not need to issue "rigctl" commands, just open a TCP socket to 
>> the daemon, and issue commands, and receive status replies via that 
>> route.
>>
>> rigctld and rigctl are different animals.
>>
>> You can have also more than one rigctld running, listening on 
>> different TCP/IP ports, for different radio's.
>>
>> As Erik wrote, they can even be on a different machine, so long as 
>> the address/port is accessible from "your" machine, the radio and 
>> it's local computer (even a Pi) could be the other side of the planet 
>> if needed.
>>
>> Python is very network friendly in that way, and it works very well 
>> too.   "localhost:port" is your friend...
>>
>> This crude code below, is what I used a while ago to get the old 
>> FT-736r to appear as a readable radio, to keep gpredict happy back in 
>> the hamlib 3.3 days.   No longer needed with hamlib 4.x
>>
>> ------------------------------------------------------------------------
>>
>> import socket
>>
>> def Main():
>>
>> #    Local temporary string storage.
>>     subfreq = "435000000"
>>     mainfreq = "145000000"
>>
>> #    GPredict side host:port
>> #    Well away from any default Hamlib port.
>>     gphost = 'localhost'
>>     gpport = 50000
>>
>> #    HamLib side host:port
>> #    Well away from any default Hamlib port.
>>     hlhost = 'localhost'
>>     hlport = 50736
>>
>> #    Create a Server socket for GPredict to connect to as a client.
>>     gpSocket = socket.socket()
>>     gpSocket.bind((gphost,gpport))
>>     gpSocket.listen(3)
>>     print ("FT-736 Helper listening on port " + str(gpport))
>>
>> #    Create a Client socket, to connect to the HamLib server.
>> #    NOTE!  rigctld MUST be started before this script is run!
>> #    Like this...
>>
>> #    $ rigctld -m110 -r /dev/ttyUSB4 -s 4800 -T localhost -t 50736
>> #   (post HamLib 4.x use -m1010 for the model number.)
>>
>>     while True:
>>         gpconn, gpaddr = gpSocket.accept()
>> #        print ("Connection from: " + str(gpaddr).rstrip())
>>
>>         # The Hamlib backend will automatically have done this, but it
>>         # will be needed if we turn CAT off, when Gpredict "Disengages"
>>         # and we later "Engage" the radio.
>>         # Not needed for Hamlib 3.3 or later, it does the right thing
>>         # by default.
>>
>> #        hlcmd = "w \\0x00\\0x00\\0x00\\0x00\\0x00\n"
>> #        print ("Sending " + hlcmd)
>> #        hlSocket.sendall(hlcmd.encode())
>>
>> #        NOTE!  If this is used, rigctld "Expects" a reply from the rig,
>> #        that will never arrive.  So there will be a delay of some 2 
>> seconds
>> #        or more before it returns to us.
>>
>>         hlSocket = socket.socket()
>>         hlSocket.connect((hlhost,hlport))
>>         print ("Linked to rigctld")
>>
>>         while True:
>>                 gpcmd = gpconn.recv(1024).decode()
>>                 if not gpcmd:
>>                         break
>>                 print ("From Gpredict: " + gpcmd.rstrip())
>>
>>                 if gpcmd[0] == "F":
>>                     # Set Main frequency: Remember the value.
>>                     mainfreq = (gpcmd[1:]).lstrip()
>>                     # code here to send to Hamlib
>>                     hlSocket.sendall(gpcmd.encode())
>>                     reply = hlSocket.recv(1024).decode()
>> #                    print ("To   Gpredict: " + reply.rstrip())
>>                     gpconn.sendall(reply.encode())
>>
>>                 elif gpcmd[0] == "I":
>>                     # Set Sub frequency: Remember the value.
>>                     subfreq = (gpcmd[1:]).lstrip()
>>                     # code here to send to Hamlib
>>                     hlSocket.sendall(gpcmd.encode())
>>                     reply = hlSocket.recv(1024).decode()
>> #                    print ("To   Gpredict: " + reply.rstrip())
>>                     gpconn.sendall(reply.encode())
>>
>>                 elif gpcmd[0] == "f":
>>                     # fake read of the main frequency
>>                     reply = mainfreq + "\n"
>> #                    print ("To   Gpredict: " + reply.rstrip())
>>                     gpconn.sendall(reply.encode())
>>
>>                 elif gpcmd[0] == "i":
>>                     # fake read of the sub frequency
>>                     reply = subfreq + "\n"
>> #                    print ("To   Gpredict: " + reply.rstrip())
>>                     gpconn.sendall(reply.encode())
>>
>>                 elif gpcmd[0] == "q":
>>                     print ("Unlinking from rigctld")
>> #                    hlcmd = "w \\0x00\\0x00\\0x00\\0x00\\0x80\n"ri
>> #                    See earlier notes at lines 45 and 55.
>>                     hlSocket.sendall(gpcmd.encode())    # or hlcmd
>>
>>                 else:
>>                     hlSocket.sendall(gpcmd.encode())
>>                     reply = hlSocket.recv(1024).decode()
>> #                    print ("To   Gpredict: " + reply.rstrip())
>>                     gpconn.sendall(reply.encode())
>>
>>         gpconn.close()
>>
>>
>> if __name__ == '__main__':
>>     Main()
>>
>> ------------------------------------------------------------------------
>>
>> Heck, if I can do it, etc...   No need to comment on bad Python 
>> practices, this was all my own work mistookes included, but it worked 
>> very well indeed.
>>
>> As above, no longer needed for the Hamlib 4.x, the local frequency 
>> memory is now implemented within the hamlib backend for the 736, and 
>> also it keeps the rig CAT port open between so long as at least one 
>> application itself stays connected to that instance of rigctld (if 
>> just to avoid the annoying beeps from the rig!)
>>
>> I could never find a reliable way to detect if the needed daemon was 
>> already running and if not, start it from within Python, though I'm 
>> sure it can be done, just the doc's are somewhat impenetrable to 
>> someone who is not a pro snake charmer!.
>>
>> That code was itself invoked from a bash script that started the 
>> daemon, started the Python helper tool, and then launched Gpredict.
>>
>> Killing stuff off in the reverse order, when Gpredict was itself 
>> exited/ended.
>>
>> Best of all, it is entirely cross platform, others used it on various 
>> Windows machines, while I was doing this on Linux.
>>
>> 73.
>>
>> Dave G0WBX.
>>
>>
>> On 30/03/2025 08:53, Stephen Pattinson via Hamlib-developer wrote:
>>> Hi Erik,
>>> Thanks for responding.
>>> My Python 3 app is starting rigctld effectively in the background 
>>> using the subprocessPopen()  mechanism. Then to retrieve parameters 
>>> from the radio, it is running subprocess.Run() which effectively 
>>> executes "rigctl -m 2 f" for example to get the VFO frequency by 
>>> capturing the response, but firing off a windows EXE program every 
>>> second is pretty awful. I assumed I could via the API I assumed was 
>>> available, open a channel/pipe/whatever and effectively do what ever 
>>> rigctl is doing internally.
>>> I've looked at the API references and web pages, but they seem 
>>> convulsively C. I see tantalizing references to python bindings (I'm 
>>> not sure what that means) and in the Debian world I see a 
>>> python3-hamlib library, but of course I'm looking for a Windows 
>>> solution.
>>> Am I looking for something that doesn't exist Erik?
>>> 73 Steve
>>> VK3SPX
>>>
>>>
>>> On 30/03/2025 18:32, Erik Icket wrote:
>>>> Hi Steve,
>>>>
>>>> One way to obtain a better segregation between your Python app and 
>>>> the rig,
>>>> is to go via the rigctld daemon.
>>>> Once the daemon runs (local or remote), you may open a socket to it 
>>>> and
>>>> issue your commands.
>>>> For example, to know the frequency, just issue a write to socket 
>>>> with "f\n"
>>>> contents.
>>>>
>>>> It is not a straight program to rig interface, as you are looking for.
>>>> However, it does not require to launch the rigctl app each time you 
>>>> issue a
>>>> command.
>>>>
>>>> g'day !
>>>> Erik
>>>> ON4PB
>>>>
>>>> -----Original Message-----
>>>> From: Stephen Pattinson via Hamlib-developer
>>>> <ham...@li...>
>>>> Sent: Saturday, 29 March 2025 09:06
>>>> To: ham...@li...
>>>> Subject: [Hamlib-developer] Python API
>>>>
>>>> Hi,
>>>> I have written a Python (3.12.3) to talk to my IC7300 via Hamlib
>>>> (V4.6.2) in a Windows 10 environment, but I'm just issuing "rigctl"
>>>> commands and capturing the response. This works fine, but it's 
>>>> rather crude.
>>>> Of course I would like to use the API which I believe is available, 
>>>> but I
>>>> cannot find how to download the necessary additional software or 
>>>> library, or
>>>> find the documentation for the Python API.
>>>> I have looked at
>>>> "https://hamlib.sourceforge.net/manuals/4.3/index.html", but this 
>>>> seems
>>>> exclusively C Ironically, the most pertinent info I retrieved from 
>>>> a search
>>>> is from the Google AI (Sigh!) which suggests I need 
>>>> "hamlib-python", but I
>>>> can't find where the AI has scooped up this information.
>>>> If anybody can point me at installation instructions and 
>>>> documentation for
>>>> the API, I would be grateful.
>>>> Thanks/73
>>>> Steve VK3SPX
>>>>
>>>>
>>>> _______________________________________________
>>>> Hamlib-developer mailing list
>>>> Ham...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/hamlib-developer
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Hamlib-developer mailing list
>>> Ham...@li...
>>> https://lists.sourceforge.net/lists/listinfo/hamlib-developer
>>
>>
>> _______________________________________________
>> Hamlib-developer mailing list
>> Ham...@li...
>> https://lists.sourceforge.net/lists/listinfo/hamlib-developer

Re: [Hamlib-developer] Python API

[Adrian <vk...@gm...>]

Well true, you can use rigctl direct to radio or rigctld server allowing 
lan / internet access.

I use rigctld with node-red full time .


73


vk4tux



On 30/3/25 22:25, Dave Baxter wrote:
>
> Not sure, but you don't need rigctld, to use rigctl. At least not in 
> my limited experience, only using hamlib on Linux.
>
> I'll have a play...
>
> 73.
> Dave
>
>
> On Sun, 30 Mar 2025, 13:19 Adrian, <vk...@gm...> wrote:
>
>     Isn't rigctl a rigctld client ? It works for me that way..
>
>     On 30/3/25 21:27, Dave Baxter via Hamlib-developer wrote:
>>
>>     Steve.
>>
>>     If you've already got "rigctld" open as a daemon in the
>>     background, you do not need to issue "rigctl" commands, just open
>>     a TCP socket to the daemon, and issue commands, and receive
>>     status replies via that route.
>>
>>     rigctld and rigctl are different animals.
>>
>>     You can have also more than one rigctld running, listening on
>>     different TCP/IP ports, for different radio's.
>>
>>     As Erik wrote, they can even be on a different machine, so long
>>     as the address/port is accessible from "your" machine, the radio
>>     and it's local computer (even a Pi) could be the other side of
>>     the planet if needed.
>>
>>     Python is very network friendly in that way, and it works very
>>     well too.   "localhost:port" is your friend...
>>
>>     This crude code below, is what I used a while ago to get the old
>>     FT-736r to appear as a readable radio, to keep gpredict happy
>>     back in the hamlib 3.3 days.   No longer needed with hamlib 4.x
>>
>>     ------------------------------------------------------------------------
>>
>>     import socket
>>
>>     def Main():
>>
>>     #    Local temporary string storage.
>>         subfreq = "435000000"
>>         mainfreq = "145000000"
>>
>>     #    GPredict side host:port
>>     #    Well away from any default Hamlib port.
>>         gphost = 'localhost'
>>         gpport = 50000
>>
>>     #    HamLib side host:port
>>     #    Well away from any default Hamlib port.
>>         hlhost = 'localhost'
>>         hlport = 50736
>>
>>     #    Create a Server socket for GPredict to connect to as a client.
>>         gpSocket = socket.socket()
>>         gpSocket.bind((gphost,gpport))
>>         gpSocket.listen(3)
>>         print ("FT-736 Helper listening on port " + str(gpport))
>>
>>     #    Create a Client socket, to connect to the HamLib server.
>>     #    NOTE!  rigctld MUST be started before this script is run!
>>     #    Like this...
>>
>>     #    $ rigctld -m110 -r /dev/ttyUSB4 -s 4800 -T localhost -t 50736
>>     #   (post HamLib 4.x use -m1010 for the model number.)
>>
>>         while True:
>>             gpconn, gpaddr = gpSocket.accept()
>>     #        print ("Connection from: " + str(gpaddr).rstrip())
>>
>>             # The Hamlib backend will automatically have done this,
>>     but it
>>             # will be needed if we turn CAT off, when Gpredict
>>     "Disengages"
>>             # and we later "Engage" the radio.
>>             # Not needed for Hamlib 3.3 or later, it does the right thing
>>             # by default.
>>
>>     #        hlcmd = "w \\0x00\\0x00\\0x00\\0x00\\0x00\n"
>>     #        print ("Sending " + hlcmd)
>>     #        hlSocket.sendall(hlcmd.encode())
>>
>>     #        NOTE!  If this is used, rigctld "Expects" a reply from
>>     the rig,
>>     #        that will never arrive.  So there will be a delay of
>>     some 2 seconds
>>     #        or more before it returns to us.
>>
>>             hlSocket = socket.socket()
>>             hlSocket.connect((hlhost,hlport))
>>             print ("Linked to rigctld")
>>
>>             while True:
>>                     gpcmd = gpconn.recv(1024).decode()
>>                     if not gpcmd:
>>                             break
>>                     print ("From Gpredict: " + gpcmd.rstrip())
>>
>>                     if gpcmd[0] == "F":
>>                         # Set Main frequency: Remember the value.
>>                         mainfreq = (gpcmd[1:]).lstrip()
>>                         # code here to send to Hamlib
>>                         hlSocket.sendall(gpcmd.encode())
>>                         reply = hlSocket.recv(1024).decode()
>>     #                    print ("To   Gpredict: " + reply.rstrip())
>>                         gpconn.sendall(reply.encode())
>>
>>                     elif gpcmd[0] == "I":
>>                         # Set Sub frequency: Remember the value.
>>                         subfreq = (gpcmd[1:]).lstrip()
>>                         # code here to send to Hamlib
>>                         hlSocket.sendall(gpcmd.encode())
>>                         reply = hlSocket.recv(1024).decode()
>>     #                    print ("To   Gpredict: " + reply.rstrip())
>>                         gpconn.sendall(reply.encode())
>>
>>                     elif gpcmd[0] == "f":
>>                         # fake read of the main frequency
>>                         reply = mainfreq + "\n"
>>     #                    print ("To   Gpredict: " + reply.rstrip())
>>                         gpconn.sendall(reply.encode())
>>
>>                     elif gpcmd[0] == "i":
>>                         # fake read of the sub frequency
>>                         reply = subfreq + "\n"
>>     #                    print ("To   Gpredict: " + reply.rstrip())
>>                         gpconn.sendall(reply.encode())
>>
>>                     elif gpcmd[0] == "q":
>>                         print ("Unlinking from rigctld")
>>     #                    hlcmd = "w \\0x00\\0x00\\0x00\\0x00\\0x80\n"ri
>>     #                    See earlier notes at lines 45 and 55.
>>     hlSocket.sendall(gpcmd.encode())    # or hlcmd
>>
>>                     else:
>>                         hlSocket.sendall(gpcmd.encode())
>>                         reply = hlSocket.recv(1024).decode()
>>     #                    print ("To   Gpredict: " + reply.rstrip())
>>                         gpconn.sendall(reply.encode())
>>
>>             gpconn.close()
>>
>>
>>     if __name__ == '__main__':
>>         Main()
>>
>>     ------------------------------------------------------------------------
>>
>>     Heck, if I can do it, etc...   No need to comment on bad Python
>>     practices, this was all my own work mistookes included, but it
>>     worked very well indeed.
>>
>>     As above, no longer needed for the Hamlib 4.x, the local
>>     frequency memory is now implemented within the hamlib backend for
>>     the 736, and also it keeps the rig CAT port open between so long
>>     as at least one application itself stays connected to that
>>     instance of rigctld (if just to avoid the annoying beeps from the
>>     rig!)
>>
>>     I could never find a reliable way to detect if the needed daemon
>>     was already running and if not, start it from within Python,
>>     though I'm sure it can be done, just the doc's are somewhat
>>     impenetrable to someone who is not a pro snake charmer!.
>>
>>     That code was itself invoked from a bash script that started the
>>     daemon, started the Python helper tool, and then launched Gpredict.
>>
>>     Killing stuff off in the reverse order, when Gpredict was itself
>>     exited/ended.
>>
>>     Best of all, it is entirely cross platform, others used it on
>>     various Windows machines, while I was doing this on Linux.
>>
>>     73.
>>
>>     Dave G0WBX.
>>
>>
>>     On 30/03/2025 08:53, Stephen Pattinson via Hamlib-developer wrote:
>>>     Hi Erik,
>>>     Thanks for responding.
>>>     My Python 3 app is starting rigctld effectively in the
>>>     background using the subprocessPopen()  mechanism. Then to
>>>     retrieve parameters from the radio, it is running
>>>     subprocess.Run() which effectively executes "rigctl -m 2 f" for
>>>     example to get the VFO frequency by capturing the response, but
>>>     firing off a windows EXE program every second is pretty awful. I
>>>     assumed I could via the API I assumed was available, open a
>>>     channel/pipe/whatever and effectively do what ever rigctl is
>>>     doing internally.
>>>     I've looked at the API references and web pages, but they seem
>>>     convulsively C. I see tantalizing references to python bindings
>>>     (I'm not sure what that means) and in the Debian world I see a
>>>     python3-hamlib library, but of course I'm looking for a Windows
>>>     solution.
>>>     Am I looking for something that doesn't exist Erik?
>>>     73 Steve
>>>     VK3SPX
>>>
>>>
>>>     On 30/03/2025 18:32, Erik Icket wrote:
>>>>     Hi Steve,
>>>>
>>>>     One way to obtain a better segregation between your Python app
>>>>     and the rig,
>>>>     is to go via the rigctld daemon.
>>>>     Once the daemon runs (local or remote), you may open a socket
>>>>     to it and
>>>>     issue your commands.
>>>>     For example, to know the frequency, just issue a write to
>>>>     socket with "f\n"
>>>>     contents.
>>>>
>>>>     It is not a straight program to rig interface, as you are
>>>>     looking for.
>>>>     However, it does not require to launch the rigctl app each time
>>>>     you issue a
>>>>     command.
>>>>
>>>>     g'day !
>>>>     Erik
>>>>     ON4PB
>>>>
>>>>     -----Original Message-----
>>>>     From: Stephen Pattinson via Hamlib-developer
>>>>     <ham...@li...>
>>>>     <mailto:ham...@li...>
>>>>     Sent: Saturday, 29 March 2025 09:06
>>>>     To: ham...@li...
>>>>     Subject: [Hamlib-developer] Python API
>>>>
>>>>     Hi,
>>>>     I have written a Python (3.12.3) to talk to my IC7300 via Hamlib
>>>>     (V4.6.2) in a Windows 10 environment, but I'm just issuing
>>>>     "rigctl"
>>>>     commands and capturing the response. This works fine, but it's
>>>>     rather crude.
>>>>     Of course I would like to use the API which I believe is
>>>>     available, but I
>>>>     cannot find how to download the necessary additional software
>>>>     or library, or
>>>>     find the documentation for the Python API.
>>>>     I have looked at
>>>>     "https://hamlib.sourceforge.net/manuals/4.3/index.html"
>>>>     <https://hamlib.sourceforge.net/manuals/4.3/index.html>, but
>>>>     this seems
>>>>     exclusively C Ironically, the most pertinent info I retrieved
>>>>     from a search
>>>>     is from the Google AI (Sigh!) which suggests I need
>>>>     "hamlib-python", but I
>>>>     can't find where the AI has scooped up this information.
>>>>     If anybody can point me at installation instructions and
>>>>     documentation for
>>>>     the API, I would be grateful.
>>>>     Thanks/73
>>>>     Steve VK3SPX
>>>>
>>>>
>>>>     _______________________________________________
>>>>     Hamlib-developer mailing list
>>>>     Ham...@li...
>>>>     https://lists.sourceforge.net/lists/listinfo/hamlib-developer
>>>>
>>>
>>>
>>>
>>>     _______________________________________________
>>>     Hamlib-developer mailing list
>>>     Ham...@li...
>>>     https://lists.sourceforge.net/lists/listinfo/hamlib-developer
>>
>>
>>     _______________________________________________
>>     Hamlib-developer mailing list
>>     Ham...@li...
>>     https://lists.sourceforge.net/lists/listinfo/hamlib-developer
>