Blog Title

SSCE

2026-09-12T00:00:00Z

An SSCE on JavaRanch (now known as CodeRanch) stands for Short, Self-Contained, Correct (or Compilable) Example. It is a highly effective troubleshooting standard used in programming forums to help others diagnose and fix your code quickly.

The 4 Pillars of an SSCE

Short: Remove all code that does not directly contribute to the problem. Strip away unrelated logic, extra variables, and large UI layouts.
Self-Contained: The code must be complete. Anyone who copies and pastes it into their IDE should be able to run it instantly without needing external files, databases, or proprietary libraries.
Correct / Compilable: The code should compile. If the issue is a runtime bug or exception, the code must run and successfully reproduce that exact error.
Example: It demonstrates the specific problem or concept you are asking about, rather than being your entire project.

Reticulum

2026-09-11T00:00:00Z

Wow! I really enjoyed Guy Royse's talk about Reticulum at KCDC 2026. He provides a github repo with his code and slides. It's really worthwhile to read Guy's slides.

Here's some of the notes I took:

pip install rns # Installs reticulum
1. Rust and JavaScript implementations also exist
Reticulum protocol is public domain.
LXMF is a related to Reticulum and allows a message to be contained in a QR code!
1. The start page says "LXMF is a distributed, delay and disruption tolerant message transfer protocol built on Reticulum."

Links from Guy's repo's readme include:

MeshChat — A chat client and NomadNet browser for Reticulum.
RServer — The webserver Guy wrote for Reticulum.
Mesh Browser — The web browser Guy wrote for Reticulum.

It was great to see live demostrations of this during Guy's KCDC 2026 talk.

When I google: Reticulum hello world

Google's AI says, do the pip and then try these two python programs:

server.py:

import RNS
import time

# Initialize Reticulum
rns = RNS.Reticulum()

# Define an application name and aspect
APP_NAME = "helloworld"
ASPECT = "echo"

def main():
    # Create a destination that others can find
    identity = RNS.Identity()
    destination = RNS.Destination(
        identity, 
        RNS.Destination.IN, 
        RNS.Destination.SINGLE, 
        APP_NAME, 
        ASPECT
    )
    
    # Set up a callback to handle incoming data
    def packet_callback(data, packet):
        message = data.decode("utf-8")
        print(f"Received message: '{message}'")

    destination.set_packet_callback(packet_callback)

    # Announce this destination so clients can discover its identity
    destination.announce()

    print(f"Server is running. Destination address: {RNS.prettyhexrep(destination.hash)}")
    print("Announced destination. Waiting for messages... (Press Ctrl+C to exit)")

    while True:
        time.sleep(30)
        # Re-announce periodically so clients started after the first
        # announce can still discover this destination
        destination.announce()

if __name__ == "__main__":
    main()

client.py:

import RNS
import sys
import time

# Initialize Reticulum
rns = RNS.Reticulum()

APP_NAME = "helloworld"
ASPECT = "echo"

# Listens for announces from the server so we can learn its real identity
class ServerAnnounceHandler:
    def __init__(self, aspect_filter):
        self.aspect_filter = aspect_filter
        self.identity = None
        self.destination_hash = None

    def received_announce(self, destination_hash, announced_identity, app_data):
        self.identity = announced_identity
        self.destination_hash = destination_hash

def main():
    print("Looking for server destination...")

    # Wait for the server to announce itself so we learn its real identity.
    # A destination created with a random identity would have a different
    # hash than the server's and packets sent to it would go nowhere.
    handler = ServerAnnounceHandler(aspect_filter=f"{APP_NAME}.{ASPECT}")
    RNS.Transport.register_announce_handler(handler)

    while handler.identity is None:
        time.sleep(0.1)

    print("Server destination found.")

    destination = RNS.Destination(
        handler.identity,
        RNS.Destination.OUT,
        RNS.Destination.SINGLE,
        APP_NAME,
        ASPECT
    )

    # Send the data packet
    message = "Hello World over Reticulum!"
    packet = RNS.Packet(destination, message.encode("utf-8"))
    
    packet_receipt = packet.send()
    print(f"Sent: '{message}'")
    
    # Confirm delivery if possible
    if packet_receipt:
        print("Packet handed over to the network.")
    else:
        print("Failed to send packet.")

    # Reticulum transmits asynchronously via a background thread, so give it
    # a moment before the process exits - otherwise the packet can be dropped
    # before it's actually written to the interface.
    time.sleep(2)

if __name__ == "__main__":
    main()

LXMF references

2026-09-11T00:00:00Z

LXMF References

Reading list gathered while building lxmf_qr.py / qr_lxmf.py, with a focus on how keys are managed in Reticulum/LXMF. All links below were confirmed from the official project metadata bundled with the installed rns and lxmf pip packages (venv/lib/python3.11/site-packages/{rns,lxmf}-*.dist-info/METADATA).

