For the past few months I have been slowly working on the next step of my New Packet Radio experiments. Since the last NPR modem revision B described in my previous article (in Czech), quite a few things have changed. What originally started as a relatively small hardware update gradually turned into something much larger.
This article summarizes what I have been doing recently and where the project is heading.
A quick recap: what NPR actually is
For readers who are new to this topic, NPR (New Packet Radio) is a radio modem architecture and protocol designed for IP networking over amateur radio. It typically operates in the 70 cm band and uses one master station coordinating multiple clients using a managed TDMA scheme. The system transports standard IPv4 traffic over radio frames and schedules uplink and downlink transmissions to avoid collisions.
The original implementation by Guillaume F4HDK uses an STM32 microcontroller and an SI4463 radio chip. The protocol supports several predefined modulation profiles based on 2GFSK or 4GFSK with symbol rates between 50 kS/s and 500 kS/s, giving usable data rates roughly between 70 kbps and 470 kbps depending on the selected mode.
My earlier work focused mainly on building compatible hardware and experimenting with the protocol. Now I am moving toward something more flexible.
From “revision C” to a completely new hardware platform
Originally my plan was simple. I wanted to build NPR modem revision C, basically the same design as revision B but with an integrated power amplifier delivering about 3 to 5 watts of RF output power.
However, when I started looking deeper into the RF path I realized that the commercially available NiceRF RF4463F30 module I had been using had several limitations. It works, but it is not really designed for extension. Adding a power amplifier stage to it is problematic, and the module does not have a particularly good output filter. Measurements show the second harmonic radiation was much higher than it should.
At that point it became obvious that if I wanted full control over the RF path, the simplest solution was to design my own RF module around the SI4463 transceiver.
First RF module prototype
The first version of this module is already sitting on my desk. It is intentionally simple. There is no power amplifier yet and the transmit and receive paths are separated. The goal of this first revision was only to verify that the matching networks and filters are correct.
So far this prototype behaves exactly as expected, which is encouraging.
Second RF module revision
The second revision of the module is currently waiting for assembly. This version adds a power amplifier stage using the GRF5504, which is similar to what we already use in the LinHT project. It also includes an RF switch, the SKY13330, to switch between transmit and receive.
At the moment I am still waiting for the last components to arrive, so I honestly do not know yet whether the design will work perfectly on the first try. RF hardware has a way of humbling you.
Rethinking the modem controller
Once I started redesigning the RF module, I began thinking about the rest of the modem as well. The original NPR hardware uses an STM32L432 microcontroller. Both the original firmware by F4HDK and my modified version run on this platform.
The STM32L432 is a nice chip, but it is already operating very close to its limits. During the refactoring of the legacy firmware I repeatedly ran into situations where I simply could not add new features because there was no remaining RAM or flash. At that point I decided to switch to something different.
Why RP2350?
The new hardware platform is built around RP2350, the microcontroller used on the Raspberry Pi Pico 2. I already used this chip in another project, a Game Boy emulator, and I really enjoyed working with it.
The RP2350 offers much more memory and CPU headroom than the STM32L432. It also provides interesting features like the PIO subsystem and flexible DMA engines, which are extremely useful when working with timing-sensitive protocols.
Another interesting aspect is that the chip contains both ARM Cortex-M33 cores and a RISC-V core, which opens the door for various experiments.
Why not ESP32?
I’m sure people will ask this question. The answer is simple and somewhat subjective. I have spent many years working with ESP32 in professional projects. For this project I simply wanted something different.
RP2350 also lacks integrated Wi-Fi and Bluetooth, but for this application that is actually an advantage. The system remains simpler and easier to control.
Most importantly, I am designing the firmware in a way that should make it platform agnostic. If I ever decide to move to another MCU, the protocol logic should remain largely unchanged.
Two radio modules instead of one
While redesigning the PCB I noticed something I didn’t consider before. The existing enclosure I use for the previous version of the NPR modem actually has enough space for two RF modules. So I decided to take advantage of that.
The new board design therefore includes two modular RF slots, and the RF module itself uses castellated edge connections so it can be mounted like a small daughterboard.
This opens interesting possibilities. One modem could potentially host:
- two NPR radios on different frequencies,
- or two NPR radios working in full duplexmode,
- or an NPR radio plus a different protocol based on CC1200 or SX1255,
- or other experimental digital modes.
The idea is to turn the modem into a general-purpose data radio platform, not just a single-mode device.
Firmware development on Pico 2
While waiting for hardware components to arrive I did not want to sit idle. So I built a temporary development setup using a Raspberry Pi Pico 2 board connected to the first SI4463 module prototype.
With this setup I started writing a completely new firmware implementation that will remain compatible with existing NPR networks. The goal is to support both roles NPR slave and master.
At the moment only the slave side is implemented.
Software architecture
The new firmware architecture is quite different from the original one. The system runs on FreeRTOS, and the network stack is handled by lwIP. The Pico SDK is used only as a thin hardware abstraction layer.
The protocol logic itself is intentionally separated from the hardware layer so that most of the code can run independently of the specific MCU platform.
Why lwIP?
The main reason is simple. LwIP already implements a complete and well-tested TCP/IP stack. This gives me a lot of functionality almost for free. For example, lwIP already supports PPP over serial (PPPoS) which I’m using during the Pico 2 development stage.
Development setup
My current development hardware does not include the Wiznet W5500 Ethernet controller used by the original NPR modem. Instead I am using PPPoS over USB serial.
On my Linux computer I can run pppd and establish a PPP connection to the modem. This creates a new network interface on the PC with its own IP address.
The NPR implementation is then structured like this:
- The RF PHY layer runs in its own FreeRTOS task.
- It schedules transmissions, processes received frames, and tracks TDMA timing.
- When an IP packet arrives over the radio it may be split across several TDMA slots and later reassembled. In NPR a single radio frame can carry roughly 252 bytes of payload, so an IP packet with the usual MTU of 1500 bytes must be segmented across multiple radio frames.
- Once the PHY layer reassembles a valid IP packet, it hands the packet to lwIP. LwIP then handles routing between its network interfaces.
In my current setup the system has two interfaces:
np0for NPR radiopp0for PPP over USB
lwIP can route packets between them automatically, which means traffic received over radio can be forwarded to the PPP interface and appear directly on my PC network stack. I did not have to implement any routing logic myself. lwIP already provides it.
This architecture also makes it easy to add more network interfaces. For example, if I connect a W5500 Ethernet controller over SPI, I only need a thin integration layer to attach it to lwIP. After that the system will be able to route packets between:
- Ethernet,
- PPP,
- NPR radio,
- and potentially additional radio links
Later I could attach a second RF module with another protocol and treat it as yet another network interface. IP packets would simply flow between them.
Did someone mention TCP/IP over classic packet radio? Or TCP/IP over M17 data? Or maybe over LoRa? Well, the last one sounds slightly absurd, but who knows…
DTN experiments
All of this ties back to something I wrote about recently: delay tolerant networking.
My hope is that this new platform will allow me to start experimenting with BPv7 and DTN concepts on amateur radio. Once I implement a BPv7 stack suitable for FreeRTOS, this modem could become a small experimental DTN node.
About cryptography
This leads to another topic that I find quite interesting and surprisingly neglected in amateur radio discussions: cryptography.
People usually associate cryptography only with encryption, and encryption is generally prohibited on amateur bands. That is correct. But cryptography is not only about confidentiality, it is also about authentication. In other words, proving identity.
Consider this simple question: if someone connects to an NPR network claiming to be OK5VAS, how do we know that it is really me?
At the moment we cannot verify that cryptographically. The system relies on trust in the community and on the assumption that operators behave according to amateur radio rules. Most of the time that assumption works, but not always.
There may also be situations where we want to allow access only to specific operators, for example members of a local radio club or people participating in an experiment. How could we enforce that?
The answer is digital signatures. For example, using the Ed25519 signature algorithm. This is an asymmetric cryptographic system that uses two keys:
- a private key, kept secret in the device
- a public key, which can be shared openly
If I can prove that I possess the private key corresponding to a known public key, another station can verify that proof using the public key. In that case the identity claim is cryptographically verifiable.
Importantly, this works without encrypting the data channel, which means it does not violate amateur radio regulations. The traffic itself remains completely readable on air.
NPR authentication extension
Why am I explaining all this cryptography and digital signature stuff? Because during the past few weeks I have been working on a protocol extension that adds master authentication and optional client authentication to the New Packet Radio protocol.
The idea is to allow the master station to broadcast a signed identity statement which clients can verify before connecting. Clients can also optionally authenticate themselves using their own key pair.
The system uses:
- Ed25519 signatures,
- the Monocypher cryptographic library,
- lightweight TLV messages integrated into the existing signaling frames of the NPR protocol.
Older NPR implementations can still communicate even if they do not support this new authentication extension. The design is backward compatible because it adds three new signaling TLV elements which may simply be ignored by the legacy NPR implementations:
- MASTER_AUTH_BEACON
A downlink broadcast TLV emitted by the master in signaling frames. It provides the master’s signed identity statement and a fresh challenge value. - CLIENT_AUTH
An uplink TLV emitted by a slave together with a normal connection request. It proves possession of the slave private key and binds the request to a recent master beacon. - MASTER_AUTH_REPLY
A downlink TLV emitted by the master together with a connection ACK or NACK. It proves liveness of the master by signing a nonce supplied by the slave.
I have already written the specification and I am currently implementing the new signaling messages in the new FreeRTOS-based firmware. But there is still quite a lot of work ahead.
Current project status
At this moment the project looks roughly like this:
- SI4463 RF module revision 1 works.
- SI4463 RF module revision 2 with GRF5504 PA is waiting for assembly.
- The RP2350 firmware runs and communicates with legacy NPR networks in slave mode.
- Master mode still needs to be fully implemented.
- The authentication extension is designed and partially implemented.
In other words, things are moving forward.
Why I do all this
In the end this project is still very much a personal experiment. I enjoy building hardware, writing firmware, and exploring what can be done with amateur radio networks. For me that is exactly what amateur radio should be about: experimenting, learning, and sharing ideas.
If you find this topic interesting, feel free to follow this blog or my Twitter account where I occasionally post development updates. And if you have ideas or would like to participate in testing, do not hesitate to contact me.
The source code, hardware schematics, and protocol documentation for this project are not public yet. Everything is still in a very early stage and publishing it now would probably create more confusion than value. Once the system stabilizes, I will release everything on GitHub.
Until then, thanks for reading.
73 de OK5VAS