Icom 7300 with Openwebrx with Hamlib Radio-Control

n6vkz — Mon, 20 Apr 2026 10:00:04 -0000

Hello everyone,
I am very new with groups Discussion Group about software, I am not a programmer. I would like the Gui to work with Icom 7300 like the SDR web page work.
I am attempting to install Openwebrx with Hamlib in the background to connect to my Icom 7300. All other software in the past has work that has Hamlib, for example FLDIGI, and other FL .. items. WSVIEW also works.
Openwebrx works great with with SDR dongle RTL , Yet, I want to it to work with Icom 7300 because it allow many ham radio packages to work together. Many that were created with Hamlib.
Yes, from the text line I have tested it with hamlib-util . My results were these:

rigctl -r 127.0.0.1 -m 3073 -s 19200 -p 4533
no reply

rigctl -r 127.0.0.1:4533 -m 3073 -s 19200 -p 4533

rigctl -r 127.0.0.1:8073 -m 3073 -s 19200 -p 4533

rigctld -r 127.0.0.1 -m 3073 -s 19200 -p 4533
^Crig_open: error = rig_init: rig has VFO_A
rig_init: rig has VFO_B
rig_init: rig has VFO_MEM
rig.c(994) trace
1:icom.c(707):icom_init entered
1:icom.c(777):icom_init returning(0)
rig_set_conf called
main: twiddle=0, uplink=0, twiddle_rit=0
main: defaulting to RTS PTT
rig.c(1050):rig_open entered
rig_settings_get_path: path=/home/yf3vkz4hamradio/.config/hamlib_settings
rig_open: async_data_enable=0, async_data_supported=1
rig_open: using network address 127.0.0.1
network_open: TCP connect
network_open: hoststr=127.0.0.1, portstr=
connect to 127.0.0.1 failed, (trying next interface): Network error 111: Connection refused
network_open: failed to connect to 127.0.0.1
rig.c(1284):rig_open returning2(-6) IO error

IO error
127.0.0.1 Connection refused

Terminating application, caught signal 2

rigctl -r 127.0.0.1:8073 -m 3073 -R /dev/ttyUSB0 -s 19200 -p 4533
rigctl: invalid option -- 'R'
Usage: rigctl [OPTION]... [-m ID] [-r DEVICE] [-s BAUD] [COMMAND...|-]
Send COMMANDs to a connected radio transceiver or receiver.

Type: rigctl --help for extended usage.

rigctlcom -r 192.168.0.6:4533 -m 3073 -R /dev/ttyUSB0 -s 115200 -p 8080
rigctlcom Version 1.6
rig_open: error = rig_init: rig_model=Icom IC-7300 20250517.14
Requesting 47928 bytes for rig_struct
Requesting 728 bytes for rig_cache
rig_init: rig has VFO_A
rig_init: rig has VFO_B
rig_init: rig has VFO_MEM
rig.c(994) trace
1:icom.c(707):icom_init entered
1:icom.c(777):icom_init returning(0)
rig.c(1050):rig_open entered
rig_settings_get_path: path=/home/yf3vkz4hamradio/.config/hamlib_settings
rig_open: async_data_enable=0, async_data_supported=1
rig_open: using network address 192.168.0.6:4533
network_open: TCP connect
network_open: hoststr=192.168.0.6, portstr=4533
connect to 192.168.0.6:4533 failed, (trying next interface): Network error 110: Connection timed out
network_open: failed to connect to 192.168.0.6:4533
rig.c(1284):rig_open returning2(-6) IO error

IO error

https://fms.komkon.org/OWRX/#INSTALL-PACKAGES (Refer to his Git pages in the web page )

The source code rigcontrol.py :

from owrx.feature import FeatureDetector
from owrx.property import PropertyStack
from owrx.config import Config
from subprocess import Popen, PIPE, STDOUT, TimeoutExpired

import threading
import select
import os

import logging

logger = logging.getLogger(name)

class RigControl():
# Mapping from rig names to Rigctl rig types (in the list)
"Icom IC-7300" : 3073,

  # Mapping from OpenWebRX modulations to Rigctl modulations