Official sources

Reticulum manual — https://markqvist.github.io/Reticulum/manual/ (mirrored at https://reticulum.network/manual/). The canonical documentation for the whole stack, including identities, cryptography, and interfaces.
- Getting Started Fast
- Using Reticulum — includes the "Included Utility Programs" section covering rnid, the identity management/encryption CLI tool.
- Supported Interfaces
Reticulum source (RNS) — https://github.com/markqvist/Reticulum — see RNS/Identity.py for the actual key-handling code.
LXMF source — https://github.com/markqvist/lxmf — see LXMF/LXMessage.py and LXMF/LXMRouter.py.
reticulum.network — https://reticulum.network/ — project home page.
FAQ — https://github.com/markqvist/Reticulum/wiki/Frequently-Asked-Questions

Client implementations built on LXMF

Sideband — https://unsigned.io/sideband
Nomad Network — https://unsigned.io/nomadnet
MeshChat — https://github.com/liamcottle/reticulum-meshchat

How keys are managed

This is the short version distilled from RNS/Identity.py and LXMF/LXMRouter.py in the installed packages — read those files directly for the authoritative details.

The Identity keyset

A Reticulum Identity is a 512-bit Curve25519 keyset, made of two separate 256-bit keys (RNS/Identity.py, KEYSIZE/CURVE constants):
- an Ed25519 key, used for signing (proves who sent a message)
- an X25519 key, used for ECDH key exchange (used to derive per-message encryption keys)
Your Reticulum/LXMF address (the destination hash you give out, e.g. an LXMF address) is a truncated hash derived from the identity's public key. It's not a secret and is safe to share; it's how others address messages to you.
The private key is the only thing that can decrypt messages addressed to that identity or produce valid signatures from it. There is no password/passphrase wrapping it by default — whoever holds the key file is that identity.

Saving and loading identities

Identity.to_file(path) / Identity.from_file(path) are the built-in save/load calls (used by both lxmf_qr.py and qr_lxmf.py via .lxmf_identities/). The library's own docstring is blunt about the risk:

Saves the identity to a file. This will write the private key to disk, and anyone with access to this file will be able to decrypt all communication for the identity. Be very careful with this method. — RNS/Identity.py, to_file()

Practical takeaways:
- Treat an identity file exactly like an SSH private key: don't commit it, don't email it, restrict its file permissions. This is why .lxmf_identities/ was added to .gitignore in this repo.
- pub_to_file(path) exists separately for saving just the public key, e.g. to hand your address to someone else without exposing anything secret.
- Identity.from_bytes(prv_bytes) / load_private_key() exist for lower-level cases, but the docstring explicitly warns never to feed them random data to "generate" a key — always use Identity() (with create_keys=True, the default) to actually generate new keys.

Forward secrecy via ratchets

A long-term Identity key by itself gives no forward secrecy — if it's ever compromised, all past traffic encrypted to it could theoretically be decrypted. Reticulum addresses this with ratchets: short-lived X25519 keys that rotate automatically and are used instead of the long-term key for actual message encryption when available (RNS/Identity.py, RATCHETSIZE, RATCHET_EXPIRY — defaults to rotating and expiring ratchets after 30 days).
Real LXMF delivery destinations turn this on via Destination.enable_ratchets(path), called from LXMRouter.register_delivery_identity() in LXMF/LXMRouter.py — ratchet keys are persisted separately from the identity file, under the router's storagepath/ratchets/ directory.
Note on our demo scripts: lxmf_qr.py/qr_lxmf.py build a bare RNS.Destination directly (no LXMRouter, no ratchets enabled), so the paper message they produce is encrypted with the static identity key only, not a ratchet. That's an accurate reflection of how LXMF paper messages actually work (they're meant to be decryptable offline, so they can't depend on ratchet state that only exists in a live router), but it's worth knowing that a normal, online LXMF conversation gets an extra layer of forward secrecy that a paper/QR message doesn't.

Key management tools

rnid — the command-line identity management and encryption utility that ships with rns. Run rnid --help (after pip install rns) to see its options for generating, inspecting, and using identities from the shell. Covered in the "Included Utility Programs" section of the manual link above.

F4HWN Fusion Firmware on a $30 radio

2026-08-15T00:00:00Z

Last month Aaron gave a talk on Alternative Radio Firmwares. On Thursday, at the pub, I installed F4HWN firmware port for the UV-K1 and UV-K5 V3 using the PY32F071 MCU which works with the QUANSHENG UV-K5 v3 $28 hand held radio. I'm very excited and curious to try out Fox Hunt Mode.

$33 AIOC to used to install

