HamBird is a paging system for amateur radio on the 70 cm ham band. Instead of POCSAG it uses chirp spread spectrum (CSS) modulation: more range, drastically less energy - and a receiver barely larger than its display.
POCSAG dates back to the 1980s and needs a signal well above the noise. CSS - known from LoRa - still decodes reliably at about −12.5 dB below the noise floor. That translates directly into range: the same coverage with a fraction of the TX power, or much more coverage at the same power.
For the receiver, the other side of the coin matters even more: chirp correlation is extremely frugal in hardware (Semtech silicon), and the HamBird protocol lets the receiver sleep almost all of the time. Only that makes a coin cell realistic as the sole power source.
Roughly 20 dB of link-budget advantage over narrow-band FSK - shadowed areas, indoors and fringe locations become reachable.
Short, robust frames plus scheduled RX windows: the receiver spends > 99.9 % of its time in deep sleep.
Spreading makes the signal immune to narrow-band interferers and frequency drift - important with a small chip antenna on a keychain.
| Item | Value |
|---|---|
| TX power 50 W | +47 dBm |
| TX antenna (omni, exposed site) | +3 dBi |
| Cable + cavity filter | −3 dB |
| RX sensitivity SAMR34 (SF9/125 kHz) | −129 dBm |
| Chip antenna on the tiny PCB | ≈ −12 dBi |
| Allowable path loss | ≈ 164 dB |
Worn on the body (−5…−10 dB) more like 10-15 km.
Looser development, less shadowing.
≈ 25-30 km with a 30 m mast, 50 km and more from a truly exposed site.
The chip antenna is the biggest minus item - and that is exactly what CSS absorbs: −129 dBm sensitivity at SF9 versus about −110 dBm for a typical POCSAG receiver, a lead of roughly 20 dB. Terrestrially, buildings, vegetation and Earth curvature set the limit (Hata model, transmitter at 30 m, receiver at 1.5 m) - not the TX power.
HamBird listens on an ordinary repeater - DB0SP, for example. When a callsign is spoken there, the matching receiver is paged via CSS. Pure simplex transmission, no return channel.
A fellow ham calls you by voice on the repeater, e.g. DB0SP.
An off-the-shelf receiver feeds the audio into the Raspberry Pi.
Offline speech recognition spots your callsign in the ongoing traffic.
The SX1268 generates the chirp, the PA raises it to site-grade power.
Your HamBird wakes in the next RX window, beeps and shows the call on e-ink.
The Raspberry Pi runs VOSK, a fully local speech recognizer - no cloud, no internet required. It listens to the repeater audio around the clock, looking for callsigns: spoken out (“Delta Lima …”) as well as spelled using the ICAO alphabet.
Once your callsign is detected, a call frame goes out to your HamBird within seconds. The transmitter also remembers the last 16 detected callsigns and broadcasts them at longer intervals - so every HamBird sees who has recently been active on the repeater.
A small web dashboard on the Pi shows live what the recognizer hears, which calls were triggered, and whether beacon and PA are running cleanly.
This is what the 1.54″ e-ink could show: 200 × 200 pixels in black, white, red and yellow. ① repeater and UTC time, next to the alert banner in red · ② the callsign being paged, large in black · ③ the callsigns heard last, from the latest broadcast.
The protocol is compact and optimized entirely for receiver energy. Transmissions use 434.900 MHz with spreading factor SF9 - 439.700 MHz is under discussion as a possible alternative. Every minute the transmitter sends a beacon as a time signal. The receivers synchronize their clocks to it and open the radio only at the expected beacon time - a few milliseconds per minute.
No - bit-pattern wake-up comes from the FSK/POCSAG world. With CSS the
preamble consists of upchirps that the radio chip
generates and detects in hardware; bytes like 0x55 0xAA simply
do not exist on the air interface. The standard length of
8 symbols (≈ 33 ms at SF9/125 kHz) is enough because,
thanks to beacon sync, the receivers know exactly when to listen -
long wake-up preambles would only be needed for unsynchronized duty-cycle
scanning. The one exception: after a battery change the receiver listens
continuously for up to 60 s until it catches its first beacon.
ASCII wastes space: with 8-bit characters, 6 bytes would end after
6 characters - DK0ABC/P would no longer fit. Callsigns,
however, only need 38 symbols (A-Z, 0-9, “/”, end). Packed as a
base-38 number, up to
9 characters fit into the same 6 bytes
(38⁹ < 2⁴⁸). Example DL1XYZ →
digit sequence 4·12·28·24·25·26 → one 48-bit number. The
callsign itself is the device ID - there is no separate serial
number, and the receiver simply compares 6 bytes.
All frames on 434.900 MHz (alternatively possible: 439.700 MHz) with SF9, 125 kHz bandwidth, CR 4/5, CRC-16 from the LoRa PHY. The beacon’s “announce” field tells the receivers whether a call or broadcast follows in this minute - only then do they stay awake longer. Simplex without a return channel: the transmitter repeats calls in the following minutes instead of waiting for acknowledgements. All content is transmitted unencrypted - as amateur radio regulations require for the use of these frequencies.
SF10 would add 3 dB of link budget (roughly 25 % more radius) but doubles every airtime - and with it the beacon RX window and the receiver’s average current. That is why HamBird starts with SF9; switching later via firmware update would be possible.
| SF9 (baseline) | SF10 (comparison) | |
|---|---|---|
| Sensitivity | −129 dBm | −132 dBm |
| SNR limit | −12.5 dB | −15 dB |
| Symbol duration | 4.1 ms | 8.2 ms |
| Airtime beacon / call / broadcast | 0.12 / 0.17 / 0.53 s | 0.25 / 0.29 / 1.0 s |
| Beacon RX window | ≈ 100 ms/min | ≈ 250 ms/min |
| Average current | ≈ 12 µA | ≈ 25 µA |
| CR2032 realistic | ≈ 16 months | ≈ 8 months |
| Urban range | ≈ 20 km | ≈ 25 km |
The minute beacon carries the UTC minute. The receiver’s crystal only has to stay accurate for one minute - even a watch crystal with a generous capture window can do that.
Between beacons the SAMR34 sleeps deeply. If the beacon announces a call or broadcast, the receiver stays awake only for the few extra milliseconds needed.
At longer intervals HamBird transmits the last 16 callsigns detected by VOSK as one collective frame - a small “who was on the repeater?” list for everyone.
Mock-up · the HamBird on its keychain - the e-ink keeps its display even without power.
Mock-up · four parts: PCB · display · frame · cover - the match sets the scale. Not a single connector too many.
Cortex-M0+ with integrated Semtech CSS transceiver - a single chip for everything.
Ceramic, right on the PCB - possible thanks to the CSS link budget.
200 × 200 px in black/white/red/yellow. Keeps its image without power, updates only on a new call.
Beeps when your own callsign is called.
One coin cell, target: more than six months of runtime.
Pressing the red button shows the owner’s contact details on the display - whoever finds the keychain knows where it belongs.
A small blue LED flashes briefly every 10 seconds - one glance is enough to see that the HamBird is running.
Firmware updates via the USB port, no programming adapter needed.
| State | Current | Share | Contribution to average |
|---|---|---|---|
| Deep sleep (RTC running) | ≈ 2 µA | > 99.9 % | ≈ 2 µA |
| Beacon RX window | ≈ 5 mA | ≈ 100 ms/min | ≈ 8 µA |
| E-ink update + alert | ≈ 10 mA | a few s/day | ≈ 2 µA |
| Average | ≈ 12 µA | ||
| CR2032 gross | 220 mAh | ÷ 12 µA | ≈ 18,300 h ≈ 25 months |
| CR2032 realistic | ≈ 65 % usable | pulse derating | ≈ 143 mAh → ≈ 16 months |
A back-of-the-envelope calculation as a basis for discussion. The derating respects the chemistry: a CR2032 is built for ~0.2 mA of continuous load - the mA pulses of the RX window and e-ink updates must come from a buffer capacitor, otherwise the cell voltage sags and part of the capacity goes unused. Capture window, crystal drift and alert frequency add further variables. Even calculated conservatively, the “more than six months” target keeps a safety factor of roughly 2-3.
| Component | ≈ € / unit (batch of 10) |
|---|---|
| Microchip SAMR34 | 7.00 |
| 1.54″ e-ink BWRY 200 × 200 | 10.00 |
| Chip antenna + matching network | 2.00 |
| Crystals (32.768 kHz + TCXO) | 2.50 |
| Transducer (piezo) | 1.50 |
| USB socket, CR2032 holder + cell | 2.00 |
| Passives, LDO, buffer capacitor | 2.50 |
| PCB, 4-layer (batch of 10) | 3.00 |
| Enclosure (3D-printed in-house) | 1.50 |
| Total material | ≈ €32 |
With shipping, customs and a scrap reserve, realistically ≈ €35-40 per sample device; assembly counted as own work (external assembly: + €5-10). Display and SAMR34 account for a good half of the cost. In a batch of 100 the unit price drops to roughly €22-25.
On the transmitter side there is deliberately nothing exotic - standard parts any ham can source. All the intelligence lives in the protocol and the receiver.
| Core transmitter | ≈ € |
|---|---|
| Raspberry Pi (mini format) + SD card | 30 |
| SX1268 module (with TCXO) | 8 |
| Mitsubishi RA60H3847M1 PA module | 100 |
| Heatsink + fan | 25 |
| Power supply 12.5 V / ≥ 15 A | 50 |
| Transmitter PCB + low-pass parts | 25 |
| Shielded enclosure (aluminium, weatherproof) | 40 |
| Small parts, sequencer, DC converter | 20 |
| Subtotal | ≈ €300 |
| Site accessories | ≈ € |
|---|---|
| 70 cm cavity band-pass filter (used/kit) | 90 |
| Antenna (omni) | 80 |
| Coax cable + connectors | 40 |
| RX receiver for the repeater audio (used) | 40 |
| Subtotal | ≈ €250 |
Total ≈ €550, depending on sourcing €500-650 - a one-time cost: a single transmitter serves any number of receivers. No driver stage is needed - at +22 dBm the SX1268 delivers more than the ~50 mW the RA60H3847M1 needs for rated output; if anything, an attenuator belongs in between. Don’t underestimate the power supply: at ~40 % PA efficiency, 60 W of RF means a good 150 W of input power.
