Setting up a Remote Station – part 12

I now have the cabinet in which the station will be housed at the remote site. I looked at “designed” solutions for environmentally controlled, waterproof, secure external housings, but we’re talking loads-a-money. Luckily, my wife suggested the above: a “secure” metal office cabinet inside a plastic wheely bin cabinet.

The latter is mainly for protection against the elements. We have something similar for general storage in the garden and we’ve never had a problem with rain penetration. In any case, the equipment will be sealed in the inner cabinet, so a little bit of seepage shouldn’t be a problem.

The next task is to build it up to be, as far as possible, a self-contained and self-managing remote station that needs as little attention as possible whilst being fully accessible and controllable from home.

Setting up a Remote Station – Part 8 networking issues

I’m seeing some strange networking issues. On a couple of occasions, I’ve lost communication to the remote station.

Currently, the remote station is sitting on the bench, and the RUT-951 router is connected to my home LAN via Wi-Fi. This is also the desired final situation.

On one occasion, the Pi and Windows PC lost comms to the Internet, even though I could access them remotely using ssh or Microsoft Remote Desktop respectively. The only interpretation is that the router lost its default route (which is to the home LAN’s gateway). However, running the route command on the router showed the proper routing table. All very odd.

The most likely cause is that I had the router sitting on top of the 12v PSU. I’ve moved it now.

