So ive been messing around with remote station control for about a year now and finally got to a point where things mostly work but its kind of a patchwork of stuff. I have a Pi running rigctld, a separate audio path through mumble, and then some custom scripts to handle the antenna switching. It works but its fragile and every time something reboots in the wrong order the whole thing needs to be babied back to life.

A buddy at the club was showing me RemoteHams and the SDR remote side of things and honestly it looked pretty polished compared to what im running. But I'm not sure if its worth switching over or if id just be trading one set of headaches for another. The internet linking part is what im most curious about — does anyone actually use it for serious HF work or is it mostly casual listening and ragchewing. Like can you run a contest remotely through it or is the latency too painful for that kind of thing.

Also curious if anyone has tried mixing SDR remote for receive monitoring with a traditional transceiver on the transmit side. Seems like that could work but idk if the RemoteHams client handles that kind of hybrid setup gracefully.

I ran RemoteHams for probably two years before I switched back to a custom setup. The client is nice but you're kind of locked into their ecosystem which started to bother me after a while. Latency wise it was fine for casual HF, I worked some DX through it without too much trouble, but contesting is rough regardless of what platform you use — the turnaround time on PTT keying alone will drive you crazy in a pileup. The SDR remote part is actually where it shines in my opinion, having a panadapter view at the remote end makes a huge difference for finding activity.

Your hybrid idea with SDR on receive and a real rig on TX should work in theory but youll need to handle the timing yourself because the client isnt really designed for split-path audio like that. I messed around with something similar using a SDRplay on the receive side and an IC-7300 on TX, had to write some glue code to keep everything synced. wasnt pretty but it did work.

honestly the mumble path is fine for what it is but yeah the reboot sequencing thing is a real pain, i had the same issue and ended up writing a systemd unit file with proper dependencies that waits for rigctld to be alive before starting the audio daemon. helped a lot. not saying you should stick with your current setup necessarily but that one thing made mine way more stable.

never actually tried RemoteHams myself so cant speak to that but ive heard the latency is somewhere around 150-300ms depending on your path which is enough to feel off but not unusable.