BackgroundI run three remote amateur radio stations at different locations across the UK. At two of my sites I have traditional wired broadband connections, but at my third site — a scout campsite — the only available internet connection is via 5G mobile broadband.
Like most mobile internet connections, this 5G connection uses Carrier Grade NAT (CGNAT). CGNAT means that my router at the remote site does not get a real public IP address — instead the mobile provider allocates a private IP address and shares a single public IP address among many customers. The result is that nothing on the internet can initiate a connection to my remote site, making remote radio operation seemingly impossible.
My radio of choice is a FlexRadio Flex 6300, a Software Defined Radio (SDR) transceiver that is controlled over a network connection using FlexRadio's SmartSDR software. FlexRadio provides a remote access service called SmartLink which is supposed to allow remote operation from anywhere in the world. Unfortunately, as I discovered, SmartLink does not work reliably when the radio is behind CGNAT.
This blog post describes the problem in detail and the solution I eventually found, which may be useful to other Flex Radio operators facing similar connectivity challenges.

Understanding the ProblemHow SmartSDR Discovers RadiosSmartSDR uses UDP broadcast packets to discover Flex radios on the local network. Broadcast packets are sent to every device on a subnet simultaneously — think of it like shouting in a room. Every device hears the broadcast and the Flex radio responds to announce its presence.
The fundamental problem with broadcasts is that they do not cross router boundaries. A broadcast sent on your home network stays on your home network — it cannot reach a radio on a different network at a remote location.
What SmartLink Is Supposed To DoSmartLink is FlexRadio's solution to this problem. It works as follows:

1. The radio registers with FlexRadio's SmartLink servers (hosted on AWS)
2. The SmartLink servers keep track of where each registered radio is
3. When a remote client wants to connect, SmartLink tells it how to reach the radio
4. The client connects to the radio via SmartLink relay servers if a direct connection is not possible

This works well when the radio has a real public IP address. SmartLink can tell the client "connect to this IP address on these ports" and the connection succeeds.
Why SmartLink Fails with CGNATWhen the radio is behind CGNAT, SmartLink advertises the CGNAT IP address rather than a publicly reachable address. The client tries to connect to the CGNAT IP but this address is not reachable from the internet — it is a private address shared among many customers of the mobile provider.
I confirmed this by hovering over the radio in the SmartSDR chooser and seeing a 92.x.x.x address (the CGNAT IP) rather than a publicly routable address.
44net Connect — A Partial Solution44net Connect is a service provided by ARDC (Amateur Radio Digital Communications) that gives licensed amateur radio operators access to the 44.0.0.0/8 IP address space — IP addresses historically allocated for amateur radio use.
Using a simple WireGuard VPN tunnel, 44net Connect provides a static, publicly routable 44.x.x.x IP address to any device, even one behind CGNAT. This is exactly what 44net was designed for — bypassing CGNAT to give amateur radio operators a reachable public IP address.
I set up 44net Connect on a MikroTik router at each of my three sites, routing all traffic through the tunnel so that devices at each site appear to have a 44.x.x.x public IP address.
With 44net Connect in place, all internet traffic from my CGNAT site exits via the 44.x.x.x address. However, SmartLink still failed — because SmartLink's IP discovery mechanism picks up the underlying CGNAT address rather than the 44net address when determining what to advertise to remote clients.

The SolutionAfter considerable experimentation and helpful advice from the 44net and FlexRadio communities, I found a two-component solution:
Component 1: WireGuard Site-to-Site Mesh TunnelRather than relying on SmartLink, I created a direct WireGuard tunnel between my home router and the remote CGNAT site router. This is a "mesh tunnel" — a direct encrypted connection between the two sites, separate from the 44net Connect tunnels.
The key insight that makes this work with CGNAT is the direction of the connection:

• The CGNAT site initiates the outbound connection to the home site
• CGNAT allows outbound connections and their return traffic
• CGNAT only blocks unsolicited inbound connections

