hamlib-developer — hamlib developers forum

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...https://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
>
>
>
>
>
>

[Hamlib-developer] [Hamlib/Hamlib] 5caa22: Add locking to rig_stop_morse

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

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: 5caa22b79a5532b2848a8e6689e0be2b36a94fde
      https://github.com/Hamlib/Hamlib/commit/5caa22b79a5532b2848a8e6689e0be2b36a94fde
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2025-03-04 (Tue, 04 Mar 2025)

  Changed paths:
    M src/rig.c

  Log Message:
  -----------
  Add locking to rig_stop_morse

and rig_wait_morse


  Commit: 9b2904c0b676dc4ed57bd09e300b6a1e81b930c8
      https://github.com/Hamlib/Hamlib/commit/9b2904c0b676dc4ed57bd09e300b6a1e81b930c8
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2025-03-04 (Tue, 04 Mar 2025)

  Changed paths:
    M rigs/kenwood/kenwood.c

  Log Message:
  -----------
  Fix timeout in kenwood_stop_morse

Add "KY0" to exceptions.


  Commit: a3e23e79cd97b4c48ea56cc2776b68d86db61a08
      https://github.com/Hamlib/Hamlib/commit/a3e23e79cd97b4c48ea56cc2776b68d86db61a08
  Author: George Baltz N3GB <Geo...@gm...>
  Date:   2025-03-04 (Tue, 04 Mar 2025)

  Changed paths:
    M src/rig.c

  Log Message:
  -----------
  Minor cleanups/fixes

Return status from rig_send_morse
Remove duplicate include and some dead code
Avoid future NULL dereference in error cases


  Commit: 0f519185acd7861412cb320e423145984ba05ab9
      https://github.com/Hamlib/Hamlib/commit/0f519185acd7861412cb320e423145984ba05ab9
  Author: Michael Black <mdb...@ya...>
  Date:   2025-03-12 (Wed, 12 Mar 2025)

  Changed paths:
    M rigs/kenwood/kenwood.c
    M src/rig.c

  Log Message:
  -----------
  Merge pull request #1676 from GeoBaltz/fix26a

More fixes for send_morse sync


Compare: https://github.com/Hamlib/Hamlib/compare/1049dc2457f2...0f519185acd7

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

[Hamlib-developer] [Hamlib/Hamlib] f8740d: Fix FTDX101D/MP ALC scale

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

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

  Changed paths:
    M rigs/yaesu/ftdx101.c
    M rigs/yaesu/ftdx101.h

  Log Message:
  -----------
  Fix FTDX101D/MP ALC scale


  Commit: 1049dc2457f2c90d47012da376836803b7c19dea
      https://github.com/Hamlib/Hamlib/commit/1049dc2457f2c90d47012da376836803b7c19dea
  Author: Michael Black W9MDB <mdb...@ya...>
  Date:   2025-03-12 (Wed, 12 Mar 2025)

  Changed paths:
    M rotators/skywatcher/skywatcher.h

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


Compare: https://github.com/Hamlib/Hamlib/compare/ed52875c3d69...1049dc2457f2

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

[Hamlib-developer] [Hamlib/Hamlib] c2d320: Update skywatcher.h - Added coordinates for parkin...

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

  Branch: refs/heads/master
  Home:   https://github.com/Hamlib/Hamlib
  Commit: c2d3202ffb0f4c51431b982ca023a586fcdbafc0
      https://github.com/Hamlib/Hamlib/commit/c2d3202ffb0f4c51431b982ca023a586fcdbafc0
  Author: gereta <355...@us...>
  Date:   2025-03-10 (Mon, 10 Mar 2025)

  Changed paths:
    M rotators/skywatcher/skywatcher.h

  Log Message:
  -----------
  Update skywatcher.h - Added coordinates for parking position

Added coordinates for parking position


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

  Changed paths:
    M rotators/skywatcher/skywatcher.h

  Log Message:
  -----------
  Merge pull request #1679 from gereta/patch-3

Update skywatcher.h - Added coordinates for parking position


Compare: https://github.com/Hamlib/Hamlib/compare/43f8afa6a4f1...ed52875c3d69

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

[Hamlib-developer] [Hamlib/Hamlib] 845a3a: Update skywatcher.c - park rotator, improved rotat...

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

  Branch: refs/heads/Hamlib-4.6.2
  Home:   https://github.com/Hamlib/Hamlib
  Commit: 845a3ac1d1b75e0b9ea7c4dea8770a1bc54f2497
      https://github.com/Hamlib/Hamlib/commit/845a3ac1d1b75e0b9ea7c4dea8770a1bc54f2497
  Author: gereta <355...@us...>
  Date:   2025-03-10 (Mon, 10 Mar 2025)

  Changed paths:
    M rotators/skywatcher/skywatcher.c

  Log Message:
  -----------
  Update skywatcher.c - park rotator, improved rotator movement

Added function to park the rotator.

