Rig Control for OpenHamClock (Idea & Request for Comments)

[ceotjoe]

Hi everyone,

I’ve been experimenting with adding basic Rig Control functionality to OpenHamClock and wanted to start a discussion about the approach and gather feedback.

The goal was to integrate rig control (frequency display, mode status, POTA/Cluster click-to-tune, and PTT) without overcomplicating the core React app or introducing heavy dependencies like direct serial port access in the browser.

The Approach: A Lightweight Local Bridge

Instead of building heavy rig control logic directly into the frontend, I implemented a small, lightweight Rig Daemon (Node.js) that runs locally on the user's machine (or a Raspberry Pi).

• Frontend: A RigContext provider and new panels (RigControlPanel, OnAirPanel) consume a simple local HTTP API.
• Backend: The daemon bridges this API to existing standard tools:
  • Hamlib (rigctld): For broad rig support via TCP.
  • flrig: For XML-RPC control (very common in digital modes).

Key Features

1. Bi-Directional Sync: Changing VFO or Mode on the radio updates the UI instantly, and vice versa.
2. Click-to-Tune: Clicking spots in the DX Cluster or POTA panels automatically tunes the radio to the spot's frequency.
   • Logic Refinement: I implemented smart mode mapping based on band plans (e.g., clicking a 20m FT8 spot sets DATA-U, 40m CW sets CW-L).
3. On-Air Indication: A new panel provides a large, clear TX status indicator for your shack.
4. Minimally Invasive: The changes to the core OpenHamClock code are minimal, mostly confined to new components and context providers.

Current Status & Testing

I have a working implementation in the feat/rig-control-minimal branch. It supports:

• Manual Frequency/Mode entry.
• PTT toggle.
• "Click-to-tune" toggles for triggering the ATU command (optional).
• Startup logging of supported modes from flrig.

Request for Comments

I’d love to hear your thoughts:

• Is a separate local daemon the right approach for you? (It keeps the browser secure and separates concerns).
• Are there failure modes or rig quirks I should account for (I currently handle DATA-U/L and CW-U/L)?
• Anyone willing to test with different rigs/setups?

You can check out the implementation here:

• Repository: HAMDevs/openhamclock
• Branch: feat/rig-control-minimal

Looking forward to your feedback!
73

[echo-gravitas]

Hi there @ceotjoe, I’m coming over from our discussion in my PR.

I’ve just tested the latest state of your fork, and I have to say: it works extremely well. Thanks a lot for this, really great work!

I noticed three things worth mentioning:

• Sometimes OHC sends SSB, FT4, FT8, DATA-L (and so on) to the /mode endpoint. In those cases, flrig and/or the transceiver don’t seem to know which mode to select and simply keep the currently active one.
• LSB, USB, CW, and AM work perfectly, with one odd exception:
  • Just now, when tuning to 14.220 MHz, AM was selected unexpectedly. I haven’t been able to fully narrow down why that happens yet.
• The 3-second delay before sending the tune command can feel a bit painful at times, it’s noticeable in day-to-day operation. 🤭

Other than that, I’d almost say we’re looking at a release candidate here. Excellent work, really impressive!

Thanks again for pushing this forward.

Edit: I'm also testing your minimal branch.

73

[ceotjoe]

@echo-gravitas I just pushed a new version of the minimal branch.

• Reduced modes to USB & LSB according to band plan, regardless if data, cw or ssb.
• Tuning delay is now configurable in daemon config file. Should also work with 0 ;-)

Happy to get feedback.

[ceotjoe]

@echo-gravitas I will do an update again this evening. Due to latest push of openhamclock main branch the implementation was broken again. I try to do the PR then also today. Otherwise this will be an ongoing issue, I guess. :-)

[echo-gravitas]

@echo-gravitas I will do an update again this evening. Due to latest push of openhamclock main branch the implementation was broken again. I try to do the PR then also today. Otherwise this will be an ongoing issue, I guess. :-)

Alright! I'm QRL at the moment, but I'll be able to test again this evening. I'm watching your branch and pushes closely. :-)

[ceotjoe]

@echo-gravitas curious how it runs on your end. There were some significant changes. SSE, adaption to current main branch.