I'm happy to meet with you and use my AIOC to install the firmware on your radio.

What is in my radio log?

2026-08-13T00:00:00Z

Claude.ai created some easy to use python scripts that put my logs into SQLite. Once the contacts are in a real database, asking questions about them is just SQL instead of scrolling through a spreadsheet.

One of the summaries that pleases me includes contacts outside of CONUS:

Confirmed QSOs outside the USA entity, by country (confirmation source: qsl_rcvd, lotw_qsl_rcvd, eqsl_qsl_rcvd, app_qrzlog_status)

Country               QSOs  Stations
------------------  ------  --------
Canada                  57        53
Japan                   25        24
France                   7         7
Netherlands              5         5
Angola                   4         1
Chile                    4         3
Dominican Republic       4         4
Germany                  4         4
Italy                    4         4
Puerto Rico              4         4
Spain                    4         4
Brazil                   3         3
Alaska                   2         2
Belize                   2         2
England                  2         2
Northern Ireland         2         2
Poland                   2         2
Switzerland              2         2
Argentina                1         1
Asiatic Russia           1         1
Belgium                  1         1
China                    1         1
Costa Rica               1         1
Cuba                     1         1
Czech Republic           1         1
Dodecanese               1         1
Ecuador                  1         1
El Salvador              1         1
European Russia          1         1
Greece                   1         1
Guam                     1         1
Hungary                  1         1
Indonesia                1         1
Lebanon                  1         1
Luxembourg               1         1
Norway                   1         1
Portugal                 1         1
Romania                  1         1
Sardinia                 1         1
Serbia                   1         1
Ukraine                  1         1
Wales                    1         1
------------------  ------  --------
TOTAL                  161  42 country(s)

161 confirmed QSOs across 42 countries, with Canada and Japan leading the way. Angola sitting at 4 QSOs from a single station stands out too.

How does VHF propagation get measured?

2026-07-23T00:00:00Z

Thanks to Jim KX0U for showing me vhf.dxview.org. It's a live map that colors the country by how far VHF signals are getting out right now — greens and yellows where things are normal, oranges and reds where the band is open. That's a great picture, but it left me wondering: where does that data actually come from? Nobody is out there with a signal generator sweeping the whole country every hour.

The trick: use the traffic that's already there

The VHF map doesn't run its own beacons. Instead it listens to a network that's already broadcasting all day long — APRS, the Automatic Packet Reporting System.

APRS stations sit on 144.390 MHz (here in North America) and send short packets: position beacons, weather data, messages, and digipeater IDs. Thousands of them are transmitting around the clock. Every one of those packets is a tiny, timestamped, geolocated propagation test that somebody already paid for.

How a packet becomes a data point

Here's the chain:

A station transmits a packet. It contains the sender's callsign and, usually, its position (or a known fixed location).
Another station hears it and gates it to the internet. These are I-gates (Internet gateways). When an I-gate copies a packet off the air, it forwards it to APRS-IS, the internet backbone of the APRS network, and stamps it with its own callsign and location.
Now you have two endpoints. The packet knows where it came from (the sender) and where it was received (the I-gate). Both have known coordinates.

That's the whole measurement. A packet that traveled from station A to I-gate B, received in the last hour, means 2 meters supported at least that A-to-B distance at that moment. Most hops are short and local. But when the band opens — tropospheric ducting, a temperature inversion, sporadic-E — I-gates start hearing stations from hundreds of miles away, and those long paths light up.

From dots to a footprint

The map takes all those received paths from the past hour and smooths them into a color-coded footprint. If the longest paths being copied in your area are 50 miles, you're green. If I-gates near you are suddenly pulling in packets from 300 miles out, that region goes orange to red. It's not predicting propagation from solar numbers or a model — it's showing you what actually got through, reverse-engineered from ordinary APRS traffic.

Why this is clever

The same idea powers a lot of ham propagation tools, but with different source data:

The HF sibling at hf.dxview.org leans on the Reverse Beacon Network (automated CW and FT8 skimmers) and PSK Reporter instead of APRS.
PSK Reporter does the same trick for FT8/digital modes: every decoded signal is a spot with two known endpoints.

In each case the insight is the same — you don't need a dedicated beacon network if you're willing to treat the everyday traffic as your beacons. On VHF, APRS packets are perfect for it: short, frequent, geolocated, and already flooding the internet through I-gates.

So the next time your position beacon gets gated by a station three states away, you weren't just showing off — you were a data point telling everyone the band was open.

Sources

QUANSHENG UV-K5

2026-07-21T00:00:00Z

Aaron's talk about custom firmware inspired me to get a pair of UV-K5 version 3 radios and some AIOCs. Hoping to have fun learning digital modes at my QTH.

Here's a long google AI response to the search "quansheng uv-k5 digipi aioc"

Combining the Quansheng UV-K5, an AIOC (All-In-One Cable), and a DigiPi creates a powerful, budget-friendly portable digital amateur radio hotspot. The AIOC functions as a USB soundcard, serial adapter, and PTT controller, bridging the UV-K5 to the Raspberry Pi running DigiPi. [1, 2, 3, 4]

The Components

Quansheng UV-K5: An incredibly versatile and inexpensive handheld transceiver (HT) covering VHF/UHF and airband, which can be modified via custom firmware.
AIOC: An open-source interface board (also known as "Universal Radio Controller") that connects to the radio's dual-pin K1 port on one end and the DigiPi via a single USB-C cable on the other. It handles both audio and PTT flawlessly.
DigiPi: A project and specialized operating system for the Raspberry Pi (built by KM6LYW) that gives you a web-based portal to run data modes like APRS, Winlink, JS8Call, and FLdigi right from your phone or browser. [3, 12]

How to Set It Up

Radio Settings: On the Quansheng, set the volume to around 25% and ensure you have the correct squelch settings configured for digital data.
AIOC to DigiPi: Connect the AIOC’s twin-prong connector to the radio. Connect the AIOC to the DigiPi’s USB port.
Initialize DigiPi: Boot up your DigiPi and navigate to the web interface. On the Initialization page, choose your AIOC (typically listed as ) as the radio interface. Enter your callsign, grid square, and APRS settings.
Firmware (Optional): Many users flash custom firmware (like IJV or DOCK firmware) to the UV-K5 to unlock better performance, like 'flat audio' or direct rig control. [19, 20, 21, 22]

Potential Challenges to Watch For

RF Interference (RFI): Because everything is highly portable, your HT's transmitted signal can easily feed back into the Raspberry Pi or the AIOC, causing the radio to get stuck in "transmit" mode.
Fix: Users in the DigiPi forums recommend adding ferrite beads on both ends of your USB cable and physically keeping the radio's antenna at least 2 meters away from the DigiPi board.
Audio Levels: Because HTs aren't strictly designed for continuous-duty digital data, you may need to fine-tune your audio input/output levels using the DigiPi web menu so your signal isn't over-deviated. [3, 24]

If you're building this setup, could you tell me which version of the Raspberry Pi you are using and which digital modes (like APRS, JS8Call, or Winlink) you plan to use? I can help you with your specific configuration files!

AI responses may include mistakes.

References

Practical Electronics course on YouTube

2026-07-19T00:00:00Z

Thanks to the University of Colorado for putting 28 videos from their course on Practical Electronics up. I am eager to learn.

They also have a 26 lecture playlist from the class Circuits & Electronics for Non-EEs.

Path Logger, Version 0.01

2026-07-18T00:00:00Z

https://n3pay-2b69c-pl1.web.app/ is the temporary URL

Simplex is where the interesting radio happens. No repeater, no linked system, just two stations and whatever the terrain and the antennas will allow. The part I kept wanting to keep track of was not the contact itself but the path — where I was, where the other station was, and whether that path worked again later.

So I built Path Logger. Version 0.01 is deliberately small.

What it does

Logs the contact. Callsign, date and time, frequency, mode, and signal reports, typed in on the spot.
Captures location. The browser's geolocation gives me my position, and I record the other station's grid or coordinates. That turns a log entry into two endpoints instead of one.
Maps the path. Every logged contact draws a line between the two stations, so a night of simplex work becomes a picture of what actually got out.
Shares the log. Multiple operators can sign in to the same project and see each other's entries. During a net or a group activation, everyone's contacts land in one map.

Why Firebase

I wanted to spend my time on the logging, not on hosting. The free tier covers everything version 1 needs: Firestore for the contact records, Authentication so operators sign in rather than sharing a password, and Hosting to serve the whole thing. No server to patch, no database to back up by hand, and the app is a URL I can open on a phone in the truck.

The tradeoff is honest: this is somebody else's platform and somebody else's quota. For a hobby log of simplex contacts, that's a trade I'm happy to make. If it outgrows the free tier, exporting Firestore documents to something self-hosted is not a hard problem.

What version 1 is not

It is not a general-purpose logger. There is no ADIF import, no LoTW or QRZ integration, no contest support. If you want a real log, use a real logger. Path Logger exists to answer one question: what paths have worked, from where, on simplex?

Version 2 ideas, roughly in order of how much I want them: ADIF export, elevation profile along the path, and marking a contact as a repeat so I can see which paths are reliable versus lucky.

The demo is live — try it and tell me what's missing.

TIL from KF0UQM that VoxDMR exists

2026-07-10T00:00:00Z

It's great to chat with people you have not met before. Today I learned, from Joe, that VoxDMR exists.