SDRconnect - The Server

Went on a quick 24-hour trip to Kongsfjord on the  28th and 29th (Ascension Day’s a holiday in secular Norway), and—finally—spring had arrived! Much welcome, after April and most of May turned out colder than usual… actually colder than February.

Main reason for the trip was checking up on the electrician’s work—a long-awaited upgrade from ungrounded outlets to grounded ones. With all the gear we’ve got running, swapping some of the doubles for quadruple outlets just made sense. Funny thing, the weekend before, I noticed one of them felt warm to the touch, and when I had a proper look, one of the leads was brittle and about to give out. So yeah, the timing couldn’t have been better! A burned-down KONG-HQ wouldn't be a pretty sight.

The Four The Better

I’ve had a bit of a play with the SDRconnect server in earlier posts, like this one.

I haven’t seen much discussion on the SDRPlay's groups.io reflector about the pros and cons of using the SDRconnect server. Maybe the nRSP-ST is the way to go if that’s the route you’re considering—or maybe people just aren’t that interested. There’s plenty of frustration over how slowly SDRconnect is developing, but barely anyone seems to mention the server functionality. Watching from the sidelines, it’s fascinating how reluctant people are to move from SDRUno to SDRconnect—just goes to show how hard it is to break old habits. Fun fact: SDRUno actually started out as Studio One (or "1") back in late 2014. Cost €149 and needed a USB dongle to function. And wow, were people furious.

Back to SDRconnect Server—I’m definitely not a fan of SDRPlay’s interface choice. That character-based CMD window takes me right back to my pre-Windows 3.0 days, and trust me, those were NOT the good old days. With all the configuration options available when setting up the server, it’s far too much hassle if you want to do anything beyond the default settings. Thankfully, Jon Hudson at SDRPlay put together a video showing how to create a batch file, which makes things a bit easier—but still far from ideal.

"Calling CQ MSDOS, listening...."

So, for personal use, what is the advantage of using the Server, instead of RDP-ing to the actual host? Because any hardware from SDRPlay except the -ST needs a physical PC at the server end anyway. Since I have five Perseus/Jaguar sessions running, RDT is my only option. Especially since I save several TB of data every week. I would need a lot more capacity on my internet connection to save IQ recordings to my client PC, and capacity = money.

One could argue that it's faster to connect to a server. Yes, but... we're talking about a  few seconds, aren't we. And sure, it's free, while many free RDT programs don't offer audio. But some of them do! And that the first client controls all receiver options while the other users can only tune within any band span the first user has decided makes it nowhere near an alternative to the KiwiSDR.

That said: Configuring the server setup is very straightforward. Of course, you need to enable Port Forwarding in you router. But then, your ISP will likely change the IP address at regular or irregular intervals, rendering the config setup unuseable unless you have a DDNS service. And to top it off, at some parts of the world there is CGNAT. Make an internet search about it, if you haven't read my first post.

In summary, I struggle to understand why I should use the SDRconnect Server. Maybe that's why there is so little talk about it on the user forum?

To wrap up this post, a couple of photos from Wednesday evening, 22:30-ish, at opposite directions (NNW vs. SSE)

(Soon to be) Midnight Sun

KAZ Antenna Construction Zone