[echo-gravitas]

@ceotjoe did you push already to main? There's no rig-control on main. What am I missing? 😅

[auroraonlineinc]

Hi, I tried it, verified that it talks to FLRIG by not running FLRIG and then starting it up and the rig-daemon responds, however trying localhost:5555 give me a CANNOT GET error. I did start the server in dev mode but I do not see the settings as you have described.

running an iCOM 7300 with flrig 2.0.07 and it works fine with WSJT-X, Server port on FLRIG XMLRPC port is 12345.

[ceotjoe]

Hi,

great you're testing it.

Could make some screens or logs of the errors (console log of daemon) you get and also of the section of rig control in the UI settings dialog.

Daemon, flrig and UI server are running on the same machine, right?

Are you using the current version of the branch I linked above? BTW: I tested with flrig 2.0.09 on Mac.

[auroraonlineinc]

Daemon and UI (openhamclock)) are on one server 10.10.10.200 flrig and wsjtx are on another 10.10.10.43 I adjusted the settings to specify where flrig was located. I know that the daemon is connecting to flrig because if I run the daemon first it waits till it can communicate with flrig, once I run flrig the daemon completes the onscreen details.

…

On Feb 11, 2026, at 3:00 AM, ceotjoe ***@***.***> wrote: Hi, could make some screens or logs of the errors (console log of daemon) you get and also of the section of rig control in the UI settings dialog. Daemon, flrig and UI server are running on the same machine, right? Are you using the current version of the branch I linked above? BTW: I tested with flrig 2.0.09 on Mac. — Reply to this email directly, view it on GitHub <#306 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BP7X7ELT4KOUU2XXRMZEVFT4LLOP3AVCNFSM6AAAAACUSXELSSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKNZWGU2TMOA>. You are receiving this because you commented.

[ceotjoe]

Where do you get this error message exactly? In the browser? Would really nice to have the screenshots I asked for to have a better impression.

BTW: Are you on Windows, Mac or Linux? Which browser are you using?

[auroraonlineinc]

I just installed your rig-control on my windows system that has flrig and wsjtx, ip is 10.10.10.43 On that same windows system I open a chrome browser and goto localhost:5555 and I get the message Cannot GET/ Below are the screen shots  

[ceotjoe]

Is OHC code taken from same branch like the daemon? If yes open the OHC UI in a browser and search in settings for Rig Control. There you can enable it and also put the IP where the daemon runs.

If no you need to take it from same branch like the daemon.

Basically:

git clone https://github.com/HAMDevs/openhamclock.git
cd openhamclock
git checkout feat/rig-control-minimal
git pull
npm install
npm start

[albertovm]

> openhamclock-rig-control@1.0.0 start
> node rig-daemon.js

[Config] Loaded configuration from /Users/admin/OHC/openhamclock/rig-control/rig-config.json
[Config] Type: rigctld
[Config] Rig: 192.168.2.250:4532
[Config] HTTP: 5555
[Rigctld] Connecting to 192.168.2.250:4532...
[HTTP] Rig Daemon listening on port 5555
[HTTP] CORS enabled for all origins
[HTTP] Connects to rigctld at 192.168.2.250:4532
[Rigctld] Connected
             

> openhamclock-rig-control@1.0.0 start
> node rig-daemon.js

[Config] Loaded configuration from /Users/admin/OHC/openhamclock/rig-control/rig-config.json
[Config] Type: flrig
[Config] Rig: 192.168.2.250:12345
[Config] HTTP: 5555
[Flrig] Client initialized (XML-RPC is connectionless)
[HTTP] Rig Daemon listening on port 5555
[HTTP] CORS enabled for all origins
[HTTP] Connects to flrig at 192.168.2.250:12345
[Flrig] Supported Modes: [
  'LSB',  'USB',
  'CW',   'CW-R',
  'AM',   'FM',
  'FM-N', 'DIG',
  'PKT'
]

Both situations I had in OHC UI - Daemon not Reachable.
And Daemon still "Cannot GET /".
First I tried rigctld because I use this with GPredict, working really fine.

[ceotjoe]