MODES = {
    "nfm"  : "FM",     "wfm"  : "WFM",
    "am"   : "AM",     "sam"  : "SAM",
    "lsb"  : "LSB",    "usb"  : "USB",
    "lsbd" : "PKTLSB", "usbd" : "PKTUSB",
    "cw"   : "CWR",
}

def __init__(self, props: PropertyStack):
    pm = Config.get()
    self.enabled = pm["rig_enabled"]
    self.rigctl  = None
    self.thread  = None
    self.mod     = None
    self.fCenter = None
    self.fOffset = None
    self.subscriptions = [
        props.wireProperty("offset_freq", self.setFrequencyOffset),
        props.wireProperty("center_freq", self.setCenterFrequency),
        props.wireProperty("rig_enabled", self.setRigEnabled),
        props.wireProperty("mod", self.setDemodulator),
    ]
    super().__init__()
    # Start RigControl if enabled
    if self.enabled:
        self.enabled = self.rigStart()

def stop(self):
    for sub in self.subscriptions:
        sub.cancel()
    self.subscriptions = []
    self.rigStop()

def setFrequencyOffset(self, offset: int) -> None:
    if self.fCenter is not None and offset != self.fOffset:
        self.rigFrequency(self.fCenter + offset)
        self.fOffset = offset

def setCenterFrequency(self, center: int) -> None:
    self.fCenter = center
    self.fOffset = None

def setDemodulator(self, mod: str) -> None:
    if mod != self.mod:
        self.rigModulation(mod)
        self.mod = mod

def setRigEnabled(self, enabled: bool) -> None:
    if enabled != self.enabled:
        self.enabled = enabled
        if enabled:
            self.enabled = self.rigStart()
        else:
            self.rigStop()

# Press or release rig's PTT (i.e. transmit)
def rigTX(self, active: bool) -> bool:
    return self.rigCommand("T {0}".format(1 if active else 0))

# Set rig's frequency
def rigFrequency(self, freq: int) -> bool:
    return self.rigCommand("F {0}".format(freq))

# Set rig's modulation
def rigModulation(self, mod: str) -> bool:
    if mod in self.MODES:
        return self.rigCommand("M {0} 0".format(self.MODES[mod]))
    else:
        return False

# Start Rigctl and associated thread
def rigStart(self):
    # Do not start twice
    if self.rigctl is not None:
        return True
    # Must have Hamlib/Rigctl installed
    if not FeatureDetector().is_available("rigcontrol"):
        return False
    # Must have rig control enabled
    if not self.enabled:
        return False
    # Compose Rigctl command
    pm = Config.get()
    address = pm["rig_address"]
    cmd = [
        "rigctl", "-m", str(pm["rig_model"]), "-r", pm["rig_device"]
    ] + (
        ["-c", str(address)] if address > 0 and address < 256 else []
    ) + ["-"]
    #cmd = ["rigctl", "-"] # @@@ REMOVE ME!!!!
    # Create Rigctl process, make stdout/stderr pipes non-blocking
    self.rigctl = Popen(cmd, stdin=PIPE, stdout=PIPE, stderr=PIPE, text=True)
    os.set_blocking(self.rigctl.stdout.fileno(), False)
    os.set_blocking(self.rigctl.stderr.fileno(), False)
    # Create and start thread
    self.thread = threading.Thread(target=self._rigThread, name=type(self).__name__)
    self.thread.start()
    # Clear current frequency and modulation
    self.mod     = None
    self.fCenter = None
    self.fOffset = None
    # Done
    logger.debug("Started RigControl as '{0}'.".format(" ".join(cmd)))
    return True

# Stop Rigctl and associated thread
def rigStop(self):
    # Do not stop twice
    if self.rigctl is None:
        return
    # If Rigctl still running...
    if self.rigctl.poll() is None:
        # Try terminating Rigctl normally, kill if failed
        logger.info("Stopping RigControl executable...")
        try:
            self.rigctl.terminate()
            self.rigctl.wait(3)
        except TimeoutExpired:
            self.rigctl.kill()
    # The thread should have exited, since Rigctl exited
    logger.info("Waiting for RigControl thread...")
    self.thread.join()
    logger.info("Stopped RigControl.")
    self.thread = None
    self.rigctl = None

