By the end of this chapter, you will be able to:
Sigfox excels at specific IoT use cases: tracking shipping containers across oceans, monitoring water meters in cities, detecting when a parking spot is occupied, and alerting when a freezer temperature rises. This analysis helps you identify when Sigfox is the ideal solution versus when another technology might be better.
“Choosing the right LPWAN is like choosing the right vehicle,” Sammy the Sensor explained. “Sigfox is a bicycle – simple, cheap, and efficient for short errands. LoRaWAN is a car – more capable, costs more upfront, but you own it. NB-IoT is a taxi – powerful and convenient, but you pay per ride. You would not take a bicycle on the highway, and you would not take a taxi to check the mailbox!”
“Let me give you the checklist,” Lila the LED offered. “Does your data fit in 12 bytes? Do you send fewer than 140 messages per day? Is Sigfox coverage available? Do you have fewer than 5,000 devices? Do you NOT need frequent commands sent to the device? If you answered yes to all five, Sigfox is probably your best bet – cheapest, simplest, longest battery life.”
Max the Microcontroller ran the numbers. “For a smart agriculture project with 1,000 soil sensors reporting every 4 hours, Sigfox is perfect. Payload: 10 bytes – fits! Messages: 6 per day – only 4.3% of quota. Range: 30-50 km rural – covers the whole farm. Battery life: 12.9 years. Cost: $6 per device per year. Every requirement is met with huge margins.”
“But know when to walk away,” Bella the Battery cautioned. “If you need more than 12 bytes, real-time alerts with under 5-second latency, frequent commands to your devices, or coverage in areas without Sigfox towers – those are dealbreakers. Do not try to force Sigfox into a use case it was not designed for. Choose the technology that matches your requirements, not just the cheapest one.”
Required Chapters:
Sigfox Key Parameters:
| Parameter | Uplink | Downlink |
|---|---|---|
| Messages/day | 140 | 4 |
| Payload | 12 bytes | 8 bytes |
| Data Rate | 100 bps | 600 bps |
| TX Duration | ~6 seconds (3 transmissions) | ~1 second (but 20-25s RX window) |
Estimated Time: 25 minutes
This chart shows a typical daily message budget allocation: with 140 uplinks/day, devices can send 24 hourly readings, 4 status updates, reserve 12 for alerts, and still have 100 messages as buffer.
The Mistake: Designing applications that consume exactly 140 messages per day, leaving no buffer for alerts, retransmissions, or edge cases.
Why It Happens: Developers calculate message requirements mathematically without accounting for real-world variability:
Flawed calculation:
- 140 messages/day / 24 hours = 5.83 messages/hour
- "I'll send a reading every 10 minutes = 144 messages/day"
- "Close enough to 140, it should work!"
What actually happens:
- Day 1: 144 messages attempted, 4 rejected after hitting daily limit
- Missing readings: 4 PM, 4:10 PM, 4:20 PM, 4:30 PM (end of day)
- Critical alert at 4:15 PM -> CANNOT SEND (quota exhausted)
- System blind during most important monitoring periodThe Fix: Design for 70-80% quota utilization, reserving capacity for exceptions:
Robust message budget (140 total):
- Scheduled readings: 100 messages (71% of quota)
-> Every 15 minutes = 96/day, leaving 44 spare
- Alert reserve: 20 messages (14% of quota)
-> For threshold violations, status changes
- Buffer: 20 messages (14% of quota)
-> For clock drift, edge cases, debugging
Practical implementation:
1. Track message count in firmware (reset at midnight UTC)
2. If count > 100: Switch to hourly readings (non-critical)
3. If count > 120: Only send critical alerts
4. If count > 135: Emergency-only modeThe Mistake: Designing control logic that expects downlink responses within seconds, like HTTP request/response patterns.
Why It Happens: Developers familiar with REST APIs or WebSockets expect synchronous communication:
Incorrect mental model:
Device: "Send sensor data + request downlink"
Cloud: "Receive data -> process -> send command"
Device: "Receive command -> execute"
Expected latency: 1-2 seconds (like HTTP)
Sigfox reality:
Device: "Send uplink at T=0"
Device: "Stay in RX mode for 20-25 seconds"
Cloud: "Process -> queue downlink -> schedule transmission"
Base Station: "Transmit downlink at T=20 seconds"
Device: "Receive downlink at T=20-25 seconds"
Actual latency: 20-25 seconds minimum!
Worse case:
- Device sends uplink without downlink flag
- Cloud decides it needs to send command
- Must wait for NEXT uplink with downlink flag
- Latency: Hours or days depending on uplink frequency!The Fix: Design for asynchronous, high-latency downlink communication: 1. Downlink flag strategy: Only set downlink flag when device specifically needs configuration (e.g., after reboot, daily config check) 2. Command queuing: Backend queues commands until device requests downlink 3. Polling interval: Include “check for commands” uplink once per day with downlink flag 4. Timeout design: Application must tolerate 24+ hour command latency 5. Use case validation: If you need sub-minute control latency, Sigfox is the wrong technology–use LoRaWAN Class C or NB-IoT instead 6. Downlink budget: Remember only 4 downlinks/day–schedule wisely (e.g., at midnight for next day’s configuration)
Scenario: AgriTech startup wants to monitor soil conditions across 1,000 fields (average 5 hectares each, spread 40 km radius from town center).
Sensor Requirements:
Evaluating Sigfox Fit:
Payload analysis: 10 bytes needed, Sigfox allows 12 bytes uplink. Fits perfectly with 2 bytes spare for future sensors.
Message frequency: 6 messages/day needed, Sigfox allows 140 messages/day. Using only 4.3% of daily quota (spare capacity: 134 messages for alerts).
Range: Fields span 40 km radius. Sigfox rural range: 30-50 km. Single base station covers entire deployment (pi x 40^2 = 5,027 km^2 coverage).
When calculating Sigfox coverage area, the effective range determines the circular coverage footprint:
\[ A_{\text{coverage}} = \pi r^2 \]
For a rural Sigfox base station with 40 km range: \[ A_{\text{coverage}} = \pi (40)^2 = 5{,}027 \text{ km}^2 \]
Real-world example: A farm spanning 200 km² (14 km × 14 km) requires just one base station at the center (14 km diagonal < 40 km radius). Compare with cellular IoT: 4G LTE-M rural range ~10 km would need 20+ towers to cover the same area, at $25k+ per tower vs. Sigfox’s $15k single installation.
Battery life calculation:
Sigfox TX: 40 mA x 6 sec = 0.067 mAh per message
Daily energy: 6 msg x 0.067 mAh = 0.4 mAh/day
Sleep: 1 uA x 24h = 0.024 mAh/day
Total: 0.424 mAh/day
With 2000 mAh battery: 2000 / 0.424 = 4,717 days = 12.9 yearsCost: 1,000 devices x $6/year subscription = $6,000/year (under $10k budget).
Sigfox is ideal for this use case!
Detailed Suitability Analysis:
| Requirement | Sigfox Capability | Match? |
|---|---|---|
| Payload size | 10 bytes (limit: 12) | YES |
| Message frequency | 6/day (limit: 140) | YES |
| Range | 30-50 km rural | YES |
| Battery life | 12+ years | YES |
| Cost | $6/device/year | YES |
| Deployment | No infrastructure | YES |
| Coverage | Operator network | YES |
7/7 requirements met perfectly!
When Sigfox Would NOT Work:
| Scenario | Reason | Alternative |
|---|---|---|
| 15-byte payloads | Exceeds 12-byte limit | LoRaWAN (243 bytes) |
| 200 messages/day | Exceeds 140 limit | LoRaWAN |
| Frequent commands | Limited to 4 downlinks/day | LoRaWAN or NB-IoT |
| Real-time critical | Fire-and-forget, no ACK | NB-IoT or LTE-M |
| No coverage | Remote regions | Private LoRaWAN |
## Cost Analysis: 5-Year TCO {#net-sigfox-cost-analysis}
Scenario: 1,000 Soil Sensors
Sigfox Deployment:
Hardware: 1000 x $10 = $10,000
Subscription: 1000 x $6/year x 5 = $30,000
Total: $40,000LoRaWAN Alternative:
Hardware: 1000 x $15 = $15,000
Gateways: 20 x $1,500 = $30,000 (rural coverage)
Network server: $300/month x 60 = $18,000
Gateway connectivity: 20 x $30/month x 60 = $36,000
Total: $99,000Result: Sigfox saves $59,000 (60% less expensive) for this application profile.
Example Output:
### Scenario 1: Environmental Sensor (Hourly Reports) ###
================================================================================
Sigfox Deployment Analysis
================================================================================
Device Configuration:
Payload Size: 10 bytes
Messages per Day: 24
TX Current: 40 mA
Sleep Current: 1 uA
Battery: 2000 mAh
Constraint Validation:
Payload valid (10 <= 12 bytes)
Messages valid (24 <= 140/day)
Battery Life Analysis:
Estimated Life: 11.6 years
Daily Energy: 472.0 uAh
- TX Energy: 448.0 uAh (94.9%)
- Sleep Energy: 24.0 uAh (5.1%)
TX Time: 0.167% of time
Feasible (>1 year battery life)
Optimization:
For 10-year battery life: 27 messages/day maximum
Optimal interval: 53.3 minutes
================================================================================Example Output:
================================================================================
Sigfox Payload Optimization Examples
================================================================================
### Example 1: Naive Approach (Wasteful) ###
Using float32 (4 bytes each) for all sensors:
Total: 3 sensors x 4 bytes = 12 bytes (100% utilization)
Can only fit 3 sensors!
### Example 2: Optimized Approach ###
Using scaled integers with appropriate precision:
Payload Analysis:
Readings: 5
Payload Size: 8 bytes
Max Size: 12 bytes
Utilization: 66.7%
Remaining: 4 bytes
Hex: 00e14186031701c2
Breakdown:
temp: 22.5 -> 2 bytes (int16, offset 0)
humidity: 65.0 -> 1 byte (uint8, offset 2)
pressure: 1013.25 -> 2 bytes (uint16, offset 3)
battery: 3.7 -> 1 byte (uint8, offset 5)
light: 450 -> 2 bytes (uint16, offset 6)
Fit 5 sensors in 8 bytes!
4 bytes remaining for flags or additional sensors
### Example 3: Adding Flags with Bitfield ###
Flags: motion_detected=True, door_open=False, tamper_alert=False,
low_battery=True, maintenance_needed=False
Packed: 0x09 (binary: 00001001)
Size: 1 byte (5 boolean values!)
Total: 5 sensors + 5 flags = 9 bytes
Still 3 bytes remaining!
================================================================================Best Applications for Sigfox:
| Application | Why Ideal |
|---|---|
| Smart metering (water, gas) | Infrequent readings, small data |
| Infrequent asset tracking | Daily/hourly location updates |
| Environmental sensors | Agriculture, weather stations |
| Smart city infrastructure | Waste bins, parking, lighting |
| Utility monitoring | < 100 messages/day, small payloads |
When to Choose Sigfox:
Scenario: 1,000 soil sensors report every 4 hours. Calculate if Sigfox message limits are acceptable.
Given:
Calculation:
Per-Device Analysis:
Messages per day: 24 hours / 4 hours = 6 messages
Sigfox limit: 140 messages/day
Utilization: 6 / 140 = 4.3%
Spare capacity: 140 - 6 = 134 messages/dayNetwork-Wide Analysis:
Total messages per day: 1,000 sensors × 6 messages = 6,000 messages/day
Total Sigfox capacity: 1,000 sensors × 140 messages = 140,000 messages/day
Network utilization: 6,000 / 140,000 = 4.3%Alert Budget Allocation: Design for unexpected events (e.g., soil too dry triggers extra alerts):
Normal operation: 6 messages/day (4.3% utilization)
Reserved for alerts: 20 messages/day (14.3% utilization)
Buffer for debugging: 14 messages/day (10% utilization)
Total planned: 40 messages/day (28.6% utilization)
Safety margin: 140 - 40 = 100 messages/day (71.4% buffer)Firmware Implementation:
#define NORMAL_INTERVAL_MS (4 * 60 * 60 * 1000) // 4 hours
#define ALERT_INTERVAL_MS (30 * 60 * 1000) // 30 minutes
void loop() {
int messageCount = getMessagesTodayCount();
// Safety check: never exceed daily limit
if (messageCount >= 135) { // Leave 5-message buffer
Serial.println("Daily message limit approaching - sleeping");
deepSleep(NORMAL_INTERVAL_MS);
return;
}
float moisture = readSoilMoisture();
bool isDry = (moisture < 20.0); // Alert threshold
// Determine next interval
unsigned long nextInterval;
if (isDry && messageCount < 26) { // Allow up to 20 alert messages
nextInterval = ALERT_INTERVAL_MS; // Send every 30 min when dry
Serial.println("ALERT mode: dry soil");
} else {
nextInterval = NORMAL_INTERVAL_MS; // Normal 4-hour interval
}
sendSigfoxMessage(moisture);
deepSleep(nextInterval);
}Cost Analysis (5-year deployment):
Sigfox subscription: 1,000 sensors × $6/year × 5 years = $30,000
Hardware: 1,000 × $10 = $10,000
Total 5-year TCO: $40,000
Alternative (LoRaWAN):
Hardware: 1,000 × $15 = $15,000
Gateways: 20 × $1,500 = $30,000 (rural coverage)
Network server: $300/month × 60 months = $18,000
Gateway connectivity: 20 × $30/month × 60 months = $36,000
Total: $99,000
Sigfox saves: $99,000 - $40,000 = $59,000 (60% cheaper)Conclusion:
Use this decision matrix to determine if your application will hit Sigfox constraints.
| Application Type | Typical Msg/Day | Payload Size | Sigfox Fit | Recommendation |
|---|---|---|---|---|
| Utility Meter (water/gas) | 1-4 | 4-8 bytes | ✓✓✓ Excellent | Use Sigfox |
| Soil Moisture (agriculture) | 6-12 | 8-12 bytes | ✓✓✓ Excellent | Use Sigfox |
| Asset Tracker (daily GPS) | 4-24 | 8-12 bytes | ✓✓ Good | Use Sigfox |
| Parking Sensor | 10-50 | 4-6 bytes | ✓ Acceptable | Use Sigfox if <50 msg/day |
| Environmental Monitor | 144 | 10 bytes | ⚠️ At limit | Redesign: reduce to hourly (24 msg/day) |
| Industrial Vibration | 1440 | 1024 bytes | ✗ Impossible | Use LoRaWAN or NB-IoT |
| Real-time Control | Continuous | Variable | ✗ Impossible | Use LoRaWAN Class C or LTE |
Red Flags (Sigfox is Wrong Choice):
⚠️ WARNING: Consider alternatives if ANY of these apply:
❌ Messages needed: >100/day per device
→ Impact: Exceeds 140/day limit with no safety margin
→ Solution: Use LoRaWAN (unlimited messages)
❌ Payload needed: >12 bytes
→ Impact: Cannot fit data in Sigfox uplink
→ Solution: Use LoRaWAN (up to 243 bytes) or NB-IoT (up to 1600 bytes)
❌ Downlink commands: >4/day
→ Impact: Exceeds Sigfox downlink limit
→ Solution: Use LoRaWAN (downlink after every uplink)
❌ Real-time latency: <5 seconds required
→ Impact: Sigfox latency is 30-90 seconds
→ Solution: Use NB-IoT or LTE-M
❌ Coverage unavailable in deployment area
→ Impact: Devices won't connect at all
→ Solution: Verify coverage FIRST, or use LoRaWAN (you deploy gateways)Green Lights (Sigfox is Perfect):
✓ IDEAL USE CASE: All of these apply:
✓ Messages needed: <50/day per device
✓ Payload size: <12 bytes
✓ Downlink rarely needed (<4/day)
✓ Battery life critical (>10 years required)
✓ Sigfox coverage exists in deployment area
✓ Small-medium deployment (<5,000 devices)
✓ Uplink-only acceptable (sensors, not actuators)
✓ Cost-sensitive ($1-2/device/year budget)Decision Tree:
Calculate your message frequency:
Messages/day = (24 hours × 60 minutes) / Interval_minutes
Examples:
Every 10 minutes: 144 messages/day ✗ EXCEEDS limit
Every 15 minutes: 96 messages/day ✓ OK (68% utilization)
Every 30 minutes: 48 messages/day ✓ OK (34% utilization)
Every 1 hour: 24 messages/day ✓✓ GOOD (17% utilization)
Every 4 hours: 6 messages/day ✓✓✓ EXCELLENT (4% utilization)
IF messages/day > 100:
→ Sigfox is wrong choice
→ Redesign interval OR choose LoRaWAN
IF messages/day = 70-100:
→ Sigfox marginal (no room for alerts)
→ Consider LoRaWAN for safety margin
IF messages/day < 70:
→ Sigfox viable (check other constraints)The Mistake: Developer calculates “average messages per day” but doesn’t account for peak events, alerts, or debugging needs.
Real-World Failure:
Building HVAC Monitor (200 units):
Initial Design:
Normal operation: Temperature reading every 30 minutes
Messages/day: 24 hours / 0.5 hours = 48 messages/day
Utilization: 48 / 140 = 34%
Developer conclusion: "Plenty of headroom!"What Actually Happened:
Month 1-3 (Normal):
Month 4 (Summer Heatwave):
The Root Causes:
The Fix:
1. Design for Peak Load:
// Bad: Alert mode with no limit
if (temp > 28.0) {
sendEveryMinutes = 5; // 288 messages/day - EXCEEDS LIMIT!
}
// Good: Alert mode with daily budget
if (temp > 28.0 && messagesToday < 100) {
sendEveryMinutes = 10; // 144 msg/day max, but throttle at 100
} else if (messagesToday < 120) {
sendEveryMinutes = 30; // Graceful degradation
} else {
sendEveryMinutes = 60; // Conservative mode to avoid cutoff
}2. Implement Message Budget Tracking:
#define MAX_MESSAGES_PER_DAY 120 // Leave 20-message buffer
void loop() {
// Check message count before sending
int msgCount = getMessagesLastInterval(24 * 3600); // Last 24 hours
if (msgCount >= MAX_MESSAGES_PER_DAY) {
Serial.println("Daily quota reached - entering low-frequency mode");
sendEveryMinutes = 120; // Send once every 2 hours
deepSleep(120 * 60 * 1000);
return;
}
// Normal sending logic...
}3. Graduated Response Strategy:
Message Budget Allocation (140 total):
- Normal operation: 48 messages (34%)
- Alert budget: 40 messages (29%)
- Debug/commissioning: 20 messages (14%)
- Safety buffer: 32 messages (23%)
Alert Throttling Rules:
- If temp > 28°C and msgCount < 70:
Send every 10 min (up to 40 extra alerts)
- If temp > 28°C and msgCount >= 70:
Send every 30 min (graceful degradation)
- If msgCount > 120:
Send hourly only (preserve visibility)4. Cloud-Side Monitoring:
# Alert when device approaches quota
def check_message_quota(device_id):
last_24h = get_message_count(device_id, hours=24)
if last_24h > 120:
send_alert(f"Device {device_id} used {last_24h}/140 messages (86%)")
if last_24h >= 140:
send_critical_alert(f"Device {device_id} HIT QUOTA - may go silent!")Revised Design:
Peak load scenario: 15% of devices in alert mode simultaneously
Normal devices (170): 48 msg/day each = 8,160 messages
Alert devices (30): 100 msg/day each (throttled) = 3,000 messages
Total network load: 11,160 messages/day
Total capacity: 200 × 140 = 28,000 messages/day
Peak utilization: 40% (safe)
Individual device budget:
Normal: 48 msg/day (34% utilization)
Alert (throttled): 100 msg/day (71% utilization)
Safety buffer: 40 messages for debugging
Result: System handles heatwave without going silent ✓Key Lessons:
The city of Barcelona deployed ultrasonic fill-level sensors in 2,300 public waste bins to optimize collection routes. This is widely regarded as one of Sigfox’s strongest use cases. Here is why the constraints align perfectly.
Why the Constraints Do Not Matter Here:
| Sigfox Constraint | Waste Bin Requirement | Fit |
|---|---|---|
| 12-byte payload limit | Fill level (1 byte, 0-100%) + battery voltage (1 byte) + temperature (1 byte) + tilt angle (1 byte) = 4 bytes | Uses only 33% of capacity |
| 140 messages/day | Report every 30 minutes during active hours (6 AM - 10 PM) = 32 messages/day | Uses only 23% of allowance |
| No downlink (practically) | Sensors are passive reporters – no commands needed | Downlink not required |
| No firmware updates OTA | Sensor firmware is simple and stable (ultrasonic range + battery monitor) | Firmware rarely changes |
| Single operator dependency | Municipal contract can absorb operator risk (city budget, not startup) | Acceptable risk profile |
Quantified Results After 18 Months:
Why Not LoRaWAN?
Barcelona had existing Sigfox coverage (deployed by the Spanish operator). A LoRaWAN deployment would have required:
The Sigfox approach cost EUR 1.20/device/year with zero infrastructure to manage. For a municipal government without IoT engineering staff, the managed network model was the decisive factor.
When This Logic Breaks Down:
If Barcelona wanted to add GPS tracking to collection trucks, camera-based contamination detection, or real-time route optimization with sub-minute updates, Sigfox would be insufficient. The lesson: Sigfox excels when the application genuinely needs only small, infrequent, uplink-only data – and waste monitoring is the textbook example.
Understanding how Sigfox use case analysis concepts interconnect:
| Concept | Depends On | Enables | Common Confusion |
|---|---|---|---|
| Message Budget Calculation | Daily message limit (140), application interval | Battery life estimation, cost analysis | Confusing uplink (140) with downlink (4) limits |
| Payload Optimization | 12-byte uplink limit, sensor data precision | Fitting multiple sensors in one message | Thinking 12 bytes means 12 sensors (type encoding matters) |
| Battery Life Estimation | TX current, message frequency, sleep current | Multi-year deployment feasibility | Forgetting to include sleep current in calculation |
| TCO Comparison | Device cost, subscription fees, infrastructure requirements | Technology selection decisions | Comparing only device cost, ignoring infrastructure |
| Suitability Framework | Message limits, payload size, coverage, latency tolerance | Use case go/no-go decisions | Designing to exactly 140 messages with no buffer |
| Downlink Strategy | 4 downlink/day limit, 20-25 second latency | Configuration updates, rare commands | Expecting real-time command-response like HTTP |
Key Dependencies:
Critical Insight: Sigfox use case analysis is elimination-based. Start with hard constraints (payload size, message frequency, coverage availability) before analyzing soft factors like cost. One violated constraint disqualifies Sigfox regardless of other advantages.
Related LPWAN Technologies:
Sigfox Technical Deep Dives:
Design and Deployment:
Exercise 1: Message Budget Calculator
Given a deployment scenario, calculate if Sigfox message limits are acceptable:
Scenario: 500 parking sensors, each reporting state changes (occupied/vacant). Average vehicle parks for 2 hours. Parking lot has 40% turnover rate per day.
Tasks:
What to Observe:
Exercise 2: Payload Optimization Challenge
Fit the following sensor data into Sigfox’s 12-byte uplink limit:
Sensors:
Tasks:
What to Observe:
Optimized solution: 2+2+2+1+2+1+2 = 12 bytes exactly! Use reduced precision for moisture/humidity (uint8) and log-scale light encoding (uint16).
Exercise 3: Battery Life Estimation
Calculate battery life for a Sigfox soil sensor:
Given:
Tasks:
What to Observe:
Sigfox suitability depends on matching application requirements to protocol constraints:
| Chapter | Description |
|---|---|
| Sigfox Device Management | Firmware updates and downlink challenges in practice |
| Sigfox Operator Risks | Infrastructure dependency and business continuity analysis |
| Sigfox Worked Examples | Practical calculations for message budgets and link budgets |
| LoRaWAN Overview | Alternative LPWAN technology with no message limits |
| LPWAN Comparison | Side-by-side comparison of Sigfox, LoRaWAN, and NB-IoT |