In UI settings you enabled rig control and provided correct IP and port I assume? Any FW blocking port 5555?

Connection to flrig looks fine at least. :-) It reads the possible modes.

Daemon, OHC and browser run on same machine?

[albertovm]

I found my stupid mistake!
Rig Daemon Host was missing "HTTP://".
Just added and it worked fine.

I am thinking that in the future, an integration between Rig-Control and Satellites (for example), can allow something close to GPredict.... using OHC to control rig to correct doppler frequency. I am really thing to study both codes to understand if it is hard to do.

Thanks!

[ceotjoe]

Great that it worked. I hope I can bring this into OHC main soon. Any further feedback ist appreciated. :-)

[auroraonlineinc]

Thanks for the quick reply When you say UI backend server are you meaning openhamlock or some other app that I need to run

…

On Feb 11, 2026, at 1:08 PM, ceotjoe ***@***.***> wrote: Ah, I understand. This will not work. You need to start the rig control daemon, check console log if it is connected to flrig. Then also start the UI backend server on the machine you want to use the UI (only for testing, later it can also run somewhere else). After backend ist started correctly go to (normally) localhost:3000 in your browser, you should see the UI then. There you can go to settings and activate Rig control. Enter your IP and port where rig control daemon runs. I hope you will manage to get it running then. — Reply to this email directly, view it on GitHub <#306 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BP7X7EKHSGKN2B5WUCBOB2L4LNVZZAVCNFSM6AAAAACUSXELSSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKNZXGI4DGNQ>. You are receiving this because you commented.

[auroraonlineinc]

So here is my configuration Windows WSJT-X, FLGIG and now rig-daemon.js Raspberry Pi OpenHamClock listening on port 3000 For testing you want me to run UI backend (not sure what this is) on my Windows system Is that correct

…

On Feb 11, 2026, at 1:08 PM, ceotjoe ***@***.***> wrote: Ah, I understand. This will not work. You need to start the rig control daemon, check console log if it is connected to flrig. Then also start the UI backend server on the machine you want to use the UI (only for testing, later it can also run somewhere else). After backend ist started correctly go to (normally) localhost:3000 in your browser, you should see the UI then. There you can go to settings and activate Rig control. Enter your IP and port where rig control daemon runs. I hope you will manage to get it running then. — Reply to this email directly, view it on GitHub <#306 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BP7X7EKHSGKN2B5WUCBOB2L4LNVZZAVCNFSM6AAAAACUSXELSSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKNZXGI4DGNQ>. You are receiving this because you commented.

[ceotjoe]

Openhamclock running on your raspi is also taken from my branch I linked above? This is needed because otherwise the necessary additions are not integrated.

If this is openhamclock from my repository you can simply go to settings in the UI and search for rig control. This needs to be enabled and you need to enter the ip of your windows machine there where the daemon runs. If you change the UI also to Dockable mode, you can add the RigControl panel and also the On Air panel. Rig Control Panel should be green light, when daemon is connected.

[ceotjoe]

I pushed a new version to feat/rig-control-minimal.

Changes:

• Integrated SSE to get rid of constant polling of the daemon by the UI, this reduces bandwidth used extremely, will be good if it will run on openhamclock.com
• localization
• simplified modes
• works with current upstream main branch (11.02.2026)
• added a user guide in daemon folder.
• added SOTA support only panel, map has no SOTA spots currently

[echo-gravitas]

@ceotjoe - Wonderful, thank you!
I’m currently testing the latest version with different transceivers, even putting it a bit under stress. So far, it’s running very smoothly.

I noticed one thing though: you mentioned that the delay before the tune command can be configured in the settings. At the moment, I don’t see that option available, is that expected?

I’ll continue testing extensively and will report back here once I have more feedback.

[ceotjoe]

Great :-)

"timeout": 5000, "tuneDelay": 3000, "pttEnabled": false,

It should be in the config of the daemon. "tuneDelay" in ms.

[echo-gravitas]

@ceotjoe - I think I’ve tortured rig control enough for now, and what can I say: this is an excellent implementation!

A few things I noticed along the way:

• tuneDelay from rig-config.json was initially not being respected. I found the issue and took the liberty of adjusting it directly in rig-daemon.js. Just trying to contribute something as well. HI.
• CW is never selected as a mode. LSB/USB/FM are chosen correctly based on the 10 MHz boundary, is that by design?
• The constant RIG (line 104 in rig-daemon.js) was defined but never used. I removed it.
• I prefixed unused parameters with _ so that eslint stops complaining.

Things I particularly like:

• If the mode is already correct, no redundant mode call is sent to the backend.
• The OnAirPanel is fantastic!
• The RigControlPanel is very handy.
• The integration of rig control into the POTA panel is really well done.

All in all, this now feels like a very clean solution. You’ve handled this in a truly professional way, excellent work! 🥳

[ceotjoe]

@echo-gravitas thanks for the kudos, but I also have to admit without modern AI tools this would not have been possible. Everything is so fast, this is really amazing. For sure you need to know how to get the best results and there I'm still learning. But if you did not do already, you should at least try Antigravity by Google it is really fun to work with.

I will integrate your changes then and possibly try a PR tomorrow or Friday then. Depends on my schedule.

Thanks for the while and all your testing.

[auroraonlineinc]

Hi, So I installed your version using the following on my pi git clone https://github.com/HAMDevs/openhamclock.git cd openhamclock npm install npm start I notice that you have under component RigControlPanel.jsx, but when I check after my install its not there. Sorry Git is new to me. Could you send me the git clone address please

…

On Feb 11, 2026, at 1:56 PM, ceotjoe ***@***.***> wrote: Openhamclock running on your raspi is also taken from my branch I linked above? This is needed because otherwise the necessary additions are not integrated. If this is openhamclock from my repository you can simply go to settings in the UI and search for rig control. This needs to be enabled and you need to enter the ip of your windows machine there where the daemon runs. If you change the UI also to Dockable mode, you can add the RigControl panel and also the On Air panel. Rig Control Panel should be green light, when daemon is connected. — Reply to this email directly, view it on GitHub <#306 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BP7X7EMUJ3QDPIPOZPGKFRD4LN3ONAVCNFSM6AAAAACUSXELSSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKNZXGMZDIOI>. You are receiving this because you commented.

[echo-gravitas]

You need to checkout the branch feat/rig-control-minimal to have the latest version. Do this in your terminal:

git checkout feat/rig-control-minimal
git pull

After that, cd rig-control and install the deps:

npm i
npm start

This starts the daemon.
You also need to npm i and npm start in the root directory to start OpenHamClock itself too. So you need to open two terminal windows to do this.

[ceotjoe]

Thanks @echo-gravitas for helping out here.

Just for better understanding an completeness, you would do this in the terminal:

On the box you want to run the UI:
​
git clone https://github.com/HAMDevs/openhamclock.git
cd openhamclock
git checkout feat/rig-control-minimal
git pull
npm install
npm start


On the box you want to run the daemon:

​git clone https://github.com/HAMDevs/openhamclock.git
cd openhamclock
git checkout feat/rig-control-minimal
git pull
cd rig-control
npm install
npm start

[auroraonlineinc]

Thanks for the details, I got it working. So from openhamclock running on my pi and the rig-control running on my Windows I am able to control my rig but it has to be from the browser running on Windows rather than some other system. Also only POTA seems to allow me to change frequencies, I thought maybe DXCluster would work as well.

…

On Feb 11, 2026, at 3:49 PM, ceotjoe ***@***.***> wrote: Is OHC code taken from same branch like the daemon? If yes open the OHC UI in a browser and search in settings for Rig Control. There you can enable it and also put the IP where the daemon runs. If no you need to take it from same branch like the daemon. Basically: git clone https://github.com/HAMDevs/openhamclock.git cd openhamclock git checkout feat/rig-control-minimal git pull npm install npm start — Reply to this email directly, view it on GitHub <#306 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BP7X7EPPZUTOWX2KEPWHFZL4LOIV3AVCNFSM6AAAAACUSXELSSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKNZXGQYTGMY>. You are receiving this because you commented.

[auroraonlineinc]