# Send command to Rigctl
def rigCommand(self, cmd: str) -> bool:
    if self.rigctl is not None:
        if self.rigctl.poll() is not None:
            self.rigctl = None
            return False
        try:
            self.rigctl.stdin.write(cmd + "\n")
            self.rigctl.stdin.flush()
            logger.debug("Sent '{0}' to RigControl.".format(cmd))
            return True
        except Exception as e:
            logger.debug("Failed sending '{0}' to RigControl: {1}.".format(cmd, str(e)))
    # Failed to send command
    return False

# This thread function reads from Rigctl process' stdout/stderr
def _rigThread(self):
    # While process is running...
    while self.rigctl.poll() is None:
        try:
            # Wait for output from the process
            readable, _, _ = select.select([self.rigctl.stdout, self.rigctl.stderr], [], [])
            for pipe in readable:
                rsp = pipe.read().strip()
                logger.debug("STD{0}: {1}".format("ERR" if pipe==self.rigctl.stderr else "OUT", rsp))
        except Exception as e:
            logger.debug("Failed receiving from RigControl: {1}.".format(str(e)))

    # Process stopped
    logger.debug("RigControl process quit ({0}).".format(self.rigctl.poll()))

    I hope you can give me a solution step by step to fix this issue in using it on a local network directly to my Icom transceiver.

    Robert N6VKZ / YF3VKZ

Kenwood TS-480 (and others?) 2 VFO

Geoff Wiggins — Fri, 28 Nov 2025 16:25:34 -0000

Hi, did you ever find an answer to this? I have the same issue with IC-7610 only showing 1 VFO.
73 Geoff G4XMJ

HamLib 4 use-case from YO3HEX - C# application with wrapper

Gabriel Tudoran — Sun, 14 Sep 2025 07:03:19 -0000

Hello,

I really hope that this email will get to you.
My name is Dex (YO3HEX) and i'm working right now on quite a big project that would allow the remote operation of up to 2 transceivers without any PC on the remote side (that includes bidirectional streaming, cat 2 ethernet and a remote keyer just to name a few).
First of all I would like to give the team a big thank you for the impressive work that you've done.
In my case i'm working on a small PC application that would allow the use of the cat 2 ethernet endpoint to control various transceivers on the other side and this lib fitted as a glove - given the fact that i'm using C# as my main development platform (one of the main reasons being the GUI) i had to create a little bit of a wrapper to expose the DLL methods / functionalities in C# but, everything works as expected and as good as it gets - there were some small problems in regards to data serialization and to the fact that as far as i understand the lib is not necessary thread safe but nothing a good ol' mutex cannot solve.
There is a small thing that I would like to discuss if you have the time in regard to the power on and power off functionality that is present in the hamlib (yes i do understand quite well that there are some limitations).
The scenario is like this - regardless if using rigctl or my own software - but i will refer to rigctl because it is easier to test.

Scenario 1 - rig is in power on state (icom 7300 for example) and i connect to the rig using rigctl - i'm issuing a power off command which would bring the rig in power off state as expected, i'm issuing then a power on command that is bringing the rig in power on state as expected - so this is working as intended.

