After completing this chapter series, you should be able to:
Sigfox is a proprietary LPWAN technology and global network operator that uses ultra-narrow band (UNB) modulation to send tiny messages (12 bytes, up to 140 per day) over extreme distances (up to 50 km) with minimal power consumption. Its operator-managed model offers the simplest IoT connectivity but enforces strict message constraints that make it ideal only for infrequent, low-data telemetry such as asset tracking, environmental monitoring, and utility metering.
Sigfox is both a proprietary LPWAN technology and the name of the French company that developed and operates it. Unlike other LPWAN technologies where you can deploy your own network, Sigfox operates as a network operator providing connectivity services globally. Sigfox pioneered the concept of ultra-narrow band (UNB) modulation for IoT, enabling billions of low-power devices to communicate with minimal infrastructure and energy consumption.
This chapter series provides comprehensive coverage of Sigfox technology, from fundamental concepts to hands-on implementation and assessment.
Characters: Sammy the Sensor, Lila the LED, Max the Microcontroller, Bella the Battery
Imagine Sammy the Sensor wants to send a postcard to the cloud every day. But Sammy doesn’t have a phone — he has a tiny walkie-talkie that can only whisper very short messages (like 12 words!) across a huge distance (an entire city!).
Bella the Battery loves this because whispering uses barely any energy. “I can keep Sammy talking for years without needing a recharge!” she says proudly.
Max the Microcontroller explains: “Sigfox is like a postal service for sensors. You pay a tiny subscription, drop your postcard in the mailbox (send a 12-byte message), and the Sigfox network delivers it to the cloud. But you can only send 140 postcards a day — so make each one count!”
Lila the LED adds: “And if the cloud wants to reply? It can only send back 4 tiny notes a day — so Sigfox is mostly about sensors reporting things, not having long conversations.”
Think of it this way: Sigfox is like a postcard service — cheap, simple, goes far, but you can’t send a novel!
If you’re new to LPWAN (Low-Power Wide-Area Network) technologies, here’s what you need to know about Sigfox:
When to use Sigfox: Asset tracking, environmental monitoring, utility metering, smart agriculture — any scenario with simple, periodic data reporting and long battery life requirements.
The Sigfox content is organized into five focused chapters, each covering specific aspects of the technology:
Technology foundations and ultra-narrow band modulation
Understanding uplink, downlink, and message constraints
Planning and implementing Sigfox solutions
Practical implementation with ESP32 simulation
Comprehensive quizzes and knowledge checks
Before diving into the individual chapters, it is helpful to see how the core components of the Sigfox ecosystem fit together. The following diagram shows the end-to-end data flow from device to application.
Key architectural points:
When selecting an LPWAN technology, Sigfox occupies a unique niche. The diagram below positions Sigfox relative to LoRaWAN and NB-IoT on the dimensions that matter most for IoT projects.
| Feature | Sigfox | LoRaWAN | NB-IoT |
|---|---|---|---|
| Modulation | Ultra-Narrow Band (UNB) | Chirp Spread Spectrum (CSS) | OFDMA / SC-FDMA |
| Spectrum | Unlicensed ISM | Unlicensed ISM | Licensed cellular |
| Max payload (uplink) | 12 bytes | 242 bytes | ~1600 bytes |
| Daily message limit | 140 uplink, 4 downlink | Duty-cycle limited | None (data-plan based) |
| Typical range | 10-50 km | 2-15 km | 1-10 km |
| Battery life | 10-15 years | 5-10 years | 5-10 years |
| Bidirectional | Very limited | Yes (Class A/B/C) | Full |
| Deployment model | Operator-managed | Private or public | Carrier-managed |
| Per-device cost | Very low (~$1-14/yr) | Medium (gateway CAPEX) | Medium (SIM + data plan) |
For the best learning experience, work through the chapters in order:
Before starting this chapter series, you should be familiar with:
1. Exceeding the daily message budget. Sigfox enforces a hard limit of 140 uplink messages per day. Developers who design for “send every minute” (1,440 messages/day) will exceed this by 10x. Always calculate your required daily message count before selecting Sigfox.
2. Expecting real-time downlink communication. With only 4 downlink messages per day, Sigfox cannot support real-time device control, frequent configuration updates, or over-the-air firmware updates. If your application requires regular cloud-to-device commands, choose LoRaWAN (Class C) or NB-IoT instead.
3. Ignoring payload encoding. A 12-byte payload is far too small for JSON or human-readable text. You must use binary encoding (bit-packing, fixed-point integers) to fit meaningful data. Sending {"temp":22.5} as ASCII uses 14 bytes – already over the limit. The same value encoded as a 16-bit integer uses only 2 bytes.
4. Assuming global coverage. Sigfox coverage varies significantly by country. Before committing to Sigfox, verify coverage in your specific deployment region using the Sigfox Coverage Map. Rural and indoor coverage gaps are common.
5. Overlooking the operator lock-in risk. Unlike LoRaWAN, where you can deploy your own gateway, Sigfox is entirely operator-dependent. If Sigfox ceases operations in your region (as has happened in some markets), you have no fallback without hardware replacement.
6. Not accounting for triple-transmission energy cost. Each Sigfox uplink transmits the message three times on different frequencies. Battery life calculations must include the energy for all three transmissions (total TX time of approximately 6-18 seconds depending on the module and region), not just a single frame. Underestimating this can lead to batteries depleting years earlier than expected.
A water utility company wants to monitor 5,000 water tanks across a rural region. Each tank has a level sensor, a temperature sensor, and a leak-detection flag. The company needs hourly readings during the day (06:00-22:00) and readings every 4 hours overnight. Battery replacement is expensive due to the remote locations, so a minimum 10-year battery life is required.
| Period | Hours | Interval | Messages |
|---|---|---|---|
| Daytime (06:00-22:00) | 16 h | Every 1 hour | 16 messages |
| Nighttime (22:00-06:00) | 8 h | Every 4 hours | 2 messages |
| Total | 24 h | – | 18 messages/day |
18 messages per day is well within the 140-message daily limit (only 12.9% utilization). This leaves headroom for alarm messages (e.g., leak detected, low battery).
| Field | Data | Encoding | Bytes |
|---|---|---|---|
| Water level | 0-100% | uint8 (0-200, /2 for 0.5% resolution) | 1 |
| Temperature | -10 to 50 C | int8 (offset by +10, x2 for 0.5C resolution) | 1 |
| Leak flag | Yes/No | 1 bit | (packed) |
| Battery voltage | 2.0-3.6 V | uint8 (0-160, /100 + 2.0) | 1 |
| Timestamp delta | 0-255 min | uint8 | 1 |
| Reserved | – | – | 8 |
| Total | 4 bytes used / 12 available |
Only 4 of 12 bytes are needed, leaving 8 bytes for future expansion (e.g., second tank, water quality sensor).
Context: Battery life calculation for Sigfox water tank monitoring (18 messages/day).
Energy per message (triple transmission): \[E_{\text{msg}} = 40\,\text{mA} \times (3 \times 2\,\text{s}) / 3600\,\text{s/h} = 0.067\,\text{mAh}\]
Daily transmission energy: \[E_{\text{daily,tx}} = 18 \times 0.067 = 1.2\,\text{mAh}\]
Sleep energy (assuming 1 µA): \[E_{\text{daily,sleep}} = 0.001\,\text{mA} \times 24\,\text{h} = 0.024\,\text{mAh}\]
Total daily consumption: \[E_{\text{total}} = 1.2 + 0.024 = 1.224\,\text{mAh/day}\]
Worked example with 6,000 mAh battery (2× AA lithium): \[\text{Battery life} = \frac{6000\,\text{mAh}}{1.224\,\text{mAh/day}} = 4,902\,\text{days} = 13.4\,\text{years}\]
To meet 10-year requirement with safety margin, use D-cell lithium (19,000 mAh) for 42-year theoretical life, or reduce to 10 messages/day for 16-year life with AA cells.
| Parameter | Value |
|---|---|
| TX current | 40 mA |
| TX duration per message | 3 x 2 s (triple TX) = 6 s |
| Energy per message | 40 mA x 6 s / 3600 = 0.067 mAh |
| Daily energy (18 msgs) | 18 x 0.067 = 1.2 mAh |
| Sleep current | 1 uA = 0.001 mA |
| Daily sleep energy | 0.001 mA x 24 h = 0.024 mAh |
| Total daily energy | 1.224 mAh |
| Battery capacity (2x AA lithium) | 6,000 mAh |
| Estimated life | 6,000 / 1.224 = 4,902 days = 13.4 years |
The 13.4-year estimate exceeds the 10-year requirement with good margin. To add safety margin (accounting for battery self-discharge and temperature effects):
| Cost Item | Per Device | Fleet (5,000) |
|---|---|---|
| Sigfox module + MCU | $15 | $75,000 |
| Annual subscription ($2/device) | $20 (10 yr) | $100,000 |
| D-cell lithium battery | $8 | $40,000 |
| Enclosure + installation | $25 | $125,000 |
| Total (10-year TCO) | $68 | $340,000 |
Conclusion: Sigfox is an excellent fit for this use case. The message budget is comfortable, the payload fits easily, and the total cost of ownership is very low at $68 per device over 10 years ($0.57/device/month).
Test your understanding of Sigfox fundamentals before diving into the detailed chapters.
The Mistake: Engineers design Sigfox applications assuming they must handle worst-case message rates every single day, leading them to incorrectly reject Sigfox for applications that would actually work fine.
Example Scenario: Smart agriculture soil moisture sensor design:
Flawed Calculation:
Correct Approach:
The Insight: Sigfox’s 140 message/day limit is a daily budget, not a sustained rate requirement. Applications with burst patterns (most real-world IoT) can use Sigfox effectively by:
Real-World Example: Parking Sensor Fleet (10,000 sensors)
| Scenario | Messages/Sensor/Day | Days/Year | Total Messages/Year |
|---|---|---|---|
| Typical weekday | 8-12 (office hours) | 250 | 2.5M |
| Weekend | 2-3 (low activity) | 104 | 0.26M |
| Holiday | 0-1 (closed) | 11 | 0.01M |
| Annual average | 7.5 messages/day | 365 | 27.4M total |
At 7.5 messages/day average, fleet operates at 5.4% of Sigfox capacity with room for 20x growth.
The Anti-Pattern That Wastes Money:
Choosing NB-IoT ($36/year/device for SIM and data plan) over Sigfox ($2/year/device subscription) because of a worst-case scenario that occurs 5% of the time costs an extra $34,000/year on 1,000 devices. The correct solution is: use Sigfox with firmware logic that reduces reporting frequency when approaching daily limit (e.g., if 120 messages sent by 6pm, switch from 15-min to 30-min intervals for remainder of day).
Best Practice: Calculate your median daily message count and 95th percentile, not worst case. If 95th percentile <100 messages/day, Sigfox is safe. If >120/day, evaluate alternatives.
Sigfox is both a technology and an operator. Unlike LoRaWAN (which you can deploy privately), Sigfox provides end-to-end managed connectivity. You buy a module, pay a subscription, and Sigfox handles the network.
Ultra-Narrow Band (UNB) enables extreme range and low power. By squeezing each transmission into a 100 Hz channel (compared to 125 kHz for LoRaWAN), Sigfox achieves superior link budget and can reach devices up to 50 km away in rural environments.
Strict message constraints define the use case. The 140-uplink / 4-downlink daily limit and 12-byte payload are non-negotiable. Always calculate your exact daily message count and payload size before selecting Sigfox.
Binary payload encoding is mandatory. With only 12 bytes per message, JSON or text encoding is impossible. Efficient bit-packing is essential for any Sigfox application.
Triple-transmission provides reliability without ACKs. Each message is sent three times on random frequencies, eliminating the need for energy-expensive acknowledgement handshakes while maintaining high delivery rates.
Lowest per-device cost in LPWAN. At $1-14 per device per year with no gateway infrastructure to purchase or maintain, Sigfox offers the most cost-effective connectivity for simple, high-volume IoT deployments.
Operator dependency is a real risk. Sigfox’s centralized operator model means coverage depends on the company’s continued operation in your region. Always have a migration plan.
Start your Sigfox learning journey with the Overview chapter, or jump directly to any chapter that matches your current learning needs.
| Direction | Chapter | Description |
|---|---|---|
| Next | Sigfox Overview | Technology foundations and ultra-narrow band modulation |
| Next | Sigfox Message Flow | Uplink, downlink, and message constraints |
| Next | Sigfox Deployment | Planning and implementing Sigfox solutions |
| Related | NB-IoT Fundamentals | Cellular-based LPWAN for licensed spectrum deployments |
| Related | LoRaWAN Comprehensive Review | Deep comparison with Sigfox’s main competitor |
| Related | MQTT Fundamentals | Application layer protocols for IoT data transport |