hamlib-developer — hamlib developers forum

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
>

Re: [Hamlib-developer] Python API

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

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...>
> <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 lis...@li...://lists.sourceforge.net/lists/listinfo/hamlib-developer
>
>

Re: [Hamlib-developer] Python API

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

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

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

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

Re: [Hamlib-developer] Python API

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

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

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

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

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

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] [Hamlib/Hamlib] ad2066: Fix headers for compability with swig 4.3.0

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

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: ad20668c752e61e8866891adc29c339dbca6a33d
      https://github.com/Hamlib/Hamlib/commit/ad20668c752e61e8866891adc29c339dbca6a33d
  Author: Michael Black W9MDB <mdb...@ya...>
  Date:   2025-03-22 (Sat, 22 Mar 2025)

  Changed paths:
    M include/hamlib/riglist.h
    M include/hamlib/rotlist.h

  Log Message:
  -----------
  Fix headers for compability with swig 4.3.0
https://github.com/Hamlib/Hamlib/issues/1669


  Commit: 44014b914ea69c7418569a1f7b6b55711aeaa81a
      https://github.com/Hamlib/Hamlib/commit/44014b914ea69c7418569a1f7b6b55711aeaa81a
  Author: Michael Black W9MDB <mdb...@ya...>
  Date:   2025-03-22 (Sat, 22 Mar 2025)

  Changed paths:
    M doc/man1/rigctl.1
    M doc/man1/rigctld.1
    M rigs/kenwood/kenwood.c
    M src/rig.c

  Log Message:
  -----------
  Merge branch 'master' of github.com:Hamlib/Hamlib


Compare: https://github.com/Hamlib/Hamlib/compare/9fe15f396312...44014b914ea6

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

[Hamlib-developer] How to get iOptron mount working with Gpredict

[pd2ch 2. <mai...@gm...>]

Hi,
I tried a lot a was reading as much as possible on the net how to connect
my iOptron AZpro mount to Gpredict.
Running Lubuntu with Hamlib and Gpredict installed.
When I run this cmd I get the following message:

pd2ch@pd2ch-CF-C2:~$ rotctld -m 1901 -r /dev/ttyUSB0 -s 9600 -C timeout=500
> -vvv -T localhost -t 4533
> read_block_generic(): Timed out 0.500598 seconds after 0 chars, direct=1
> read_block_generic(): Timed out 0.500565 seconds after 0 chars, direct=1
> ioptron_transaction: unexpected response, len -5: ''
> rot_open: error = serial_setup: stopbits=1
> serial_setup: parity=0
> serial_setup: Handshake=None
> serial_setup: tcsetattr TCSANOW
> read_string_generic called, rxmax=4095 direct=1, expected_len=1
> ser_set_dtr: DTR=0
> ser_set_rts: RTS=0
> ioptron_open called
> ioptron_get_info called
> read_string_generic called, rxmax=4095 direct=1, expected_len=1
> write_block(): TX 11 bytes
> read_block_generic called, direct=1
> read_block_generic(): Timed out 0.500598 seconds after 0 chars, direct=1
> read_string_generic called, rxmax=4095 direct=1, expected_len=1
> write_block(): TX 11 bytes
> read_block_generic called, direct=1
> read_block_generic(): Timed out 0.500565 seconds after 0 chars, direct=1
> ioptron_transaction: unexpected response, len -5: ''
> retval, RIG_OK str -8  0  tr
> Communication timed out
>
>
In Gpredict I see a error popping up when I engage the rotator. The mount
is connected via a usb serial cable to my laptop. (wifi is also 'on' on the
mount, but now idea how to set this connection up.)

Any help or advice is welcome!
Thanks in advance,

Kees.

