38 Sigfox Introduction and Basics
38.1 Introduction
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.
By the end of this chapter, you will be able to:
- Explain how Sigfox’s ultra-narrow band (UNB) modulation achieves long range with 100 Hz channels
- Describe the Sigfox operator-managed network architecture and its business model trade-offs
- Contrast Sigfox with LoRaWAN across deployment cost, coverage, and payload constraints
- Evaluate Sigfox suitability for specific IoT applications based on message limits and latency
- Design efficient 12-byte payloads using integer encoding within the 140 message/day constraint
Key Concepts
- Sigfox: Proprietary LPWAN technology using ultra-narrowband modulation; founded in France in 2010, provides network as a service model for IoT connectivity.
- Ultra-Narrowband (UNB) Modulation: Sigfox’s physical layer using 100 Hz channel width; achieves high sensitivity through extreme spectral efficiency.
- Network-as-a-Service: Sigfox’s original business model providing fully managed IoT connectivity eliminating need for customer-deployed infrastructure.
- Bidirectional Communication: Sigfox supports both uplinks (device to cloud) and downlinks (cloud to device); downlinks are severely limited to 4 per day maximum.
- Device Autonomy: Sigfox devices select random frequencies from 200 kHz band and transmit 3 times per message for redundancy; no prior synchronization required.
- Sigfox Ecosystem: Hardware partners (Sigfox-certified modules from various vendors), network operators (SNOs in 70+ countries), and platform integrations.
- Historical Context: Sigfox pioneered LPWAN commercialization before LoRaWAN and NB-IoT matured; company restructuring in 2022 affected long-term network commitments.
In one sentence: Sigfox is an ultra-low-power, operator-managed LPWAN that sends tiny messages (12 bytes) over extreme distances with no local infrastructure required.
Remember this rule: Choose Sigfox over LoRaWAN when you need global coverage without building infrastructure, only send small infrequent messages (<140/day), and can accept the operator’s coverage footprint; choose LoRaWAN when you need network control, larger payloads, or coverage in areas Sigfox doesn’t reach.
38.2 Prerequisites
Before diving into this chapter, you should be familiar with:
LPWAN Fundamentals: Understanding low-power wide-area network characteristics and trade-offs provides essential context for Sigfox’s design decisions and positioning
Networking Basics: Familiarity with wireless communication concepts, modulation schemes, and network topologies helps you understand Sigfox’s ultra-narrow band technology
LoRaWAN Fundamentals: Knowledge of alternative LPWAN technologies like LoRaWAN enables meaningful comparisons of deployment models, message limits, and coverage approaches
Wireless Sensor Networks: Understanding battery-powered sensor constraints and long-range communication needs explains why Sigfox targets specific IoT use cases
“Sigfox is the simplest LPWAN out there!” Sammy the Sensor said. “Unlike LoRaWAN where you set up your own gateways, Sigfox is a ready-made network. You just buy a Sigfox-enabled device, subscribe to the service, and start sending data. The network is already built and covers over 70 countries!”
“The trade-off is flexibility,” Lila the LED explained. “Sigfox limits you to 140 messages per day with only 12 bytes each. That is enough for ‘temperature is 25 degrees’ but not for a video feed. Think of it as a telegram service – short messages, long distances, very cheap.”
Max the Microcontroller added, “Sigfox’s Ultra-Narrow Band technology is fascinating. Each message uses just 100 Hz of bandwidth at 100 bits per second. That extreme narrowness gives incredible range and receiver sensitivity. The downside is the very low data rate, but for simple IoT sensors, that is perfectly fine.”
“What I love is the device simplicity,” Bella the Battery said. “A Sigfox radio module costs just a few dollars and uses minimal power. Combined with the 140-message daily limit, this means I can last ten or more years on a single battery. For simple monitoring applications like parking sensors and water leak detectors, Sigfox is an excellent choice!”
38.3 Getting Started (For Beginners)
38.3.1 What is Sigfox? (Simple Explanation)
Analogy: Think of Sigfox like a telegram service for IoT - tiny messages sent over huge distances, ultra-reliable, and incredibly cheap.
REGULAR CELLULAR (4G/5G) SIGFOX
━━━━━━━━━━━━━━━━━━━━━━ ━━━━━━
📱 → 📶 → 🌐 📟 → 📶 → ☁️
• Send texts, calls, video • Send tiny messages (12 bytes)
• High data, high cost • Very low data, very low cost
• Monthly subscription • $1-2/device/year
• Need SIM card • Simple radio chip
Like comparing:
📧 Email (any size, any time) ✉️ Postcard (small, limited)Key Terms Explained:
| Term | Simple Explanation |
|---|---|
| UNB (Ultra Narrow Band) | Radio signal squeezed into extremely thin channel - like using a laser pointer vs flashlight |
| Uplink | Message from device to cloud (140 messages/day allowed) |
| Downlink | Message from cloud to device (only 4 messages/day - very limited!) |
| Base Station | Sigfox tower that receives messages - you don’t build these, Sigfox does |
Why This Matters:
- Coverage in 75+ countries without you building a single tower
- Simplest LPWAN deployment - just buy devices and they work (if coverage exists)
- 10-20 year battery life means “install and forget”
38.3.2 What Makes Sigfox Different from LoRaWAN?
| Feature | Sigfox | LoRaWAN |
|---|---|---|
| Network ownership | Sigfox operates it (like AT&T) | You can build your own |
| Messages per day | Limited to 140 uplink | Unlimited (fair use) |
| Downlink messages | Only 4/day | Varies by device class |
| Coverage | 75+ countries (they build towers) | You choose coverage |
| Payload size | 12 bytes max | Up to 242 bytes |
| Cost model | Pay per device/year | Pay for infrastructure |
| Range | 10-50 km (rural), 3-10 km (urban) | 2-15 km (similar) |
| Power | 10-20 year battery life | 5-15 year battery life |
38.3.3 When to Use Sigfox
Source: Stanford University IoT Course - This diagram illustrates the evolution of precision agriculture and how LPWAN technologies like Sigfox enable the “Future” scenario where distributed sensors (weather stations, plant sensors, UAVs) communicate over long ranges to provide integrated data insights. Sigfox’s 10-50 km range and 10+ year battery life make it ideal for agricultural deployments where sensors are spread across large farms.
Perfect for:
- Asset tracking (where is my shipping container?)
- Simple sensors (parking spot occupied? yes/no)
- Utility meters (monthly water reading)
- Environmental monitoring (temperature once per hour)
- Global deployments (single subscription works across countries)
NOT suitable for:
- Real-time control (too slow, limited downlinks)
- Large data (12-byte limit)
- Frequent updates (140/day max)
- Private networks (you can’t run your own Sigfox)
- Areas without Sigfox coverage (operator dependency)
38.3.4 The 12-Byte Challenge
Sigfox messages are tiny—only 12 bytes! Here’s what you can fit:
12 BYTES = What Can You Send?
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
✅ Temperature + Humidity + Battery: 6 bytes
✅ GPS coordinates (lat/long): 8 bytes
✅ Door status + timestamp: 5 bytes
✅ Water meter reading: 4 bytes
❌ Photo: ~100,000 bytes (impossible!)
❌ Audio clip: ~50,000 bytes (impossible!)
❌ Detailed log: ~500 bytes (too big)Design Tip: You need to get creative with data encoding. Use integers instead of floats, pack multiple values into single bytes, send only changes (deltas) instead of absolute values.
38.3.5 Self-Check: Understanding the Basics
Before continuing, make sure you can answer:
- What is Sigfox’s main advantage? → Very low cost ($1-2/device/year), global coverage without building your own network, simplest deployment
- Why only 12 bytes? → Ultra-narrow band modulation (100 Hz channels) trades data size for extreme range and low power
- When would you choose Sigfox over LoRaWAN? → When you want global coverage without infrastructure investment, only need tiny infrequent messages, and have operator coverage in your area
- What’s the downlink limitation? → Only 4 downlink messages per day per device - mostly one-way communication, use sparingly
38.4 In Plain English: Sigfox Explained
Imagine you’re traveling the world and want to update your family about your location:
Email (like Wi-Fi/Cellular):
- Send long messages with photos and videos
- Requires finding Wi-Fi or buying expensive data plans
- Battery drains quickly from constant connectivity
- Can send unlimited messages anytime
Postcard (like Sigfox):
- Write a tiny message: “Arrived Paris. Weather nice. -John”
- Works everywhere (global postal system)
- Extremely cheap ($1-2 per year unlimited)
- Limited space (12 bytes = ~12 characters)
- Can only send 140 postcards per day
- Takes time to deliver (not instant)
Key Insight: Sigfox trades message size and frequency for extreme affordability and simplicity. It’s designed for devices that say “I’m here” or “Temperature: 72°F” - not devices having conversations.
Real-World Translation:
Wi-Fi Smart Home: Sigfox Smart Sensor:
───────────────── ───────────────────
🏠 "Camera uploading 4K video" 📟 "Door opened"
💰 $50/month broadband 💰 $1/year total
🔋 Plugged into wall power 🔋 10-year battery
📱 Send gigabytes anytime 📱 Send 12 bytes max, 140×/dayThe Genius: For most IoT sensors, you don’t NEED video quality - you just need to know “yes/no” or “current value.” Sigfox strips away everything except the essentials, making it dirt cheap and ultra-reliable.
38.5 Real-World Example: Concrete Numbers
The Challenge: Barcelona needed to monitor 20,000 trash bins across the city to optimize garbage truck routes and reduce fuel costs.
Traditional Approach (Cellular IoT):
Solution: NB-IoT with daily status reports
─────────────────────────────────────────
Cost per bin:
• Hardware: $30 (NB-IoT modem + sensor)
• Subscription: $5/month × 12 = $60/year
• Total 5-year cost: $30 + ($60 × 5) = $330 per bin
• City total: 20,000 bins × $330 = $6,600,000
Message capacity:
• Can send 500+ messages/day
• Each message up to 1600 bytes
• ...but bins only need 1 update/day!Sigfox Approach (What Barcelona Actually Chose):
Solution: Sigfox with daily fill-level updates
──────────────────────────────────────────────
Cost per bin:
• Hardware: $12 (Sigfox module + ultrasonic sensor)
• Subscription: $1/year (Sigfox annual fee)
• Total 5-year cost: $12 + ($1 × 5) = $17 per bin
• City total: 20,000 bins × $17 = $340,000
Message breakdown:
• Daily message: Fill level (1 byte) + GPS (6 bytes)
+ battery (1 byte) + bin ID (2 bytes)
+ timestamp (2 bytes) = 12 bytes ✓
• Frequency: 1 message/day = 30 messages/month
• Within limit: 140 messages/day max ✓✓
• Downlink use: Emergency requests only (4/day available)Results After 3 Years:
- Cost savings: $6.26M vs $340K = $5.92M saved (95% reduction)
- Fuel savings: 30% reduction in truck routes (optimized pickup)
- Efficiency: Bins emptied when 80%+ full (not on fixed schedule)
- Battery life: 8-10 years per sensor (no maintenance)
- Coverage: 99.7% message delivery rate in urban environment
Why Sigfox Was Perfect:
- Tiny payloads (12 bytes sufficient for “bin 45% full”)
- Infrequent updates (once per day, not real-time)
- Massive deployment (20,000 devices = subscription savings)
- Existing coverage (Sigfox already deployed in Barcelona)
- Long battery life (10+ years = minimal maintenance)
The Lesson: When your IoT application needs tiny messages sent infrequently across many devices, Sigfox can deliver 95% cost savings compared to cellular alternatives.
The Mistake: Designing a Sigfox-based system that requires immediate response to events (e.g., alarm systems, emergency alerts, real-time tracking).
Why This Fails:
Sigfox has inherent latency that makes it unsuitable for time-critical applications:
Latency Breakdown:
1. Device transmission: 2-6 seconds (UNB at 100 bps)
2. Triple redundancy: Messages sent 3× on different frequencies
3. Base station reception: 0-2 seconds (waiting for all 3 copies)
4. Backhaul to cloud: 5-15 seconds (base station → Sigfox backend)
5. Backend processing: 2-5 seconds (deduplication, geolocation)
6. Callback delivery: 1-5 seconds (HTTP POST to your server)
Typical end-to-end: 30-90 seconds
Worst case: 2-5 minutes (network congestion, retry logic)Real-World Failure Case:
A security company deployed Sigfox panic buttons in elderly care homes: - Expectation: Alert sent within 5 seconds of button press - Reality: 45-120 second delays from press to alert received - Outcome: Regulatory violation (emergency response systems require <10 sec) - Cost: $180,000 in recalled devices + $50,000 regulatory fine
Why Sigfox Has This Latency:
- Ultra-Narrow Band = Ultra-Slow: 100 Hz bandwidth = 100 bps data rate (vs. 50,000 bps for LoRaWAN)
- No Real-Time Protocol: Sigfox is “fire and forget” — device doesn’t wait for ACK
- Triple Transmission: Each message sent 3× on different frequencies for reliability, not speed
- Cloud Processing: All intelligence is server-side, adding round-trip delay
- No Quality of Service: Best-effort delivery with no prioritization
Latency Comparison:
| Technology | Typical Latency | Use Case Fit |
|---|---|---|
| Wi-Fi | <100 ms | Real-time control, video |
| Cellular (4G) | 50-200 ms | Mobile apps, voice calls |
| NB-IoT | 1-3 seconds | Smart meters, fleet tracking |
| LoRaWAN | 2-5 seconds | Building automation, alerts |
| Sigfox | 30-90 seconds | Periodic monitoring, non-urgent reporting |
Correct Application Design:
✓ Good Uses for Sigfox:
- Daily temperature reports from agriculture sensors
- Hourly tank level monitoring for refill scheduling
- Parking space occupancy (updates every 5 minutes)
- Monthly utility meter readings
- Soil moisture tracking (changes slowly over hours)
✗ Bad Uses for Sigfox:
- Fire alarms (need <5 second response)
- Panic buttons (need <10 second response)
- Vehicle tracking for theft recovery (need <30 second updates)
- Real-time asset monitoring (need continuous updates)
- Industrial process control (need <1 second loops)
Alternative Solutions for Time-Critical Applications:
- Use NB-IoT (1-3 sec latency):
- Cost: $2-5/device/month
- Best for: Emergency systems, mobile tracking
- Use LoRaWAN (2-5 sec latency):
- Cost: Gateway investment (~$500) + devices
- Best for: Building automation, local alerting
- Hybrid Approach (Sigfox + Local Response):
- Sigfox for monitoring → triggers local action
- Example: Smoke detector sends Sigfox alert BUT sounds local siren immediately
- Cost-effective for non-critical monitoring with local safety backup
Design Rule:
If your application completes this sentence… > “When event X happens, the system must respond within __ seconds”
…and the blank is less than 60 seconds, do NOT use Sigfox.
Use Sigfox for applications where you’d say: > “When event X happens, I want to know about it within the next hour”
Key Takeaway: Sigfox’s 30-90 second latency is a fundamental characteristic of Ultra-Narrow Band technology, not a bug or network issue. Design your application around this constraint from day one, or choose a different technology. Attempting to “optimize” Sigfox for real-time use will fail — the physics of 100 Hz bandwidth makes sub-10-second latency impossible.
38.6 How It Works: Sigfox End-to-End Message Flow
Understanding the complete journey of a Sigfox message helps clarify the operator-managed model:
Step 1: Device Wakes and Prepares (10-50 ms) The sensor wakes from sleep mode (1.5 μA), reads sensor value (temperature: 23.5°C), encodes to binary (2 bytes: 0x00EB = 235 → divide by 10 = 23.5°C), packs 12-byte payload with device ID, battery status, and timestamp.
Step 2: Triple Transmission (6 seconds) Device transmits the same 12-byte message three times on pseudo-random frequencies within 868 MHz band. Each transmission takes ~2 seconds at 100 bps. Frequency hopping (e.g., 868.130 MHz, 868.180 MHz, 868.220 MHz) provides diversity against narrow-band interference.
Step 3: Base Station Reception (0-3 seconds) Multiple base stations within 30-50 km range receive message copies. Stations perform no processing - just timestamp RSSI (signal strength) and forward raw data to Sigfox cloud via backhaul (3G/4G/fiber).
Step 4: Cloud Deduplication and Processing (5-15 seconds) Sigfox cloud receives 2-5 copies from different base stations, selects strongest signal (highest RSSI), performs geolocation triangulation using RSSI from multiple stations (Atlas service), decrypts payload, and prepares for application delivery.
Step 5: Application Callback (2-5 seconds) Sigfox sends HTTP POST webhook to your application server with JSON payload containing device ID, decoded data, RSSI, timestamp, and estimated location (if Atlas enabled). Your application processes and stores data.
Total Latency: 30-90 seconds (typical), up to 5 minutes in congested networks. This is why Sigfox is unsuitable for real-time alerts.
38.7 Incremental Learning Examples
Master Sigfox deployment through these progressive scenarios:
Example 1: Single Parking Sensor (Beginner Level) Deploy one sensor reporting “occupied” or “vacant” every 5 minutes.
Message Design:
Payload: 1 byte = 0x00 (vacant) or 0x01 (occupied)
Messages/day: 12 hours × 12 per hour = 144 messagesProblem: 144 messages exceeds 140 limit by 4 messages!
Solution: Report every 6 minutes instead (10 per hour × 12 hours = 120 messages). Leaves 20-message margin for error retransmissions.
Lesson: Always design with 15-20% margin below daily limit.
Example 2: Temperature + Humidity Sensor (Intermediate) Warehouse sensor reports temperature (-20 to +60°C, 0.1°C precision) and humidity (0-100%, 0.1% precision) every hour.
Naive Encoding (Floats - WRONG):
Temperature: 4 bytes (float)
Humidity: 4 bytes (float)
Device ID: 4 bytes
Total: 12 bytes ✓ (barely fits)Optimized Encoding (Integers - CORRECT):
Temperature: 2 bytes (int16: -200 to +600 → divide by 10)
Humidity: 2 bytes (uint16: 0 to 1000 → divide by 10)
Device ID: 2 bytes (65,535 devices possible)
Battery: 1 byte (0-255 → 0-100% or 0-5.0V)
Timestamp: 2 bytes (seconds since midnight)
Status flags: 1 byte (8 boolean flags)
Reserved: 2 bytes (future use)
Total: 12 bytes with 40% space savedLesson: Binary encoding doubles your data capacity. Reserve unused bytes for future features.
Example 3: GPS Tracker with Battery Optimization (Advanced) Asset tracker sends GPS location every 2 hours (12 messages/day) to achieve 5+ year battery life.
GPS Coordinate Encoding:
Latitude: 40.7128° N (New York)
Encoded: 40.7128 × 100,000 = 4,071,280 (requires 3 bytes: 0x3E1DF0)
Longitude: -74.0060° W
Encoded: -74.0060 × 100,000 = -7,400,600 (3 bytes signed)
Payload:
- Lat: 3 bytes
- Lon: 3 bytes
- Altitude: 2 bytes (±32 km range, 1m precision)
- Speed: 1 byte (0-255 km/h)
- Battery: 1 byte
- Flags: 1 byte (GPS fix quality, motion detected)
- Reserved: 1 byte
Total: 12 bytesPower Budget:
Per GPS reading + transmission:
- GPS fix (30 seconds): 40 mA × 30s = 1,200 mAs
- Sigfox TX: 120 mA × 6s = 720 mAs
- Processing: 10 mA × 5s = 50 mAs
Total per reading: 1,970 mAs
Daily: 12 readings × 1,970 = 23,640 mAs = 6.57 mAh
Sleep: 1.5 μA × 86,400s = 129.6 mAs = 0.036 mAh
Daily total: 6.61 mAh
Battery (2× AA lithium, 6,000 mAh):
Life: 6,000 ÷ 6.61 = 908 days ≈ 2.5 years ✓Lesson: GPS dominates power budget (95%). Reduce fix frequency or use Sigfox Atlas instead for 10+ year life.
Let’s calculate the message budget and battery life tradeoffs for a Sigfox deployment with and without GPS.
Scenario: Asset Tracker with 140 Daily Messages
If we use all 140 allowed messages per day (maximum limit):
\[T_{interval} = \frac{24 \times 3600 \text{ sec}}{140 \text{ messages}} = 617 \text{ sec} \approx 10.3 \text{ minutes}\]
Battery Life with GPS (every 10 minutes):
Energy per transmission with GPS:
\[E_{GPS} = 40 \text{ mA} \times 30 \text{ s} = 1,200 \text{ mAs}\] \[E_{TX} = 120 \text{ mA} \times 6 \text{ s} = 720 \text{ mAs}\] \[E_{processing} = 10 \text{ mA} \times 5 \text{ s} = 50 \text{ mAs}\] \[E_{total} = 1,970 \text{ mAs} = 0.547 \text{ mAh per message}\]
Daily consumption at 140 messages:
\[E_{daily} = 140 \times 0.547 = 76.6 \text{ mAh/day}\]
For 6,000 mAh battery:
\[\text{Battery Life}_{GPS} = \frac{6000}{76.6} = 78 \text{ days} \approx 2.6 \text{ months}\]
Battery Life WITHOUT GPS (Sigfox Atlas, every 10 minutes):
Energy per transmission without GPS:
\[E_{TX\_only} = 720 + 50 = 770 \text{ mAs} = 0.214 \text{ mAh}\]
Daily consumption:
\[E_{daily} = 140 \times 0.214 = 30 \text{ mAh/day}\]
Battery life:
\[\text{Battery Life}_{noGPS} = \frac{6000}{30} = 200 \text{ days} \approx 6.7 \text{ months}\]
Optimal Strategy (GPS Every 12 Hours):
Sending GPS location twice daily + Atlas-only for other messages:
\[E_{daily} = (2 \times 0.547) + (138 \times 0.214) = 1.09 + 29.5 = 30.6 \text{ mAh/day}\]
\[\text{Battery Life}_{hybrid} = \frac{6000}{30.6} = 196 \text{ days} \approx 6.5 \text{ months}\]
Key Insight: GPS consumes 2.6× more energy than Sigfox transmission alone. Using Sigfox Atlas for routine tracking and GPS only for critical updates extends battery life by 150%.
38.8 Concept Check
## Try It Yourself
Exercise: Design Your 12-Byte Payload
Pick a sensor application and design an optimal 12-byte payload:
Scenario: You’re monitoring a wine storage cellar. Sensors measure: - Temperature: 8-18°C (0.1°C precision important) - Humidity: 40-80% (1% precision sufficient) - Light level: 0-1000 lux (ambient light detector) - Door status: Open/Closed boolean - Battery voltage: 2.0-3.6V (0.01V precision)
Your Task:
- Determine data types and byte allocations
- Design encoding scheme (fixed-point integers)
- Calculate total bytes used
- Verify it fits in 12 bytes
Solution Guide:
Temperature: Range 8-18°C with 0.1°C precision
→ Store as (value - 8) × 10 → range 0-100 → 1 byte (uint8)
Humidity: Range 40-80% with 1% precision
→ Store as (value - 40) → range 0-40 → 1 byte (uint8)
Light: Range 0-1000 lux
→ 2 bytes (uint16) direct value
Door: Boolean
→ 1 bit (can pack with other flags)
Battery: 2.0-3.6V with 0.01V precision
→ (value - 2.0) × 100 → range 0-160 → 1 byte (uint8)
Device ID: Unique identifier
→ 2 bytes (uint16, supports 65,535 sensors)
Timestamp: Minutes since midnight
→ 2 bytes (uint16, 0-1440 minutes/day)
Status flags: 1 byte (8 bits for door + 7 other flags)
→ Bit 0: Door (0=closed, 1=open)
→ Bit 1: Low battery warning
→ Bit 2-7: Reserved
Checksum: Simple XOR of all bytes
→ 1 byte
Reserved: Future expansion
→ 1 byte
Total: 1+1+2+1+2+2+1+1+1 = 12 bytes ✓ Perfect fit!What to Observe:
- Did you use floats or integers? (Floats waste space)
- Did you use offsets to reduce range? (Temp 8-18 vs 0-255)
- Did you pack boolean flags into a single byte?
- Did you leave room for future features?
38.9 Concept Relationships
| Concept | Builds On | Enables | Common Confusion | Real-World Impact |
|---|---|---|---|---|
| 12-Byte Payload Limit | UNB 100 bps data rate, 2-second transmission | Binary encoding, data compression | 12 bytes ≠ 12 characters (ASCII wastes space) | Temperature as float (4B) vs int16 (2B) = 50% payload saved |
| Operator-Managed Model | Cellular network analogy, no gateway ownership | Zero infrastructure investment, global roaming | Cannot deploy private Sigfox network (unlike LoRaWAN) | Barcelona waste: 20K devices, zero gateways deployed by customer |
| 140 Message Daily Limit | 1% EU duty cycle, 6-second transmission × 3 replicas | Hourly reporting (24/day), not real-time | Limit is physics-driven, not billing restriction | Hourly = safe (24/day); every 10 min = 144/day (exceeds limit) |
| 30-90 Second Latency | UNB transmission time, cloud processing, spatial diversity | Periodic monitoring, not emergency alerts | “Low latency” ≠ Sigfox (compare NB-IoT 1-3 sec) | Parking sensors OK (5-min updates); panic buttons FAIL (need <5 sec) |
| Coverage Verification | Operator-dependent deployment, no self-extension | Pilot testing requirements, risk mitigation | Coverage maps show estimates, not guarantees | Barcelona urban 99.7% success; rural farm 40% (unusable without pilots) |
38.10 See Also
Deepen your Sigfox knowledge with these related chapters:
- Sigfox Scenarios & Common Mistakes - Learn from real failures: message limits, coverage gaps, downlink constraints
- Sigfox Technology Deep Dive - UNB modulation physics, link budget calculations, architectural details
- Sigfox vs LoRaWAN Comparison - Operator vs self-deployed tradeoffs, cost crossover analysis
- LPWAN Fundamentals - Understand low-power wide-area network context and positioning
- Binary Encoding Best Practices - Techniques for packing maximum data into minimal bytes
38.11 Summary
This chapter introduced Sigfox’s fundamental concepts and positioning as an operator-managed LPWAN:
- Sigfox is a network service, not just a technology - you cannot deploy your own infrastructure
- Ultra-low cost ($1-2/device/year) with extreme simplicity (no gateway setup)
- 12-byte payload limit requires efficient data encoding strategies
- 140 uplink + 4 downlink messages/day suits infrequent sensor data, not real-time applications
- Coverage dependency - must verify operator coverage exists before deployment
- Ideal for: simple sensors, asset tracking, utility metering in covered areas
Common Pitfalls
Sigfox and LoRaWAN serve similar use cases but have fundamentally different constraints. Sigfox’s 12-byte payload and 140 messages/day are far more restrictive than LoRaWAN. Applications designed for LoRaWAN often need significant redesign for Sigfox.
Evaluating Sigfox without acknowledging the 2022 corporate restructuring and Unabiz acquisition provides an incomplete technology assessment. Include current network stability and long-term support commitments in any new Sigfox deployment evaluation.
Sigfox eliminates gateway investment but has per-device subscription costs. For large deployments (1000+ devices) on private networks, LoRaWAN can have lower TCO despite gateway costs. Always calculate total cost over deployment lifetime for the specific device count.
Sigfox coverage varies significantly by country and region. Some rural areas in even well-covered countries have no Sigfox service. Verify coverage in all target deployment locations before selecting Sigfox as the connectivity technology.
38.12 What’s Next
Continue learning about Sigfox with these related chapters:
| Next Topic | Chapter | Description |
|---|---|---|
| Common Mistakes | Sigfox Scenarios and Common Mistakes | What happens when requirements do not match Sigfox constraints |
| Technology Deep Dive | Sigfox Technology Deep Dive | UNB modulation physics and network architecture details |
| Worked Examples | Sigfox Examples and Assessment | Deployment calculations and knowledge checks |
| Advanced Topics | Sigfox Advanced Topics | Deep dive into implementation and protocol details |