So now I have the following Openhamclock with rig-control running on Pi400 - IP 10.10.10.200 Windows running WSJT-X with rig-daemon running and start-relay.bat running - connected to icon 7300 via usb and running flrig - IP 10.10.10.43 Mac browser pointing to 10.10.10.200:3000 I can control my rig so all is working fine. So What would be great now is to populate the browser with the FREQ, Power, SWR and ON THE AIR of the rig. Now that is cool.

…

On Feb 11, 2026, at 4:48 PM, ceotjoe ***@***.***> wrote: In UI settings you enabled rig control and provided correct IP and port I assume? Any FW blocking port 5555? Connection to flrig looks fine at least. :-) It reads the possible modes. Daemon, OHC and browser run on same machine? — Reply to this email directly, view it on GitHub <#306 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BP7X7EJB4OGSGXZFMNBJYP34LOPTVAVCNFSM6AAAAACUSXELSSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKNZXGQ2TOOA>. You are receiving this because you commented.

[auroraonlineinc]

In your documentation for rig-control it mentions that we should see Real-Time Rig Status - Freq display, Mode and PTT I don’t see any of that info - I am using Modern Theme

…

On Feb 11, 2026, at 4:48 PM, ceotjoe ***@***.***> wrote: In UI settings you enabled rig control and provided correct IP and port I assume? Any FW blocking port 5555? Connection to flrig looks fine at least. :-) It reads the possible modes. Daemon, OHC and browser run on same machine? — Reply to this email directly, view it on GitHub <#306 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BP7X7EJB4OGSGXZFMNBJYP34LOPTVAVCNFSM6AAAAACUSXELSSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKNZXGQ2TOOA>. You are receiving this because you commented.

[auroraonlineinc]

Update: If I use the Docker Theme I can tune the radio using POTA, DXCluster, SOTA I noticed that I had to add the Rig-Control Window in the Docker theme… OMG its perfect and very responsive. And the HUGE ON AIR is great. Very well done!!!!

…

On Feb 11, 2026, at 4:48 PM, ceotjoe ***@***.***> wrote: In UI settings you enabled rig control and provided correct IP and port I assume? Any FW blocking port 5555? Connection to flrig looks fine at least. :-) It reads the possible modes. Daemon, OHC and browser run on same machine? — Reply to this email directly, view it on GitHub <#306 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BP7X7EJB4OGSGXZFMNBJYP34LOPTVAVCNFSM6AAAAACUSXELSSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKNZXGQ2TOOA>. You are receiving this because you commented.

[albertovm]

This is very interesting.
If we had satellite frequencies in realtime, we could use OHC to define correct frequency to any satelite, just selecting it in the map.

[ceotjoe]

@auroraonlineinc great I'm happy that it works for you now also. Probably documentation needs some updates, for sure. I added already a userguide.md in the daemon folder in the most current version. I will review your comments until now and try to optimize it also. Thank you for the feedback.

[ceotjoe]

@albertovm if it's only about recalculating the frequency somehow and the needed data is already available, this should no problem to be integrated into rig control.

[albertovm]

@albertovm if it's only about recalculating the frequency somehow and the needed data is already available, this should no problem to be integrated into rig control.

OHC is using shashwatak/satellite-js, and it is able to make the frequencies correction, using TLE data.

OHC is downloading sats data or it is hardcoded?
OpenGD77 downloads sat list and its TLE data from https://celestrak.org/NORAD/elements/ (I use Amateur or Active list).

Maybe add a checkbox "sat freq rig control" to enable/disable control, and a popup to select the wanted sat.
I am thinking yet the best place to do this... maybe a new panel.

Let me place this subject to ##302

[ceotjoe]

I've created PR #357 tonight.

I'm a bit worried about the amount of changes. This will be difficult to review for the maintainers. Probably I should not have prettified (using prettier, on the files I changed) already existing code. Real changes get a bit blurry because of that. Maybe it needs to be reworked in that direction. But I wanted to prettify at least my own code. Because this really makes PRs looking better in future. Project should introduce that in general.

[echo-gravitas]

Great! Hopefully the PR will go through.
I also tried to introduce prettier and a corresponding config file in my PR. Without globally defined formatting every PR will be a little nightmare for the maintainers.