All Text and Images and content Copyright 2017 Mark Abraham - may not be reproduced or used without the authors permission.

With the new crop of SDRs in the shack for a little while now I have started to notice patterns with different operating models.  This post is a micro discussion with regards to the various approaches to remote use of one’s rig over a network, be it by virtue of its network interface or by accessing a host remotely.


What has triggered this post in particular is the observation that some radios perform very differently than others over a home network.  Also, with all the buzz out there about remote ops, I wanted to cut through some of the hype and bring my readers some reality on their expectations.

So lets get to the "Why" a little more in depth.  I have a lot of radios for review in the shack right now, some I am keeping and some I am not.  Having access to multiple high-end SDR transceivers all at once naturally creates comparative observations, even without trying differences become apparent.  What I was seeing is that some radios seem to behave better than others when operated over a network.


 OSI Model

Above is the OSI model, it depicts a model of a network from its physical starting point to a user’s experience end point, the starting point being the physical network layer (1) or the presentation layer (7) depending on where the source  of a given discussion resides.

In this case we are most familiar with the application which means we see a live interactive signal on a panadapter and hear or see the various ham protocols or IE modes.  By the way, just to be technically clear, the presentation layer is where data is put into its end format for consumption by an application and not necessarily the application itself.  An example is a JPEG image or an MP3 sound file.  That is the presentation.  The fact that an application uses it is not really part of the OSI mode.  You might therefor then think of an application as layer 8 if that makes things easier.

To keep it simple though we will just speak in terms of the Graphical User Interface (GUI) we use from the output of layer 7.  When we talk about the various client models they can really embody layers 5,6 and 7 as to how the presentation layer and then the eventual user interface and experience data are developed for an application to consume.  The diagram bellow starts at a high-level demonstrate the various models.  Odds are that most SDRs fit one of these models and the brands listed are just common ones to aid the discussion for remote access.


  1. The Flex model uses thin clients to leverage radio processed signal data, clients can be thin on a computer and or a device.  A channel to conntected to the radio is created and keeping it simple, that channel is used to send commands to the radio and for the radio to send back the data associated with the commands.
  2. The MB1 is part computer and runs a fat client onboard the radios win 10 computer.  A remote access server package such as NoMachine can be used to provide a thinner client to access the MB1 on other computers or devices.  Alternately Network Audio and Com Cables can also be used to allow remote access to interface with third party packages on the remote computer such as HRD, DM780, ect.  In this latter example, the Radio software runs on the MB1 and then network com port and network audio channels are created like Virtual Serial Ports and Virtual Audio Cables do one can for example control the radio via ComCat, Ham Radio Deluxe or send Digital Audio from DM780 to support ditial modes.
  3. The Anan model leverages IP to access the radio so that it can send fat client data to the computer to be processed.  It can also send fat data to a device client.  Fat data requires a device/computer capable of sufficient procession power to process the data and present it in a user interface.  From there the client can be remotely accessed as in the previous model via Nonmachine or similar to a device or remote computer.
  4. The last device, the Elad is connected to a computer via USB.  The computer can then be used to expose the interface remotely via NoMachine or similar on a device or other computer.

Once we transport data over IP, the models are more or less similar in that the data (more importantly the amount of data) is pushed to the end devices in the various models.  One could argue though in the left Anan model there are more possible failure points and a greater probability of latency which is the delays associated with device/computer processing and transport over a network.  That model has the data going to a computer and being processed, rendered to a client and then that client being rendered into a remote access model (Screen Data and Audio Data) and pushed to a device where it has to be processed and rendered again.  You can just access the Anan directly with a device, however the interface at this point and time is more limited.  One could also under reasonable conditions just access the Anan with a distant end computer over a dedicated network like a VPN (Virtual Private Network) which is in essence a dedicated channel point to point from source to destination that is often secured to protect privacy).

Just to also give you some network 101, you can think of layers 1-4 in the OSI model as everything network!  This means that it represents the protocols used, VPN if applicable and IPSec, TCP and UDP, encryption if applicable, and then all the physical network hardware and network operating system from a switch to a jack in a wall.  So those layers are used to get the data if you will from one device to another.  So data from layer 7 is converted eventually into paclkets and assigned a protocol, then gets pushed through the hardware to the distant end hardware to the distant device, the packets are deconstructed into data and runs through layers 5-7 and finally into an application of file for the end user or end user application.

I will tell you right now, I dont have all the answers for you, however, what follows next may help and be of interest.

Alright, enough of that, lets summarize where we are in this conversation and get back to its purpose.  The discussion is about what/why one radio would behave differently over a network verses another.  

  • The amount of data
  • The protocols it might use (TCP/UDP?others)
  • Differences in the go between such as middle men devices