By having the remote site dial out to the home site (rather than the other way around), the CGNAT is completely bypassed. The home site listens for the incoming connection and the tunnel is established.
Once the tunnel is up, the home network has full IP connectivity to all devices at the remote site. Any device on the home network can reach any device at the remote site by IP address.
Component 2: SmartUnlinkEven with full IP connectivity via the mesh tunnel, SmartSDR still could not discover the radio automatically — because, as described above, UDP broadcasts do not cross router boundaries.
The solution is a free utility called SmartUnlink (https://github.com/brianbruff/SmartUnlink), developed by Brian Bruff. SmartUnlink runs on the client PC and acts as a broadcast proxy — it takes the radio's IP address as input and makes the radio appear in the SmartSDR chooser as if it were on the local network.
With SmartUnlink running and pointed at the remote radio's IP address, SmartSDR discovers and connects to the radio successfully.

Equipment Required

• MikroTik RB750GR3 (hEX) at the CGNAT remote site — this is important. The hAP lite (the smaller, cheaper MikroTik) struggles to run two simultaneous WireGuard tunnels (44net Connect + mesh tunnel) and may crash. The hEX has a quad-core 880MHz processor and 256MB RAM which handles both tunnels easily.
• MikroTik hAP lite (or better) at the home site — the home router only needs to run one mesh tunnel alongside the 44net Connect tunnel. The hAP lite can manage this but runs close to its limits; a hEX is recommended if budget allows.
• 44net Connect account — free for licensed amateur radio operators at https://connect.44net.cloud
• SmartUnlink — free download from https://github.com/brianbruff/SmartUnlink/releases
• A PC running SmartSDR v4.x

Step-by-Step Setup GuidePrerequisitesBefore starting, ensure:

• 44net Connect tunnels are configured and working on both the home and remote routers
• Both routers are running RouterOS 7.x (7.23.1 recommended)
• You know the 44net IP addresses of both routers (e.g. 44.x.x.x)
• You know the LAN subnet of the remote site (e.g. 10.230.0.0/16)
• You know the LAN subnet of the home site (e.g. 192.168.88.0/24)
• You have Winbox or SSH access to both routers

Step 1: Choose Your Tunnel ParametersYou will need:

• A new subnet for the mesh tunnel (must not overlap with either LAN): e.g. 10.200.0.0/24
• Home tunnel IP: e.g. 10.200.0.1/24
• Remote tunnel IP: e.g. 10.200.0.2/24
• A port for the new tunnel: e.g. 51821 (different from 44net Connect which uses 51820)

Step 2: Create WireGuard Interface on Remote (CGNAT) RouterConnect to the remote router via Winbox and run:
/interface wireguard add name=wgMesh listen-port=51821 comment="Mesh tunnel to Home" Get and note the public key:
/interface wireguard print Note the public-key value — you will need this for the home router configuration.
Step 3: Create WireGuard Interface on Home RouterConnect to the home router via Winbox and run:
/interface wireguard add name=wgMesh listen-port=51821 comment="Mesh tunnel to Remote" Get and note the public key:
/interface wireguard print Note the public-key value — you will need this for the remote router configuration.
Step 4: Configure the Home RouterReplace <REMOTE-PUBLIC-KEY> with the key from Step 2, and <REMOTE-44NET-IP> with the remote site's 44net IP address, and <REMOTE-LAN-SUBNET> with the remote LAN subnet:
/ip address add address=10.200.0.1/24 interface=wgMesh comment="Mesh tunnel home end" /ip firewall filter add action=accept chain=input protocol=udp dst-port=51821 comment="Allow mesh WireGuard" place-before=0 /ip route add dst-address=<REMOTE-LAN-SUBNET> gateway=wgMesh comment="Remote site via mesh" /interface wireguard peers add interface=wgMesh public-key="<REMOTE-PUBLIC-KEY>" allowed-address=10.200.0.2/32,<REMOTE-LAN-SUBNET> persistent-keepalive=25s comment="Remote mesh peer" Step 5: Configure the Remote (CGNAT) RouterReplace <HOME-PUBLIC-KEY> with the key from Step 3, <HOME-44NET-IP> with the home router's 44net IP address, and <HOME-LAN-SUBNET> with the home LAN subnet:
/ip address add address=10.200.0.2/24 interface=wgMesh comment="Mesh tunnel remote end" /ip firewall filter add action=accept chain=input protocol=udp dst-port=51821 comment="Allow mesh WireGuard" place-before=0 /ip route add dst-address=<HOME-LAN-SUBNET> gateway=wgMesh comment="Home LAN via mesh" /interface wireguard peers add interface=wgMesh public-key="<HOME-PUBLIC-KEY>" endpoint-address=<HOME-44NET-IP> endpoint-port=51821 allowed-address=10.200.0.1/32,<HOME-LAN-SUBNET> persistent-keepalive=25s comment="Home mesh peer" /ip firewall nat add chain=srcnat out-interface=wgMesh action=masquerade comment="Mesh masquerade" Step 6: Verify the TunnelOn the remote router, check for a handshake:
/interface wireguard peers print detail You should see last-handshake appear within 30 seconds. Then ping the home tunnel endpoint:
/ping 10.200.0.1 count=4 On the home router, ping the remote radio:
/ping <FLEX-RADIO-IP> count=4 If all pings succeed, the mesh tunnel is working correctly.
Step 7: Add a Route on the Client PCOn the Windows PC running SmartSDR, open an Administrator command prompt and run:
route add <REMOTE-LAN-SUBNET> mask <SUBNET-MASK> <HOME-ROUTER-LAN-IP> For example:
route add 10.230.0.0 mask 255.255.0.0 192.168.88.1 To make this permanent across reboots:
route -p add 10.230.0.0 mask 255.255.0.0 192.168.88.1 Test from the PC:
ping <FLEX-RADIO-IP> Step 8: Install and Configure SmartUnlink

1. Download SmartUnlink from https://github.com/brianbruff/SmartUnlink/releases
2. Install and run SmartUnlink on the client PC
3. Enter the Flex radio's IP address at the remote site
4. SmartUnlink will proxy the broadcast discovery

Step 9: Connect with SmartSDR

1. Start SmartUnlink (before SmartSDR)
2. Open SmartSDR — the radio should appear in the chooser
3. Connect — audio and waterfall data will flow via the mesh tunnel

MTU SettingsThis is important and often overlooked. You must set the MTU correctly on both the WireGuard interfaces and in SmartSDR:
For non-CGNAT sites (wired broadband):

• WireGuard MTU: 1380 (44net default)
• SmartSDR Radio MTU: 1340 (Settings → Radio Setup → Network → Advanced → MTU)

For CGNAT sites (5G/4G/Starlink):

• WireGuard MTU: 1280
• SmartSDR Radio MTU: 1240

Without correct MTU settings, SmartSDR will connect but the waterfall/spectrum display will be blank as UDP packets are silently dropped due to fragmentation.
To set WireGuard MTU on MikroTik:
/interface wireguard set wireguardPOP mtu=1280
LimitationsThis solution works well but has some important limitations to be aware of:

1. Requires a non-CGNAT connection at one end — the mesh tunnel needs at least one publicly reachable endpoint. If both ends are behind CGNAT this solution will not work as described. Both ends would need 44net Connect tunnels and a different approach (such as ZeroTier) would be needed.
   
2. Home router is always in the path — all radio traffic routes via the home site before reaching the remote site. This adds latency and means the home internet connection must be reliable and fast enough to carry radio traffic.
   
3. SmartUnlink must be running — it is not automatic and must be started before SmartSDR on each client session.
   
4. Route must be added on each client PC — any PC used to connect remotely needs the static route to the remote LAN subnet added. This is a one-time setup per PC.
   
5. SmartLink is bypassed — you cannot connect from an arbitrary location without first installing SmartUnlink and adding the route. This makes impromptu connections from unfamiliar locations (hotel, friend's house) more complex.
   
6. hAP lite is marginal for two tunnels — if using an hAP lite at the home site, monitor CPU usage carefully. Running two WireGuard tunnels simultaneously pushes the hAP lite close to its limits. An hEX is strongly recommended.
   

ResultsWith this solution in place, I can operate my Flex 6300 at the remote 5G CGNAT site from my home network with:

• Latency of approximately 80ms
• Full waterfall and spectrum display
• Good audio quality
• Reliable connection

The solution has proven stable and is a significant improvement over the weeks of troubleshooting SmartLink over CGNAT.

AcknowledgementsMany thanks to the 44net Connect reflector community, particularly Brian W1BKW for the MTU tip, and to G4IRN John Warburton for his excellent write-up on ZeroTier bridging which informed much of this investigation. Thanks also to Brian Bruff for developing SmartUnlink.
73 de M0BPQ

 My conclusions at 28Mhz are:

1) Gain is more important than tower height at this site on this band.
2) The 5 element at 28MHz has a better figure of merit at 60 ft in most directions as it's gain doesn't fall away at medium arrival angles compared to higher antennas.
3) The take of angle to the EU is quite a lot more than 5 degrees,  maybe EU isn't DX?
4) My on air experience is that the 3 el at 100 ft is able to open the band. I guess this is because the arrival angle is low and the combination of 100ft tower and the slope works to our advantage.

