Appearance
Transports
Every channel a MeshSat kit or node can pass a message over, and where each one stands today. Each has its own page, and every page opens with the same status code you see here and on meshsat.net.
Reticulum is not a channel: it is the encrypted routing that runs over the channels below, and it has its own page under Reticulum. The same table is in the Bridge's README.
Status codes
| Code | What it means |
|---|---|
| LIVE | Tested and working on our prototype hardware: the two V1 field kits, or a MeshSat node with a phone |
| CODE | In the Bridge, not running on a kit: either no kit carries the hardware, or we have no record of a run |
| BENCH | The hardware is on our bench, not in a kit yet |
| COMING SOON | The hardware is on its way to the bench. Nothing has been tested |
| FUTURE PLAN | Planned. Nothing is bought |
A code says where a channel is, not how well it works. What has actually been shown is in the "Proven so far" column and on each page, and every page that is not LIVE says what we plan to test and how.
These labels record the tests performed, not production readiness. MeshSat has never been used in a real emergency. For Reticulum interfaces, tests against rnsd do not establish compatibility with physical radios or every third-party client.
Satellite
| Channel | Status | Proven so far |
|---|---|---|
| Iridium IMT | LIVE | Verified over a real satellite link, March 2026, then in both kits with many messages both ways |
| Iridium through a MeshSat node | LIVE | Satellite messages both ways with MeshSat Android and MeshSat iOS. The Bridge's own client has not run against a real node |
| Iridium SBD | LIVE | Worked on hardware in a kit, and works through a MeshSat node (row above) |
Radio
| Channel | Status | Proven so far |
|---|---|---|
| Meshtastic | LIVE | Working on hardware, both kits |
| APRS | LIVE | Working on hardware: a VHF radio on 144.800 MHz in both kits |
| Cellular | LIVE | SMS in both directions, working on hardware |
| Wi-Fi | LIVE | Each kit's uplink. The kit-to-kit link was proven once and is switched off |
| 10 m HF shouts | CODE | Codec verified against a reference, no radio yet |
| TETRA Direct Mode | LIVE | Working on hardware: texts between both kits in Direct Mode, through the Bridge on both sides |
| HF data | COMING SOON | Nothing on a radio |
| Wi-Fi HaLow | COMING SOON | Nothing on a HaLow radio |
| Own 2G cell | BENCH | On the bench: two phones on our cell, texts and calls both ways; the Bridge runs the cell. Not in a kit |
Wired
| Channel | Status | Proven so far |
|---|---|---|
| Fiber | COMING SOON | Nothing |
| Single-pair copper | COMING SOON | Nothing |
Short range
| Channel | Status | Proven so far |
|---|---|---|
| ZigBee | CODE | Code complete, light field exposure. No dongle in a kit since 20 September 2026 |
| Bluetooth LE | CODE | No record of a run on a kit |
| RNode | CODE | Verified against rnsd, not a radio |
| KISS TNC | CODE | Verified against rnsd, not a TNC |
IP and Hub
| Channel | Status | Proven so far |
|---|---|---|
| Hub link | LIVE | Both kits report to the Hub. A fallback over SMS and Iridium |
| MQTT | LIVE | Both kits reach the Hub over MQTT |
| TAK | LIVE | A direct link to a TAK server on both kits. Through the Hub: not released on the Bridge |
| Webhooks | CODE | No record of a Bridge webhook running on a kit |
| IP mesh: UDP and AutoInterface | CODE | Verified against rnsd. Reticulum over TCP is the IP path that is live |
Receive only
These carry no messages out. They tell the kit something.
| Channel | Status | Proven so far |
|---|---|---|
| Jamming watch | LIVE | Tested against ambient noise only, never against a real jammer |
| Cell broadcast alerts | CODE | No record of an alert received on a kit |
| DCF77 time signal | BENCH | Nothing. Two receiver modules on the bench, none wired to a kit |
Transport lifecycle
Every transport in the Bridge follows the same lifecycle:
- Init. The transport is created with its configuration.
- Connect. The underlying connection is established: a serial port opened, a TCP session connected.
- Run. The transport listens for incoming messages and accepts outgoing sends.
- Reconnect. On connection loss it retries by itself with exponential backoff.
- Shutdown. A graceful disconnect on process exit.
Common features
All transports share these:
- Auto-detection. Serial transports can find their device on USB hotplug.
- Health checks. Each transport reports its connection status through the API.
- Metrics. Message counts, latency and error rates per transport.
- Dead letter queue. Failed sends are queued for retry with a configurable lifetime.
- Message transforms. Payloads can be transformed before sending: compression, encoding, format conversion.
Next steps
Pick a channel above, or see the Architecture section for how transports work with the policy engine.