In short that means that some of these models might perform better than others and it would seem at the surface that the Flex model would rule the roost as far as network performance because it is sending slimmer data and that goes right to the first factor on the list above.

Its worth noting that the more points of failure or complexity of a model, the more chance and risk there is for latency and issues that could degrade performance, just like we pointed out above.  Latency is a term for the delay that is incurred when data is converted from analougue to digital, processed by computing resources, transported by computer busses or network channels and then reconstructed back eventuly into analouge data. We typical speak of latency in milliseconds (ms).  Sometimes you can heare latency when you monitor your own mic iput on the radio and it comes back to you ever so slightly delayed and throughs you off or as an ech sometimes.   


So lets use good ole Joe Ham mentality to dig in!

Below are the screen shots of the first three models.  I would expect the Elad model to perform like the MB1 model given a computer with reasonable horsepower is being used to process the Elad fat client.



Flex 6500 and SmartSDR on a PC





Flex 6500 and SmartSDR on a PC


MB1 running ExpertSDR via NoMachine to another PC


*Windows presents the bandwith interms of MBps. People often assume that a download speed of 1 Megabit per second (1 Mbps) will allow them to download a 1 Megabyte file in one second. This is not the case, a Megabit is 1/8 as big as a Megabyte, meaning that to download a 1 MB file in 1 second you would need a connection of 8 Mbps.


What is it you see?

Flex is 6Mbps on the computer and likely as well on the iPad app.  I regret I really don’t have a decent viable way to measure wireless, however, it was the iPad access that really got me started on all this, more on that in a bit!  Of note, the first additional slice added 1Mbps and subsequents were about .5 Mbps.

The Anan averaged about 11.5 Mbsp and only added about .2 to .3 Mbps to activate the second receiver.

The NoMachine method of access averaged about 6.Mbps. and covers the MB1 and Elad in theory.  No additional bandwidth for additional slices because its one screen data pipe and one audio pipe.

This might be an eye opener for those professing one model over another.  That said, it gets even more interesting as we get right down to the point now.  The Flex seems to hiccup on my mesh network via wireless more than working a radio via NoMachine.  I am on a mission of sorts to figure out why, because I do like the Flex on the iPad quite a bit.  The MB1 via NoMachine also works really well and its hard in some ways to choose other than performance.  One other note of interest that unfortunately gets lost in topics like these is that the NoMachine method provides you built in security with encrption via its NX protocol.  We can talk about security more later.

On one hand you have an app that was custom designed to run the Flex remotely.  Its clean, well organized, ect.  On the other, you have access to a full featured SDR client and computer behind it to run all modes (digital modes, ect).  There are quirks though like the buttons being small, often too small to consistently used with success.  Even SSB is a trick because you have to work a bit to hit Mox for PTT or bring up the Key Board and block a part of the screen to use the space bar.

There are other factors to consider as well, what do you do it your radio locks in transmit while operating remotely? What if it freezes and remote controls dont work?  I haven’t found the cause yet, its going to take some research, however, the Flex locked in XMIT and I had to run from the deck to the radio to unkey it which would only work via powering it off.  Talk about scary!  I dont have real faith in long distance remote ops because of that.  I think that I would need a way to kill power to the radio in an emergency sitution like that.

And on that note, I want to just talk about the overall big picture here.  The flex works fine with a hardwired network connection, as do all the other radios.  I am not so sure about wireless, and listen, before you just go blame my network, you need to know that its all GB speed and I have a mesh network with several access points.  Its all new and modern and I have Google Fiber which is GB also for internet access.  You can see the speed required in all the models varies from 6Mbps to 12Mbs an the Anan model on a dedicated hardwire. 

Even more interesting was how much the speeds changed over WIFI.  The Flex and NoMachine Models adapted and reduced bandwidth down to about 3Mbps while the Anan more than doubled to 24Mbps.  I ran this multiple times to validated that this was the case including changing locations and proximities to the access points.  I also monitored performance in terms of the audio and panadapter displays and noted that the NoMachine model performed more consistently.  The Anan model was much more sensitive to Network traffic annomalies and the Flex model hiccuped every so often with tiny losses of the audio with the interaction freezing.  This might be as short as a quarter to half second to as much as a second or two.

People don’t account for all the traffic on their home network.  I can tell you from experience that some Apps for example can kill a home network. Take Pandora for example, it used to reap havoc, as did Skype when my family was using those apps.  Take my network for example, there are over 50 devices on it running a variety or protocols and with varying bandwidth needs.  The radios hooked to Hamzilla have a dedicated Giga Switch that feeds into another Giga Switch and then directly hardwired to the main router and FW.