Please use the comments below or tag me in Twitter!
​

​A popular YouTuber was speaking recently about how we should use vertical antennas to “command DX” as their primary lobes are at low angles, he uses gain at 5 degrees to promote the antennas we sells. This reminded me of some work by N6BV published in the ARRL Antenna Handbook which demonstrated that your terrain also has a substantial impact on the lobes of your antenna.  This led me to consider what the effects of the terrain at GB2GP has upon on the performance of our antennas.

There is nothing new here; N6BV created some modelling software called HF Terrain Analysis (HFTA) which plots the gain of typical horizontal antennas over your specific terrain and can compare it to flat earth. We are pretty lucky that Gilwell Park is on a local high spot so it will be interesting to see how the slopes that are in several directions have an impact. 

The image below is a typical HFTA output and compares the gain of a 3 element, 28MHz yagi at 100ft over the terrain at Gilwell Park (blue line) beaming to north America, compared to the same antenna over flat ground (green line). The terrain give a clear advantage at 2 degree take off angle, +7dBi,  but a 2.5bDi disadvantage at the 5 degrees.​

Generating the terrain profiles for HFTA) has generally been a serious undertaking, but luckily K6TU has done us all a great service by automating this on his website https://k6tu.net/?q=TerrainProfiles. I have used these and thank him for making these publicly available.