Luckily, one of my reasons for choosing this router now comes to the fore. Being a router designed for remote installation, it has services built in that enable it to recover from some problems:

  • One is a service to ping a defined IP address (in my case and reboot if a pre-determined number of attempts fail to get a response.
  • The second is that you can set the router to reboot on a schedule.

I have now enabled both services, with the router rebooting at 3AM.

Setting up a Remote Station – Part 7 Testing

I’m far along that I am now able to use the station as if it was remote. There is one exception though – I don’t have the relay that will switch the radio on an off. I have a SONOFF 4CHPROR3 WiFi Smart Switch on order. That should arrive today.

Apart from that, the station works.

If I want to use digital modes, I connect to the Windows PC using Remote Desktop and run FT8 etc from there. For voice modes, I run SmartSDR on my local machine and use Flexlink to connect to the remote radio.

I’m going to be away for a while, so I won’t make further progress for a few weeks, but when I return I need to give consideration to antennas and lightning protection.

Setting up a Remote Station – Part 6 Remote Access

In this post I am going to discuss the need for a local Windows PC and considerations for remote access.

Local Windows PC

I allowed for a local Windows PC in the original spec, but I was hoping to not need it. However, after watching Mike, VA3MW’s YouTube video on his remote station, I changed my mind. Mike’s arguments in favour were:

  1. running Ham-related software locally reduces Internet traffic and latency; and,
  2. having everything local opens up the potential for others to access and use the station with minimal trouble

So, I stumped up for a Mini IT8 from Geekom. This is a micro-PB with an Intel i5, 16GB RAM and 512GB SSD. More than enough for my needs. It runs Windows 11 (unfortunately), but I’m gradually getting used to its foibles.

So far I’ve installed:

The PC is logged into my Microsoft account so the OneDrive replicates to my home QTH.

I’ll access the remote PC over Microsoft’s Remote Desktop client – remembering to play audio on the remote server and not back on the home station.

It’s worth noting that I’m only proposing to use the remote installation of SmartSDR for digital modes. For voice modes and CW I’ll use SmartSDR on my home Mac and use FlexLink to access the Remote Station.

Remote Access

Given that I am designing a Remote Station, access to the Remote Station is a major aspect of the design. The primary requirement is for remote access from my home QTH, but I also want access when I am on the road.

Normally, this would be relatively easy to achieve because the RUT951 would be directly connected to the Internet and I could either open ports or set up a VPN gateway.

In my case though, it is hoped that the Remote Station will be connected to the host’s LAN (as it is at home on the bench), in which case there is an additional router/firewall in the path to the Internet. I cannot assume that I have any potential to control this host-LAN router, so I cannot forward ports or use something like UPnP.

So, what I am doing is to have the RUT951 establish a VPN back to my home network. That way:

  1. I don’t need to worry about the public IP address of the remote station; and,
  2. once the VPN is established, I have full access to the remote station’s LAN

My Home LAN already has a OpenVPN gateway to allow me remote access to the LAN when I am on the road. Hopefully, with this arrangement I can VPN into the Home LAN and also get access to the Remote LAN. We’ll have to see what effect this has on audio latency etc.


At the Server end

  • The home QTH OpenVPN server is reachable from the Internet.
  • The Home QTH LAN is
  • The VPN Server’s Home QTH LAN IP is
  • The VPN uses
  • The VPN server uses the following server.conf (relevant content only)
dev tun 
topology subnet 
push "dhcp-option DNS" 
push "route"
push "route" 
  • The Home QTH’s router has a static route to using the gateway

At the Remote Station

  • The LAN has the address space
  • The RUT951 is
  • Once connected to the VPN, the RUT is also

With this config, the remote LAN is reachable from the Home LAN and vice-versa.

Setting up a Remote Station – Part 5 Setup continued

Rather than continually editing part 4, I’ve decided to move to separate posts.

A lot has happened since I last posted and a lot of progress has been made. I’m nearly at the point where I am ready to start testing the system in the home shack.

From my log:

  • I’ve realised that the Shelly 2.5 Wifi Switch won’t work after all. It needs to be powered by at least 30V DC and the two relays have one side connected to the 0V line. I need them to be independent. I’ll probably implement a couple of switched outputs using the GPIO lines on the Pi.

  • I configured the OpenVPN client on the router to connect to my home’s OpenVPN server.

  • I put a SIM card in the router and set up the failover rules so that the failover order is:

    • My Home LAN (will be changed to the Host LAN at the final location)
    • Any WAN connection that might be plugged in
    • 4G modem
  • This works, though I had to change the process by which the router detects the need to failover, and then "fail-back". The router detects the need to failover by pinging an address periodically. I set a different target for each interface.

  • The VPN connects OK, but I can’t route traffic.

    • I needed to "push" a route to the home LAN to the OpenVPN client, and add static routing statements to the home LAN’s router.
    • I also needed to add additional firewall rules on the OpenVPN server

I now had a major brain fade and managed to screw up the configuration of the Pi, so I needed to start again from scratch. Thank heavens for ansible and the fact that Home Assistant takes regular back-ups.

  • I set up an Home Assistant automation to detect when the UPs went on to battery and use this to kick off the automation that shuts the radio (if it’s on)
  • With this in place, and knowing I’d be away for a few days, I decided to see how long the UPS would power the system and whether it would recover atomically when the power returns. I disconnected the mains and went away
  • When I came back, everything had functioned correctly and the UPS had enough energy to power the system for 5h30m. More than enough.

Still to do

  • Sort out the relay switching for the radio power
  • Finalise the Node-Red dashboard
  • Add temperature/humidity sensors for inside and outside the cabinet
  • Install a Real Time Clock on the Pi

Setting up a Remote Station – Part 4 Build Log

Updated: 20/3

This post will document the process of putting together all the elements of the remote station “on the bench” in the shack. I’ll update this as it goes, and hopefully put up some pictures as well.

Day One

The router, pi and UPS have arrived, so I’ve made a start.

  • Configure the router
    • Connected my laptop to one of the LAN ports and logged in as admin
    • Changed the admin password
    • Set up the LAN Wi-Fi and address range. It needed to be changed because the default would clash with one of my internal networks.
    • Enabled https management access from the WAN
    • Connected the WAN to my home Wi-Fi and checked I could log in from the WAN, enabling me to disconnect from the router’s LAN
    • Check that the router can reach the internet and install the NTP server package to be the local time server for those occasions when the WAN is either disconnected or using 4G as I want to minimise unecessary network traffic.
  • Build the Pi
    • Downloaded the aarch64 Debian 11 image and copied it to the SSD
    • Connected keyboard, mouse and monitor to the Pi and booted it for the first time.
    • Connected it to the house WiFi, and used ‘nmcli’ to set a static address.
  • I then configured a firewall rule on the router to allow ‘ssh’ traffic to the Pi.
  • Configured the Pi
    • I use Ansible and Debops to manage the configuration of the various computers at chez M5KVK, so I ran the bootstrap playbook to:
      • update the system software
      • create some users on the Pi,
      • set up their “.ssh/authorized_keys”
      • give them “sudo” privilege
      • install a bunch of packages
    • After this, I could log in remotely to the Pi as ‘pi’
  • Install Docker, ‘os-agent’ and Home Assistant using the Supervised Installer

Day Two

  • Installed the Home Assistant addons and adjusted configuration.yaml to use Mosquito Broker, MariaDb and InfluxDb.
  • Installed the Node-Red addon
  • Installed system_sensors as a service
    • I noted that this had been created on the assumption that the operating system was Raspbian. Debian does not have the hooks to monitor the power supply, so that sensor is dead.
    • I also need to run the service as ‘root’ rather than ‘pi’

Day Three

  • The Tapo plugs have arrived, so I installed the Tapo Controller integration. For this I needed to install HACS.
  • I setup the Tapo plugs using the Tapo iOS app, connected them to the router’s WiFi, made a note of their IP addresses and added the two plugs to the Home Assistant Tapo Controller integration.

Day Four

I added the APC UPS integration to get better feedback and form the basis for the automation that shuts the radio down if the mains power fails. After reading some of the Flex documentation I realised that I needed to sequence the power to the radio. Basically, I need three “switches”

  1. To control the mains to the power supply.
  2. To control the 12V supply from the power supply to the Flex
  3. To remotely control the Flex power itself.

So, I’ve ordered a Shelly 2.5PM WiFi Relay Switch with two relays that can be controlled by Home Assistant. One will control another 12V 30A relay in the 12V feed from the power supply. The other will be connected to the Flex’s remote control port. The sequence will be:

  • Initial state, all switches OFF
  • On user command:
    • Switch on mains power and wait 2s
    • Switch on 12V and wait 2s
    • Switch on Flex
  • On user command or UPS going to battery
    • Switch off Flex and wait 30s for it to shutdown safely
    • Switch off 12v and wait 2s
    • Switch off mains power.

Setting up a Remote Station – Part 3 Software

Parts 1 and 2 covered the motivation and system design for the remote station. This post will cover the configuration of the Raspberry Pi System Control Computer.

High level view

The following operating system services will be installed:

Home Assistant

Home Assistant is implemented as a series of Docker containers. The recommendation is to either install it on Home Assistant OS or as a single Docker container.

Using Home Assistant OS provides a fully supported environment and you can use Home Assistant itself to install the various addons; whereas if you install Home Assistant on its own, you need to manually install and manage the other addon containers.

However there is another partially supported installation route, and that is to run the Home Assistant Supervised Installer on Debian 11: Note: not Raspbian. Given that I wanted to install other services, and I have the experience needed, I have chosen the Supervised Installer route.

In addition to the addons, I also need to install several Home Assistant Integrations the main one being: the Tapo Controller so I can control the mains switches.

Node-Red Dashboard

I’ll cover this later as I haven’t really given it any great thought yet. However, in principle there will be a single page with two groups of objects: the first displaying various sensors and the second with the various controls that are needed – such as switching on the mains power to the radio.

Setting up a Remote Station – Part 2 System Design and Components

Part 1 of this series covered the motivation behind this project and the requirements I set. This part will outline the system design and the components I’ve chosen.

System Design

Design Philosophy

The objective is to create a self-contained and secure environment that delivers the required functionality, looks after itself as much as possible, reports its status back to base and is fully remotely controlled. The desired location for the remote station is somewhere that already has Internet access and has a Wireless LAN that we can connect to. This avoids the need to rely on 4G access, but this will also be provided as a failover option.

I’ve chosen to deliver this using readily available components and base the control system on Home Assistant. Home Assistant is open-source software that can be used to monitor and automate just about all aspects of your home. It has a vast catalogue of supported devices and services and I’ve been using it for some years to add some smarts to my home.

I’m running Home Assistant on a Raspberry Pi 4 housed in the Argon One metal enclosure from Argon 40 with its companion M2 SSD to improve performance and reliability. I can’t speak highly enough for this enclosure. Not only is beautiful to look at, it has significant passive cooling plus a variable-speed fan. Having the SSD significantly improves the usability of the Pi – especially with the M2 SSD.

The Remote Station

  • Router with 4G modem and ability to join a host WiFi (if one is available)
  • UPS
  • Remote controlled mains switches for the Windows PC (if needed), and the Radio Power Supply
  • Raspberry Pi computer running Debian 11 (not Raspbian) and Home Assistant
  • Flex 6400 HF radio
  • Remote On/Off control system for Flex

The Home Station

  • Windows PC running SmartSDR
  • Microphone
  • Key
  • Other ham-related software such as VarAC

Component selection


I’ve chosen to use the Teltonika RUT951 industrial router. I already have one of these installed in my motorhome and it’s excellent. It isn’t cheap, but it is perfect for this job. It delivers:

  • 4G dual MIMO WAN access with support for two SIM cards,
  • Ability to connect to an external Wireless LAN as a WAN
  • Automatic failover between the various WAN connections
  • Internal Wired and Wireless LANs with 3 physical ports
  • VLAN capability (not used in this project)
  • Digital I/O, Modbus support and MQTT
  • VPN server and client
  • Remote management (not used)


I’m not looking to power the radio for any great time in the absence of mains power, but I do want to be able to shutdown in an orderly fashion. I’ve opted for the APC BackUPS 650. This provides 650VA capacity, six protected outlets, plus two surge-protected only outlets.

The following devices are connected:

  • 5V 3A PSU for the Raspberry Pi Station Control Computer (SCC)
  • 9V 1A PSU for RUT951 Router
  • Tapo P110 remote controlled sockets for the Radio PSU and optional Windows computer
  • Raspberry Pi Station Control Computer running Home Assistant

I have a lot of experience with the Pi and with Home Assistant, so this combination was a natural choice. I’ll cover the Home Assistant configuration in another post.

Radio PSU

To give me the potential to maybe operate off-grid, I’ve chosen the MyDel PS-1335 12V 30AMP PSU with battery backup capability to give a 30A UPS. The MyDEL is an unknown quantity to me. It has a good spec and is supposed to have very low noise. We’ll have to see. Just in case it proves to be unsuitable for any reason, I have another 30A PSU I can use instead.

Flex-6400 Radio

Originally, I intended using my Elecraft K3S in the remote station and using something like RemoteHams to control it. After playing with RemoteHams, I felt that there was something missing. Also, there is the issue of power control on the K3S. You can remotely command the radio to power off, but you can’t power it on remotely. This needs to be done by toggling a control pin – not a problem, but an added complexity.

For a while now, I’ve been looking at the FlexRadio range, and realised that the 6400 is ideal for this application: after all, it’s designed to be operated remotely. I went for the straight 6400 rather than the 6400M. The one I have does not have an ATU. If the proof of concept works, I’ll add the ATU module.

I’ll cover the software and the detail of controlling the power to the 6400 in a separate post.

Setting up a Remote Station – Part 1 Motivation and Requirements

Like many hams, I am deluged with RF noise.
I live on a residential estate and I am surrounded by solar panels, TVs, the (to my mind) rule-breaking VDSL, and many, many Switched Mode Power Supplies.

I’ve gradually been ground down by the challenges of operating from my home QTH and decided that I either needed to take radical action or hand in my license and sell all my equipment.
The options for radical action were:

  • stop operating from home and only operate /M, /P or /A; or
  • setup a remote station in a quieter location.

I do operate /P a lot more than I used to, but this post is the first in series on setting up a remote station.

Requirements – Mandatory

So, what do I want to be able to do?

  • Full HF capability: 160m – 10m
  • 100W
  • Single multi-band antenna
  • Full remote control of radio and power
  • Remote access over 4G
  • Support for all modes
  • Partial protection against local mains failure (I.e. ability to shutdown in an orderly fashion)

Requirements – Desirable

  • Remote access over local WiFi
  • Ability to recover from station failure
  • Multiple antenna options

Requirements – Future Possibilities

  • 6m
  • Rotator control
  • Access by other (authorised) hams
  • Extended operation in the absence of mains power
  • Solar charging of batteries

Requirements – Other

  • Physically secure cabinet (weatherproof if necessary)

The next few posts will cover the design phase and the bench top building phase. Let’s see how it goes.