Thread: [Hamlib-developer] Python API
Library to control radio transceivers and receivers
Brought to you by:
n0nb
Menu
▾
▴
hamlib-developer
|
From: Stephen P. <st...@bi...> - 2025-03-29 08:18:51
|
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 |
|
From: Erik I. <run...@gm...> - 2025-03-30 07:32:22
|
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 |
|
From: Stephen P. <st...@bi...> - 2025-03-30 08:06:27
|
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 > |
|
From: Erik I. <run...@gm...> - 2025-03-30 20:21:37
|
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 > |
|
From: Dave B. <g8k...@go...> - 2025-03-30 11:57:50
|
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 |
|
From: Stephen P. <st...@bi...> - 2025-04-01 04:37:24
|
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. |
|
From: Adrian <vk...@gm...> - 2025-03-30 12:20:05
|
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 |
|
From: Dave B. <g8k...@go...> - 2025-03-30 14:17:19
|
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 |
|
From: Nate B. <n0...@n0...> - 2025-03-30 17:38:21
Attachments:
signature.asc
|
* 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 |
|
From: Dave B. <g8k...@go...> - 2025-03-30 12:32:38
|
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
>
>
|
|
From: Adrian <vk...@gm...> - 2025-03-30 12:43:55
|
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
> |
|
From: George B. <geo...@gm...> - 2025-03-31 08:44:32
|
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 |
|
From: Stephen P. <st...@bi...> - 2025-04-01 04:43:51
|
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 |
|
From: George B. <geo...@gm...> - 2025-03-31 18:29:42
|
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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X