Tag: Flex-6400

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.

Setting up a Remote Station – part 13 The Installed Station

The main image shows the installed station – but still in the garden. The top shelf has the Flex 6400 on it, the middle shelf the control system and the bottom has the UPS and power supplies. Hopefully, this will cut down on noise induction.

This image shows the control board before being installed in the cabinet.

Top left is the ancillaries board with an input jack from the ancillary 12V PSU, a couple of Power Poles to feed other 12V devices, the ESP8266 running ESPHome and code for the environmental sensors – an on-board Temp/Humidity sensor for the internal cabinet, and two 1-wire temperature sensors that will be placed in the space between the two cabinets and outside. On the far right is the Teltonika RUT951 router. In the picture it has its internal aerials on, but in the field it will have the 4G antennas and one of the wi-fi antennas connected to external antennas.

Below that is:

  • The Sonoff 4ch switch which controls the Remote On/Off and PTT on the Flex, and the 12V power to the remote auto ATU (not shown)
  • The Geekom Mini IT8 Windows PC
  • The Netgear Ethernet switch, and
  • The Raspberry Pi4 in its smart Argon One case.

Not shown in this image are any power leads. Also not shown in this image, but visible in the main one, are the two Tapo wi-fi switches that control the mains input to the main 12V PSU and the PC’s PSU. The switches are on the middle shelf in case the wi-fi doesn’t penetrate to the bottom shelf. I’m going to try them in the bottom today.

The station is now built, but I’m going to leave it in the garden for a week or so to accumulate sensor readings so I can decide if I need to add forced cooling. It will be located against a north facing wall, so won’t get any direct sun. It’s in a similar north-facing position in the garden, but will get a bit of early morning and late afternoon sun for the next week or so.

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 10 Overview of the Final System

Hopefully the image above should help to understand what the station consists of. The station comprises:

  • a 240V network with the UPS at its core and feeding:
    • two Tapo switches (one for the PC and one for the Radio PSU);
    • the permanently-on auxiliary 12V PSU that powers the Sonoff, network switch and the ATU controller; and,
    • the permanently-on PSUs for the Router and the Pi-based Station Controller.
  • A mixed wired and WiFi network connecting most devices.
  • The main Radio PSU – Flex – ATU – Antenna Disconnect RF chain.
  • The Sonoff that switches the Flex on and off and operates the PTT when needed.
  • The Pi-based Station Controller running Home Assistant.
  • The Windows 10 PC used for digital modes.

I hope this all make sense.

Moving on, the station has been operating from my home QTH for some time now whilst I scout out a suitable remote location. I’m glad to say that a local farmer has agreed to let me site the station on their land. The only downside is that the station needs to be outside, so I now need to source a suitable IP65 or IP66 (but ventilated) wall-mounted cabinet to house it all in. Not easy to find!

For the antenna, there is a convenient line of trees close by and a 10m high barn; to which they have agreed I can mount a 20m pole to be one end of the doublet antenna I intend to use – the other end being one of the trees. With luck I’ll be able to erect a decent doublet at 20m off the ground and fed by balanced feeder from the SG-230; which will be mounted 2-3m off the ground at a convenient location midway between the ends of the doublet – probably somewhere on the wall of the aforementioned barn. I’ll use a 12V combiner to feed power to the ATU and the antenna disconnect unit.

Setting up a Remote Station – Part 9 Nearly Complete

Let me start with an apology. This site has been off the air for some weeks due to a server move initiated by my hosting provider. They gave me plenty of warning, but unfortunately the move took place whilst I was away and unable to react. Hopefully all is well now.

Nearly complete

It’s been some time since I last posted on this topic because I have been away on an extended trip. However, I’m back now and am now very nearly (hopefully) at the point where I can move the completed station to its new location. Since the last update, I’ve been able to:

  • Resolve the networking issue I grappled with in the previous post by adding an intermediate Ethernet switch.
  • Rebuilt the Station Control Computer to run Home Assistant on its preferred operating system – Home Assistant OS. HAOS is a stripped down Linux built using BuildRoot: which is optimized for embedded devices.
  • As a consequence, I’ve also migrated a couple of the additional systemd services I used before, to use Home Assistant Addons, viz: The code to monitor the UPS, the code to monitor the Pi, and the code to control the fan in the Argon40 case I am using. For the UPS, I am now using NUT rather than APCUPSD. This forced me to change the code in the Windows PC as well.
  • I’ve also added integrations to display the current RF conditions and provide warnings of any local thunderstorms.

My main tasks still outstanding are:

  • To source an auto-disconnect for the antennas.
  • To build a 12V injector to feed power to the SG-230 ATU that will be located at the base of the antenna.
  • To enable the MQTT service on the router, so it can report status to Home Assistant
  • To work on the Home Assistant dashboard that will be used to control everything.
  • Develop automations to disconnect the antennas and power off the ATU if lightning is detected close by, or when the radio is off.

Once I have fixed the final location I can also:

  • Decide on what is needed to house everything, which will also let,
  • Lay everything out on a plywood base board,
  • Finalise cable lengths and source screened cables for everything.

So, actually there’s quite a lot still to do.

In the next post, I’ll summarize where we are and include some diagrams that should hopefully make everything clearer.

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.

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

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 192.168.1.0/24 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.