[Hamlib-developer] [Hamlib/Hamlib] e00f35: Fix my previous commit ("Add bold" d9545845)

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

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: e00f3575697d8258fb88745d428b77fff75f1095
      https://github.com/Hamlib/Hamlib/commit/e00f3575697d8258fb88745d428b77fff75f1095
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-03-17 (Mon, 17 Mar 2025)

  Changed paths:
    M doc/man1/rigctld.1

  Log Message:
  -----------
  Fix my previous commit ("Add bold" d9545845)


  Commit: 9fe15f396312dca878435ed4ed1121a3928bd025
      https://github.com/Hamlib/Hamlib/commit/9fe15f396312dca878435ed4ed1121a3928bd025
  Author: Michael Black <mdb...@ya...>
  Date:   2025-03-17 (Mon, 17 Mar 2025)

  Changed paths:
    M doc/man1/rigctld.1

  Log Message:
  -----------
  Merge pull request #1683 from dforsi/fix/typos

Fix my previous commit ("Add bold" d9545845)


Compare: https://github.com/Hamlib/Hamlib/compare/c6a30081cbc3...9fe15f396312

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

Re: [Hamlib-developer] [Hamlib/Hamlib] e109fe: Fix typos

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

George Baltz

> This has changed some of the references to 'rigctld' to 'rigctl' in the
> rigctld.1 man page.  Is that what was wanted?

no, that was by mistake repeated with copy and paste!

thanks for reporting it,
-- 
73 de IU5HKX Daniele

Re: [Hamlib-developer] [Hamlib/Hamlib] e109fe: Fix typos

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

This has changed some of the references to 'rigctld' to 'rigctl' in the 
rigctld.1 man page.  Is that what was wanted?


On 3/16/25 6:11 PM, Michael Black via Hamlib-developer wrote:
>    Branch: refs/heads/master
>    Home:   https://github.com/Hamlib/Hamlib
>    Commit: e109fe355d0fb4f1da9fc0dcb3dc5a304f08a771
>        https://github.com/Hamlib/Hamlib/commit/e109fe355d0fb4f1da9fc0dcb3dc5a304f08a771
>    Author: Daniele Forsi IU5HKX <iu...@gm...>
>    Date:   2025-03-16 (Sun, 16 Mar 2025)
>
>    Changed paths:
>      M doc/man1/rigctl.1
>      M doc/man1/rigctld.1
>
>    Log Message:
>    -----------
>    Fix typos
>
>
>    Commit: cb0196875b1580cdef6cd8748eed8f84b305a173
>        https://github.com/Hamlib/Hamlib/commit/cb0196875b1580cdef6cd8748eed8f84b305a173
>    Author: Daniele Forsi IU5HKX <iu...@gm...>
>    Date:   2025-03-16 (Sun, 16 Mar 2025)
>
>    Changed paths:
>      M doc/man1/rigctl.1
>      M doc/man1/rigctld.1
>
>    Log Message:
>    -----------
>    Fix underline and italics
>
>
>    Commit: 2da07e484c5162a8ed8e3be2395452c2b21a0bcb
>        https://github.com/Hamlib/Hamlib/commit/2da07e484c5162a8ed8e3be2395452c2b21a0bcb
>    Author: Daniele Forsi IU5HKX <iu...@gm...>
>    Date:   2025-03-16 (Sun, 16 Mar 2025)
>
>    Changed paths:
>      M doc/man1/rigctld.1
>
>    Log Message:
>    -----------
>    Escape literal \n
>
> Otherwise it isn't rendered correctly.
>
>
>    Commit: cd72187a7cc99c0168f6150de7cb21dbed7801d5
>        https://github.com/Hamlib/Hamlib/commit/cd72187a7cc99c0168f6150de7cb21dbed7801d5
>    Author: Daniele Forsi IU5HKX <iu...@gm...>
>    Date:   2025-03-16 (Sun, 16 Mar 2025)
>
>    Changed paths:
>      M doc/man1/rigctl.1
>      M doc/man1/rigctld.1
>
>    Log Message:
>    -----------
>    Fix usage of .EX
>
> Add missing .EE and remove some .EE that were out of place.
>
>
>    Commit: 0e1e794cfa569c8994ab98a75d133a1fb6b3fbb3
>        https://github.com/Hamlib/Hamlib/commit/0e1e794cfa569c8994ab98a75d133a1fb6b3fbb3
>    Author: Daniele Forsi IU5HKX <iu...@gm...>
>    Date:   2025-03-16 (Sun, 16 Mar 2025)
>
>    Changed paths:
>      M doc/man1/rigctl.1
>      M doc/man1/rigctld.1
>
>    Log Message:
>    -----------
>    Set parameter keywords bold, not their descriptions
>
>
>    Commit: d9545845b01b830f4aa5470e842e754ca023484a
>        https://github.com/Hamlib/Hamlib/commit/d9545845b01b830f4aa5470e842e754ca023484a
>    Author: Daniele Forsi IU5HKX <iu...@gm...>
>    Date:   2025-03-16 (Sun, 16 Mar 2025)
>
>    Changed paths:
>      M doc/man1/rigctld.1
>
>    Log Message:
>    -----------
>    Add bold
>
>
>    Commit: c6a30081cbc3752ef1c904512ff4bbf8b2fe9e03
>        https://github.com/Hamlib/Hamlib/commit/c6a30081cbc3752ef1c904512ff4bbf8b2fe9e03
>    Author: Michael Black <mdb...@ya...>
>    Date:   2025-03-16 (Sun, 16 Mar 2025)
>
>    Changed paths:
>      M doc/man1/rigctl.1
>      M doc/man1/rigctld.1
>
>    Log Message:
>    -----------
>    Merge pull request #1682 from dforsi/fix/manpages
>
> Fix manpages
>
>
> Compare: https://github.com/Hamlib/Hamlib/compare/0f519185acd7...c6a30081cbc3
>
> To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer

[Hamlib-developer] [Hamlib/Hamlib] e109fe: Fix typos

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

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: e109fe355d0fb4f1da9fc0dcb3dc5a304f08a771
      https://github.com/Hamlib/Hamlib/commit/e109fe355d0fb4f1da9fc0dcb3dc5a304f08a771
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-03-16 (Sun, 16 Mar 2025)

  Changed paths:
    M doc/man1/rigctl.1
    M doc/man1/rigctld.1

  Log Message:
  -----------
  Fix typos


  Commit: cb0196875b1580cdef6cd8748eed8f84b305a173
      https://github.com/Hamlib/Hamlib/commit/cb0196875b1580cdef6cd8748eed8f84b305a173
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-03-16 (Sun, 16 Mar 2025)

  Changed paths:
    M doc/man1/rigctl.1
    M doc/man1/rigctld.1

  Log Message:
  -----------
  Fix underline and italics


  Commit: 2da07e484c5162a8ed8e3be2395452c2b21a0bcb
      https://github.com/Hamlib/Hamlib/commit/2da07e484c5162a8ed8e3be2395452c2b21a0bcb
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-03-16 (Sun, 16 Mar 2025)

  Changed paths:
    M doc/man1/rigctld.1

  Log Message:
  -----------
  Escape literal \n

Otherwise it isn't rendered correctly.


  Commit: cd72187a7cc99c0168f6150de7cb21dbed7801d5
      https://github.com/Hamlib/Hamlib/commit/cd72187a7cc99c0168f6150de7cb21dbed7801d5
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-03-16 (Sun, 16 Mar 2025)

  Changed paths:
    M doc/man1/rigctl.1
    M doc/man1/rigctld.1

  Log Message:
  -----------
  Fix usage of .EX

Add missing .EE and remove some .EE that were out of place.


  Commit: 0e1e794cfa569c8994ab98a75d133a1fb6b3fbb3
      https://github.com/Hamlib/Hamlib/commit/0e1e794cfa569c8994ab98a75d133a1fb6b3fbb3
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-03-16 (Sun, 16 Mar 2025)

  Changed paths:
    M doc/man1/rigctl.1
    M doc/man1/rigctld.1

  Log Message:
  -----------
  Set parameter keywords bold, not their descriptions


  Commit: d9545845b01b830f4aa5470e842e754ca023484a
      https://github.com/Hamlib/Hamlib/commit/d9545845b01b830f4aa5470e842e754ca023484a
  Author: Daniele Forsi IU5HKX <iu...@gm...>
  Date:   2025-03-16 (Sun, 16 Mar 2025)

  Changed paths:
    M doc/man1/rigctld.1

  Log Message:
  -----------
  Add bold


  Commit: c6a30081cbc3752ef1c904512ff4bbf8b2fe9e03
      https://github.com/Hamlib/Hamlib/commit/c6a30081cbc3752ef1c904512ff4bbf8b2fe9e03
  Author: Michael Black <mdb...@ya...>
  Date:   2025-03-16 (Sun, 16 Mar 2025)

  Changed paths:
    M doc/man1/rigctl.1
    M doc/man1/rigctld.1

  Log Message:
  -----------
  Merge pull request #1682 from dforsi/fix/manpages

