Tuesday, August 3, 2021

The Evolution of Remote Station Control

An inspiration I got out of HR3 as part of the "Bannerman Island Expeditionary Force" was to review my gear, improve the QRP station setup I brought, build a new portable station, and rebuild my home station setup. 

While I have plenty of room in our unfinished basement neither space heater in the winter or air quality in the summer makes for a comfortable armchair operating experience.

So I started looking into the ability to remotely operate from the comfort of my upstairs office space while keeping my transceiver in the basement. 

Connectivity between the transceiver and my upstairs office would need to be via my existing wired network. So I needed to understand what interfaces and features are available and then specifically for my radio.

When we talk remote operations we need to be clear in context and from who's perspective, station or operator, we are having the conversation about. Definitions to consider below:

  • Station may have local and remote operators
  • Operator may operate local or remote stations
  • Local Operations is an operator co-located with a station
  • Local Station is a station co-located with an operator
  • Remote Operations is an operator remote from a station
  • Remote Station is a station that is remote to an operator
  • Remote is traversing some virtual space where the operator does not have direct physical access to the controls of the station. The space could be a home network, across the Internet, or some other medium.

Disclaimer

I forewarn you that my "style" in writing technical reviews includes providing a reference model where one may or may not already exist. It comes from years of IT solutions architecture for global enterprise having to be explained to business and engineers alike.

Local Station

Control of a transceiver breaks down to two categories of services to be supported:

  • Control (on/off, frequency, mode, PTT, etc)
  • Audio (Microphone, Speaker)

Physical interfaces for radio controls started with DE9 (DB9) connections providing serial communications.  Yaesu then went with 8-pin Mini-DIN female and ICOM with 3.5mm mono female. Both their interfaces provide serial communications but at TTL levels hence they require interface cables with level converters built-in. Cables are available with conversion to DB9 or USB attachment to a PC. 

Physical interfaces for Audio start external speaker and microphone jacks. Radios may also include a 6-pin mini-DIN chassis connector that may be labelled as a DATA port. The label is misleading since the connector only carries audio.


I warned you about my architecture perspective on technology hence i give you the above Local Station model. In that model we have the physical interfaces discussed with a dotted line separating the Control and Audio services.

The serial communications on the physical interfaces communicate using a protocol proprietary by each radio manufacturer. The protocols are published and free of license encouraging application development. 

Raw audio is fed into the sound ports of a PC with further process done either by the application itself and/or a combination of software libraries.

With USB replacing DB9 on PCs and USB ability to support audio and other human interface devices, radio manufacturers add USB A physical interfaces in transceivers for control and audio and provide the necessary software drivers for PCs.

An example setup would be a laptop with a serial-to-USB cable connect for control and an external USB audio device (like a Signalink) for audio running applications like FLrig/FLdigi or Ham Radio Deluxe.

Remote Station

The biggest complexity when it comes to setting up remote station capability has to do with audio. 

IMPORTANT: If all you want to do is data modes and have no interest in SSB (or AM) then all you need to do is focus on is the control service for a remote station. I wanted to mention this up front to save you headaches if you are a data-mode only person.

Remote Station setups require a PC attached to your transceiver that communicates with the remote PC you are operating from across your home network, the Internet, or some other high-bandwidth low-latency connection (hint.) This will require additional layers, server and client.

Remote Desktop services included in Windows 10 tend to be the first choice in client and server using the RDP protocol. This software gives you the experience of sitting in front of the station PC less audio.

For audio you will need to install a VoIP server on your station PC such as Murmur or utilize a VoIP service like Skype. This introduces the digitization of audio using CODECs served by the VoIP server to the VoIP client. As mentioned if you just plan on using digital modes you do not need to bother with VoIP and just party on with your favorite digital mode apps.

Remote Desktop services included in Windows 10 advertises as support audio as well but I have heard of mixed success since best practice is to use a separate audio device (USB Audio) to connect to the transceiver.

So in this setup your building on the local station setup running Remote Desktop Services or a VNC server and connecting with the corresponding client applications on your remote laptop. Audio may have Murmur server software running on the local station and the Mumble client on the remote laptop.

Web-enabled Station

