SmartSDR remote operation wish list

Bjørn Ove Kristiansen

I recently received my Flex-6300 and have had the pleasure of operating it for a few days. Due to space constraints, I don't have the ability to put up an antenna where I live, so I've had to run my rigs remotely from my work place. Previously, this has been done using RemoteRig, which has proven to work quite well. When it comes to Flex-6300 and SmartSDR in its current state, however, I see a few issues that should be taken into consideration for the upcoming v2 release.

For reader reference, my network conditions are as follows:

On the RADIO side: ADSL 20 / 2, cabled connection
On the REMOTE side: Cable 10 / 2, cabled connection
VPN: Permanent, router to router, using OpenVPN. Adaptive compression (turning compression off has also been tested)

Running ADSL on the radio side puts significant restraints on the ability to fully utilize the features of SmartSDR. This is not SmartSDR's fault, it's obviously a limitation caused by the nature of the DSL connection. As soon as upload bandwidth goes beyond a few hundred kbps, latency increases significantly. So that's a challenge, but it's not an impossible task to deal with. 

SmartSDR is a demanding piece of software when it comes to bandwidth usage. It can be limited, however, by reducing the waterfall and scope update intervals, but that is about the only thing one can do. I propose the following:

• First, implement the ability to toggle the pan adapter and scope on/off. Analogue radios usually just come with a frequency counter and an S-meter. Sometimes that is sufficient
• Also, implement the ability to switch between audio codecs. I read somewhere that Flex have not wanted to do so, because the assumption is that users do not want to compromise on audio quality. While I agree that audio quality is important, I would most certainly compromise on audio quality (at least listening quality) if the alternative was not to be able to be on the air.
  
  The compromise doesn't have to be significant either. On my RemoteRig I have the ability to select narrowband and wideband codecs. A codec like alaw has a bandwidth of 8kHz and occupies abount 60kbps in each direction. That is significantly more than what's needed for normal SSB operation, where the bandwidth is around 2,7kHz. I'm sure that there are narrowband codecs that will give you acceptable qualities, but I have not tested them, as I have never needed to go below the demands of an alaw codec on the RemoteRig setup.
  
  I would also advice on giving the user the ability to select different codecs for rx and tx. That could make a difference for users with asynchronous connections.
• DAX audio: Why does it need to generate so much data traffic? Again, as per above, most radio signals do not occupy more than 2,7kHz audible bandwidth anyway. I haven't tested digital modes yet, but I assume one needs to run DAX to do so. However, whenever I turn on a DAX channel, the connection quickly turns unusable and eventually drops, simply because there is not enough available upload bandwidth on the radio side
• Why would SmartSDR assume that I always want to use the computer's default audio device when operating remotely? I would suggest that it is made possible to define which audio device to use for SmartSDR. It's a hassle having to go into Windows' sound settings and change my default audio device from my computer speakers to my USB headset every time I want to use the radio. This, of course, also applies to the audio input device.
• Also it appears that SmartSDR treats UI-generated traffic and audio traffic the same. So if there's a hiccup somewhere, audio does not get priority. While this can be complicated, one should look into the ability to prioritize audio. In other words, if there are bandwidth limitations, one should try to keep the audio running without interruptions.
  
• Finally, the remote operations feature really needs a remote power on or off. Yes, I know that I can do so using a wifi enabled relay, but that is no reason not to make it possible to remotely turn the radio on or off from within the software. Besides, who wants to fiddle around with an extra cellphone app or a website just for toggling the on/off switch? Okay, if that's your thing, fine. But I for one would like to see one single UI for controlling all the bells and whistles of my Flex radio, and that includes the ability to toggle power on/off.

Ideally, what would be great is the ability to switch between program modes. A standard mode and a light mode would for instance make sense. Then one could set up what features needed to be available in the light mode and switch between them as one accessed the radio over varioyus types of internet connections. At your home, running over LAN? Standard mode, no compromises, everything running at highest possible quality. From a hotel room across the country? Switch to Light mode, and the program will recall that you have turned off the waterfall and set a custom audio codec for that mode.

Just my .02. Looking forward to the next major update and hope to see at least some of this make it in there.

Regards,
Bjorn

Watts - K4QJZ

Excellent recommendations for consideration, as an Engineer with 30+ years of designing may RF resources including global remote operations of transceivers using dial up lines to Satellite resources you have offered some excellent suggestions for consideration. As a Ham I was also an early user of RemoteRig it has never failed. It works well and can offer a lot of valuable lessons to be learned about remote operations as to reliability and quality.
As one of the original purchasers of the 6700 I am looking forward to fully replacing my ICOM setup with remote operations with the 6700. The radio is so fantastic they will have a hard act to follow with remote operations, which work as well as the radio. They have made a good first start but clearly have many steps to go.

Ken - VE5KC

How about a mode where SmartSDR automatically scale the network operation to the available bandwidth. Reduce waterfall, spectrum display or even turn it off if the network connection can not support them but still allow audio & radio control.

Paul Christensen, W9AC

Bjorn has made some excellent recommendations.  After assembling a remote station where a DSL circuit at the radio site is a limiting factor for pan/waterfall display, a "lite" setting  from Flex will be demanded by such users.  I'm sure Fllex understands this and is likely one reason for the SSDR delay earlier this year when Flex moved from from v1.3 to v1.4  I suspect that work will make it possible to better implement lite WAN connections over upload-limited DSL connections. 

In our present case, the remote Internet station is built around a pair of Elecraft K3 transceivers and RemoteRigs.  As Bjorn points out, the RemoteRig device has evolved over time to accommodate poor-to-moderately performing Internet connections.   At the radio location, the upload speed is limited to 600 Kbps. while download gives us 10 Mbps.  The end goal is to augment or replace the K3 pair with my Flex 6700.   

Even after trying to work with Windstream, our DSL provider, they absolutely will not  change the upload data bandwidth without paying for a very expensive commercial account.    Access to Comcast with its much better up/down speed service plan options is about five miles to the south where their service footprint ends.  While we could install high power WiFi devices on the towers, the reality is that it's a headache to work with a subscriber at the fringe of the Comcast service area, install a tower or monopole at the subscriber site, create yet another account, etc.  In the end, we may need this anyway in order to realize the full potential of SSDR v2.0.  But, not everyone is willing to go to that extreme in order to have adequate return bandwidth from the radio site.   Hopefully, Bjorn's recommendations will be considered by Flex; his recommendations are needed for those of us with marginal Internet connections.

Ken - NM9P

These are indeed good suggestions.  
I especially like the "light mode" and the high/low bandwidth option for audio codecs.  Two would probably do, the standard high quality, and one with reduced, but acceptable quality for poor internet connections.  I also agree that TX & RX should be separately selectable.  I might be OK to sacrifice RX quality as a trade-off for bandwidth, but might want to maintain my higher quality TX audio if the circuit will handle it.

Ken - NM9P

KY6LA_Howard

Although it has been added previously we need to be able to start and stop Remote SSDR clients remotely. For example you are in remote location 1 and try to start SSDR from that location only to find that SSDR is already running on the Local Machine. Under current single client SSDR you would not be able to begin your remote session unless you could find some way to shut down SSDR on the Lo.cak Statiom Or you move to remote location 2 only to find SSDR was still running on Remote Station 1.