so ive been messing around with remote station control for about 6 months now and finally got a setup that mostly works but im running into some weirdness with the RemoteHams client and i cant figure out if its my end or the server side. background: i have an IC-7300 at a rural property about 40 miles away, running RemoteHams RCForb server on a windows 10 box out there, static IP from the local cable provider, and on my end im on comcast with a pretty solid 200/20 connection.

the SDR remote piece is what's giving me grief. when i use the built in SDR panadapter through the RCForb client it works great for maybe 20-30 minutes then just kind of... stutters. audio keeps going but the waterfall freezes and sometimes the whole client drops back to the connection screen. i dont think its a bandwidth thing because my audio quality stays fine when the waterfall dies, so its clearly two separate streams doing something weird.

also on a related note, ive been thinking about tying this into echolink or some kind of internet linking for when my remote HF setup is down and i just want to ragchew. anyone done both on the same machine? feels like it might be a port conflict situation waiting to happen but maybe im overthinking it.

the waterfall freeze thing with RCForb is a known annoyance, or at least it was for me. what fixed it on my end was bumping up the SDR buffer settings in the server config — theres a tab for it i forget exactly where but it's in the audio/SDR settings area. default buffer is pretty small and over a WAN connection with any jitter at all it just falls apart eventually. i went to something like 4096 and it got way more stable. still not perfect but i can run 2-3 hours without a drop now.

on the echolink question yeah you can run it on the same box, i do. just make sure echolink is using UDP 5198/5199 and your RCForb stuff is on its own ports, theres no real conflict as long as your router isnt doing something dumb with NAT. the only issue i had was echolink hogging CPU when a net was active and it caused some audio glitching on the remote side. ended up giving echolink its own low priority in task manager and that sorted it out mostly.

cant speak to the SDR waterfall issue specifically but ive had RemoteHams running on a pi4 for a while now and the internet linking side of things is where it gets interesting. i actually have it bridged to an allstar node so people on the allstar network can key up through my remote HF setup which is kind of a weird hybrid thing but it works for our local club when we want to do HF nets without everyone needing their own HF rig. latency is the enemy there obviously, you get that double delay where allstar has its own codec latency and then the remote HF link adds more on top, so it sounds a little off but for casual ragchewing nobody really cares.

the cable internet stability question is real though. i found that a lot of these issues come down to the upload side more than download — 20 meg upload sounds fine but if the cable node in your neighborhood is congested at peak hours your jitter goes up and these audio/control protocols absolutely hate jitter. might be worth running a jitter test at different times of day and see if the freezes correlate with evening hours or something.