<![CDATA[M0BPQ Amateur radio - Radio Blog]]>Thu, 25 Jun 2026 18:53:34 -0700Weebly<![CDATA[Remote Flex Radio Operation Over 5G CGNAT Using 44net Connect and WireGuard Mesh]]>Thu, 25 Jun 2026 20:44:08 GMThttps://m0bpq.weebly.com/radio-blog/remote-flex-radio-operation-over-5g-cgnat-using-44net-connect-and-wireguard-meshBackgroundI 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
]]><![CDATA[Effect of antenna height on 21MHz performance at GB2GP]]>Wed, 30 Dec 2020 22:48:09 GMThttps://m0bpq.weebly.com/radio-blog/effect-of-antenna-height-on-21mhz-performance-at-gb2gpThe next contest band for HFTA analysis is 21MHz. The GB2GP antennas are either 3 elements on the 100ft tower or 4 elements on either the 80 or 60ft towers.
The graphs below show that the as wavelength increases, height becomes more important to achieve the lower take of angles. the absolute difference between the high 3 element and lower 4 element yagis is less than at 28MHz, but the 4 element antenna at 60ft has better average performance across a wide range of arrival angles, as indicated by the Figure of Merit. 

The general terrain at GB2GP has a downward slope in several directions, with the only rise towards the North East - i.e. towards Japan. This is reflected in the HFTA analysis where the extra tower height seems to really help. You can see the general horizon with the screen shot from heywhatsthat.com below.

Picture

On 21Mhz, a lower antenna may be better overall, but my conclusion is that this band will not see any major improvement by moving antennas around.

]]><![CDATA[Effect of antenna height at GB2GP on performance at 28MHz]]>Sun, 27 Dec 2020 23:39:22 GMThttps://m0bpq.weebly.com/radio-blog/effect-of-antenna-height-at-gb2gp-on-performance-at-28mhzGB2GP has three towers at 60, 80 and 100ft. For 28MHz we currently have a 3 element yagi at 100ft, a 5 element yagi at 80ft, which could be moved to the 60ft tower if needed. There is no easy way to move the big yagi to 100ft.
The HFTA analysis presented in the gallery below compares these antennas against a flat earth model. I have assumed the following beam headings:
JA - 30 Deg
EU - 80 Deg
AF - 170 Deg
NA -300 Deg
SA - 235 Deg
AS - 80 Deg
Click through the gallery and let me know which height would would choose and why!
 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!
​
]]><![CDATA[A study on the effect of terrain on your antennas]]>Sun, 27 Dec 2020 08:00:00 GMThttps://m0bpq.weebly.com/radio-blog/netmask-subnet-25525500-16gateway-1023011dns1-8888dns2-8844remoterig-1-ports-5000-to-5003-ip-1023010080remoterig-2-ports-5004-to-5007-ip-1023010081remoterig-3-ports-5008-to-5011-ip-1023010082webswitch-1-port-5012webswitch-2-5Picture
​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. 
Picture

The following posts will show a band by band analysis for GB2GP. 

]]><![CDATA[CQWW CW]]>Mon, 26 Nov 2012 14:42:42 GMThttps://m0bpq.weebly.com/radio-blog/cqww-cw 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?

]]><![CDATA[More WY209 issues]]>Tue, 16 Oct 2012 17:25:16 GMThttps://m0bpq.weebly.com/radio-blog/more-wy209-issues 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!
Picture
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

]]><![CDATA[Wimo WY209 Build and problems]]>Tue, 09 Oct 2012 11:15:29 GMThttps://m0bpq.weebly.com/radio-blog/wimo-wy209-build-and-problemsI 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!
Picture
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!
Picture
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. 
Picture
I could have flipped the booms through 90 degree and redrilled, but as the picture below shows, the boom sections supplied are too short.
Picture
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...
Picture
]]><![CDATA[QSO with 8P6DR]]>Mon, 08 Oct 2012 11:37:06 GMThttps://m0bpq.weebly.com/radio-blog/qso-with-8p6drWorking 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!
]]><![CDATA[WPX CW 2012]]>Tue, 29 May 2012 05:44:50 GMThttps://m0bpq.weebly.com/radio-blog/wpx-cw-2012For 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!
Summary of DXCC entities worked by MØBPQ on all bands

