The K3 that would “sometimes” not Transmit

There is nothing more frustrating than an intermittent fault that only presents itself at a contest or when you’re working rare DX. My Elecraft K3 has been doing just this on and off for the past three years and it’s been slowly driving me crazy.

My K3 had developed a nasty fault where it would refuse to make any RF when in transmit. You could hear the radio getting itself setup trying to transmit but no RF would appear at the output. The photo below is not my best effort it was however made very early in the morning with a mobile phone, but you should get the gist from the display;

What you see above is 0 Watts being reported, no SWR display with the TX LED lit. It certainly wont make any QSO’s like that.

So this wasn’t the first time I’d seen a fault similar to this. A year ago the LPA module failed after copping a static discharge in the antenna port from a dipole in a dry wind storm. With the help of Elecraft support this turned out to be nothing more than a small signal MOSFET that had failed on the LPA and was easily fixed. Well so I thought.

At the last OCDX contest in October 2018 the radio faulted again right at the start of the contest. So the station was quickly reconfigured and the radio removed from service. However once I returned home and turned the radio on, it powered up and transmitted as if nothing had happened. Damn this fault is now intermittent…

All that was left was to keep testing and wait for the radio to fail and catch it in the act. So after much angst I just couldn’t seem to make it fault with anything I could identify as a pattern. I’d do something and it would fault, power cycle it and it would work again; there was no consistency,. So I used every trick I’ve learnt to make radios fault, like;

  • pulling, pushing, prodding and re-seating every cable to see if there was a broken connection, more nothing.
  • pulling, cleaning and re-seating every board from the main board to dislodge oxide buildup, more nothing.
  • tighten and check all screws, long shot… more nothing
  • using a hot air-gun and freezer spray to see if something had become temperature dependant, nothing.
  • Double checking the wiring & build

So this afternoon the radio decided to fault and carry on faulting. Now was the time to get the covers off. Once done I noticed that the LED on the top of the KSYN3A would sometimes not light. Power cycle the radio and the LED would come back on, then power cycle it a few more times and it would stay off. The great part was when the LED was off the radio made no RF. Ah Ha, there is no such thing as a coincidence ! I’d finally caught this fault in the act.

The KSYN3A is responsible for generating the Local Oscillators (LO) for transmit and receive, no LO and there can be no RF. Right that’s starting to make sense.

So now I could narrow down on the fault. From everything I had observed I had a suspicion that there was a problem with the output of the KREF3 board, either not providing the KSYN3A synthesiser with a signal or one that was out of spec. It was certainly a good place to start..

However before going much further I needed to check that the cabling between these modules was right.

I should also point out that my radio also has the K144XV 2m Transverter fitted, which is just to the right in the image above. It also has a reference locking kit. Hmmm, this immediately raised yet another red flag. Reading the K144XV reference locking kit manual I found the following wiring diagram;

However this is not how I found my radio was configured. It instead had the K144XV REF_IN connected to J1 on KREF3 and J2 connected to the KSYN3A J83. Huh ?

Now looking carefully this wiring diagram I noticed it had KSYN3 not KSYN3A, so perhaps things are different if you use the new Synthesiser. Well here’s the wiring diagram;

Ah Ha ! It seems that when I installed the KSYN3A upgrade I didn’t wire the K144XV module correctly. What I had done is connect the K144XV reference to J1 on KREF3 not J1 on KSYN3A. Damn !

The worst part is this wiring mistake appeared “to work” but it had instead introduced an intermittent fault where the reference output is loaded by the K144XV to the point the signal was marginal and the KSYN3A faulted.

So I have moved the cables to the right locations now and so far over the past 4 hours the radio has not faulted. Only time will tell if I have this intermittent fault nailed. I guess going to another contest will be the acid test. Oh wait there’s one of them on right now, so it’s time to fire this radio up for the John Moyle Memorial Field Day (JMMFD) and see what happens.

GPSd and the HP un2420

At a recent radio club technical night we ran through the setup of ntpd and GPSd for time syncing laptops. This is important when running modes like FT8 and JT65 where transmissions are synchronised to the nearest second, or for satellite tracking.

Picture of HP2420 Modem

During the tech night we used a external USB GPS, however my laptop has a HP un2420 broadband modem inside that includes a built in GPS. So after the tech night I decided to see if I could get GPSd to work with this module.

In a previous post I found that you could send a string to the last of three USB serial ports that this module creates [ttyUSB0-2], that would then activate the GPS functions within the module you can read this here (click).

So to use this module we need GPSd to send a “\$GPS_START” string to the GPS before it tries to use it. It also needs to send a “\$GPS_STOP” string to the GPS when GPSd stops.

It turns out GPSd has internal mechanisms to do this via a device-hook that you can find in the man page, however there aren’t many examples of “how” to do this on the internet.

The device hook file is nothing more than a simple bash script that is called by GPSd as it starts or stops the GPSd service. It will call this bash script using two parameters, the first is the name of the device, the second is the action required i.e.”activated” or “deactivated”. So all we need is a basic script, there are probably more elegant ways to write this script than what I’ve used, but it works for me.

So using your favourite editor create the file below with the following contents;

/etc/gpsd/device-hook

#!/bin/bash
#
#device hook script to start and stop HP2420 internal GPS
#
if [ "$1" = "/dev/ttyUSB2" ] && [ "$2" = "ACTIVATE" ];
then
echo "\$GPS_START" > "/dev/ttyUSB2"
sleep 5
else
if [ "$1" = "/dev/ttyUSB2" ] && [ "$2" = "DEACTIVATE" ];
then
echo "\$GPS_STOP" > "/dev/ttyUSB2"
fi
fi