My point here is that I don’t think remote access is really quite prime time like perhaps some are making it out to be.  People always say it all works perfect in either the spirit of brand loyalty or fear of being debuked for surely being the exception rather than the norm.  I call BS on it all!  LOL

I just so happened to get the Flex news letter while doing this article and it was talking about the status of SmartSDR2 and SmartLink and spoke very positive of remote access, but there was a tiny disclaimer statement int here about performance.

We havent really talked about the protocols much yet, so lets breifly discuss them.  First off, my own disclaimer, I am by no means a network expert, so anyone who finds fault with what comes next, please ping me with your thoughts and corrections.

TCP and UDP take different approaches to facilitating communications between devices.  TCP addresses packet loss which in Laymans terms addresses trying to get all your data without loss from one end to the other.  If a packet is not received its resent and then reinserted in the overall data stream.  I am over simplfying this so please forgive me, however, UDP just sends the data and what makes it makes it and what doesnt simply doesnt.  

These two seemingly simple statements though have signifcant impact on communications.  At the surface you might think that you definitely want TCP so you can avoid loss.  That error correction can come at the cost of some performance.  Its handy in a poor networking environment where you have interuptions and surge events.  On the other hand, in a clean network environment, its not of much use and UDP can perform better.


So above, you can see where I have those differences noted.  I should note that the Flex model uses both TCP and UDP.  UDP is used for the intitial connection for discovery of the radio and TCP is used for the mainstream communication.  NoMachine uses UDP and its own propritary protocol NX to facilitate security.  While very complex, let me quickly convey that some seucirty protocols provide data loss protection inherintly within the primary means of communication (TCP/UDP) as a means of authentication and privacy protection.  Think of it this way, to ensure true confidfentiallity and  real security, you need data integrity.

If a network is not stable, then a TCP protocol for coomunications may manifest itself in the way of hiccups to the end user.  You have all been there before where maybe your listening to a video on YouTube and theres a hiccup.  There will never likely be a guarentee of perfect internet.

Before we move on, as a CISSP (Certified Information Security Professional) I want to note that I think security has been greatly overlooked thus far in the SDR designs.  An SDR is merely an Appliance in the end and appliances are more and more becoming heavily attacked.  While perhaps not likely, consider this scenario; your remote ops site is attached by a hacker.  They Key the radio to full transmitt and leave it locked to broadcast a nasty message of their choice and leave it looped and transmitting.  It causes your radio to overheat, burn up and even possibly start a fire and burn your shack down.  Or how about they lock you out and charge you ransom?  If you follow the news, recently the internet was rendered unstable when hackers took over peoples home security cameras and TV's ect and triggered them to become an army of armed robots to flood the internet DNS servers making much of the internet unaccessible.  This was a planned methodical planed display of power and just how easy it can be to take the internet out. Many believe it was a weaponization test and the big even for complete internet blackout is yet to come.  IE, this stuff is real and if not on your radio, you might head the warning to consider this stuff before exposing your appliances to the internet.  BTW, if its on your home network and your home network is connected to the internet, its definitely exposed already.  And no, your firewall doesnt stop everything.


So. Lets go back to our list and add one to the performance impacts list:

  • The amount of data
  • The protocols it might use
  • Differences in the go between such as middle men devices
  • Amount of other network subscribers and traffic.

So, think about it for a minute.  We can already have issues on our own home network which is certainly prettier than the internet.  We have hype claiming internet remote access is a true reallity now and it is, its just that there are some disclaimers that go with it.  Look, its true that you will be able to try it and have some level of success.  But is that really going to be useable?  Yes, and no is my answer because its going to vary by each persons own standards on what is and is not acceptable.

The Flex remote access while sitting on my deck, sure, its ok, far from perfect.. and before someone crys foul over it not being hooked to the network directly, STOP.  In todays world, your device is more than likely going to be hooked in wireless.  Even most laptops are now. 

My point is this; hardwired one can say that remote access is close to prime time.  It’s a network and you have to always understand that packet delivery is not always guaranteed in a timely manner. 

For wireless, nope, we will need thinner pipes and ways to compensate for latency.

Well, I hope you found this interesting!  I plan to dig into the protocols more and get a more technical breakdown of what is being used in the models up above.  Remember, there are performance variables depending on whether TCP or UDP are used.

Stay tuned, this was also presented in the forums and will have its own topic in case folks want to challenge or discuss the details.  Maybe someone can already just tell me the for mentioned details and protocols and male life easier. 



All Text and Images and content Copyright 2017 Mark Abraham - may not be reproduced or used without the authors permission.