so ive been running a remote station for about two years now using a raspberry pi and a bunch of custom scripts to handle PTT, CAT control, and audio routing over the internet. it works but its honestly a pain to maintain and every time my ISP does something weird or the power flickers at the shack the whole thing falls apart and i have to SSH in and restart like six different processes.

a buddy of mine at the club keeps telling me to just use RemoteHams and be done with it but i always assumed it was kind of basic compared to what i have. recently though i started looking at the SDR remote side of it and that got my attention — the idea of having a wideband SDR at the remote site feeding back over the internet while also being able to key the transmitter is actually pretty cool if the latency is manageable.

my main question is whether anyone has actually compared running RemoteHams client/server against a homebuilt setup in terms of audio quality and latency on a normal residential cable connection. and does the SDR piece actually work well or is it one of those features that looks good on paper but stutters constantly in practice. also curious how the internet linking side plays into this if youre also trying to tie in an echolink node or something similar at the same remote site.

I've done both actually. Ran a homebrew setup for probably three years — FlRig for CAT, mumble for audio, some sketchy bash scripts for PTT that I was never fully happy with. Switched to RemoteHams about 18 months ago and honestly the stability difference is real. The client handles reconnects automatically which alone was worth it for me because my remote site is at a family cabin and I can't just drive out there every time something drops.

The SDR remote piece is interesting but I'll be honest, on a cable connection I found the bandwidth usage to be pretty significant if you crank the sample rate up. I run it at a lower rate and it's fine for monitoring band conditions but don't expect to do serious wideband monitoring at the same time as you're transmitting — at least not on a typical 10-15 Mbps upload connection. Latency on the regular voice/CW side is fine though, I've worked plenty of DX with no issues.

On the echolink thing, I actually do have a node at the same site and it runs completely independently on its own little pi. RemoteHams doesn't really care what else is on your network as long as you're not choking the bandwidth. Just make sure you QoS the RemoteHams traffic or you'll get audio glitches when the echolink node gets busy.

the latency question really depends on your path more than the software tbh. ive had RemoteHams sessions that felt totally transparent and others where there was this annoying 300-400ms tail on everything that made CW basically unusable. same software both times, different routing on different days. if your remote site and operating location are both within the same metro area youll probably be fine but if theres a bunch of hops across the country all bets are off.

never tried running it alongside internet linking stuff so cant help there