This script simply matches the USB serial device the HP un2420 creates with the word ACTIVATE and fires the magic string into the USB serial device and will return 0 to GPSd. The same happens when GPSd wishes to stop the GPS device. These internal GPS devices do not like starting then immediately stopping, it can bork the device to the point it requires the laptop to be rebooted. So to prevent this a short sleep delay has been added just after we activate the GPS. I could have equally added it after or before the STOP command, but this might not be a good idea as laptops have a tendency to hibernate and we would like the GPS to stop.

Now that we have our script we need to make sure it’s executable by GPSd. I found that if you start GPSd and don’t let it daemonise for debugging, it will tell you which user and group that it starts with, we just need to make our permissions match;

$ sudo gpsd -N -D3 -F /var/run/gpsd.sock /dev/ttyUSB2
gpsd:INFO: launching (Version 3.17)
gpsd:INFO: listening on port gpsd
gpsd:INFO: stashing device /dev/ttyUSB2 at slot 0
gpsd:INFO: running with effective group ID 20
gpsd:INFO: running with effective user ID 122

gpsd:INFO: startup at 2019-03-07T23:52:07.000Z (1552002727)

I’ve highlighted the two lines we’re looking for. We can go and match these ID numbers to the specific user and group in the /etc directory. If you press Ctrl-C then GPSd will stop. Looking at the ID’s on my laptop this was user ‘gpsd’ and group ‘dialout’, YMMV.

So now we can set the right owner and permissions for our device-hook file;

$ sudo chown root:dialout /etc/gpsd/device-hook
$ sudo chmod 750 /etc/gpsd/device-hook
$ ls
legend@HP-ProBook:/etc/gpsd$ ls -al
total 20
drwxr-xr-x   2 root root     4096 Mar  8 09:54 .
drwxr-xr-x 130 root root    12288 Mar  8 00:06 ..
-rwxr-x---   1 root dialout   280 Mar  8 09:54 device-hook

Basically owner is left as root and we’ve given read and execute permissions to group dialout. This will allow GPSd to read the file and only sudo users able to edit it.

So using the same command line as before start GPSd in a window. Now in a second window launch a client like cgps. In the GPSd window we should see something like this;

legend@HP-ProBook:$ sudo gpsd -N -D3 -F /var/run/gpsd.sock /dev/ttyUSB2
gpsd:INFO: launching (Version 3.17)
gpsd:INFO: listening on port gpsd
gpsd:INFO: stashing device /dev/ttyUSB2 at slot 0
gpsd:INFO: running with effective group ID 20
gpsd:INFO: running with effective user ID 122
gpsd:INFO: startup at 2019-03-07T23:52:07.000Z (1552002727)
gpsd:CLIENT: => client(0): {"class":"VERSION","release":"3.17","rev":"3.17","proto_major":3,"proto_minor":12}\x0d\x0a
gpsd:CLIENT: <= client(0): ?WATCH={"enable":true,"json":true};\x0a
gpsd:INFO: running /etc/gpsd/device-hook /dev/ttyUSB2 ACTIVATE
gpsd:INFO: /etc/gpsd/device-hook returned 0

gpsd:INFO: SER: opening GPS data source type 3 at '/dev/ttyUSB2'
gpsd:INFO: SER: speed 9600, 8N1
gpsd:INFO: attempting USB device enumeration.
gpsd:INFO: 8087:0020 (bus 2, device 2)
gpsd:INFO: 1d6b:0002 (bus 2, device 1)
gpsd:INFO: 05c8:0403 (bus 1, device 4)
gpsd:INFO: 03f0:251d (bus 1, device 8)
gpsd:INFO: 8087:0020 (bus 1, device 2)
gpsd:INFO: 1d6b:0002 (bus 1, device 1)
gpsd:INFO: vendor/product match with 091e:0003 not found
gpsd:INFO: SER: speed 9600, 8O1
gpsd:INFO: SER: speed 9600, 8N1
gpsd:INFO: SER: speed 9600, 8N1
gpsd:INFO: SER: speed 9600, 8N1
gpsd:INFO: gpsd_activate(2): activated GPS (fd 8)

< BIG SNIP>

^Cgpsd:WARN: received terminating signal 2.
gpsd:INFO: closing GPS=/dev/ttyUSB2 (8)
gpsd:INFO: running /etc/gpsd/device-hook /dev/ttyUSB2 DEACTIVATE
gpsd:INFO: /etc/gpsd/device-hook returned 0

gpsd:WARN: exiting.

The two lines we need to find I’ve highlighted above. Basically we want to see GPSd execute our script with a return value of 0 (success). I’ve snipped a sizeable amount of information out of the above window to make it more readable. You should also see where I’ve hit Ctrl-C which generates a warning to cgps that GPSd has shutdown, which is neat !

Ok so now we have GPSd starting and stopping the GPS device in my laptop correctly. However this is not the end of the story, laptops are able to be suspended so we need to take care of this as well. So using your favourite editor create/edit the following file;

/etc/pm/sleep.d/96_gpsd

#!/bin/bash
#
# what we want done with our GPS in the laptop
case "$1" in
hibernate)
#stop GPSd
systemctl stop gpsd.socket
systemctl stop gpsd
;;
suspend)
#stop GPSd
systemctl stop gpsd.socket
systemctl stop gpsd
;;
restart)
#restart GPSd
systemctl restart gpsd
;;
esac

Thankfully as soon as we tell GPSd to stop it calls /etc/gpsd/device-hook and DEACTIVATES the GPS module for us. Now we also need to set the permissions correctly;

legend@HP-ProBook:/etc/pm/sleep.d$ chmod 755 96_gpsd
legend@HP-ProBook:/etc/pm/sleep.d$ ls -al
total 20
drwxr-xr-x 2 root root 4096 Mar  8 11:09 .
drwxr-xr-x 3 root root 4096 Apr 27  2018 ..
-rwxr-xr-x 1 root root  273 Mar  8 11:09 96_gpsd

