You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First time posting here. I've been building this protocol for the last year - the idea started before I even bought my first device.
Meshtastic carries text. Works great for humans. But if you want to send structured, machine-parseable instructions between nodes, you hit the payload wall fast.
Meshtastic already uses protobuf internally via nanopb, so you know what protobuf buys you. A compiled protobuf message for something like a move-to-waypoint command still runs 50-70 bytes depending on field population. At SF12/BW125kHz, your usable payload is 51 bytes. It's tight.
OSMP is an encoding that replaces verbose key-value structures with opcode lookups against a shared dictionary. That same move instruction becomes R:MOV@BOT1:WPT:WP1 at 21 bytes. A threshold alert with a medical code: H:HR@NODE1>120→H:CASREP∧M:EVA@* at 35 bytes. Both fit a single SF12 packet with room to spare.
Measured on 29 real-world vectors from five frameworks (compiled with protoc 3.21.12): 70.5% smaller than compiled Protocol Buffers, 86.8% smaller than minified JSON. Protobuf wins on one vector (numeric-heavy Kubernetes scaling, 27 bytes vs 32). SAL wins the other 28. Full methodology, .proto schemas, and reproduction scripts are published in the repo.
Decode at the other end is a table lookup against the dictionary. No parsing ambiguity, no schema negotiation per message. 342 opcodes across 26 namespaces (environmental sensors, geospatial/nav, health/clinical, robotics, emergency management, network routing, and others).
The Python SDK has no dependencies beyond the standard library. If you're already using the meshtastic Python library to script your nodes, the integration is straightforward: encode your message with the OSMP SDK, send it as the text payload via sendText(), decode on the other side. The encoding rides inside a standard Meshtastic text message. No firmware changes. No custom modules.
I have a Heltec T114 connected over USB serial to my test mule and a SenseCAP T-1000-E to check the relay on my phone - planning to share results when the first SAL-encoded message crosses the mesh.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
First time posting here. I've been building this protocol for the last year - the idea started before I even bought my first device.
Meshtastic carries text. Works great for humans. But if you want to send structured, machine-parseable instructions between nodes, you hit the payload wall fast.
Meshtastic already uses protobuf internally via nanopb, so you know what protobuf buys you. A compiled protobuf message for something like a move-to-waypoint command still runs 50-70 bytes depending on field population. At SF12/BW125kHz, your usable payload is 51 bytes. It's tight.
OSMP is an encoding that replaces verbose key-value structures with opcode lookups against a shared dictionary. That same move instruction becomes R:MOV@BOT1:WPT:WP1 at 21 bytes. A threshold alert with a medical code: H:HR@NODE1>120→H:CASREP∧M:EVA@* at 35 bytes. Both fit a single SF12 packet with room to spare.
Measured on 29 real-world vectors from five frameworks (compiled with protoc 3.21.12): 70.5% smaller than compiled Protocol Buffers, 86.8% smaller than minified JSON. Protobuf wins on one vector (numeric-heavy Kubernetes scaling, 27 bytes vs 32). SAL wins the other 28. Full methodology, .proto schemas, and reproduction scripts are published in the repo.
Decode at the other end is a table lookup against the dictionary. No parsing ambiguity, no schema negotiation per message. 342 opcodes across 26 namespaces (environmental sensors, geospatial/nav, health/clinical, robotics, emergency management, network routing, and others).
The Python SDK has no dependencies beyond the standard library. If you're already using the meshtastic Python library to script your nodes, the integration is straightforward: encode your message with the OSMP SDK, send it as the text payload via sendText(), decode on the other side. The encoding rides inside a standard Meshtastic text message. No firmware changes. No custom modules.
I have a Heltec T114 connected over USB serial to my test mule and a SenseCAP T-1000-E to check the relay on my phone - planning to share results when the first SAL-encoded message crosses the mesh.
Repo: https://github.com/Octid-io/cloudless-sky
Python SDK: https://github.com/Octid-io/cloudless-sky/tree/main/sdk/python
Efficiency analysis (full methodology, .proto schemas, reproduction scripts): https://github.com/octid-io/cloudless-sky/blob/main/docs/SAL-efficiency-analysis.md
Apache 2.0 with express patent grant.
Beta Was this translation helpful? Give feedback.
All reactions