Tech and tooling for urban voice communications
  • Rust 96.5%
  • Dockerfile 3%
  • Shell 0.5%
Find a file
2026-03-04 12:42:31 -07:00
dmr-master dmr-master: restart hblink in the container if it dies 2026-02-05 17:13:09 -07:00
manet-mesh-health-gui Add support for "UPS Hat (E)" 2026-03-04 12:42:31 -07:00
DMR-Hotspot.md DMR Hotspot: md syntax 2026-02-03 12:41:55 -07:00
DMR-Master.md add DMR Master info 2026-02-03 13:08:11 -07:00
Manet.md start mesh health visualizer 2026-02-24 22:02:57 -07:00
README.md add DMR Master info 2026-02-03 13:08:11 -07:00

Goals

Provide mobile, reliable, secure, grid-independent/grid-down voice communications for community support organizations operating in an urban environment spanning tens of blocks.

System Architecture

Each individual has a DMR HT.

When the group is close enough, voice comms go directly between DMR HTs over VHF/UHF. (Experimentally this means within about 0.5 or 0.75 miles.) All HTs are set to the same frequency & encryption key, and operate in simplex mode.

When the group is too dispersed for direct simplex DMR communications (more than about a half mile, several blocks apart), we start a bunch of comms infrastructure:

  • an ad-hoc mesh IP network with enough nodes to connect everyone
  • one DMR Master Server
  • one DMR Hotspot for each locality

Each locality's hotspot is set to a different frequency, but all use the same encryption key. It's up to the operators to configure their HTs to communicate with their local hotspot.

Network: Manet, IP on 802.11s mesh network, running on 802.11ah HaLow radios.

Voice communications: DMR HT radios. One Baofeng DM-1701 DMR HT per person, one mobile DMR Hotspot per locality, and a single DMR Master server.

This system architecture enables us in the future to experiment with other, non-DMR voice comms options, i.e. VOIP channels with PTT speaker/mics and earbuds.

Deployment example / Main use case

The group is fielding several roving teams within a relatively small area. Everyone has line of sight to each other. Everyone carries a DM-1701, set to talk using a single designated frequency and encryption key.

The group decides to split into two subgroups. The two subgroups will not have line of sight to each other, but everyone within each subgroup will have line of sight to everyone else in that subgroup.

In preparation for splitting up we power up a bunch of equipment:

  • several Manet nodes
  • one DMR Master
  • two DMR Hotspots

Each of these devices is a rugged battery powered computer, about 1 liter, about 1 kg.

The Manet nodes self-assemble into an ad-hoc mesh IP network. Each Manet node makes a normal Wifi hotspot. The DMR Master and DMR Hotspots connect to the Wifi hotspots. The DMR Hotspots find the DMR Master using mDNS.

The DMR Hotspot for subgroup A is configured to receive and transmit using the frequency and encryption key from the original group. The people in subgroup A do not need to change their HT radio config.

The DMR Hotspot for subgroup B is configured to receive and transmit using the same encryption key, but a different frequency. This prevents the two hotspots from picking up each others traffic over the air and creating a transmit loop. FIXME: is this needed? The people in subgroup B need to change their HT radio configs to the new frequency.

When a person in one of the subgroups keys their radio, their transmission is heard immediately by everyone in their subgroup (because they have line of sight). Their transmission is also heard by their DMR Hotspot. The DMR Hotspot sends the transmission over the IP mesh network to the DMR Master, which sends it to the other subgroup's DMR Hotspot. The other subgroup's DMR Hotspot transmits the audio on its frequency and it's heard by all the HTs of that subgroup.

Future work / Stretch goals

  • location tracking
  • text communication
  • mesh health monitoring
    • show a map of the area of operations
    • show the location of each mesh node
    • show RSSI of each node-node link
    • this would let us keep the mesh healthy by dynamically adding nodes where they're needed
  • support multiple independent DMR talk groups for sub-teams