Changed behavior for incoming requests to change position. If the motor is moving, the requests are silently ignored. Stopping the motor movement before each request to change position caused the movement from point A to point B to take a very long time because tracking applications send the dynamic position of the tracked object (e.g. satellite) in regular short intervals and in case the rotator was on the opposite side, by the time the rotator reached the position of the object, the object had traveled a considerable distance.


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

  Changed paths:
    M rotators/skywatcher/skywatcher.c

  Log Message:
  -----------
  Merge pull request #1680 from gereta/patch-2

Update skywatcher.c - park rotator, improved rotator movement


Compare: https://github.com/Hamlib/Hamlib/compare/73a2f2fa4617...c5d4baef5366

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

[Hamlib-developer] [Hamlib/Hamlib] f54e52: Update skywatcher.c

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

  Branch: refs/heads/Hamlib-4.6.2
  Home:   https://github.com/Hamlib/Hamlib
  Commit: f54e52342d3f785ffc09c159adaa2626fcca624b
      https://github.com/Hamlib/Hamlib/commit/f54e52342d3f785ffc09c159adaa2626fcca624b
  Author: gereta <355...@us...>
  Date:   2025-03-08 (Sat, 08 Mar 2025)

  Changed paths:
    M rotators/skywatcher/skywatcher.c

  Log Message:
  -----------
  Update skywatcher.c

Probably by mistake the call to read data from the serial port was left twice. Therefore, controlling Skywatcher mounts does not work and ends with a timeout. Otherwise, excellent work - since all Skywatcher mounts use the same motor controller firmware, it is possible to control not only Allview but all mounts from this manufacturer.


  Commit: 73a2f2fa4617a9c887fc7e2344fe4fbd6be78c86
      https://github.com/Hamlib/Hamlib/commit/73a2f2fa4617a9c887fc7e2344fe4fbd6be78c86
  Author: Michael Black <mdb...@ya...>
  Date:   2025-03-08 (Sat, 08 Mar 2025)

  Changed paths:
    M rotators/skywatcher/skywatcher.c

  Log Message:
  -----------
  Merge pull request #1677 from gereta/patch-1

Update skywatcher.c


Compare: https://github.com/Hamlib/Hamlib/compare/8703647c8cb2...73a2f2fa4617

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

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

[Ben Z en de r. <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

Re: [Hamlib-developer] Need help, rigctl utility is working but rigctld daemon is not working

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

On Wednesday, March 5, 2025 2:51:36 PM Eastern Standard Time Stephen Gabelich 
wrote:
> I’m having trouble getting rigctld to work
> 
> I’m running DragonOS and I currently have hamlib version 4.7 installed and
> my rig is a TX-500
> 
> rigctl -m 2050 -r /dev/ttyUSB0 <all commands> work
> rigctld -m 2050 -r /dev/ttyUSB0 nothing works; it hangs, i.e., does not

That's what it is supposed to do.  To use rigctld, start it as a background 
task, like:
rigctld -m 2050 -r /dev/ttyUSB0 &

Then, in your application(s), use "hamlib dummy" (model 2) and "localhost" to 
connect to rigctld

Maybe even easier - some of the logging apps will start rigctld for you.  I 
start it from cqrlog, and then other apps (wsjt, etc) can use the same 
rigctld.

> return to the command prompt
> 
> sudo systemctl restart rigctld  gave me this error (: Unit rigctld.service
> not found)
> 
> I created the following a file (someone else’s idea), which didn’t help
> /etc/systemd/system/rigctld.service
> [Unit]
> Description=rigctld Hamradio rig controler
> After=syslog.target network.target
> [Service]
> Type=simple
> ExecStart=/usr/bin/rigctld -m 2050 -r /dev/ttyUSB0
> User=rigctld
> Group=rigctld
> [Install]
> WantedBy=multi-user.target
> I’m not a Linux expert and I’m out of ideas
> Thanx
> Steve AJ6TL

-- 
73
N3GB

[Hamlib-developer] Need help, rigctl utility is working but rigctld daemon is not working

[Stephen G. <ste...@gm...>]

I’m having trouble getting rigctld to work

I’m running DragonOS and I currently have hamlib version 4.7 installed and my rig is a TX-500

rigctl -m 2050 -r /dev/ttyUSB0 <all commands> work
rigctld -m 2050 -r /dev/ttyUSB0 nothing works; it hangs, i.e., does not return to the command prompt

sudo systemctl restart rigctld  gave me this error (: Unit rigctld.service not found)

I created the following a file (someone else’s idea), which didn’t help
/etc/systemd/system/rigctld.service
[Unit]
Description=rigctld Hamradio rig controler
After=syslog.target network.target
[Service]
Type=simple
ExecStart=/usr/bin/rigctld -m 2050 -r /dev/ttyUSB0
User=rigctld
Group=rigctld
[Install]
WantedBy=multi-user.target
I’m not a Linux expert and I’m out of ideas
Thanx
Steve AJ6TL

[Hamlib-developer] [Hamlib/Hamlib] 43f8af: Add simicr8600

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

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

  Changed paths:
    M simulators/Makefile.am
    A simulators/simicr8600.c

  Log Message:
  -----------
  Add simicr8600



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