Skip to content

Why Jam?

Jam aims to make using Protocol Buffers (PB) in bandwidth restricted networks (e.g. LoRaWAN and Cellular) more scalable, repeatable, and easier to use.

Simply: Jam efficiently encodes and decodes small Base64 encoded Protobuf messages.

pydantic

Why Jam?

Jam was created out of my own frustration with LoRaWAN device manufactures, each of whom seems content designing their own custom binary serialization protocol. The problem is:

  • No standard message format
  • Deciphering new device payloads is a PITA
  • This makes onboarding new devices a PITA
  • See Tektelic
  • See failed CayenneLPP format

Why not JSON?

JSON is great. Kinda. It features flexible schemas and is human readable. Both, however, are an issue. Human readable means the schema (keys) need to travel with the values. Making for pretty large and expensive messages over the network. It's flexible schema means more chances for mistakes. It's the wild west with JSON!

Why Protocol Buffers?

Protocal Buffers (a.k.a. Protobuf, PB) is a well established standard for producing strongly typed and schemaful messages in compact, binary format.

  • Automatic code generation. Write your schema as .proto and automatically generate language neutral code to work encode/decode.

In and IoT context (especially in LoRaWAN IoT environments), compact messages are incredibly useful for saving on expensive network bandwidth.

Meshtastic is using Protobufs in LoRa network extensively. Meshtastic

Compactness

Consider the following example. Let's say you had a sensor deployed in the field which was uplinking the following JSON message every 5 minutes.

{
    "batt_soc": 19,
    "batt_mv": 2100,
    "temp_c": 25.0,
    "tamper": false,
    "ttu_set": 60
}
Each uplink would consume 81 bytes . Small enough, you'd think. But remember, this is being send every 5 minutes. That means over the course of a year 8.52MB. Again, not terrible. But what if we multiple that by 5,000 devies. 42.6GB! Getting expensive. {. annotate }

Note

This does not include protocol headers (e.g. 12 bytes for LoRaWAN headers)

Compare that to the same exact message, but encoded using Jam into a Protobuf message:

CBMQtBAdAADIQSg8

At just 16 bytes. 1.68 MB over a year. 8.4GB across 5,000 devices.

Thats a HUGE savings.

Format Bytes Frequency (min) Per Month Per Year 5,000 Devices
JSON 81 5 0.70 MB 8.51 MB 42.55 GB
Protobuf 18 5 0.15 MB 1.89 MB 9.45 GB
Savings 63 5 0.55 MB 6.62 MB 33.1 GB!

Standard

Protobuf is a well established standard developed by Google and used at Netflix, CockrochDB, and many others.

Pretty cool right? Ready to Spread some Jam?

Credits

Jam logo credit Toothless Font by Weape Studio