Testing of this script is as simple as calling it with the correct first parameter. Testing that our distros are calling this file is a little harder and may be the subject of yet another post. I’m thinking that I need to measure if there is a performance difference with the GPS running while hibernated or not, this sounds easy but will take many hours. Still pondering.

There we go, the internal GPS within the un2420 should now be available, it would be worth rebooting your machine to make sure everything is working well.

MoonSked and Ubuntu 18.04LTS

Recently I was indoctrinated into the world of 6m EME when a few club members and I decided to give it a try on something of a whim. With a bit of encouragement from Lance W7GJ we raided and cherry picked our way through a few fellow club members shacks and sheds and pieced together a “small” portable 6m EME station. You can read about the activation on our club website once it’s published (click). The picture below speaks volumes;

The moon at moon set (4am) with our 6m EME station – photo by Scott VK5TST

While looking at various Apps and trying to work out how this EME thing works, I discovered MoonSked written by David GM4JJJ.

At first glance it appeared to be a cross platform application that would help me plan and understand how this EME thing works without wasting too many late nights outside. What I liked most is I could run it on both Windows or Linux. My main computer in the shack still runs Windows (for reasons), however for laptop(s) and servers I prefer various flavours of Linux. So the installation of MoonSked on my main shack computer was straight forward, however things rapidly fell apart when I tried the same on my Laptop that runs Ubuntu 18.04LTS. I downloaded the zip file, placed it in my home directory and then tried to run it, sigh it didn’t work.

After a quick check of the website I noticed the last version of Ubuntu that MoonSked was built to run on was 9.10 (karmic koala) which went end of life years ago (2013). Being a binary distribution means recompiling and linking this against 64-bit libraries was not an option, sigh; we had to do this the old fashioned hard way.

So having grown up using Linux for more years than I’d care to admit I had a fair idea that this would be the classic “shared library dependency problem”. I wasn’t to be disappointed and even learnt a little about how the new linux multiarch (well new to me) system worked.

So the crux of the problem was MoonSked was compiled against 32-bit binary libraries and my Ubuntu 18.04LTS distro is entirely 64-bit. It is little wonder that MoonSked couldn’t run. So the place to start with any dependency problem is the infamous ‘ldd utility’. Let’s poke inside MoonSked and see what libraries are under the hood;

legend@HP-ShackBook:~/MoonSked$ ldd MoonSked
linux-gate.so.1 (0xf7f48000)
libgtk-x11-2.0.so.0 => not found
libgdk-x11-2.0.so.0 => not found
libgmodule-2.0.so.0 => not found
libglib-2.0.so.0 => not found
libgthread-2.0.so.0 => not found
libgobject-2.0.so.0 => not found
libgdk_pixbuf-2.0.so.0 => not found
libpango-1.0.so.0 => not found
libpangocairo-1.0.so.0 => not found
libpangoft2-1.0.so.0 => not found

libpthread.so.0 => /lib32/libpthread.so.0 (0xf7f07000)
libdl.so.2 => /lib32/libdl.so.2 (0xf7f02000)
libXi.so.6 => not found
libXext.so.6 => not found
libX11.so.6 => not found

libstdc++.so.6 => /usr/lib32/libstdc++.so.6 (0xf7d7c000)
libm.so.6 => /lib32/libm.so.6 (0xf7cb1000)
libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0xf7c93000)
libc.so.6 => /lib32/libc.so.6 (0xf7aba000)
/lib/ld-linux.so.2 (0xf7f4a000)
libcairo.so.2 => not found

Ok so there are a few libraries missing and thankfully I can see some of the lib32 libraries are being found. What is not immediately apparent is that 32-bit libraries can be installed separately and sit alongside the very same 64-bit libraries. The multiarch features of the latest linux kernel and GNU tools is what confuses MoonSked trying to find it’s libraries. So to get MoonSked we need to solve the shared library dependencies separately. So watch the following carefully.

We start by double checking that we are in fact running a full 64-bit system;

legend@HP-ShackBook:~/MoonSked$ uname -m
x86_64
legend@HP-ShackBook:~/MoonSked$ dpkg --print-architecture
amd64

Excellent the kernel is 64-bit and we are using the 64-bit package repository that should be linked against 64-bit libraries. Now we check the following;

expert@HP-ShackBook:~/MoonSked$ dpkg --print-foreign-architectures
i386

Ah Ha ! This is excellent as it means that we can install the 32-bit libraries with the dpkg/apt tools without having to configure dpkg. If you find that i386 isn’t defined as a foreign architecture you’ll need to use dpkg to enable it. There are plenty of websites on the net that can assist here (YMMV), Ubuntu 18.04LTS comes pre-configured for 32-bit and 64-bit multiarch out of the box.

So now we can simply use apt-get to install the dependencies. I simply use a process of elimination to work out what is missing. First I’d use apt-cache and the name of the shared lib to search for library names or resort to the internet, then I’d use apt-get to install it and then re-run ldd again to see the result. The following line works well when the output from ‘ldd’ gets more than a page or two;

$ ldd MoonSked | grep "not found"

This will basically print out any library dependency that was not found to the display. Slowly but surely you work your way through to the end of your list, making notes as you go for your blog (*grin*). Rather than document all of the above steps I’ll just give you the short list;

sudo apt-get install libc6:i386 libpango-1.0:i386 libcairo2:i386 libpangocairo-1.0:i386 libgtk2.0-0:i386 libcanberra-gtk-module:i386 libatk-adaptor:i386 gtk2-engines-murrine:i386 libdlm3:i386

Now the observant will notice at the end of each package is a colon and i386. This tells apt/dpkg to install the 32-bit library and not the default 64-bit package. Depending on what apps you have on your linux machine already some of these packages may already be installed and up to date. If you do find this is the case then simply drop the name off the list above and keep trying.