Summary of DXCC entities worked during WPX-CW by MØBPQ on all bands
Type of propagation: All Mode: All mode
From 24/05/2012 to 28/05/2012

DATA OF FIRST QSO
DXCC QSO Conf CALLSIGN DATE TIME BAND
4L (Georgia) 1 0 4LØA 27/05/2012 00:10 20 m.
5B (Cyprus) 2 0 5B/RN3QO 26/05/2012 09:07 10 m.
6V-6W (Senegal) 1 0 6V7S 26/05/2012 21:35 15 m.
9A (Croatia) 7 0 9A3VM 26/05/2012 07:43 10 m.
9V (Singapore) 1 0 9V1YC 27/05/2012 00:19 15 m.
A7 (Qatar) 1 0 A73A 26/05/2012 23:32 80 m.
BY,BT (China) 1 0 BY5CD 27/05/2012 20:42 20 m.
CA-CE (Chile) 5 0 CE3CT 26/05/2012 19:59 10 m.
CM, CO (Cuba) 2 0 CO2MS 26/05/2012 22:23 20 m.
CT (Portugal) 1 0 CT2AA 26/05/2012 22:33 20 m.
CT3 (Madeira Is.) 3 0 CR3L 26/05/2012 09:25 10 m.
CV-CX (Uruguay) 1 0 CX2AQ 26/05/2012 20:49 15 m.
D2-3 (Angola) 1 0 D3AA 26/05/2012 21:41 20 m.
DA-DL (Fed. Rep. of Germa) 16 0 DL1WA 26/05/2012 09:14 10 m.
EA8-EH8 (Canary Is.) 1 0 EC8AFM 26/05/2012 20:37 15 m.
EA-EH (Spain) 9 0 EA5AER 26/05/2012 07:54 10 m.
ER (Moldovia) 2 0 ER4X 26/05/2012 21:21 15 m.
EU, EV, EW (Belarus) 3 0 EW8DJ 26/05/2012 09:21 10 m.
F (France) 2 0 F5VHY 26/05/2012 20:56 15 m.
FM (Martinique) 3 0 FM5BH 26/05/2012 20:08 10 m.
G, GX (England) 5 0 GØUCH 26/05/2012 09:49 10 m.
GJ, GH (Jersey) 2 0 MJØCFW 26/05/2012 21:10 15 m.
HA, HG (Hungary) 2 0 HA8RH 26/05/2012 09:02 10 m.
HC-HD (Ecuador) 1 0 HD2A 26/05/2012 20:26 10 m.
HJ-HK (Colombia) 3 0 HK1NA 26/05/2012 20:00 10 m.
HO-HP (Panama) 1 0 HP1WW 26/05/2012 20:11 10 m.
I (Italy) 13 0 IT9BXR 26/05/2012 07:56 10 m.
J3 (Grenada) 1 0 J39BS 26/05/2012 20:09 10 m.
JA-JS (Japan) 3 0 JA8RWU 26/05/2012 21:07 15 m.
K,W,N, AA-AK (United States of A) 97 0 K9CT 26/05/2012 07:26 20 m.
KH2 (Guam) 1 0 NH2T 26/05/2012 21:15 15 m.
KH6 (Hawaii) 1 0 KH6LC 26/05/2012 21:22 15 m.
KL7 (Alaska) 2 0 KL7RA 26/05/2012 21:33 15 m.
KP2 (Virgin Is.) 2 0 KP2M 26/05/2012 19:51 10 m.
LA-LN (Norway) 1 0 LA4DQ 26/05/2012 22:03 20 m.
LO-LW (Argentina) 5 0 LU6EF 26/05/2012 20:18 10 m.
LY (Lithuania) 8 0 LY7A 26/05/2012 09:12 10 m.
LZ (Bulgaria) 10 0 LZ9W 26/05/2012 07:52 10 m.
OE (Austria) 1 0 OE3K 27/05/2012 20:30 15 m.
OF-OI (Finland) 2 0 OG1M 26/05/2012 09:40 10 m.
OK-OL (Czech Republic) 5 0 OL4A 26/05/2012 20:42 15 m.
OM (Slovak Republic) 3 0 OMØWR 26/05/2012 07:32 20 m.
OX (Greenland) 1 0 XP2I 27/05/2012 00:14 20 m.
OZ (Denmark) 3 0 OZ3SM 26/05/2012 23:18 20 m.
P4 (Aruba) 4 0 P49Y 26/05/2012 20:01 10 m.
PA-PI (Netherlands) 1 0 PA3CVI 26/05/2012 23:50 80 m.
PJ7 (Sint Maarten) 1 0 PJ7T 26/05/2012 19:54 10 m.
PPØ-PYØ (Fernando de Noronh) 1 0 PWØF 26/05/2012 20:19 10 m.
PP-PY (Brazil) 14 0 PW7T 26/05/2012 09:29 10 m.
PZ (Suriname) 1 0 PZ5P 27/05/2012 00:08 20 m.
S5 (Slovenia) 9 0 S58MU 26/05/2012 20:52 15 m.
SA-SM (Sweden) 1 0 SJ2W 26/05/2012 21:27 15 m.
SN-SR (Poland) 9 0 SO2R 26/05/2012 07:34 20 m.
ST (Sudan) 1 0 ST2AR 27/05/2012 18:41 15 m.
SV-SZ (Greece) 1 0 SV1BJW 27/05/2012 18:56 15 m.
TK (Corsica) 1 0 TK4A 26/05/2012 08:56 10 m.
UA2 (Kaliningrad) 1 0 UA2FL 27/05/2012 20:43 20 m.
UA-UI1,3,4,6, (European Russia) 14 0 R1DX 26/05/2012 09:40 10 m.
UA-UI8,9,Ø,RA (Asiatic Russia) 3 0 RX9AF 26/05/2012 22:01 20 m.
UR-UZ, EM-EO (Ukraine) 11 0 UR7MZ 26/05/2012 07:29 20 m.
V2 (Antigua & Barbuda) 1 0 V26EV 27/05/2012 19:01 15 m.
VE, VO, VY (Canada) 14 0 VE2OXA 26/05/2012 07:25 20 m.
XA-XI (Mexico) 1 0 XE2S 27/05/2012 18:47 15 m.
YL (Latvia) 4 0 YL2SM 26/05/2012 09:24 10 m.
YO-YR (Romania) 2 0 YO8AXP 26/05/2012 09:27 10 m.
YT-YU, YZ (Serbia) 8 0 YT9W 26/05/2012 07:44 10 m.
66 339 0
]]><![CDATA[Pan adapter for Elecraft K2]]>Fri, 20 Apr 2012 12:05:01 GMThttps://m0bpq.weebly.com/radio-blog/pan-adapter-for-elecraft-k2_ My Elecraft K2 hasn’t seen the use that it really warrants since I bought it several years ago. With field day approaching in June and the revised rules  allowing SDRs and skimmer I thought I would dust it off and try to finally get my software panadapter working.

