Documentation

How it works

From the moment you press the mic button to the moment the message plays on the other side: what happens, in plain English, with the diagrams to match.

The five layers

Voicetastic is one layer in a stack of five. Each layer trusts the one below it to handle its own concerns.

1. Your application Recording UI, playback, chat list 2. Voice protocol (this is Voicetastic) Build, fragment, FEC, NACK, reassemble 3. Meshtastic application layer MeshPacket • PortNum::PRIVATE_APP 4. Meshtastic channel encryption AES-256-CTR with the channel pre-shared key 5. LoRa radio Modem preset chosen by the user
Voicetastic occupies layer 2. Everything below it is plain Meshtastic.

What happens when you press the mic

  1. Record. Your microphone captures audio.
  2. Encode. The audio is compressed with a codec. By default that is Codec2 at 1.2 kbps, optimised for the slowest LoRa presets. Voice codecs trade audio quality for very small files; on a 30 second clip you save several hundred× compared to raw PCM.
  3. Fragment. The encoded bytes are sliced into chunks small enough to fit in a LoRa packet (about 200 bytes each).
  4. Protect. A few extra parity chunks are added so the receiver can rebuild the message even if some chunks are lost in flight.
  5. Send. Each chunk travels from radio to mesh to receiver at a paced rate so the airwaves do not get flooded.
  6. Reassemble. The receiver collects chunks, asks for any genuinely missing ones (a NACK, see below), and decodes the audio.
  7. Play. A play button appears in the chat list.
Record microphone Encode Codec2 / AMR / Opus Fragment ≤ 215 B chunks Add FEC parity shards Send via Meshtastic
The send pipeline. Each box is a step; the trickle on the right is the paced LoRa transmit.

Surviving a lossy network

LoRa is a long range radio. Long range radios drop packets, sometimes 30 or 40 % of them. Voicetastic uses two complementary techniques so a handful of lost chunks does not ruin the whole message.

Forward Error Correction (FEC)

Before sending, the protocol computes a few extra parity chunks using Reed-Solomon coding. The receiver only needs any N out of N + P chunks (DATA or PARITY, it does not matter which) to rebuild the original audio. Losses below the parity budget are silently absorbed, with no round trip.

Sent (4 DATA + 2 PARITY): D0 D1 lost D2 D3 P0 P1 Receiver has 5/6 chunks → FEC rebuilds D1. No retransmit needed.
Reed-Solomon parity lets the receiver fill in a missing chunk on its own.

Selective NACK

If too many chunks are lost for FEC to absorb, the receiver waits a moment for the dust to settle (about 1.5 seconds) and then sends a single NACK back to the sender: a bitmap saying "I still need chunks 1, 4 and 7". The sender retransmits only those.

Sender Receiver DATA chunks (some lost) NACK bitmap (≈ 1.5 s later) Retransmit of missing chunks only
One bitmap covers every missing chunk. The sender only resends what was actually lost.

How it talks to the radio

The app on your phone or laptop never touches LoRa directly. It speaks Meshtastic's binary protocol over either Bluetooth Low Energy or a USB serial cable, and the radio handles the rest.

ConcernWhere it livesWhat it means for you
Voice chunking, FEC, NACKVoicetasticYou don't choose chunk sizes; the client picks based on your modem preset.
Routing, ACKs, channelsMeshtastic firmwareStandard Meshtastic features; nothing to configure in Voicetastic.
On-air encryptionMeshtastic channel PSKIf you trust the people on the channel, your voice is private from outsiders.
BLE / USB transportMeshtastic GATT serviceSame connection you'd use for the official Meshtastic app.
i

Want the byte level details (every header field, every flag, every reserved bit)? See the Frame Format page on the protocol wiki.

Meshtastic primer Voice messages