55  Payload Builder & Validator

Interactive IoT payload design and format comparison tool

animation
data-formats
payload
optimization
fundamentals

55.1 IoT Payload Builder

Design efficient payloads for your IoT application and understand the tradeoffs between different data formats.

NoteAbout This Tool

This interactive tool helps you design IoT payloads by adding fields, comparing encoding formats (JSON, Compact JSON, CBOR estimate, Binary struct), validating against protocol limits, and calculating data volume at scale.

TipHow to Use
  1. Add Fields using the field builder - select type, name, and example value
  2. Compare Formats to see size differences between JSON, CBOR, and binary
  3. Check Protocol Compatibility against LoRaWAN, Sigfox, NB-IoT limits
  4. Calculate Scale to estimate daily/monthly data volumes
  5. Try Templates for common IoT patterns (temperature sensor, GPS tracker, etc.)

55.2 Understanding Payload Design

55.2.1 Why Payload Size Matters

In IoT systems, every byte counts. Payload size directly impacts:

  • Bandwidth costs - Cellular data is expensive at scale
  • Battery life - Larger payloads = longer transmit time = more energy
  • Protocol compatibility - Many protocols have strict size limits
  • Latency - Smaller payloads transmit faster

55.2.2 Format Trade-offs

Format Comparison Summary
Format Pros Cons Best For
JSON Human-readable, universal Large, parsing overhead Wi-Fi, debugging
CBOR 40-50% smaller, self-describing Binary, less tooling LoRaWAN, CoAP
Binary Struct Smallest possible Rigid, no field names Sigfox, ultra-constrained

55.2.3 Protocol Payload Limits

%% fig-alt: Bar chart showing maximum payload sizes for common IoT protocols, ranging from Sigfox at 12 bytes to NB-IoT at 1500 bytes.
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#FFFFFF', 'primaryBorderColor': '#16A085', 'lineColor': '#7F8C8D', 'secondaryColor': '#ECF0F1', 'tertiaryColor': '#FFFFFF'}}}%%
flowchart LR
    subgraph Limits["Protocol Maximum Payload Sizes"]
        SIG["Sigfox<br/>12 bytes"]
        SF12["LoRaWAN SF12<br/>51 bytes"]
        SF10["LoRaWAN SF10<br/>115 bytes"]
        SF7["LoRaWAN SF7<br/>242 bytes"]
        BLE["BLE<br/>244 bytes"]
        NB["NB-IoT<br/>1,500 bytes"]
    end

    SIG --> SF12 --> SF10 --> SF7 --> BLE --> NB

    style SIG fill:#E74C3C,stroke:#2C3E50,stroke-width:2px,color:#fff
    style SF12 fill:#E67E22,stroke:#2C3E50,stroke-width:2px,color:#fff
    style SF10 fill:#F1C40F,stroke:#2C3E50,stroke-width:2px,color:#000
    style SF7 fill:#27AE60,stroke:#2C3E50,stroke-width:2px,color:#fff
    style BLE fill:#9B59B6,stroke:#2C3E50,stroke-width:2px,color:#fff
    style NB fill:#3498DB,stroke:#2C3E50,stroke-width:2px,color:#fff


%% fig-alt: Decision tree for choosing appropriate data format based on protocol and payload requirements.
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#FFFFFF', 'primaryBorderColor': '#16A085', 'lineColor': '#7F8C8D', 'secondaryColor': '#ECF0F1', 'tertiaryColor': '#FFFFFF'}}}%%
flowchart TD
    START[What protocol<br/>are you using?] --> Q1{Sigfox?}
    Q1 -->|Yes| BIN[Custom Binary Only<br/>12 byte limit]
    Q1 -->|No| Q2{LoRaWAN?}
    Q2 -->|Yes| Q3{SF12?<br/>Long range}
    Q3 -->|Yes| CBOR1[CBOR or Binary<br/>51 byte limit]
    Q3 -->|No| CBOR2[CBOR preferred<br/>115-242 bytes]
    Q2 -->|No| Q4{Wi-Fi/LTE/Ethernet?}
    Q4 -->|Yes| JSON[JSON OK<br/>Bandwidth plentiful]
    Q4 -->|No| Q5{BLE?}
    Q5 -->|Yes| CBOR3[CBOR recommended<br/>244 byte ATT MTU]
    Q5 -->|No| ASSESS[Assess your limits<br/>Choose accordingly]

    style START fill:#2C3E50,stroke:#16A085,stroke-width:2px,color:#fff
    style BIN fill:#E74C3C,stroke:#2C3E50,stroke-width:2px,color:#fff
    style CBOR1 fill:#E67E22,stroke:#2C3E50,stroke-width:2px,color:#fff
    style CBOR2 fill:#16A085,stroke:#2C3E50,stroke-width:2px,color:#fff
    style CBOR3 fill:#16A085,stroke:#2C3E50,stroke-width:2px,color:#fff
    style JSON fill:#27AE60,stroke:#2C3E50,stroke-width:2px,color:#fff

This decision tree helps you quickly identify which data format is appropriate based on your communication protocol.

55.2.4 Field Type Optimization

When designing payloads, choose the smallest data type that fits your data:

Recommended Data Types by Range
Data Range Recommended Type Size
0 to 255 uint8 1 byte
-128 to 127 int8 1 byte
0 to 65,535 uint16 2 bytes
Temperature (-40 to 125) int8 1 byte
Humidity (0-100%) uint8 1 byte
GPS coordinates float32 4 bytes
Timestamps uint32 4 bytes
TipPayload Optimization Tips
  1. Use short field names in JSON (e.g., “t” instead of “temperature”)
  2. Scale values to use smaller integers (e.g., temp * 10 as uint16 instead of float)
  3. Use enums for categorical data (0, 1, 2 instead of “low”, “medium”, “high”)
  4. Batch readings when possible to reduce per-message overhead
  5. Include version field for schema evolution
  6. Omit null/default values to reduce size
WarningCommon Mistakes
  • Over-engineering: Using float64 for temperature (int8 or int16 usually sufficient)
  • Verbose names: “device_identifier” vs “id” adds 14 bytes in JSON
  • Redundant data: Sending device ID in every message when it’s in the topic/address
  • No compression: Consider gzip for JSON over high-bandwidth links

55.2.5 Real-World Example: Temperature Sensor

Temperature Sensor Payload Comparison
Format Payload Size
JSON {"id":"S001","t":23.5,"h":65,"ts":1702732800} 47 bytes
Compact {"i":"S001","t":23.5,"h":65,"s":1702732800} 44 bytes
CBOR Binary encoding ~28 bytes
Binary 4B id + 2B temp + 1B hum + 4B ts 11 bytes

The binary format achieves 77% reduction compared to JSON!

55.3 What’s Next

Explore related data format topics:

Interactive tool created for the IoT Class Textbook - PAYLOAD-001