For the last few months I have been slowly turning my New Packet Radio experiments into a larger project called PacketRF. It started as a relatively small experiment around New Packet Radio, but over time it became clear that what I actually wanted to build was not only another NPR implementation. What I want is a small, low-cost and reasonably hackable radio networking platform, something that can be used for IP over RF today, but also for more interesting experiments later, especially delay-tolerant networking.
This article is meant as an introduction to the project. Not as a release announcement, not as a finished product, and definitely not as a polished user manual. PacketRF is still very much work in progress. Some parts already work quite well, some parts are rough, some parts exist only as early code, and some parts are still only ideas in my head. But there is now enough working code and hardware that it makes sense to start writing about it publicly and, more importantly, to start a discussion.
The whole project comes from a feeling I have had for some time when looking at data communication in amateur radio. We have many interesting systems, and many of them are genuinely useful, but a lot of them are built as complete vertical stacks around one particular use case. That is not necessarily wrong, but it also means that if you want to experiment with only one layer, or build something slightly different, you quickly find yourself fighting the design.
VARA is a good example from the amateur radio world. It is impressive from the user point of view, and it is clearly useful, but as an experimenter it is more or less a black box. Winlink is another example, although in a slightly different way. Winlink is a very successful radio email system, but it is an application and service ecosystem, not a general packet networking stack that you can freely build on.
Outside amateur radio, Meshtastic and MeshCore show something very interesting. They prove that many people want small, cheap, low-power radio devices that form some kind of network and do something useful without infrastructure. I like that, but even there, the same pattern appears again. The system implements everything from the radio layer through routing and transport up to the actual user application.
When we put so much effort, hardware, time and RF spectrum into building a radio network, should the final result really be mostly a system for sending a few short text messages, weather comments and greetings? I do not mean that in a dismissive way, but I think amateur radio can do more.
This is the point where PacketRF enters the picture. I do not want PacketRF to be one more application-specific modem. I want it to behave more like a normal network node, except that one of its interfaces happens to be radio.
What PacketRF is
PacketRF is firmware for RP2350-based radio nodes. On one side there is a host-facing network interface, currently USB CDC-NCM and optionally wired Ethernet using W5500. On the other side there is a radio transport, currently New Packet Radio using an SI4463 transceiver. From the host point of view, the node looks like a normal network interface. You assign an address, configure routes, and send traffic through it.
The firmware is structured with modularity in mind. NPR is one module, the IP stack is handled through lwIP, the management system is separate from the radio protocol. The device has its own identity key, and configuration changes can be signed. The point of all this structure is not to make the firmware look complicated, but to avoid building another single-purpose monolith that becomes painful as soon as the next idea appears.
Current state of the project
PacketRF is not finished, and I do not want to pretend that it is. The best description right now is probably “working prototype and research platform”.
- The NPR master and slave modes work.
- Interoperability with the original NPR firmware works.
- IPv4 packets can move over the radio link.
- USB networking works.
- W5500 Ethernet is supported.
- The cryptographic tools and key store are implemented.
- The management tool exists and can configure the device locally or remotely.
The last two points deserve a little more explanation. PacketRF does not try to encrypt amateur radio traffic, because that is not the goal and in many amateur contexts it would not be allowed anyway. But authentication is different. I want the node to be able to verify who is allowed to connect to it, change its configuration, reboot it, change radio parameters, or later influence routing behavior.
The current model uses asymmetric cryptography for management. A new node starts in a bootstrap state, you install the first admin key with proof of local physical access, and from then on signed management requests can be verified by the device.
It’s not perfect, because keys stored in flash are not protected against a determined physical attacker, but even this is already much better than an unauthenticated command interface listening on a radio-reachable network.
The main incomplete or rough parts are:
- The documentation is work-in-progress and incomplete.
- Internals and configuration system may (and probably will) change.
- The firmware needs more long-term testing.
- The hardware needs another revision.
- DTN (BPv7) is still not implemented in the firmware.
If you want a polished modem that behaves like a consumer product, PacketRF is not that. If you want a platform to experiment with radio IP networking and eventually DTN, then it may already be interesting.
Hardware today
The easiest way to try PacketRF today is a Raspberry Pi Pico 2 with an SI4463 radio module for the 70 cm band. The radio module needs SPI and an IRQ pin. With a simple wiring harness, USB cable and a suitable 70 cm antenna, this is enough to build a working NPR node. It can be configured as a slave or as a master, and it can interoperate with original NPR nodes.
A nice detail is that you do not even need the radio module to start exploring the firmware. A plain Pico 2 can run PacketRF and expose the USB network and management interfaces. Of course it will not transmit anything and it is not useful as a radio node, but it is useful for looking at the management model, testing the host tool, inspecting the schema and getting a feeling for the system before connecting RF hardware.
If you add a W5500 Ethernet module to the Pico 2 setup, the node becomes much more interesting. You have USB, Ethernet and NPR in one small device, which is already enough for a practical bench network or a simple field experiment.
My longer-term hardware direction is the RF Baseboard. This is a custom RP2350B-based board with USB-C, W5500 Ethernet, 16 MB flash, optional PSRAM and two radio module positions. The idea is that the baseboard provides the boring but necessary parts of the node, and different radio modules can be plugged in depending on the experiment. Right now I have a module with SI4463 and a 3 W PA for NPR, and another module with audio DAC/ADC for experiments with ordinary radios and classic packet radio.
The RF Baseboard works, but it’s not something I can honestly present as a finished board. It works well enough for firmware development and experiments, but it has not been field tested properly. I have already destroyed one board, where the SI4463 stopped responding over SPI. Four other boards are still alive and useful.
I would like to make another hardware revision with better robustness and probably some layout and usability improvements. But this is a hobby project, not a funded product, so hardware iterations take time and money. For now, if you want to experiment today, use a Pico 2 with SI4463, and optionally add W5500 Ethernet.
Why start with New Packet Radio
New Packet Radio by Guillaume F4HDK caught my attention because it already lives in a useful middle ground between HAMNET and classic Packet Radio.
Classic 1200 baud packet radio is historically important and still interesting, but it is painfully slow for many modern experiments. WiFi-based amateur systems such as Hamnet or AREDN can be very fast, but they need suitable bands, paths, antennas and deployment conditions. NPR sits somewhere between those worlds. It uses the 70 cm band, offers usable data rates, carries IPv4 traffic, and has a network model that is understandable and practical.
That combination is rare. The important thing for me was not only that NPR works as a modem, but that it carries IP. Once you have an IP interface, even a slow and strange one, a lot of ordinary network tooling becomes available. You can route traffic, run services, measure latency, try how real applications behave when the link below them is narrow, scheduled, shared and sometimes unreliable. That is much more interesting to me than another isolated serial data channel.
So PacketRF started with NPR for a very practical reason: NPR works, it is interesting, and there is already an ecosystem to interoperate with. But NPR is not meant to be the final boundary of the project. It is the first transport.
Beyond NPR
The next obvious area is classic packet radio through an audio interface. There is already an initial Bell 202 / 1200 baud decoder in the codebase, although it is not complete yet and I do not want to present it as a working feature. I want PacketRF to be able to work not only with dedicated RF chips, but also with ordinary radios through audio.
Classic packet radio has one important property that modern custom hardware sometimes lacks: a lot of people already have radios. If PacketRF can eventually use an audio module and a normal transceiver or handheld, it becomes possible to experiment with custom protocols on hardware many operators already own.
Other possible directions are still open. Different RF chips such as CC1200-class devices may make sense. LoRa may make sense for long-range, low-rate links, although I am not interested in simply reimplementing Meshtastic/MeshCore. WiFi or HaLow may make sense for higher-throughput local links. I do not know yet which of these are worth the effort.
DTN as the long-term goal
This also connects back to the earlier DTN article. There I described DTN mostly as an architectural answer to intermittent amateur radio networks. PacketRF is my attempt to build the small, practical piece that is needed before those ideas can be tested properly.
My concrete target is BPv7 on small embedded devices with limited memory. I already have an early C++ implementation running on a PC, and I can send bundles locally on localhost. The next step is to bring that implementation into PacketRF firmware and start sending bundles over NPR links.
I expect this to be difficult. Memory is limited, routing is hard, storage has to be well designed. But that is exactly why I want PacketRF to exist. I do not want to only write about DTN for amateur radio. I want a small network of real nodes, with real radios, antennas, timing, losses and operator mistakes, and then see what works.
What next
The short-term goal is to make PacketRF with NPR stable enough that I can build several nodes, give some of them to other people, and create a small experimental network.
After that, I want to get BPv7 running inside PacketRF and start moving bundles over the NPR transport.
Only then will the more interesting questions begin. How should routing work when contacts are irregular? How much storage does a small node need? What metadata is useful and what is too expensive? How should node identity and authentication interact with amateur radio callsigns? Can the same platform use NPR for one path and classic packet or LoRa for another? Where does IP make sense, and where does DTN make more sense?
Thanks
PacketRF is mostly a one-person project, but not developed completely in isolation. Robin OK2AWO helped with hardware testing and measurements and gave me several useful pieces of feedback. Andreas OE3ANC was immediately willing to prepare antennas and a setup at his QTH so we could try the first experimental NPR link.
Thanks to both of them.
Closing
I am especially interested in practical feedback. What hardware would you actually build? What frequency plans and channel widths are realistic in your area? What use cases are more interesting than another chat application? What would you want from a small low-power radio router? What would make such a platform useful for Hamnet, AREDN, emergency exercises, field events, telemetry or remote sites?
I do not promise that PacketRF will become all of that. It may simply teach me a lot about what does not work. But even that would be a good result. This is amateur radio. We are allowed to build imperfect things in order to learn from them.