If you have used a WebSDR site then you have tasted the web-enabled  station experience less the ability to transmit. The client is a web browser providing control and audio services. The web browser connects to server software running on the station PC. All that is offered is control and audio. To receive digital modes you digitally pipe the audio to a digital mode application on your PC.

For remote stations there is a distinction between client, server, and applications but for web-enabled stations the lines get blurred. 


A web browser is your single client for control and audio services connecting to multiple servers with results blended in the browser using the HTML5. CSS, Javascript, and WebRTC. This technology is part of front-end development that delivers the end-user experience. The back-end includes the servers and applications that communicate with transceivers via an API. The API handles the different protocols used by each radio manufacturer.

Two examples of this approach are RigPi OS v2.0 and Universal HamRadio Remote HTML5 (UHRR).

My Current Station

Since it is difficult to setup a permanent station in my home, I decided my home station will be packaged  into a luggable 4U rack case. 

With that station setup my operating position will always be remote connected somewhere within my home network. No intention of using it across the Internet. 

I start with my ICOM IC-7200 transceiver which has USB for control and audio and I decided to use a Raspberry Pi 3B+ as the station PC. A good alternative would be a Windows 10 stick PC which can be bought for as low as  $150 USD. 

The reason I wanted to go with a Raspberry Pi was flexibility to experiment with a hybrid of Remote and Web-enabled station. 

Luggable 4U Rack. The RPi is in a shielded case and installation into the back upper corner of the case

Using a Raspberry Pi for our purposes requires a certain level of Linux experience depending that corresponds with the amount of time and patience you have in building the experience you want. 

Anyone who has spent serious time with Raspberry Pi will tell you that you can spend hours from creating your SD image to adding packages and tweaking the final install to the way you like it. A number of ham-focused Linux distributions have come and gone with HamPi and KM4ACK being two of the best open source projects left to help hams build useful Pi installations. 

But in the interest of keeping the build simple and quick I opted to buy RigPi OS v2.0 from MFJ for only ~$30 USD. 

Amazon Fire HD Tablet with RigPi Web interface running. To the left is the Raspberry Pi 3B+ in shielded case connected  to my wired network. USB connection from Pi to the ICOM 7200

While RigPi OS is intended for use with the RigPi Station Server  hardware package MFJ sells, it makes for a great foundation build for your station. 

Since my only interest is data modes and plan on using remote desktop software to connect to the station I disabled the Murmur VoIP server and only use the included applications for now and not the web interface. Out of the box RigPi OS install is optimized for remote voice operators. 

If you want to use the rig controls within digital mode applications like Fldigi and WSJT-X you need the Murmur VoIP server off and not connected to your radio via the web interface.

For my remote PC I went with a Amazon Fire HD 10.1 Tablet with a detachable case that has a bluetooth keyboard. I used the Fire Toolbox software so I  I could install apps from Google Play on the tablet such as VNC Viewer for Android and Remote Desktop for Android though I will only be using VNC to access my station. 

While the station Pi is wired to my home network, the tablet will connect to it via WiFi. WiFi is used very little and only as a client network in my home.

Sitting at my office desk, connected via VNC with the tablet to the Pi, WSJT-X running on the Pi

Final Thoughts

I know I did not go into any depth of the web-enabled station model especially when I am using RigPi OS v2.0 as my Linux platform which is known for its web browser interface. I wanted to bring the introductory narrative to conclusion of what I did for my station before getting deep on the web-enables subject.

The two examples I cited RigPi OS and UHRR as web-enabled examples because they reflect the direction where station interfaces will go. While RigPi is a packaged solution, UHRR is an open source project that includes the raw materials to manage a transceiver from client down to API. 

Reviewing UHRR exposes how much front-end development is required in building a web interface from the coding itself to web-frameworks they are built on (like Bootstrap) to the back-end services that communicate via API to the transceiver.

With WiFi being added as an interface option by radio manufacturers, it will be interesting to see how much growth there potentially could be in open-source "web dashboard" deevelopment.

73,

- Joe, NE2Z






No comments:

Post a Comment

We really do not want to moderate comments, so lets keep it easy to use until it becomes an issue.