Scenario 2 - rig is in power off state - rigctl will cont connect to the rig - which i do think is kinda by design because it would be expected that the rig would reply with some data when rigctl tries to query it - but in case of many transceivers the cat interface would listen only for power on frames (which is the case of 7300 for example) and in this case would not reply to any other types of cat queries - in this scenario, if rigctl is disconnected from the rig after a power off there would be no way to turn it back on (maybe i'm wrong and there are other parameters that can be passed to rigctl which i might have missed or i do not know about - by no means i did not review the whole code of hamlib)

As a final word i'm sending you some screens with the application that i'm working on, which right now is on the development phase (mouse wheel would also allow to modify the VFO when mouse is over the VFO display) and yes everything works stellar - again thank you for the magnificent work that the team have done.

73 DE YO3HEX / YP3X
Dex

Problems using rotctld

Nate Bargmann — Sun, 10 Aug 2025 15:45:50 -0000

Did you try rotctl.exe stand alone as I suggested? Make sure any rotctld.exe processes are killed first.

Let's simplify this as much as possible. Also, please add -vvvvv to the command line.

Problems using rotctld

Achim Knierim — Tue, 05 Aug 2025 19:42:41 -0000

Thanks for the advice.

Some hours later without success...

I started rotctld in a commandline box
I started rotctl in another commandline box

If I paste P 20 20 into rotctl I can see rotctld is receiving data but rotor stays quite.

I think there is a problem with the speed of the COM-Port.
In the Documentation of Sarctrac I noticed it needs 9600.
starting rotctld -s 9600 will produce an error (invalid configuration)

So I cheked what happens with different connection speed using Putty.
Puty with 9600 works, I can controll Sarctrac
Puty with 19200 produce an error 31 (a connected device ist noch working)

It seems, that Sarctrac just accept 9600.
Cause rotctld -s 9600 will produce an error (invalid configuration), I think rotctld will not accept 9600
- It doesn't matter, if I set the Com-Port to 9600 or 19200 in the Devicemanager...

I checked that there just one process of rotctld and rotctl ist running and no other Program that may use the Com-Port. Putty is also closed when using the rot-commands.

What do you think about my thoughts, that rotctld has problems with speed of 9600?

Maybe I also should look for a Serialport-Monitor to see what happens when I use Putty @9600 and rotctld @19.200 ...

Problems using rotctld

Nate Bargmann — Mon, 04 Aug 2025 19:25:11 -0000

Using commandline
"C:\Program Files\hamlib-w64-4.5.5\bin\rotctld.exe" -m 202 -r COM6 -s 9600 -T 127.0.0.1 -t 4533 creates the error above.

Now changed to 19200 in the Config for COM6 and used -s 19200 and the commandline returns no error - I think I am a step ahead... But Rotor dosn't move at all..

Now tested:
"C:\Program Files\hamlib-w64-4.5.5\bin\rotctl.exe" -m 202 -r COM6 -s 19200 -t 4533
Got no error!

Did you kill the rotctld process before starting rotctl? If not, you have two programs in contention for the same serial port.

Make sure you have no rotctld process(es) running in Task Manager (or whatever they call it now). Then try:

"C:\Program Files\hamlib-w64-4.5.5\bin\rotctl.exe" -m 202 -r COM6 -s 9600

As I see it, unless the serial rate in the rotator controller has been changed, then 9600 is the rate that should be used. If 19200 works, then I suspect the controller setting has been changed and you'll need to use 19200 throughout.

If that succeeds, then close rotctl and start rotctld:

"C:\Program Files\hamlib-w64-4.5.5\bin\rotctld.exe" -m 202 -r COM6 -s 9600 -T 127.0.0.1 -t 4533

To have rotctl communicate with it, you'll use a different syntax than you used above:

"C:\Program Files\hamlib-w64-4.5.5\bin\rotctl.exe" -m 2 -r 127.0.0.1:4533

You can find an example at:

https://n0nb.users.sourceforge.net/man1/rotctl.1.html#EXAMPLES

Years back I learned that MS Windows doesn't seem to like localhost and works with 127.0.0.1. Perhaps that has changed.

Bear in mind that rotctld is using the serial port, and then rotctl is using the network loopback address to communicate to it. This should probably be explained more clearly in the manual page.

Finally, regarding serial speeds. Unless otherwise told, e.g. the -s option, Hamlib will select the fastest serial rate defined in the device's capability structure. Here is that part of the capabilities for rotator model 202:

Port type:      RS-232
Serial speed:       9600..19200 bauds, 8N1, ctrl=NONE
Write delay:        0ms, timeout 200ms, 3 retries
Post write delay:   0ms

Hope this helps.

Problems using rotctld

Achim Knierim — Mon, 04 Aug 2025 17:04:53 -0000

Thanks for replying, Nate.
CH340 is a USB Serial to WiFi-Adapter shipped with theSarctrac.
It connects the Rotor via COM-Interface by WiFi.
I can control the Rotor this way by Ham Radio Deluxe and by Putty - so it basicly works.

Using commandline
C:\Program Files\hamlib-w64-4.5.5\bin\rotctld.exe -m 202 -r COM6 -s 9600 -T 127.0.0.1 -t 4533 creates the error above.

Now changed to 19200 in the Config for COM6 and used -s 19200 and the commandline returns no error - I think I am a step ahead... But Rotor dosn't move at all..

Now tested:
"C:\Program Files\hamlib-w64-4.5.5\bin\rotctl.exe" -m 202 -r COM6 -s 19200 -t 4533
Got no error!

Rotator command: P
Azimuth: 30
Elevation: 30

Nothng happpens, so I'll check the current Position that should be at 0, 0

Rotator command: p
get_pos: error = easycomm_rot_set_position called: 30.000000 30.000000
easycomm_transaction called: AZ30.0 EL30.0

rig_flush: called for serial device
read_string_generic called, rxmax=4095 direct=1, expected_len=1
tcflush
write_block(): TX 14 bytes, method=2
rot_get_position called
easycomm_rot_get_position called
easycomm_transaction called: AZ EL

rig_flush: called for serial device
read_string_generic called, rxmax=4095 direct=1, expected_len=1
tcflush
write_block(): TX 7 bytes, method=2
read_string_generic called, rxmax=32 direct=1, expected_len=1
read_string_generic(): Timed out 0.481 seconds after 2 chars, direct=1
easycomm_transaction read_string failed with status -5
easycomm_rot_get_position got error: -5
Communication timed out

At https://www.sarcnet.org/sarctrac-mk3.html they wrote:
Rotator emulation - Serial protocol: AMSAT EasyCommII with position feedback - 9600/N/8/1.

Maybe hamlib won't accept 9600 and Sarctrac won't accept 19200?
But what I saw at other COM-Devices that it soesn't matter, what speed was selected it always worked...

Rig type FLRig seems to have a bad name

VK5PJ Peter Sumner — Sat, 02 Aug 2025 21:54:39 -0000

Hello,
what I can report back, is with the new HAMLIB DLL's it reports back extra information to WSJT-X in the form of the Rig type that is connected to FLRIG and that string is stored in the WSJT-X INI file. This extra information in the RIG= string of WSJT-X triggers some form of mis match error and forces it back to being the 1st rig type in the list ( ADAT )

When I start WSJT-X and select the entry for "W1HKJ FLRig" and save that, it is all runs fine for that session BUT what is stored in the INI file for WSJT-X is actually: "W1HKJ IC-7610(FLRig)"
it would seem that some where HAMLIB is reading the Rig type from FLRIg and then passing that along in the rig list array, which also has now dynamically changed to be "W1HKJ IC-7610(FLRig)" this cascades into an eventual mis match of information.

Is there any way to stop HAMLIB reading the extra information from FLRig so that the list of rigs will always be predictable?

Regards
Peter, vk5pj

Rig type FLRig seems to have a bad name

VK5PJ Peter Sumner — Sat, 02 Aug 2025 10:14:59 -0000

Hi Nate,
I grabbed the nightly build for 2025-08-02 (2nd Aug) and I can see the change of the name for the FLRIG entry, thanks. I am finding it still miss behaves when used with WSJT-X 2.7, It is hard to describe but no where as smooth as when I use the very old HAMLIB DLL so it seems there is some thing not quite right for me. If I go through all the setup for the rig and it works well but when I close WSJT-X and open it again, I am back to a RIG error and it defaults to the ADAT rig settings grrrr... not sure how to describe it any better right now. Will look again when I have had a sleep.

Peter Sumner, vk5pj

Rig type FLRig seems to have a bad name

VK5PJ Peter Sumner — Sat, 02 Aug 2025 03:02:42 -0000

Hi Nate,
thanks for the update, I have been swapping HAMLIB DLL's back and forth to try and work out where it went wrong, the only data points I have is one that works from back in 2023 (came with WSJT-X v2.61) and those that do not from 2024 (part of the ver 2.7x R.C stream) up to now (all were part of the WSJT-X packages) will have a look tomorrow or the next day to see what is in the nightly builds. I only just recently heard that Michael Black had died, which was very sad, he had always been a great help to us using HAMLIB as part of WSJT-X.
Regards,
Peter Sumner

Recent posts to Discussion

Icom 7300 with Openwebrx with Hamlib Radio-Control

Terminating application, caught signal 2

Type: rigctl --help for extended usage.

IO error

Kenwood TS-480 (and others?) 2 VFO

HamLib 4 use-case from YO3HEX - C# application with wrapper

Problems using rotctld

Problems using rotctld

Problems using rotctld

Problems using rotctld

Rig type FLRig seems to have a bad name

Rig type FLRig seems to have a bad name

Rig type FLRig seems to have a bad name