Updated System Control Computer screens

I thought I’d post some updated screens from the Raspberry Pi that monitors and controls the remote station.

By way of a refresher, it’s a Raspberry Pi 4 in an Argon One case and running Home Assistant. The SCC does the following:

Provides a control surface for the main 12V power supply, the Flex itself, the remote ATU and the Windows PC
Monitors the state of the various switches and sensors in the remote shack
Controls the heating and cooling for the cabinet
Alerts me to various conditions
Does its best to protect the entire system when the going gets tough 🙂

So, on to the images.

Control Screen

This is the main control screen as seen from a desktop or laptop. At the top are various status indicators, followed by the time and current propagation and then buttons to control the Flex PSU, the ATU, the Flex 6400 and the Windows PC that I use for digital modes.

The final button allows me to toggle the PTT line on the Flex. This is needed if you change the SmartLink configuration.

All windows are dynamic, depending on the browser viewport. This image is the same screen, but seen on a mobile device. Basically, it removes unnecessary elements.

Propagation Screen

The next screen displays more detail on the current propagation state.

System State Screen

Next is a screen showing various indicators about the system state. Some of this is a repeat of what’s on the Control Screen.

Environment Screen

The inner cabinet has temperature sensors on each shelf, plus sensors for the temperature in the external cabinet and outside. Home Assistant uses these with virtual thermostats to control a heating element and cooling fans in the inner and outer cabinets.

In extremis, Home Assistant will shut down the radio if things are getting too hot. It will alert me using Pushover if it’s getting too cold, so that I can (e.g.) switch on the Power Supply and (maybe) the Flex to warm things up.

Grafana

All sensor values, system state changes etc are logged to an Influxdb database, from where it can be displayed using Grafana.

This screen shows propagation history, and there is another displaying temperature and humidity changes.

Using SmartLink to access my remote shack

A consequence of the way my remote shack is connected to the Internet stops me using FlexRadio’s SmartLink to access it. I knew this would be the case, and I put in place a solution to give me access from home; but it was only a partial solution because I couldn’t use the Windows version of SmartSDR. This article details how I implemented a more general solution using a Virtual Private Server and Zerotier.

Background

All Flex radios are LAN connected and support multiple ways to access them from a network device running a variant of the SmartSDR software. You can “Discover” the radio from SmartSDR running on a Windows PC – but only if it’s on the same IP subnetwork. If you are using the excellent SmartSDR for Mac – which I do most of the time – you can also access the radio using a specific IP address – which overcomes the restriction in SmartSDR for Windows. For both clients, you can also access the radio using FlexRadio’s proprietary SmartLink protocol.

Unfortunately, there are situations where none of these solutions work; and I am in one of those situations.

Problem

SmartLink is a deceptively simple protocol that enables a radio to register its presence in a central directory so that suitably authenticated SmartSDR clients can lookup the IP address of the radio; and then connect to it. Provided the user can open a couple of ports in the firewall, this approach works for most installations because the radio is sitting on a home LAN behind a simple router/firewall that implements Network Address Translation. Unfortunately – as detailed elsewhere on this Blog – my remote shack is located behind two firewall routers – of which I have control over only one. On top of that, the Internet Service Provider to which my kind farmer’s router is connected implements CGNAT; which also screws up SmartLink.

The Partial Solution

As an interim solution as a way of allowing me to access my Flex 6400 from home, I setup an Layer 3 Overlay Network using Zerotier between my home Unifi USG router and the Teltonika RUT951 at the remote site. This effectively created a VPN circuit between the two sites – bypassing the farm’s router – and allowing me to “see” the Flex. However, this only works for SmartSDR for Mac because only this variant allows one to specify the IP address of the radio. SmartSDR for Windows doesn’t work because it can only use either Discovery or SmartLink to the radio.

Discovery requires the PC and the Radio to be on the same Level 3 network – which they aren’t; and SmartLink “sees” the IP address of my router, not the IP address of the farm’s router (plus of course, there is no route).

The Full Solution

To enable SmartSDR for Windows to work, I needed to get the radio to advertise an accessible IP address. My solution was to implement a Virtual Private Server in the cloud and set it as the default route for my remote shack.

This is how I did it.

The Virtual Private Server

After some research, I settled on IONOS as a hosting provider. My needs are very basic and they are very cheap. Also, their technical support is responsive and they’re located in the UK: which helps to reduce network latency.

Ansible and Debops

I use Ansible and Debops to manage the configuration of the many servers and network devices under my control. I won’t go into details as there are plentiful sources of excellent tutorials, but in brief: Ansible allows me to define the configuration of the VPS in a series of text files on my computer and then “build” the VPS with a single command. Debops builds on Ansible to deliver a comprehensive suite of configurations for Debian based servers.

The files are themselves managed in a git repository, and if I want/need to change the configuration, I simply update the text files and run the command again. Crucially, it means I don’t have to worry about backing up the VPS. If it gets compromised or corrupted, I destroy it and recreate it from scratch with a single command.

It’s brilliant!

The VPS Configuration

The VPS is a smallest IONOS provides; with 1GB RAM and 10GB of disk. The Ansible and Debops configurations:

Harden the VPS against attacks
Install Zerotier and configure it
Install nginx and configure a Reverse Proxy to give me access to the Raspberry Pi that controls the remote shack.
Configure the WAN firewall to forward traffic on the Smartlink ports to the remote site.

At the remote site

The RUT-951 supports Zerotier out of the box, so all I needed to do was connect it to the Zerotier network and configure it to use the VPS as its default route.