Antenna height has a substantial impact on take of angles for horizontal antennas and we are fortunate at GB2GP to have three towers for HF yagis at 60, 80 and 100ft. Would swapping the antennas round offer any significant advantage on any particular contest band? The following posts simulates our current antennas at each height in key directions.

HFTA also includes take off (or arrival) angle data for signals over specific paths. Whilst 5 degrees cited in the opening paragraph might work as a rule of thumb, it’s a long way from the full picture as the Angle of Arrival changes with ionospheric conditions and HFTA plots the percentage probability of different arrival angles on a second y axis. This data suggests that we all need different antennas to suit every set of conditions, but acknowledging the real world, HFTA also includes a coarse judge of quality that amalgamates the gain over your terrain with the Angle of Arrival profile to help us decide which configuration is best.

The graph below shows the same set of antennas and direction with elevation statistics for the same path. 8% of signals arrive at 2 degrees where our 3 element yagi at 100ft has a terrain advantage, but similar percentage of signals arrive at 5 degrees where we have a disadvantage over flat terrain. 

I am about to move house, so only made a few QSOs in CQWW this weekend, mainly with pacific DX found via the cluster.

I heard one station in zone 27 weakly running a pile up so I joined in the fray to try and work a new band slot. After a while the QRM was bad and I couldn’t hear the DX. I decided to stop transmitting and wait for a “TU” so that I can get stuck in again without causing QRM.

Me: [I’ll wait for a TU before calling again]

DX: comes up from the noise “TU – qrz?”

Me: [too slow to drop my call. I’ll wait for the next QSO to be completed]

DX: “M0BPQ – 599 27”

Me: [How the hell did that happen? Quick! Tx a report] “M0BPQ 599 14”

DX: “M0BPQ TU X1YZ TEST”

So, a valid QSO from my side, but how did he know I was there? He must have been using a code reader of some sort and picked me off the screen?

The guys from Wimo have been really quick on email and kindly sent out a new boom to fix my incorrectly packed antenna. This arrived at the Scout site on Saturday. The problem is that the box had a neat cut round the centre and the new boom is bent like a banana in two axes.

I hope the Wimo guys can claim for this from their courier as I need another one!

I took a closer look at the remaining parts to build the last yagi and found two potential problems. One is easy to solve – an element without a hole through it which I re-drilled in a flash. The second problem is not so good. The Driven Element has a tag on one side which I assume is used to align the elements and ensure they are all driven in phase. The problem I have is that I can’t align this DE with the other three in the stack without turning it round backwards! Three of the antennas have the DE tag on the left when the connector is facing forwards, whilst the final one has it on the right. Do Wimo produce the DEs in different orientations?   Or has the tag been placed on the wrong side? How do I find out? I can’t use an ohm meter on a folded dipole…. Answers on an email postcard, please

I have been buiding some wimo yagis to use for JOTA,but have hit some problems with one antenna. Here are the parts laid out for the two new yagis that I bought. All looks well!

But looking a bit more closely there is a problem with the boom sections. The top pair are OK, with the rear boom section at the very top of the picture and the front boom being the next one down. However the two sections supplied for the next antenna are identical. This photo was taken at the point where the DE attaches. Apologies for the quality of the photos!

So, have I been sent 2 x rear booms? I think not. If you compare the top boom section and the bottom two then holes do not line up. This is at the D1 hole. 

I could have flipped the booms through 90 degree and redrilled, but as the picture below shows, the boom sections supplied are too short.

So - I now have three antennas complete, and have written to wimo to solve the boom problem with the third. Let's hope the customer service is good...

Working 8P6 is nothing special, but it was nice to get 8P6DR, who is my HWCG club mate -G3RWL. Here's a video of a him working PY some time later!

For the first time in almost 3 years I got the chance to operate in WPX CW. Conditions seemed to be good and I had a lot of fun over the 6 or so hours I was on (in bursts). Over all I made 339 Qs in  66 DXCC without really trying. The most fun I have had on the radio for some time!