The set up is fairly simple. A K2 with Z10000 buffer board is attached to a cross country wireless SDR which has been re crystalled for 4.9125MHz. I am using an E-MU 0202 USB soundcard with the SDR, but as my PC is quite limited, I plan to only use it to read 48KHz of spectrum. From a software point of view I would like to run N1MM as my contest logger as well as skimmer and possibly NAP3 as a panadapter. This clearly put some real pressure on COM port usage, as all of those bits of software need access to the K2’s COM port. Fortunately, N8LP has developed LP-Bridge (LPB2) that handles all of this and I am trying to integrate all of this kit together using the information on Larry’s website.

The problem I have now is that it only partially works.  Larry’s documentation suggests that one should use Kenwood mode in NAP3 to connect to LPB2 on com port 99. This is where my first problem arises; there is neither com port 99 nor a generic Kenwood setting in NAP3, even when NAP3 is opened first as Larry has suggested to others on the LP-Pan forum.

However, if I close LPB2 and choose Elecraft K2 in NAP3 with the appropriate com port (6 in my case) then I can connect to the radio and NAP3 tracks my VFOs no problem.  Similarly, in Skimmer, if I choose IF mode, then Elecraft K2 in the CAT tab, then skimmer connects to the radio and tracks the VFO. The problem here is that I still haven’t told skimmer what my IF out frequency is so I don’t know if that is the correct way to do things.

So a partial success? Clearly I need to get LPB2 working so that I can skim and contest log at the same time. The next issue is that I have a huge spike in the panadapter and skimmer waterfall. I thought the Z10000 should be taking this out? Or have I told NAP3 the wrong IF frequency?

]]>