As I wrote at the very beginning of this post, these are the steps that worked for me on my Ubuntu 18.04LTS installation. I’m hoping that the process used to seek and destroy the missing dependencies makes sense it’s certainly not the only way to do it, works for me YMMV.

At least now I can fire up MoonSked on Ubuntu 18.04LTS and continue my 6m EME experiments. Thanks again to David GM4JJJ for writing MoonSked !

Mikrotik OpenVPN Configuration

There is heaps of information about configuring a Mikrotik Router as an OpenVPN server on the net.  The following simply documents what I found when I tried to follow in their footsteps.

The first reference I found was Medo’s instructions on how to configure the VPN, I used this to create the certificates, configure the server and get close to a working solution.

However my configuration was a little different in that the remote device I was connecting too (RB411 over 3G) did not have a FQDN only a fixed IP.  So for the ca-template and server-template I used the Fixed IP (xx.xx.xx.xx) for the common name, for the client-template I used the name of the router (RouterName).

/certificate
add name=ca-template common-name=xx.xx.xx.xx days-valid=3650 key-size=4096 key-usage=crl-sign,key-cert-sign
add name=server-template common-name=xx.xx.xx.xx days-valid=3650 key-size=4096 key-usage=digital-signature,key-encipherment,tls-server
add name=client-template common-name=RouterName days-valid=3650 key-size=4096 key-usage=tls-client

I’ve changed both the IP and RouterName to protect the innocent, I’m sure any readers will figure out where to insert their own configuration.

I also found that if you did not change the common name of the client-template certificate then the signing process of Medo’s post would fail with a weird error message.

/certificate
sign ca-template name=ca-certificate
sign server-template name=server-certificate ca=ca-certificate
sign client-template name=client-certificate ca=ca-certificate

Now getting the certs off the remote router was also “interesting”.  This wasn’t something that I’d really done before.   So after a bit of googling and some trial and error I ended up using the pscp utility that is part of the PuTTY package.  You can find the relevant certificates using the /file command.

