Re: [Hamlib-developer] Python API
Library to control radio transceivers and receivers
Brought to you by:
n0nb
Menu
▾
▴
Re: [Hamlib-developer] Python API
|
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
> |