And that was it. When I run SmartSDR, I see the IP address of the VPS and I can connect to it.

Simples.

Pulling it all together

Now that I’m pretty much at the end of the series on putting together my remote shack, I thought I should list all the posts in a single location, rather than having folks stumbling their way around my blog. So here it is:

There will be a couple more posts with updated screenshots of the control system and external views of the shack and aerial. I’ve also got a post on improvements to the remote access solution.

First Light at the Remote Shack

It’s been so long since I last updated this project, you could be forgiven for thinking that I’d abandoned it. Apologies for that. However, the good news is that the remote shack is up and running. The performance needs to be improved, but it works.

I soak tested the whole set of kit in the back garden for nearly a year so that I could be sure that everything worked, and could be recovered if something untoward happened. It also gave me the opportunity to test the environmental controls across summer and winter. As it turned out, I didn’t learn enough.

Environmental Changes

The main change was to insulate the inner cabinet with some aluminium backed polystyrene sheet (the sort of the stuff sold to go down the back of radiators) and add a controlled 60W heater in the base of the inner cabinet. Based on the performance last summer, I didn’t need any forced ventilation – though I left provision for it in the system design. Now that it’s in it’s final position, I now know I do need forced ventilation as well. I’ll fit something next time I visit.

Moving to the Farm

I moved the shack to the farm in June, but immediately realised that my original site survey had been invalidated by the erection of a new steel-framed barn. After a lot of wandering around with my phone testing WiFi signal strength, I realised there was nowhere I could place the kit and connect directly to the farm’s WiFi. That required a re-think.

Luckily, I was able to negotiate a new position close to an external power socket and with easy cable runs to the main farm building and where I wanted to put the antenna. However, I did need to re-design the connection to the farm’s Wi-Fi network as there was no line-of-site link to the nearest Access Point.

I bought a TP-Link CPE210 PoE Wireless Access Point. This device can be placed in client mode to become an Ethernet connected wireless interface for the RUT951 router. I placed the CPE210 physically close to the farm’s main Access Point and ran a 40m long Ethernet cable back to the WAN port of the RUT951 in the cabinet. It works perfectly and I’m getting about 20ms ping times to google.com. Throughput is not really important, but I’m getting about 10 MBytePS down and 500 kBytePS up.

Antenna

I’ve changed my mind about hanging a big doublet in the trees for now and have instead erected a multi-band vertical. Initially I looked at DX-Commander, but then realised that I had a 18m Spiderbeam pole in the shed. With a wire running up it and the SG-230 ATU at the bottom ( plus radials), it has the potential to provide a 80m-10m antenna.

First Light

The newly located system went live in the middle of July. I’ll do a video run through of the station as it appears from home when I get time.

Still to do are:

The antenna is not performing as well as I hoped – the wire length needs to be adjusted – and base noise levels are higher than I hoped – though considerably better than from home.
With the compromised method of getting Internet access (i.e. via somebody else’s wireless network), I am suffering from double-NAT: IP addresses are being translated twice whereas NAT only occurs once in usual cases. This prevents me exploiting the UPNP feature on the farm’s router to open a temporary hole in the firewall for SmartLink. As a result, I can’t access the Flex using SmartLink. I can get in using a VPN connection using ZeroTier, but the performance is insufficient for voice traffic. \

To get around this, I am implementing a cloud-based Virtual Private Server that will be an access server for the remote shack. All traffic to and from the shack will transit the VPS where I can control fire walling and other aspects. More on that another time.

Remote Station Screenshots

As I’ve been “playing” with it a bit, I thought I’d post some updated screenshots of the control system I use for the remote station. As a reminder, I use a Raspberry Pi 4 running Home Assistant OS and Home Assistant.

There are four tabs on the screen for: Overall status and control; Current and recent propagation conditions; more system status information; and environment conditions at the remote station.

In addition, there are special screens showing more detailed information and diagnostics should they be needed.

Image of propagation screen — Propagation Screen

Image of system status screen — System State Screen

Image of environment screen — Environment Screen

The last screen looks more complex than it needs to be because I have been playing with the system to optimize the temperature and humidity in the cabinet. Once I’m done, I’ll hide the various thermostats because they’ll never be adjusted by a user.

Setting up a Remote Station – part 12 Pictures

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 8.8.8.8) 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:

running Ham-related software locally reduces Internet traffic and latency; and,
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:

VE7CC DX Cluster software
Log4OM logging software
SmartSDR for Windows to drive the Flex locally
WSJT-X

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:

I don’t need to worry about the public IP address of the remote station; and,
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.

Implementation

At the Server end

The home QTH OpenVPN server is reachable from the Internet.
The Home QTH LAN is 172.29.12.0/24
The VPN Server’s Home QTH LAN IP is 172.29.12.11
The VPN uses 10.8.0.0/24
The VPN server uses the following server.conf (relevant content only)

dev tun 
topology subnet 
server 10.8.0.0 255.255.255.0 
push "dhcp-option DNS 172.29.12.1" 
route 10.29.5.0 255.255.255.0 
push "route 172.29.12.0 255.255.255.0"
push "route 0.0.0.0 0.0.0.0" 
client-to-client

The Home QTH’s router has a static route to 10.29.5.0/24 using the gateway 172.29.12.11

At the Remote Station

The LAN has the address space 10.29.5.0/24
The RUT951 is 10.29.5.1
Once connected to the VPN, the RUT is also 10.8.0.5

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