Understanding Sigfox’s message flow is crucial for designing efficient IoT applications. This chapter covers the uplink and downlink communication patterns, power consumption implications, and common pitfalls that developers encounter.
By the end of this chapter, you will be able to:
When a Sigfox device sends a message, it broadcasts on a random frequency, and multiple base stations pick it up. The Sigfox cloud then deduplicates the messages and forwards the data to your application. This chapter traces the complete journey of a Sigfox message from sensor to cloud to your dashboard.
“When I send a Sigfox message, it is like throwing three paper airplanes at once,” Sammy the Sensor explained. “Each airplane flies on a different random frequency, and multiple catchers – the base stations – try to grab them. Even if one airplane gets lost or crashes into interference, the other two probably make it through. That triple transmission trick is what makes Sigfox so reliable!”
“But here is the catch with downlinks,” Lila the LED added. “If the cloud needs to send a message back to me, I have to stay awake and listen for 20 to 25 seconds after my uplink. That is like waiting by the mailbox for a letter that might not come. And I can only do that four times a day! Most of the time, I just send my data and go straight back to sleep.”
Max the Microcontroller counted on his fingers. “The power math is dramatic. An uplink costs me about 0.067 milliamp-hours – tiny! But waiting for a downlink costs about 0.35 milliamp-hours – that is over 5 times more energy. A full uplink-plus-downlink cycle costs 0.41 milliamp-hours, roughly 6 times the uplink alone. If I requested a downlink after every single message, my battery would drain much faster. That is why smart Sigfox devices only request downlinks when they absolutely need a configuration update.”
“Think of it like a postcard system,” Bella the Battery summarized. “Sending a postcard is cheap and easy – that is the uplink. But if you want a reply, you have to stand by the mailbox for 25 seconds each time, and you can only check four times a day. Design your application to send postcards without expecting replies, and I will last for a decade!”
Before this chapter, ensure you’ve completed:
The Sigfox communication protocol follows a carefully orchestrated sequence for uplink (device-to-cloud) and optional downlink (cloud-to-device) messaging:
Context: Sigfox downlink RX window consumes significantly more energy than uplink-only operation.
Uplink energy: \(E_{\text{up}} = 40\,\text{mA} \times 6\,\text{s} / 3600 = 0.067\,\text{mAh}\)
Downlink RX energy: \(E_{\text{down}} = 50\,\text{mA} \times 25\,\text{s} / 3600 = 0.347\,\text{mAh}\)
Energy ratio: \(E_{\text{down}} / E_{\text{up}} = 0.347 / 0.067 = 5.2 \times\)
Worked example: Device sending 24 messages/day with 2,400 mAh battery: - Uplink-only: \(24 \times 0.067 = 1.6\,\text{mAh/day}\) → Battery life: \(2400 / 1.6 = 1500\,\text{days} = 4.1\,\text{years}\) - With 4 downlinks/day: \(24 \times 0.067 + 4 \times 0.347 = 1.6 + 1.4 = 3.0\,\text{mAh/day}\) → Battery life: \(2400 / 3.0 = 800\,\text{days} = 2.2\,\text{years}\)
Adding just 4 downlinks daily cuts battery life in half from 4.1 to 2.2 years.
| Operation | Duration | Current | Energy | Impact |
|---|---|---|---|---|
| Sleep | 23h 59m | 1 uA | 0.024 mAh/day | Minimal |
| Uplink only | 6 sec | 40 mA | 0.067 mAh | 1x (baseline) |
| Uplink + Downlink RX | 31 sec | 40-50 mA | 0.414 mAh | ~6x more |
| Daily operations (24 up) | 24 msg/day | Mixed | 1.6 mAh/day | 4.1 year battery |
| With 4 downlinks | 24 up + 4 down | Mixed | 3.0 mAh/day | 2.2 year battery |
Design recommendation: Use downlink sparingly (monthly configuration updates) rather than frequently (daily commands) to preserve battery life.
The mistake: Designing IoT applications that require frequent bidirectional communication, assuming Sigfox supports downlink messaging comparable to uplink capacity.
Symptoms:
Why it happens: Sigfox is fundamentally asymmetric by design:
This asymmetry exists because downlink requires the device to stay awake in receive mode for 20-25 seconds after requesting a downlink window, consuming approximately 5-6x more energy than uplink-only operation.
The fix:
Prevention: Before choosing Sigfox, count your downlink requirements. If devices need more than 4 commands/day or firmware updates more than annually, consider LoRaWAN (unlimited downlinks after each uplink) or NB-IoT (full bidirectional TCP/UDP). Sigfox excels at “sensors that report” but struggles with “actuators that receive commands.”
The mistake: Designing payload formats without considering Sigfox’s strict 12-byte uplink limit, leading to either data truncation or message fragmentation across multiple transmissions.
Symptoms:
Why it happens: Sigfox enforces a hard 12-byte payload limit for uplink messages. Developers accustomed to MQTT (256MB), HTTP (unlimited), or even LoRaWAN (243 bytes) often design payloads that exceed this:
A “simple” GPS tracker with timestamp and battery level easily reaches 16-20 bytes in naive encoding.
The fix:
Compact binary encoding: Replace floats with scaled integers (GPS: 4 bytes for lat/lon combined at 10m resolution)
Eliminate redundant data: Device ID is already in Sigfox frame header; don’t repeat in payload
Relative timestamps: Send seconds-since-last-message (2 bytes) instead of full epoch (4 bytes)
Data prioritization: Send critical values every message, less critical values in rotation
Payload design template:
Bytes 0-1: Primary sensor (scaled integer)
Bytes 2-3: Secondary sensor (scaled integer)
Bytes 4-5: Battery/status flags (packed bits)
Bytes 6-11: GPS or additional data (compressed)Prevention: Design payloads on paper before coding. Use bit-packing for boolean flags, scaled integers instead of floats, and delta encoding for slowly-changing values. Validate that typical and worst-case payloads fit in 12 bytes. If 12 bytes is insufficient even with optimization, consider LoRaWAN (243 bytes) or NB-IoT (1600 bytes per message).
The Mistake: Implementing aggressive retry logic that sends the same message multiple times when no acknowledgment is received, quickly consuming the 140 messages/day quota.
Why It Happens: Developers accustomed to TCP/IP or MQTT expect acknowledgments and implement retry patterns like “send up to 5 times until ACK received.” With Sigfox’s fire-and-forget model (no native ACKs) and 140 message/day limit, this approach exhausts the daily budget by mid-morning:
Scenario: Sensor sends every 15 minutes with 3 retries per reading
- Readings/day: 96 (24 hours × 4/hour)
- With 3 retries: 96 × 3 = 288 messages/day
- Sigfox limit: 140 messages/day
- Result: Device blocked by 10:30 AM, no data for rest of dayThe Fix: Accept Sigfox’s inherent ~95-98% delivery rate without retries. Design your application to tolerate occasional missing messages:
The Mistake: Requesting a downlink but putting the device to sleep before the receive window opens, resulting in missed configuration updates or commands.
Why It Happens: The downlink window has strict timing requirements that developers often misunderstand:
Sigfox Downlink Timing:
1. Device sends uplink with downlink request flag = TRUE
2. Device MUST stay awake for 20-25 seconds in RX mode
3. Base station transmits 8-byte downlink during this window
4. If device sleeps early → downlink lost forever
Common mistake:
- Uplink sent at T=0
- Device enters sleep at T=5 seconds (too early!)
- Downlink arrives at T=20 seconds → device asleep → lostThe downlink arrives 20 seconds after uplink, but many implementations only wait 5-10 seconds before sleeping.
The Fix: Implement proper downlink handling with conservative timing:
The Misconception: Many companies assume Sigfox offers global coverage similar to cellular networks (190+ countries), leading to deployment failures in 20-40% of target markets.
Reality Check with Real-World Data:
Sigfox Coverage Reality (2024):
Case Study: Global Fleet Management Failure
Why This Happens:
Pre-Deployment Verification Protocol:
Bottom Line: Sigfox is excellent for European regional deployments but NOT a global solution like cellular networks. Always verify operator availability AND coverage quality per country before committing to Sigfox.
Scenario: A pharmaceutical distributor needs to monitor temperature inside refrigerated delivery vans. Each van carries vaccines that must remain between 2C and 8C. Regulators require temperature readings every 15 minutes with tamper-evident logging. The company has 50 vans operating 12 hours/day.
Step 1 – Message budget calculation:
| Parameter | Value | Calculation |
|---|---|---|
| Readings per day | 48 | 12 hours x 4 readings/hour |
| Sigfox daily limit | 140 messages | Protocol hard limit |
| Headroom for retries | 20% | 140 x 0.80 = 112 usable messages |
| Messages needed | 48 | Well within 112-message budget |
Good – 48 messages/day leaves 64 messages as safety margin for retransmissions caused by poor cellular-like coverage in underground parking garages.
Step 2 – Payload design within 12-byte constraint:
A naive approach would send one reading per message: {"temp": 4.2, "time": "2025-01-15T10:30:00"} – but this is 45 bytes, far exceeding the 12-byte limit and wasting JSON overhead.
Optimized binary encoding (packs 4 readings into one 12-byte message):
| Byte | Field | Encoding | Range |
|---|---|---|---|
| 0 | Message type + sequence | 4-bit type + 4-bit seq | 16 types, 16 sequences |
| 1 | Battery voltage | uint8, x0.02 + 2.0V | 2.0-7.1V, 0.02V resolution |
| 2-3 | Reading 1: temperature | int16, x0.01C | -327.68 to +327.67C |
| 4-5 | Reading 2: temperature | int16, x0.01C | Same |
| 6-7 | Reading 3: temperature | int16, x0.01C | Same |
| 8-9 | Reading 4: temperature | int16, x0.01C | Same |
| 10 | Alert flags | 8 bits | Door open, over-temp, under-temp, battery low, GPS fix, etc. |
| 11 | GPS grid cell (coarse) | uint8 | 256 predefined delivery zones |
Result: 4 temperature readings per message means only 12 messages/day instead of 48 – a 4x reduction that extends battery life and leaves 128 messages/day as headroom.
Step 3 – Downlink strategy for alerts:
With only 4 downlinks/day, the backend cannot send individual acknowledgments. Instead, use a polling pattern:
downlink_request flag. Backend responds with an 8-byte downlink containing the current alert threshold, reporting interval, and any pending configuration changes.Step 4 – Power budget:
| Activity | Current | Duration | Daily Count | Daily Energy |
|---|---|---|---|---|
| Transmit (uplink) | 45 mA | 6 sec | 12 | 0.90 mAh |
| Receive (downlink window) | 12 mA | 25 sec | 1 | 0.083 mAh |
| Sleep | 0.003 mA | 23.97 hrs | 1 | 0.072 mAh |
| Sensor reading | 5 mA | 0.5 sec | 48 | 0.033 mAh |
| Daily total | 1.09 mAh | |||
| Annual total | 397 mAh | |||
| Battery life (2,400 mAh cell) | 6.0 years |
Key design decisions and why:
In this chapter, you learned about Sigfox’s communication patterns and constraints:
Message Flow:
Power Impact:
Common Pitfalls to Avoid:
Continue learning about Sigfox deployment:
| Order | Chapter | Focus |
|---|---|---|
| Next | Sigfox Deployment | Coverage verification and deployment best practices |
| Then | Sigfox Hands-On | Interactive lab with ESP32 simulation |
| Then | Sigfox Assessment | Comprehensive quizzes and review |