C:\Program Files (x86)\PuTTY>pscp -r -P 22 user@xx.xx.xx.xx:/* \temp
user@xx.xx.xx.xx's password:
ca-certificate.crt        | 1 kB | 1.8 kB/s | ETA: 00:00:00 | 100%
server-certificate.crt    | 1 kB |   1.8 kB/s | ETA: 00:00:00 | 100%
client-certificate.key    | 4 kB |   1.8 kB/s | ETA: 00:00:00 | 100%

Once I had the certs on my local machine I could continue to follow Medo’s blog.

Now I didn’t want the VPN users to end up in a different IP address space, so I changed my VPN DHCP pool range to be just under the usual Ethernet pool and then set the VPN local address to be the next address under the VPN pool.  Here’s a quick overview;

VPN local_address:  xx.xx.xx.64
VPN dhcp_pool:      xx.xx.xx.65-xx.xx.xx.75
ethernet dhcp_pool: xx.xx.xx.100-xx.xx.xx.200

So I ended up modifying the following commands;

/ip pool
add name="vpn-pool" ranges=xx.xx.xx.65-xx.xx.xx.75

/ppp
profile add name="vpn-profile" use-encryption=yes local-address=xx.xx.xx.64 dns-server=xx.xx.xx.64 remote-address=vpn-pool
secret add name=user profile=vpn-profile password=p4ssw0rd

/interface ovpn-server server
set default-profile=vpn-profile certificate=server-certificate require-client-certificate=yes auth=sha1 cipher=aes256 enabled=yes

Now before anyone says anything you need to change the name and password to suit your own VPN user, at the very least make sure you use a good password.  You’ll notice I dropped the AES-128 and AES-192 ciphers in preference to the 256bit option.   More on this later.

This is where I ran into trouble that took me a while to resolve.

I had installed OpenVPN GUI 2.4.5 which simply refused to connect, it throws TLS errors that are odd.  It turns out that as of OpenVPN 2.3.11 there was a change made that makes it incompatible with older Mikrotik routers, you can read all about it here and there is more information here.

This post also talks about being able to use the tls-cipher parameter to force the client to relax it’s checking of certificates, however I wasn’t able to make this work.  It appears that the latest version of RouterOS have fixed this issue, but that has to wait until I’m next at the console of this particular router to upgrade it.

So after uninstalling the latest OpenVPN 2.4.5 GUI and installing an older version OpenVPN 2.3.10, I was able to connect to my RB411 with v3.2.2 firmware with the following config;

client
dev tun
proto tcp-client
remote xx.xx.xx.xx 1194
resolv-retry infinite
nobind
persist-key
persist-tun
cipher AES-256-CBC
verb 3
remote-cert-tls server
auth SHA1
auth-user-pass
redirect-gateway def1
ca "C:\\Program Files\\OpenVPN\\config\\ca-server.crt"
cert "C:\\Program Files\\OpenVPN\\config\\server.crt"
key "C:\\Program Files\\OpenVPN\\config\\client.key"

As you may notice I use Windows for my main machine, so Mac and Linux users will have to do a little more googling on how to specify the paths in this file.   Now the cipher matches the tweak I made to the ovpn-server within the mikrotik router limiting the choice to AES-256 bit.

The proof is in the pudding, after copying all of the certs and config into the approriate directory I could get the VPN client to connect to my remote Mikrotik RB411 router over the VPN.  Many thanks to Medo for blogging his adventures with RouterOS and I hope the suggestions I’ve made above are useful to some.

APRS iGate – Part 3 AX25 Config

Now that the Raspberry Pi is configured we can get back to the radio part again, so lets start with configuring the TNC.

Configure AX25 axports file

Before we can start any ax25 configuration we need to define the call signs and ports in the axports file;

$ sudo nano /etc/ax25/axports

edit the last line to look like this;

# /etc/ax25/axports
#
# The format of this file is:
# name callsign speed paclen window description
#
1 VK5ZM-5 19200 236 2 145.175MHz (1200 bps)

Don’t worry about all the speed, paclen and window values just yet, copy what you see below.  These values are as described in the TNC-Pi user manual.

Configure Kissattach

Now before the ax25 tools can use a TNC it has to be attached to the kernel.  We’ll do this using a utility called kissattach.  This utility will create the necessary ax0 networking interface, we’ll assume our TNC will use the Serial Port ttyAMA0.  Lets test that kissattach will start;

$ sudo kissattach /dev/ttyAMA0 1 10.1.1.1

One note make sure that the IP address passed to the ax0 port is not part of your LAN, it needs to be different !  If you want to be old school you can always throw this into the 44.xx.xx.xx IP address range that was reserved for Amateur use, you can find more details here.

If you dont see any error messages type the following command;

$ ifconfig

look for the following lines;

 ax0: flags=67<UP,BROADCAST,RUNNING> mtu 236
 inet 10.1.1.1 netmask 255.0.0.0 broadcast 10.255.255.255
 ax25 VK5ZM-5 txqueuelen 10 (AMPR AX.25)
 RX packets 0 bytes 0 (0.0 B)
 RX errors 0 dropped 0 overruns 0 frame 0
 TX packets 0 bytes 0 (0.0 B)
 TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

All going well we now have a working ax25 interfaces and most of the TNC configured.

Now we need to make sure kissattach is started after a reboot, so open the following file;

 $ sudo nano /etc/rc.local

We need to add the following lines somewhere near the bottom, I found that the maintainers of raspbian-stretch print the IP address to the console when the machine boots, so I added the following after this;

# starting ax0 interface using kissattach
if [ -x /usr/sbin/kissattach ]; then
  echo "Starting Kissattach: Binding port ax0"
  /usr/sbin/kissattach /dev/ttyAMA0 1 10.1.1.1
fi

You can test this by rebooting and then checking if the service was restarted, but we’ll need to edit this file again before the end of this post so hang tight for a minute !

AXListen

One of the more tricky aspects of configuring ax25 on linux is we must deal with is non-root access to the ax0 interface that we’ve just created.  On any Linux system you normally must have be root or use sudo to access any network interface.

So what we do is the same trick that admins do with the command ping and set the SUID permission bit on the axlisten file.  By setting this permission bit it will allow non-root users to execute this command as if they were root, without being granted any further root privileges.

$ sudo chmod 4755 /usr/bin/axlisten

now we can test it;

$ls -al /usr/biin/ax*
-rwxr-xr-x 1 root root 50836 Sep 20 2015 axcall
-rwxr-xr-x 1 root root 17516 Sep 15 2015 axgetput
-rwsr-xr-x 1 root root 43064 Sep 20 2015 axlisten

Depending on your shell you may find that the text “axlisten” is coloured with a red background.  If you look carefully at the user permission bits (highlighted above in bold) you should see that instead of an X for execute it has changed to an S for SUID.

Unless you have your TNC connected to a radio and channel traffic there is not much point in testing just yet, however if you do simply run;

$ axlisten -c

It can take time but you should see packets being decoded, the yellow LED on the tncpi will also light when a packet is decoded.

One thing I’ve noted (a of Feb 2018) is that axlisten has not been compiled with ncurses support in the latest Raspbian-stretch packages which means there is no colour support.  You will occasionally see “Could not initialize color support” (sic), wihch is annoying since raspbian-jessie works perfectly.  Hopefully the maintainers will fix this oversight at some point.  We can always compile ax25-tools from scratch, Charles K4GBB has an excellent tutorial and script here for those wishing to try this themselves.

Configure Mheard

The mheard daemon monitors the AX25 channels and records call signs that it hears along with some basic stats.   This can be handy for debugging RF issues and just generally gauging how well your node is working.  It’s much the same as the mheard function found in many packet TNC’s in the day.

To get mheard running we simply edit the rc.local file again;

$ sudo nano /etc/rc.local

Then add the following lines at the bottom of the file after where we start kissattach (see above);

# starting mheard daemon
if [ -x /usr/sbin/mheardd ]; then
  echo "Starting Mheard Daemon"
  /usr/sbin/mheardd
fi

Now is probably a good time to test that we will survive a reboot;

$ sudo reboot

Once the Pi has restarted use the following commands to see what happened;

$ ps -aux | grep mheard
root 2049 0.0 0.0 1908 120 ? S Feb17 0:00 mheardd
$ ps -aux | grep kiss
root 413 0.0 0.0 1908 108 ? S Feb17 0:00 /usr/sbin/kissattach /dev/ttyAMA0 1 10.1.1.1

The mheard command needs to monitor the AX25 channels for a little while before it starts recording information, here’s an example of it working.

$ mheard
Callsign Port Packets Last Heard
VK5ZM-7 1 11 Sun Feb 18 09:52:04

If the output remains blank then using axlisten make sure you’re hearing traffic and that the receive LED (yellow) is being illuminated as traffic is heard.   This needs to be working before mheard will start to do something.

Now we can get onto alignment of the radio and some further testing in the next instalment.

APRS iGate – Part 2 Pi Config

Bringing up a Raspberry Pi (rPi) is not difficult for anyone with some basic linux admin skills.  If you haven’t looked at the hardware I’m using you can read this back here in part 1.  The instructions below are the basics of what I’ve done for my rPi, yours will likely be different YMMV.

Prepare Raspbian

I downloaded the latest “lite” version of Raspbian from here at the time of writing that was Raspbian Stretch.  For an iGate you don’t really need all the graphics and bling, the command line is easy to use.

Once downloaded I extracted and wrote the image to an 8Gb SDCard using win32diskimager.   From there the card went in to the Pi and then let it boot with a screen and keyboard attached.   Watch carefully and make sure that the OS expands the image to fill your entire SDCard.

I’d suggest plugging the Pi into your network using the Ethernet adaptor to start with, this is somewhat easier to deal with than setting up the WiFi.

Update, Upgrade and Configure

Once the Pi has booted log in using the default pi user name and password, you can find this on the rPi website.  Once you’re logged in run the following commands;

#sudo apt-get update
#sudo apt-get update

Answer yes to any questions regarding increased disk usage.   This will bring your Pi up to date with all of the latest changes.  Now we’re ready to configure the Pi hardware, execute the following command;

#sudo raspi-config

This will bring up a ncurses menu in which you can configure your Pi.  I’d suggest the following changes are made;

  • Configure your WiFi in the network options menu
  • Configure your localisation options (locale, timezone and keyboard layout)
  • Configure the Interfaces
    • Enable SSH
    • Enable i2c
    • Enable Serial

Once you have finished then exit the raspi-config tool and reboot your Pi

Change the Default User

Personally I don’t use the Pi user account and prefer to create my own user.   I usually run the following commands;

#sudo adduser myuser

Where myuser is your preferred user name.  Follow the questions and when faced with the password don’t be tempted to make it an easy one, especially if you intend to allow external ssh.   If you fear loosing the password then look at Lastpass, there are others but I like Lastpass.

Now still using the pi user open the following file;

#sudo nano /etc/group

Working your way down the file every time you see a line that contains pi add your new users name.  This will then grant your new user the same privileges as the default pi user.  It’s really important you update this one;

sudo:x:27:pi,myuser

Again change “myuser” to your preferred user name and before anyone tries to hack my systems this isn’t the user name I use either (Duh!).   Once you’ve worked your way to the end of this file then save your changes, again google will help you here.

It’s time to test your new account, make sure that you can login and execute sudo commands before you go any further.

Open the following file in your favourite editor;

#sudo nano /etc/shadow

Did I mention I like nano ?  Now look for the line starting with pi, it will be long compared to the others in this file, between the first and second colon replace the text with an asterisk.  Pay careful attention while deleting that you don’t go too far !   It should end up looking something like this;

pi:*:17499:0:99999:7:::

The text between the first and second colon is a hash of the user password, replacing it with the asterisk disables this user from logging in from the console or ssh without deleting the user.  It means you can use the command;

#sudo su pi

to switch to the pi user should you ever need to in the future.

 

Firewall

Personally I don’t like running my Pi’s without some form of firewall.   Right now the firewall is not configured this will be done after the AX25 tools have been installed.  It is up to the reader if they decide to enable the firewall before allowing remote logins to the Pi.

WiFi & Bluetooth

The rPi-3 comes with WiFi and Bluetooth enabled.  I was pleasantly surprised to see both interfaces in the boot up sequence appear and be configured.   The Bluetooth interface does not present any security risks and it should be safe to leave this enabled.

I prefer to connect my rPi’s to Ethernet interfaces in preference to using WiFi.  I’d also like at some point to work out how to get the rPi to perhaps be a WiFi access point, meaning I can log into the machine locally.  That will certainly be a blog entry at some point in the future.  For the time being I’ve simply left the interface un-configured.  Both the Bluetooth and WiFi can be disabled by adding the lines shown to config.txt file in the boot directory;

#sudo nano /etc/config.txt

>> Add these lines to the bottom of config.txt <<
dtoverlay=pi3-disable-bt
dtoverlay=pi3-disable-wifi

Finished ?

Anyway the basic installation and configuration of the Pi is now complete.  Next we can concentrate on configuring the AX25 and iGate software, which I’ll continue in Part 3.

APRS iGate – Part 1 Hardware

In late 2012 I built my first receive only APRS iGate from a Raspberry Pi (rPi) and a Argent Data Tracker T2-301.   This has faithfully sat in a corner of my garage forwarding APRS packets to the internet all this time.  Drawing just shy of 1 watt in power, it doesn’t add any significant costs the household power bill.   I’ve been surprised just how reliable this setup has been and from time to time I even remember to login and check for security updates.

Since I built that first machine there’s been some nice developments in the world of rPi’s and AX25, so I thought I’d share the details of my latest APRS iGate project.

While searching for rPi power supplies I came across the BitScope Blade Uno which can power and hold a Model-B rPi and a HAT.   I was pondering one of these when it hit me that if you take this board, add a rPi and a Coastal ChipWorks TNCPi then I’d have a rather nice hardware platform on which to build a new APRS iGate  Even better is I can stuff it in a small 19″ rack mount case instead of sitting it on a shelf in the garage !.

So I just had to order the bits and wait the for the shipping.  Below is the hardware assembled, total cost just shy of A$150

I ordered the TNCPi as a kit and soldered it together in an hour or so, John W2FS’s kit is easy to build and the instructions are great.   I’ve also decided to use a Raspberry Pi 3 which includes on-board WiFi and Bluetooth.   With the hardware assembled then all we’ve got to do is configure it, which I’ll continue in Part 2.

Stackmatch Initial Tests

Well the Stackmatch PCB’s finally came back from the Manufacturer along with the components from Mouser, so it was time to build.  I’m pleased with the 3D model and the actual final assembly, they are pretty close !

This slideshow requires JavaScript.

I’ve not mounted the LED’s on the left hand side yet, this will wait until I can drill the front panel of the diecast enclosure and begin final assembly.  Since I’ve got more than one of these to make I’m getting a template made from steel that I can mount on the front panel and then drill all the holes.

The assembly in the picture above is the first prototype and I wasn’t going to wait for the front panel and die-cast box to be ready before testing.  The connectors have been attached at roughly the right height using an additional nut as a spacer, I’ve only fitted half the standoffs to save some time.

So the question is does it work?

The first test is simply a test of the isolation between ports.  So taking a spectrum analyser with tracking generator the idea is to measure the insertion loss between the input and one output as we switch between all three outputs one at a time and record the results.  All outputs are terminated in a 50 ohm load.  What is interesting with this stackmatch is we can also select “no outputs” where no relays are energised, this has a surprising result on the measured isolation;

This slideshow requires JavaScript.

OK, so what can we deduce from these series of plots.  The Spectrum analyser (SA) tracking generator was on the Stackmatch input, the SA input was on Output #1 unless you missed it.   As we switch each output from #1 to #3 we can see the insertion loss change.  As you would expect when we select output #1 we measure the insertion or through loss of the stackmatch, when we select any output other than #1 we measure the Isolation between ports.

Here’s the all important worst case summary, which is of course at the high end of the HF band i.e 10m;

  • Insertion Loss < -0.2dB
  • Isolation > 37dB

That is not too bad for a single device covering from 160m to 10m.  In real terms it means when we are transmitting 400W PEP (+56dBm) on 10m that less than 80mW (+19dBm) will be leaking out the other two ports.  The same can be said for helping prevent overload in the receiver from adjacent contest stations (i.e. on 20m).  The AREG typically use Elecraft K3’s and high end Icom transceivers so these typically don’t give too hoots about QRO contest stations on adjacent bands in the first place.     The best part is as we go lower in frequency the Isolation increases a further 10dB which can only improve the situation.

The insertion loss is barely measurable, so nothing should be getting really hot or require further bypassing.

Now what was also interesting is the difference in output isolation with no outputs being selected and just one.   The isolation to an unused port increased by +5dB to +6dB when the input was terminated into just one antenna.  That is something that we’ll need to take care of with our control system, not selecting any output is bad.

So then it was a question of moving the Spectrum Analyser input to Port #2, terminating Port #1 and repeating the above measurements again.  We do the same again for Port #3, shuffling the dummy loads and measuring once more.  I’ll not bother putting up all of these plots, suffice to say all of the isolation between ports were within 0.5dB of each other and insertion loss didn’t move.

Now for the main event, parallel combinations.

To do this we use a Return Loss (RL) measurement, so I’ve placed the RL bridge on the input to the Stackmatch and then terminated every output in a good quality dummy load, this is important !.  Then by switching the outputs in succession I can generate the various parallel combinations (25 ohms and 16.7 ohms) and then switch the transformer into to see the effect.  In all cases a 30pF Silver Mica cap has been tacked across the output of the auto transformer as per our previous experiment (click).  Here’s the measured plots;

This slideshow requires JavaScript.

So from our first plot where only one output is selected our return loss looks excellent with the minor exception of a spike at 8MHz.   I’m not sure that this is real just yet and will be doing some further work on what that resonance could be.  It’s got to be a parasitic capacitance there somewhere, will track that down later.   You might notice that the RL is better than -20dB (1.2:1) anyway, so a moot point really.

When we place output #1 and #2 in parallel we get 25 ohms and the RL rises to -10dB as you’d expect.  Then when we kick in the transformer we see an immediate improvement of RL to better than -18dB (1.3:1) at worst case (10m).

Now when we place all three outputs in parallel our RL is destroyed -6dB, but again if we kick in the transformer we see an improvement in RL of -13.5dB (1.6:1).  If you get your calculator out you find the ratios are smack bang on our design of 2.25:1.    So to summarise;

  • Return Loss (1-output) < -20dB
  • Return Loss (2-output) < -18dB
  • Return Loss (3-output) < -13dB

Yaay it works !

So there we have it, the beginnings of a workable stackmatch design.  As with any new design there is still plenty to be tweaked and played with.  In the coming weeks I’ll be;

  • investigating the effect of the cap across the output
  • chasing down that odd parasitic resonance at 8MHz with one antenna selected
  • measuring the temperature rise of the transformer with 120W of CW being blasted into it, or 300W of RTTY to give it some real curry…
  • Making the final enclosures and seeing what effect (if any) this has on the design
  • Trying #16, #20 & #24 gauge PTFE wire on the same core to see if the performance or characteristics of the transformer changes
  • Seeing what effect the +/- J term from various antennas has on the combined feed point impedance that our radio will see (thanks to David VK5DGR for bringing that one up !)

Yes it’s going to be a busy few months as we explore what this new toy can do.

Stackmatch Binocular Matching Transformer

Many stackmatch designs use a toroid core, but I’ve decided to  instead investigate using a multi-aperture “binocular” core.

There are not many manufacturers of large-ish binocular cores that can take the full VK HF limit of 400W PEP, let alone a full kilowasp amplifier !

So to start with I’ve chosen two well known binocular cores that you can obtain from various online suppliers;

  • Amidon BN-61-002
  • Fair Rite 2861010002

Both are the equivalent of each other in terms of price, size and material.  Both are made from Type 61 NiZn Ferrite material with a ui of approximately 125.   This material has good low loss properties and is essentially what others have used for their toroid designs.  It seems like a good place to start.

The transformer is wound the same way as if on a toroid, so take three wires, twist them together (battery drill helps) and wind the desired number of turns through the holes.   It seems sensible to start with a full core and take turns off if I achieved too much inductance.  Both of these cores hold ~4 turns of trifiliar wound 20AWG silver plated PTFE wire, it might add the last turn is hard to do.  All that is left is to series up the windings and tap at the appropriate positions, the schematic is to the right.

To make my measurements I decided to use a variable resistor (R1) to check the effect of load change on the transformer.  I had also seen some designs using a small amount of shunt C across the output to neutralise the output leakage inductance as well, so I placed a variable cap across the variable resistor when needed.

To make these measurements I’m fortunate to have a Spectrum Analyser with tracking generator and a suitable Return Loss Bridge.  The return loss bridge has a directivity of > 45dB at HF.  This means I can see how much energy is being transferred to the load resistor (R1), any RF energy that is being reflected back to the spectrum analyser is therefore wasted, so in all of the screen captures below the lower the Return Loss the better !

You can see the experimental setup in the image below and my initial measurement on the kitchen table…

I’d start these measurements by adjusting R1 until I achieved the lowest Return Loss and then remove the resistor temporarily and measure it separately with a 4-digit ohmmeter.  I wanted to check that I was close to 22.2 ohms in all cases.   With such a low resistance don’t forget to deduct the resistance of the multimeter leads.

Once I had confirmed the impedance transformation was correct I would then tack the trimmer cap across R1 and start with it completely un-meshed (min C).   The cap on the secondary side of our transformer will assist in “tuning” out the output reactance (Xs) of the transformer a little and improving the return loss at the upper end of our plot.

However there is a null that will occur at the low end of VHF that you need to be wary of as it can be unstable, you can if you have enough capacitance bring it into HF spectrum which is not advisable.   You will easily see the point where I’ve added too much in the sequence below.   What you’re looking for is just enough turns to give you the broadest match possible with the smallest value of C across it’s output.

Here’s a sequence of plots showning what happens as you increase C from min (5p) to too much (120p).  This was with 3 turns wound through the core, R1 approx 22.3 ohms;

This slideshow requires JavaScript.

So in the above sequence you can see what the effect that the capacitance has across the output.  As we keep adding capacitance the return loss kept getting better and better before the null appears.  The ideal compromise was somewhere between 65p-80p.

What you can also do is widen out the frequency from 1-200MHz and watch what effect any nulls will have on the response.  It also pays to vary the load (R1) and see what happens as the load decreases below and above the desired match.   I found that as the output impedance goes up the null has a much more prominent effect as the load is varied.

So starting at 4 turns I checked the impedance ratio and then wen’t looking for the best compromise in terms of response, stability and lowest capacitance.   Below are the three best candidates that I found;

This slideshow requires JavaScript.

So as we reduce the turns (inductance!) we see the return loss decrease at the low end, but we also see the required capacitance to flatten out the upper end also reduce.   Based on these measurements the best compromise I found for this transformer is 2T C=30p.   Ideally a return loss less than -20dB is a good target to aim for, I’ll let the reader work out what the equivalent VSWR is for this RL value (hint: it’s low, for additional points also take a look at a RL of -10dB for reference !).

Now to check that this is stable I’ve included a plot that is much wider in terms of checking the VHF region for signs of that null we wish to avoid.  Hmm, this combination is potentially usable up to 6m, now there’s an idea for another day.

Sweet no signs of the null being anywhere close to the MF/HF bands I want to operate over.

Now the ultimate test is to make two of these transformers, place them back to back into a 50 ohm load then measure the insertion loss. That will give me some idea on what sort of loss this transformer will have an ultimate how hot it will get when I attempt to pass 120W CW/FM or 400W pep of SSB.

More to come.

Yet Another Stackmatch Design

In October each year I join my local radio club AREG and participate in the Oceania DX (OCDX) contest.   For the past few years I’ve been the band captain for the 15m/10m station.  We started in 2014 with just an Icom IC-706mk2 and 2 element broadband Hexbeam, but this quickly morphed into a complete Elecraft K-line, Amplifier, SDR’s, filters and Spiderbeam on a 8m pump up mast; as a portable station.

This slideshow requires JavaScript.

So to take our station yet another step forward we need to add additional antennas like mono-band verticals to take advantage of lower propagation angles. Here in VK we are along way from anywhere, so the majority of our propagation on most bands is below 20 degrees.   However before you can take advantage of these additional antennas you need to switch between them.

Trolling the internet for inspiration we discovered the 3 to 1 Broadband Stackmatch.  This is a simple 3 port antenna switch that can individually switch each antenna to the radio, but it can also be used to parallel up any two or all three antennas ports together.

It exploits the fact that two 50+j0 ohm antennas in parallel is 25+j0 ohms and three in parallel just shy of 16.7+j0 ohms.  So by inserting a transformer with a fixed impedance matching ratio we can bring the parallel antennas effective impedance back up close enough for many amplifiers/transceivers not to care about the minor mismatch.   So that is deviously clever and simple.

The equivalent circuit of a stackmatch transformer is shown to the right, you’ll see it drawn many different ways but I find it easier to understand when drawn as an autotransformer.

Accordingly the maths says;

n = Np / Ns
Z’ = (n)^2 x Zload

So lets see what happens;

Np = 3, Ns = 2, n = 3/2 = 1.5

So with two antennas in parallel;

Z’ = (1.5)^2 x 25 = ~65.3 ohms

With three antennas in parallel;

Z’ = (1.5)^2 x 16.7 = ~37.6 ohms

This small impedance mismatch (~14 ohms) either side of 50 ohms will not cause many radios much difficultly. It does however tell us that we must ensure that our antennas are resonant (50+j0) since we have ignored the imaginary impedance for simplicity.  What is also not explained is you need to keep the feedlines to each antenna from the stackmatch as close to the same length as you can or there be more trouble with impedance transformations.

There are plenty of designs on the internet and products available from suppliers but their cost are quite simply prohibitive, especially if you want 6 or more of these units to achieve your desired switching arrangement (*gasp*) at a contest.

So here starts yet another project to design and build my own low cost 3 to 1 Stackmatch.   It certainly has not taken long to come up with a workable 3D model.  It kind of helps that I design products like this every day as an Design Engineer.  I’ve also learnt a trick or two about lowering cost in my time.

However in talking about this project over a coffee with an old work colleague/Boss he reminded me about the perils of using Toroid cores for broadband transformers.  He suggested I should instead use a multi-aperture “binocular” core or “pig nose” core as I seen them listed on eBay (LOL).  These binocular cores also have the added advantage of being smaller than a FT240-61 toroid core that everyone seems fond of.  You can see the grey block in the picture below that represents this core, it’s tiny compared to the equivalent toroid.

So that begs the question, just how good are they ?   Well there is nothing like buying a core and winding one to find out (click).