Benchmark methodology

Sample telemetry schema

Reference payload used for size calculations matches dummy-device.js and test_device.cpp:

{
  "temp": 22.5,        // float32, 4 bytes
  "humidity": 40.0,    // float32, 4 bytes
  "is_active": true    // uint8 boolean, 1 byte
}

Packed little-endian payload: 9 bytes.

Struct encoded frame

Protocol v2 telemetry uplink:

[1B proto=2][16B key_id][1B schema][4B unix_ts][12B nonce][payload][32B HMAC-SHA256]

• Header: 34 bytes
• HMAC: 32 bytes
• Reference payload: 9 bytes
• Authenticated frame: 75 bytes

The landing page rounds this to ~100 B as a small authenticated UDP uplink example (a few extra schema bytes, or typical IPv4+UDP headers on the wire, land near that figure). It is not a claim that every Struct payload is 100 bytes.

Encryption and delivery confirmation

For the same 9-byte sample, optional encryption adds 32 bytes, making the uplink 107 bytes. Confirmed UDP adds a 69-byte signed storage receipt. With minimum IPv4 and UDP headers, one successful exchange is 200 bytes without encryption or 232 bytes with encryption, before link-layer overhead. These are format calculations, not packet captures.

Lost packets or receipts can add retransmissions. Radio registration, time synchronization, signal quality, and modem tail time also affect energy use. Smaller payloads alone do not establish battery savings.

HTTPS / TLS cold-uplink example

The ~5.2 KB HTTPS figure is an approximate cold TLS + HTTP POST overhead used for the comparison — a new TCP connection, TLS handshake, and a small JSON telemetry request. It is not a packet capture stored in this repository.

100 / 5200 ≈ 1.9% remaining, which is the source of “~98% less transmitted data per cold uplink” in the illustrative estimate. That ratio does not mean the packed struct is 99% smaller than the JSON document. The JSON body for this schema is on the order of tens of bytes; most of the 5.2 KB is session/handshake overhead.

Persistent HTTPS/TLS sessions and persistent MQTT connections may have substantially lower per-message overhead than a cold connection. MQTT, TCP, and HTTPS are appropriate for many workloads; the comparison is limited to intermittent cold uplinks.

Fleet cost model

The ~$2,400/month figure is a model, not a measured invoice:

• 10,000 devices
• 1 cold uplink per minute
• ~5,100 bytes saved per ping (5,200 − 100)
• ≈ 2.2 TB/month
• $1.10/GB metered cellular

It does not apply if devices keep MQTT or TLS sessions alive, batch readings, or transmit less often.

Still unmeasured

The following are not measured in this repository. Landing-page cells say Benchmark pending rather than guessed numbers.

• CBOR, MessagePack, and Protobuf encodings of the sample schema
• JSON + MQTT/TLS per-message size on a warm session
• Radio awake time / “10× less awake time” (no MCU capture yet)
• Battery-life deltas (depend on modem, signal, retries, sleep current, chemistry, temperature, firmware)
• Decode latency on a specific microcontroller
• Compiler flags and MCU used for firmware timing

These measurements are not in the repository. A reproducible bench would encode the sample schema to JSON, CBOR, MessagePack, and Protobuf, capture cold HTTPS against Struct UDP, and record radio-on time for a named board with published compiler settings.

Verified from implementation

• Generated headers use #pragma pack(1) structs and static_assert on size — no malloc/new in the packing path.
• Field types: float32, int32, uint8, boolean, flags.
• Transports: TCP stream and UDP datagram, both Protocol v2 + HMAC-SHA256.
• Optional ChaCha20-Poly1305 on Pro/Scale, with timestamp + durable nonce replay checks.
• Destinations are signed HTTPS webhooks, not first-party Datadog/AWS connectors.

When other encodings win

• Protobuf — schema evolution, nested messages, multi-language codegen.
• CBOR / MessagePack — self-describing binary without an out-of-band schema.
• MQTT — long-lived bidirectional sessions, fan-out, command/control.
• HTTPS / JSON — request/response, firewall traversal, human-debuggable APIs.