so ive been running a remote station for about a year now, started with RemoteHams because it seemed like the easiest path to just get on the air from my apartment while keeping the rig at my parents place out in the country where the noise floor is actually usable. setup wasnt too bad honestly, the RCForb client connects fine most of the time and the latency is manageable on SSB if you're not trying to do anything fast paced. their SDR remote stuff is where it gets interesting though because you can actually run a wideband rx session without having to babysit the whole rig, just spin up the SDR view and dig around the band which is pretty cool for dx watching.

but then i started messing with my own setup — running a pi4 with a SDRplay RSPdx on one end and just tunneling everything through a VPN back to my apartment. the control latency is way lower when im on the same VPN and i have way more flexibility with the audio codec and buffer settings. the thing is its a lot more to maintain and when something goes wrong at the remote end i have to either bug my dad to go look at something or drive out there which is a 2 hour round trip.

anyone else bouncing between the hosted remote platforms and DIY? curious if theres something in between im not seeing. also wondering if anyone has experimented with the internet linking side of things for like coordinating skeds through echolink or something tied into the remote — felt like there might be something there but i havent thought it all the way through yet.

yeah the tradeoff you're describing is basically the whole game with remote ops. RemoteHams is fine if you want something that just works and you dont want to deal with NAT traversal and port forwarding and all that, but the moment you want to do something slightly outside what their client supports you're kinda stuck. i ran RCForb for about 8 months on a IC-7300 at a club site and it was solid for casual operating but the audio compression artifacts got to me on weak signal stuff, not terrible but noticeable.

the DIY VPN route is where most serious remote guys end up eventually. i use wireguard now instead of OpenVPN and the overhead is much lower, makes a real difference on the audio path. for the SDR side i actually run both — the RSP for monitoring and the main rig for TX, and i bridge them with a little audio routing on the remote machine so i can use SDR Console as a panadapter while the rig handles the actual contacts. takes some messing around to get the audio levels right but once its dialed its really nice.

the echolink thing is interesting but i never went down that road, feels like a different use case to me. echolink is more about linking repeaters and having a presence on a node, not really the same as remote HF control. unless you mean something else by the linking idea?

been lurking this thread and just want to say the latency thing on RemoteHams really depends on where the server node is geographically relative to both you and the rig. i had a terrible experience early on becuase i was being routed through a node that was like cross country for no obvious reason. once i figured out how to pin to a closer relay point it got a lot better. still not as good as a direct VPN tunnel but workable.

one thing i havent seen mentioned — if your remote site has halfway decent upload bandwidth you might look at whether you can just run a direct HTTPS connection with something like Hamlib and a custom audio stream rather than going full VPN. bit more exposed security wise but some guys do it and it cuts out a layer. i dont do it personally but ive seen it come up on the RemoteHams groups.io list a few times.