Fix manpages


Compare: https://github.com/Hamlib/Hamlib/compare/0f519185acd7...c6a30081cbc3

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

Re: [Hamlib-developer] rotctl connected to rotctld , Range problem min max

[Ben Z en de r. <hoo...@gm...>]

I solved this by upgrading hablib to version 4.5.4 on the Satnogs Pi
libhamlib, libhamlib-dev and libhamlib0utils, after which also
python3-hamlib needed to be updated.

Now all works great !

Op do 6 mrt 2025 om 09:27 schreef Ben Z en de rest <hoo...@gm...
>:

> Hi,
> I am updating some Arduino rotor control software with feedback of AZ and
> EL values when called (GS232 protocol, sending on C2 command sent by
> rotctld Pi to Arduino.
>
> So far, so good. Running rotctld on the rotor controlling Pi , and
> Gpredict on the remote PC it nicely tracks the satellites and shows the
> reported values of AZ and EL in the Gpredict window.
>
> Time to check the same controlling the remote Pi from my Satnogs Pi, which
> is going to control the AZ ./ EL motor.
>
> I run :
>  rotctl -m 2 -r 192.168.0.186:4533 -vvvvvvvvvv
>
>
> I get in return, as values:
>
> 0000    5c 64 75 6d 70 5f 73 74 61 74 65 0a                 \dump_state.
> read_string called, rxmax=64
> read_string(): RX 2 characters
> 0000    31 0a                                               1.
> read_string called, rxmax=64
> read_string(): RX 4 characters
> 0000    36 30 32 0a                                         602.
> read_string called, rxmax=64
> read_string(): RX 19 characters
> 0000    6d 69 6e 5f 61 7a 3d 2d 31 38 30 2e 30 30 30 30
> min_az=-180.0000
> 0010    30 30 0a                                            00.
> read_string called, rxmax=64
> read_string(): RX 18 characters
> 0000    6d 61 78 5f 61 7a 3d 34 35 30 2e 30 30 30 30 30
> max_az=450.00000
> 0010    30 0a                                               0.
> read_string called, rxmax=64
> read_string(): RX 16 characters
> 0000    6d 69 6e 5f 65 6c 3d 30 2e 30 30 30 30 30 30 0a
> min_el=0.000000.
> read_string called, rxmax=64
> read_string(): RX 18 characters
> 0000    6d 61 78 5f 65 6c 3d 31 38 30 2e 30 30 30 30 30
> max_el=180.00000
> 0010    30 0a                                               0.
> Opened rot model 2, 'NET rotctl'
> Backend version: 20200528.0, Status: Stable
>
>
> So, at rotator command prompt I enter p (to get position) which results in
>
> rot_get_position: got az=135.00, el=29.00
> Azimuth: 135.00
> Elevation: 29.00
>
> So, now trying to send the AZ EL to 50 50 with P 50 50 which results in
>
> rotctl_parse: input_line: P 50 50
> rot_set_position called az=50.00 el=50.00
> rot_set_position: south_zero=0
> rot_set_position: range problem az=50.00(min=0.00,max=0.00),
> el=50.000000(min=0.00,max=0.000000)
> set_pos: error = Invalid parameter
>
>
> So, the first report when starting tells me I can set AZ and EL within
> certain ranges, but when setting it says de min and max values are zero ?
>
> Terminating the rotctl connection on that pi, and sending:
>
> pi@raspberrypi:~ $ echo "\set_pos 50.0 50.0" | nc -w 1 192.168.0.186 4533
>
> starts setting the AZ and EL of the motor to the requested problems.
>
> What am I possibly overlooking ?
>
> Thanks,
> Ben
>
>
>
>
>
>