New Packet Radio in PacketRF
PacketRF exists, today, primarily to run New Packet Radio on modern RP2350 hardware while staying fully compatible with the original F4HDK firmware and existing deployed NPR networks. If you want the one-line summary: PacketRF carries plain IPv4 traffic over the 70 cm amateur band using NPR's master-controlled TDMA model, and it does so as a drop-in network interface from the host's point of view.
The wider project introduction lives in PacketRF and the deeper history in Original NPR vs PacketRF. This page is specifically about what NPR is, what it is for, and what to expect from it once you have a node on the air.
Compatibility first, novelty second
PacketRF is not an attempt to replace NPR with something different. The goal is to keep interoperability with existing NPR equipment while moving the firmware, the management interface, and the surrounding tooling into a cleaner shape. That means a PacketRF master and an original F4HDK slave should connect to each other without anyone touching the air protocol, and that is exactly what current testing confirms.
Where PacketRF does want to extend NPR — for example with optional authenticated admission of slaves on the master, described in NEP-0002 — those extensions go through a written proposal first and are designed to be ignored by older parsers. There is no PacketRF-only dialect waiting to surprise an unsuspecting NPR deployment.
What is on the air today
A PacketRF node currently provides, as either master or slave:
- the standard NPR modulation profiles, on SI4463
- the TDMA schedule, allocation frames, fast and slow uplink modes
- timing-advance tracking and feedback
- the connection handshake (CONNECT_REQ, CONNECT_ACK, CONNECT_NACK)
- the WHO neighbor advertisement and a host-visible neighbor cache
- IPv4 segmentation and reassembly across NPR frames
- master-side address allocation for connecting slaves
- proxy ARP on Ethernet-like local interfaces, so a host on the wired side can reach NPR-side addresses without manual routing tricks
Everything in that list is the standard NPR behavior — PacketRF is the implementation, not the protocol designer. The behavior of the air interface is documented authoritatively in F4HDK's NPR protocol specification and NPR advanced user guide, both linked from the Hackaday project page.
The network model in one paragraph
An NPR network has exactly one master and one or more clients. The master controls timing on the channel, publishes a slot allocation table on every TDMA frame, and decides who gets uplink airtime. Clients stay synchronized to that timing and only transmit in the opportunities the master assigned to them. Because the payload is plain IPv4, the radio side of a client node looks, from the host operating system, like a normal network interface — the same idea as plugging in an Ethernet cable, except the cable is a shared TDMA channel with a managed schedule on top.
That last sentence sounds simple and it is true, but it has consequences that are not always intuitive on the first day. The most important one is that the link is shared and scheduled. Your packet does not leave when you press enter; it leaves when the master next gives your client an uplink slot. That is also why a "clean" link can still feel slow on ping — the schedule, not the RF, is the bottleneck. There is a separate page just for that: Latency and Ping Expectations.
What NPR is good at
NPR is a comfortable carrier for the kind of traffic that is bursty, modest in size, and tolerant to a few hundred milliseconds of latency. In practice that is a wide and useful range:
telemetry from remote sites, MQTT and CoAP control traffic, low-rate APRS gateways, router-to-router management links, telnet on a remote shack box, file synchronization that does not mind being patient, lightweight web services, status dashboards, monitoring, anything that fits the expectation of "small request, small response, occasional larger payload". On a healthy 70 cm path with a reasonable modulation profile this works genuinely well.
What NPR is not for
NPR is a managed TDMA system on a shared radio channel. That defines its strengths but it also defines a few hard "no" cases.
It is not a transport for tight-jitter VoIP. It is not a reasonable medium for video streaming. It is not a substitute for broadband, and it will not behave like a cable modem under heavy load — deep buffering, aggressive retransmission, and TCP cubic behavior all assume a very different link layer than this. None of that is a flaw in NPR; it is what a managed amateur radio TDMA channel is supposed to look like. Pushing heavy traffic at it is the fastest way to discover the limits, and not the kind of discovery anyone enjoys.
What changes how the link feels
Once a PacketRF node is connected and stable, the things that decide whether the link feels fast or slow, smooth or jittery, are usually:
- which modulation profile is selected — wider channels and higher symbol rates give shorter TDMA frames and more raw throughput, but they also demand a cleaner path,
- whether the client is currently in fast mode (one transmit opportunity per TDMA frame) or slow mode (one opportunity every multiframe, by default
x8), - the size of the IP packets, in particular whether they cross the NPR segmentation boundary at 252/253 bytes,
- the master's allocation policy under load, when more clients are asking for airtime than the channel can serve in one frame.
Each of those topics has its own page:
If you have an NPR link in front of you and it does not behave the way you expect, those pages, in that order, are usually the right place to look before reaching for an SDR.
Operator-side documentation
Configuring a PacketRF node for NPR — picking master vs slave, choosing the modulation profile, allocating an IP range, putting the radio on the air — is operational documentation rather than protocol theory. That material lives in the dedicated PacketRF Operating Guide, which is the PacketRF-specific counterpart to F4HDK's Advanced user guide and is meant to be read with a node on the bench.