Online Amateur Radio Community Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Automated SOTA Packet Node - This is unfinished! ======

===== Introduction =====

Lots of folk run packet radio nodes on a Raspberry Pi, but not many use them as portable/deployable packet radio devices. A friend and I have experimented with this, making relays from hill to hill so that I could connect to stations I couldn't usually reach, with computers connected to a pair of  [[https://www.rigpix.com/protrx/tait_tm8110.htm|Tait 8110]] ex-business radios. This was made possible using a couple of  [[https://tarpn.net/t/nino-tnc/n9600a/n9600a_info.html|NinoTNCs]] that we'd built recently and we tested links up to the blistering speed of 4800 baud on VHF - tidy.

Since my friend I are both very big fans of [[https://www.sota.org.uk/Summits On The Air]] I had the idea at that point of making a deployable SOTA node where folk could connect to with one hop (simplex-only contacts for SOTA, so no hopping) and I could exchange details and log contacts. The question of whether packet QSOs were counted as QSOs was answered by Andy MM0FMF, all-round SOTA hero, and he also included a little tidbit that made my ears prick up: since packet is error correcting simply receiving a message could be akin to a signal report. Readability if it decodes? 5. Signal? You can infer it was good enough. Time of WSO? In the packet node's logs. Callsign? Also in the logs.

This made me wonder: if I include the summit reference in the text that users see on connect could you deploy an automatic node to hoover up packet QSOs while you work voice on another frequency. I'm yet to hash out whether this is kosher with the guys on the [[https://reflector.sota.org.uk/|SOTA reflector]]  but I'm proceeding anyway with the project. If I DID have to chat manually with chasers I'd need to connect to the node myself, however, so connectivity needs considering also.

There's a lot of info out there all over the place on doing stuff like this. While I hate reinventing the wheel writing things out is something I enjoy, so I'll put my own spin on it by documenting the process I followed to build a basic packet node on an RPi, power it, and then customise it so that it was deployable inside and out in the field, along with some SOTA mods in the node config so that people see the right thing when they connect.

===== First step: prepare your Pi =====

I used a bog-standard RPi Zero W (the first one) for this with Raspbian Lite 32 bit. For doing packet radio you need a TNC (Terminal Node Controller). I'm using a hardware TNC, the NinoTNC as noted above. I have no idea how well Direwolf or other sound modems run on an RPi, so you may need a beefier one than a Zero. We'll talk about TNCs later.

For power you can use the mains for setup, but I just went straight to a good quality USB power bank with a decent 5V output that I'd be using in the field. The NinoTNC will of course need power from this too, so make sure it's a good battery. If you're knowledgeable in the area then you could also include a UPS, Solar, batteries at this point. Beyond the scope of my post, I'm afraid.

===== Second step: install the node software =====

Dead easy, this bit: install LinBPQ using the excellent repo from Tom M0LTE: https://github.com/M0LTE/linbpq/

This repo allows for full compilation of the software from source as well as setting you up with a default config to play with. I replaced some lines in his instructions to download my own [[https://gist.githubusercontent.com/mpentler/a1fc50d943d9213027f85b348bac5dcf/raw/c268fb2d7290c755c2af7832064cfec8b7703fbe/bpq32.cfg|already-created config]] from a GitHub gist, made it all into a bash script to one-shot run it, and it all ran successfully. You'll have to edit a config yourself, and there some excellent examples out there. I'll assume most folk are doing this for VHF, but you could do HF if you want.

At this step is where you'll also need to configure LinBPQ to use your TNC of choice. This is very easy for KISS hardware TNCs like the NinoTNC, slightly less easy for software TNCs. There's plenty on the internet about that.

The rest of the config is relating to the node's setup, which may be beyond the scope of this post.

===== Third step: connectivity =====

So surely all I needed to do was make the Pi announce as a wireless AP and connect to it, and then I can ssh in from my phone! Brilliant! Then I can connect to the node. Even if automatic operation was okay it'd be nice to monitor the node connections live anyway.

I still want to connect it to the home wireless for updating and maintenance, however, and I didn't want to have to switch manually in case I mucked it up and couldn't get back into the Pi without a display and keyboard handy. I found an app to do this called  [[https://davesteele.github.io/comitup/|ComItUp]] - and it worked a treat. The only issue is that the Pi couldn't see the internet. With no backup clock available that means all the times would be out in the logs. And then someone told me I was being silly: simply connect the Pi to the phone's hotspot and you have an internet route. Find the IP the phone gave the Pi and then you can shell in. This is much simpler to set up too.

Grab your phone's personal hotspot SSID and password. Then SSH into your node and add the details for your device at the end of the /etc/wpa_supplicant/wpa_supplicant.conf file. WPK-PSK is probably correct for key_mgmt but you may need to check: