KL1V
Another Alaskan Ham
09 May 2025
🦐 IT'S AS SHRIMPLE AS THAT 🦐
10 January 2025
Ham projects for 2025
2025 has dawned with a fresh list of aspirations for myself. While some goals, such as a new job, are outside the scope of this blog, there are multiple items that deserve to be listed here, mostly to hold my feet to the fire.
Site Summit BBS:
I've managed to convince holdouts on the KL7AA board to let me move forward with an upgrade/replacement of the packet node on Site Summit. The plan is to install a full featured linBPQ based packet node with BBS, forwarding, and Winlink capabilities in its place. There will be a 1200bd port on 145.010MHz and a 9600bd port on 440.050MHz. Ideally, this will also be links to the Wasilla node too, although I haven't yet approached the MatSu club on this matter.
Robust Packet HF APRS igate:
The radio running the Robust Packet HF igate on 10.1473MHz USB has apparently seem to have gone deaf, although I have not dedicated time to in-depth troubleshooting of the system. For the time being, the igate has been pulled offline, pending future troubleshooting efforts. The future of this system is, at this time, unknown.
Home shack master plan:
Utilizing my current Hermes Lite 2 and shack pc running Linux Mint, plus hopefully a Hardrock50 amp if I manage to save up the money, my purely personal goal is to have a fully remote HF operating position. I also plan to bring my VHF igate back online. I also have a SEA-222 marine HF transceiver, which, if it is stable enough, I plan to press into service as an HF packet node on 14.105MHz LSB (technically 14.102MHz USB, since packet doesn't care, but who's counting). If all this jank actually ends up working, I may crosslink the HF packet and VHF APRS port, but that's much further down the line.
There's a lot up there, when you start dissecting each piece, and that's before you factor in other obligations, but I think I can pull it off.
~moose
Junkbin GPS Stratum 1 NTP Clock Source (A Work in Progress)
I don't know where most of these parts came from, but when I opened my electronics junk drawer the other day I found an Orange Pi Zero+ and a serial GPS of dubious quality that also featured a PPS out. With these two parts in hand and a suitable project box, my weekend free time is suddenly consumed with a pending project: build a stratum 1 NTP server using only parts on hand.
OK, but what even is that word salad of a title?
Network Time Protocol (NTP) is a method of synchronizing clocks over the internet. Wikipedia has much better information than I could ever hope to provide here, but the gist is NTP servers are organized hierarchically based on their distance from known stable clock sources. This distance is referred to as the 'stratum' of the server. Stratum 0 is a master clock itself, such as a GPS, atomic clock, WWV signal, or other authoritative time source. Stratum 1 is any NTP server directly attached to a stratum 0 clock. Since my junk drawer project welds a microcomputer and GPS receiver together, it will (eventually) qualify as stratum 1 (with caveats).
Pulse Per Second (PPS) is a signal put out by time sources to define the precise beginning of a second. A GPS connected via serial port can vaguely define the time in its NMEA sentences, but PPS provides a stable 'tick-tock' to the time sentences.
New Years' Day aurora
19 August 2024
Gull Rock Trail
10 August 2024
AREDN Mesh Access via PFSense Firewall
After several months of wrestling with integrating an AREDN node into my home network, I finally arrived on an iteration that I think I am content with. It isn't perfect, and I will detail the limitations below, but to sum it up, I am treating the AREDN node as a second WAN, with a bit of tomfoolry to get DNS working properly.
This guide will only allow for access to resources on the mesh. It will not allow access to the wider internet via the mesh.
Most of the configuration followed the PFSense dual-WAN guide word for word (which can be found here). As seen in the screenshot above, the connection is set up as DHCP. One area where I deviated from the guide is unchecking both boxes under the 'Reserved Networks' header, as AREDN utilizes the 10.0.0.0/8 private address space. On a side note, your home network better not be using the same address space or you're probably going to have a bad day.
The most important key to making all this work is DNS. If you try and enter your AREDN node's IP address as a DNS resolver for the AREDN connection gateway, PFSense will puke out an error. This leads to my workaround utilizing PFSense's internal DNS resolver, Unbound.
In PFSense 'services' menu, select 'DNS Resolver' and scroll all the way to the bottom where you will see the header 'Domain Overrides'. Add an override for the domain "local.mesh" pointing at the IP address of your local AREDN node. This allows unbound to redirect all DNS queries ending in local.mesh to the mesh node.
And that's it! Point your browser at your node and browse around the mesh to make sure everything works as expected. Note that this is not a perfect solution. For example, if you host a service behind PFSense that you also wish to expose to the mesh, you will have to add a second set of rules to expose that device and specific port. In that scenario, it would also be beneficial to add a static IP in your mesh node as well. However, for simple access to the larger mesh, this solution is hard to beat.
~ moose