36  Sigfox Introduction and Fundamentals

In 60 Seconds

Sigfox operates as a network-as-a-service using Ultra-Narrow Band modulation at 868/915 MHz, delivering 12-byte messages up to 140 times per day with 10+ year battery life. Unlike LoRaWAN, you cannot deploy your own Sigfox network – it is entirely operator-managed with global roaming via a single subscription.

36.1 Introduction

⏱️ ~15 min | ⭐⭐ Intermediate | 📋 P09.C10.U01a

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.

Learning Objectives

By the end of this chapter, you will be able to:

• Explain Sigfox’s ultra-narrow band (UNB) modulation and its trade-offs for range, power, and throughput
• Contrast the Sigfox operator-managed network model with self-deployed LPWAN architectures
• Analyze Sigfox power consumption relative to LoRaWAN, NB-IoT, and cellular alternatives
• Evaluate Sigfox suitability for specific IoT applications using payload, message rate, and coverage criteria
• Calculate message capacity, binary payload encoding, and daily transmission budgets for Sigfox deployments

Key Concepts

• Sigfox Origin: French IoT company founded 2010; pioneered commercial LPWAN networking before LoRaWAN and NB-IoT emerged as alternatives.
• Technology Positioning: Sigfox targets extremely simple, infrequent IoT data transmission; optimized for minimum device complexity and cost at the expense of flexibility.
• Network Model: Original network-as-a-service model where Sigfox SA and regional operators provide complete managed connectivity without customer infrastructure investment.
• Technical Pillars: UNB modulation, base station diversity reception, cloud-based device management, and simple API-based application integration.
• Market Focus: Asset tracking, utilities metering, environmental monitoring, and industrial monitoring where infrequent small data is sufficient.
• Competitive Context: Sigfox competed successfully before LoRaWAN became widely available; now faces challenges from LoRaWAN’s open ecosystem and NB-IoT’s carrier backing.
• Current Status: Unabiz acquired Sigfox network and technology assets in 2022; committed to network continuation but long-term trajectory uncertain for new deployments.

Key Takeaway

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.

36.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

Sensor Squad: The Tiny Postcard Network!

“Sigfox is like a postcard service for IoT!” Sammy the Sensor said. “I can send a tiny message – just 12 bytes – over distances of 30 to 50 kilometers. That is enough for a temperature reading, a GPS coordinate, or a simple ‘door open’ alert. I cannot send photos or stream data, but for simple status updates, it is perfect!”

“The beauty of Sigfox is simplicity,” Lila the LED explained. “You do not need to set up gateways or manage a network. Sigfox already built the infrastructure in over 70 countries. Just activate your device, and it starts sending messages through their base stations to their cloud. It is the easiest LPWAN to get started with!”

Max the Microcontroller added, “The 140-message-per-day limit sounds restrictive, but think about what IoT sensors actually do. A parking sensor only needs to report when a car arrives or leaves. A water leak detector only needs to say ‘leak detected!’ A temperature logger sending once every 11 minutes uses about 131 messages per day – within the limit!”

“My favorite thing about Sigfox,” Bella the Battery said, “is that the devices are incredibly simple and cheap. Because all the intelligence lives in the cloud, the device just needs a radio and a microcontroller. Less hardware means less power consumption, which means I can last for ten years or more on a single battery!”

36.3 Getting Started (For Beginners)

New to Sigfox? Start Here!

If terms like “ultra-narrow band,” “uplink-only,” or “140 messages/day” sound confusing, this section will explain Sigfox’s unique approach with a simple analogy.

36.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”

36.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

36.3.3 When to Use Sigfox

Academic Resource: Stanford IoT Course - Smart Agriculture Evolution

Evolution of precision agriculture showing how LPWAN enables connected farming

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)

36.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.

36.3.5 Self-Check: Understanding the Basics

Before continuing, make sure you can answer:

1. What is Sigfox’s main advantage? → Very low cost ($1-2/device/year), global coverage without building your own network, simplest deployment
2. Why only 12 bytes? → Ultra-narrow band modulation (100 Hz channels) trades data size for extreme range and low power
3. 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
4. What’s the downlink limitation? → Only 4 downlink messages per day per device - mostly one-way communication, use sparingly

36.4 In Plain English: Sigfox Explained

Think of Sigfox as Sending Postcards Instead of Emails

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×/day

The 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.

36.5 Real-World Example: Concrete Numbers

Case Study: Smart Waste Management in Barcelona

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:

1. Tiny payloads (12 bytes sufficient for “bin 45% full”)
2. Infrequent updates (once per day, not real-time)
3. Massive deployment (20,000 devices = subscription savings)
4. Existing coverage (Sigfox already deployed in Barcelona)
5. 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.

Network Architecture

Sigfox Network Architecture

UNB Technology

Sigfox UNB Modulation

Message Flow

Sigfox Message Flow

Figure 36.1: Sigfox network architecture and ultra-narrow band technology

Putting Numbers to It

Context: Sigfox transmits each message three times on different random frequencies to achieve reliability without acknowledgments.

Frequency diversity probability: If single-transmission success rate is 90% (p = 0.1 failure), then probability all three transmissions fail is:

\[P(\text{all fail}) = p^3 = (0.1)^3 = 0.001 = 0.1\%\]

Therefore delivery reliability reaches 99.9% through triple transmission.

Energy budget analysis: Each transmission consumes 50 mW for 2 seconds = 100 mAs. Annual energy for 140 messages/day:

\[E_{\text{annual}} = 3 \times 140 \times 365 \times 100\,\text{mAs} = 15,330,000\,\text{mAs} = 4.26\,\text{Ah}\]

Worked example: With 2,400 mAh battery at maximum rate (140 msg/day): - Transmission energy: 4.26 Ah/year - Battery life: 2,400 mAh / 4,260 mAh = 0.56 years

But at typical rate (10 msg/day): 0.30 Ah/year → 8 years battery life

36.5.1 Why Sigfox Transmits Each Message Three Times on Different Frequencies

Sigfox’s ultra-narrow band (UNB) approach creates a unique reliability challenge: a 100 Hz wide channel is easily disrupted by even minor narrowband interference (a single harmonic from an industrial motor, for example, can obliterate the entire channel). To compensate, every Sigfox uplink message is transmitted three times on three different randomly selected frequencies within a 40-second window.

This design has specific engineering consequences:

Frequency diversity. The three transmissions use three different frequencies within the 192 kHz uplink band (868.034-868.226 MHz in Europe). If one frequency happens to coincide with an interference source, the other two probably will not. The probability of all three hitting interference simultaneously is roughly p³, where p is the probability of a single collision. With the 192 kHz band divided into approximately 1,920 potential 100 Hz channels, and typical urban interference occupying 5-10% of channels, the probability of all three replicas failing is (0.1)³ = 0.1%, yielding 99.9% message delivery.

Time diversity. The three replicas are spaced randomly within a 40-second window. This protects against bursty interference that might blank the band for a few seconds (e.g., a passing vehicle’s ignition noise). The 40-second window means the device’s radio is active for only 3 x 2 seconds = 6 seconds total, with 34 seconds of dead time between transmissions.

The cost of triple transmission. Each replica consumes approximately 50 mW for 2 seconds at 868 MHz (100 mW EIRP limit in EU). Three transmissions per message x 140 messages per day x 365 days = 153,300 transmissions per year. At 100 mAs per transmission (50 mA x 2 seconds), the annual energy budget for transmissions alone is 4.26 Ah. A 2,400 mAh lithium thionyl chloride battery (typical for Sigfox devices) would last 0.56 years if transmitting at maximum rate. In practice, most Sigfox devices send only 1-10 messages per day, extending battery life to 8-15 years. The 140 messages/day limit is partly a practical battery constraint, not just a network capacity rule.

36.6 Related Chapters

Continue Learning

Now that you understand Sigfox fundamentals, explore these related topics:

Next recommended chapters:

• Sigfox Best Practices: Common mistakes, deployment scenarios, and pitfalls to avoid
• Sigfox Technology Deep Dive: UNB modulation details, network architecture, and geolocation
• Sigfox Worked Examples: Message budgets, TCO calculations, link budgets, and timing compliance
• LoRaWAN Fundamentals: Compare with alternative LPWAN for deployment decisions

Foundation chapters:

• LPWAN Fundamentals: Understanding low-power wide-area network characteristics
• Wireless Sensor Networks: Battery-powered sensor constraints

Worked Example: Encoding 5 Sensors in 8 Bytes

Scenario: Agricultural soil monitor needs to transmit 5 sensor readings in a single Sigfox message.

Naive Approach (Fails):

# Using float32 for each value (4 bytes each)
temperature = 22.5    # 4 bytes (float32)
humidity = 65.0       # 4 bytes (float32)
pressure = 1013.25    # 4 bytes (float32)
battery = 3.7         # 4 bytes (float32)
light = 450           # 4 bytes (float32)
Total: 5 × 4 = 20 bytes → EXCEEDS 12-byte limit!

Optimized Approach (Works):

# Scaled integers with appropriate precision
temperature: int16, 0.1°C resolution
  22.5°C → 225 (2 bytes)
  Range: -3276.8°C to +3276.7°C

humidity: uint8, 1% resolution
  65% → 65 (1 byte)
  Range: 0-100%

pressure: uint16, 0.1 hPa resolution
  1013.25 hPa → 10132 (2 bytes)
  Range: 0-6553.5 hPa

battery: uint8, 0.02V resolution
  3.7V → 85 (1 byte, offset 2.0V)
  Formula: (3.7 - 2.0) / 0.02 = 85
  Range: 2.0V-7.1V

light: uint16, 1 lux resolution
  450 lux → 450 (2 bytes)
  Range: 0-65535 lux

Total: 2 + 1 + 2 + 1 + 2 = 8 bytes
Remaining: 12 - 8 = 4 bytes for device ID, flags, etc.

Encoding Function:

def encode_sensor_data(temp, humidity, pressure, battery, light):
    payload = bytearray(8)

    # Temperature: int16, big-endian
    temp_raw = int(temp * 10)
    payload[0] = (temp_raw >> 8) & 0xFF
    payload[1] = temp_raw & 0xFF

    # Humidity: uint8
    payload[2] = int(humidity)

    # Pressure: uint16, big-endian
    pressure_raw = int(pressure * 10)
    payload[3] = (pressure_raw >> 8) & 0xFF
    payload[4] = pressure_raw & 0xFF

    # Battery: uint8, offset and scale
    battery_raw = int((battery - 2.0) / 0.02)
    payload[5] = battery_raw

    # Light: uint16, big-endian
    payload[6] = (light >> 8) & 0xFF
    payload[7] = light & 0xFF

    return payload.hex()

# Example usage
hex_payload = encode_sensor_data(22.5, 65, 1013.25, 3.7, 450)
print(f"Payload: {hex_payload}")
# Output: "00e141279955b901c2"
# Length: 8 bytes ✓

Decoding Function (Cloud Backend):

def decode_sensor_data(hex_payload):
    data = bytes.fromhex(hex_payload)

    temp = ((data[0] << 8) | data[1]) / 10.0  # Signed int16
    humidity = data[2]
    pressure = ((data[3] << 8) | data[4]) / 10.0
    battery = 2.0 + (data[5] * 0.02)
    light = (data[6] << 8) | data[7]

    return {
        "temperature_c": temp,
        "humidity_percent": humidity,
        "pressure_hpa": pressure,
        "battery_v": battery,
        "light_lux": light
    }

# Decode
decoded = decode_sensor_data("00e141279955b901c2")
print(decoded)
# {'temperature_c': 22.5, 'humidity_percent': 65,
#  'pressure_hpa': 1013.2, 'battery_v': 3.7, 'light_lux': 450}

Key Lessons:

• Use smallest datatype that fits your range and precision requirements
• int16 for temperatures (−3276.8 to +3276.7, 0.1°C resolution)
• uint8 for percentages (0-100%, 1% resolution)
• Offset and scale for limited ranges (battery 2.0-7.1V fits in 1 byte)
• 8 bytes → 5 sensors with high precision
• 4 bytes remaining for metadata (device ID, timestamp, status flags)

Common Beginner Mistake: Using float types wastes 3 bytes per value. 99% of sensor readings don’t need 32-bit floating-point precision!

Decision Framework: Sigfox vs LoRaWAN vs NB-IoT Selection

Use this decision matrix to choose the right LPWAN technology for your IoT project.

Requirement	Sigfox Score	LoRaWAN Score	NB-IoT Score	Winner
Payload <12 bytes, <140 msg/day	✓✓✓ (3)	✓✓ (2)	✓ (1)	Sigfox
Payload >100 bytes	✗ (0)	✓✓ (2)	✓✓✓ (3)	NB-IoT
No local infrastructure	✓✓✓ (3)	✗ (0)	✓✓✓ (3)	Sigfox/NB-IoT
Own/control network	✗ (0)	✓✓✓ (3)	✗ (0)	LoRaWAN
Global coverage	✓ (1)	✗ (0)	✓✓✓ (3)	NB-IoT
Lowest cost (<1000 devices)	✓✓✓ (3)	✓✓ (2)	✓ (1)	Sigfox
Largest deployment (10k+ devices)	✓ (1)	✓✓✓ (3)	✓✓ (2)	LoRaWAN
20+ year battery life	✓✓✓ (3)	✓✓ (2)	✓ (1)	Sigfox
Bidirectional communication	✗ (0)	✓✓✓ (3)	✓✓✓ (3)	LoRaWAN/NB-IoT
No operator dependency	✗ (0)	✓✓✓ (3)	✗ (0)	LoRaWAN

Scoring Guide:

• ✓✓✓ (3 points) = Excellent fit
• ✓✓ (2 points) = Good fit
• ✓ (1 point) = Acceptable
• ✗ (0 points) = Poor fit / Not supported

Decision Tree:

Do you need >12-byte payloads OR >140 messages/day?
├─ YES → Sigfox is ruled out
│   └─ Do you need to own/control the network?
│       ├─ YES → LoRaWAN (deploy gateways)
│       └─ NO → NB-IoT (operator network)
│
└─ NO → Sigfox is viable
    └─ Do you need bidirectional communication?
        ├─ YES → Consider LoRaWAN (4 downlinks/day may be insufficient)
        └─ NO → Sigfox is likely optimal (lowest cost, longest battery)

Real-World Example: Choosing Technology for 500 Agricultural Sensors

Requirements:

• 500 soil moisture sensors across 50 farms
• Transmit every 2 hours (12 messages/day)
• Payload: 10 bytes (sensor ID, moisture, temp, battery)
• Budget: $30,000 total
• Battery life goal: 10+ years
• Coverage: Rural areas, some farms 30+ km from nearest city

Evaluation:

Sigfox:

• Payload: 10 bytes < 12 bytes ✓
• Messages: 12/day < 140/day ✓
• Cost: 500 × ($8 device + $6/year × 5 years) = $19,000 ✓
• Coverage: Check Sigfox coverage map (may have gaps in rural areas) ⚠️
• Battery: 15+ years ✓✓✓

LoRaWAN:

• Payload: 10 bytes < 242 bytes ✓✓✓
• Messages: Unlimited ✓✓✓
• Cost: 500 × $12 + 15 gateways × $1,500 + $300/mo × 60 months = $46,500 ✗ (exceeds budget)
• Coverage: You deploy gateways where needed ✓
• Battery: 8-12 years ✓✓

NB-IoT:

• Payload: 10 bytes < 1600 bytes ✓✓✓
• Messages: Unlimited ✓✓✓
• Cost: 500 × $15 + $5/device/month × 60 months = $157,500 ✗✗✗ (way over budget)
• Coverage: Depends on carrier (may have rural gaps) ⚠️
• Battery: 5-8 years ✓

Winner: Sigfox

• Meets all technical requirements
• Lowest cost ($19,000 vs $46,500 vs $157,500)
• Longest battery life (15+ years)
• Critical action: Verify Sigfox coverage at all 50 farm locations BEFORE deployment
• Backup plan: If coverage gaps exist at 5-10 farms, deploy small LoRaWAN gateway for those sites only

Common Mistake: Confusing “Global Coverage” with “Coverage Everywhere”

The Mistake: Developer assumes “Sigfox operates in 75+ countries” means “my device will work everywhere in those 75 countries.”

Why It’s Wrong:

Sigfox Coverage is Cellular-Style, Not Satellite:

• Coverage exists where Sigfox operator deployed base stations
• Urban/suburban areas: Generally good coverage
• Rural/remote areas: Often zero coverage
• Coverage maps show “intended coverage,” not guaranteed signal

Real Example: France (Best Sigfox Coverage)

• Paris: 99% coverage (dense base station deployment)
• Rural Normandy: 60-80% coverage (sparse base stations)
• French Alps mountain valley: 0% coverage (no base stations)

Coverage Map Reality Check:

• “Coverage Available” on map ≠ signal guaranteed
• Base stations have 30-50 km range, but:
  • Blocked by hills/mountains
  • Weakened by forests
  • Non-existent in sparsely populated areas

Costly Deployment Failure: A logistics company deployed 1,000 Sigfox container trackers for global shipping. They verified Sigfox operates in 75 countries and assumed global coverage.

What happened:

• Port of Los Angeles: ✓ Excellent coverage (urban)
• Port of Mumbai: ✓ Good coverage (urban India)
• Rural Australian outback (trucking route): ✗ Zero coverage
• South Pacific ocean shipping lanes: ✗ Zero coverage (no base stations at sea!)
• Result: 30% of shipments had zero tracking data

The Fix:

1. Test coverage BEFORE deployment:

# Coverage verification checklist
locations = [
    {"name": "Farm A", "lat": 43.2, "lon": -1.5},
    {"name": "Farm B", "lat": 43.8, "lon": -1.2},
    ...
]

for loc in locations:
    # Visit location with test Sigfox device
    # Send 10 test messages over 24 hours
    # Calculate success rate
    if success_rate < 95%:
        print(f"WARNING: {loc['name']} has poor coverage!")

2. Use Sigfox coverage API (if available):

import requests

def check_sigfox_coverage(lat, lon):
    # Note: Sigfox doesn't provide public API
    # Contact operator for coverage verification
    response = requests.get(
        f"https://operator.sigfox.com/coverage?lat={lat}&lon={lon}",
        headers={"Authorization": "Bearer YOUR_TOKEN"}
    )
    return response.json()["coverage_level"]

3. Plan for coverage gaps:

• Hybrid approach: Use Sigfox where covered, fallback to LoRaWAN/LTE in gaps
• Dual-radio devices: Sigfox primary, NB-IoT backup (adds $5-8 per device)
• Mobile gateways: Deploy portable LoRaWAN gateway for uncovered routes

4. Verify coverage claims with pilot:

• Deploy 10-20 devices across all target locations
• Run for 2-4 weeks
• Measure actual delivery rates BEFORE ordering 10,000 devices

Coverage vs Countries Comparison:

Technology	Countries	Actual Coverage	Best Use Case
Sigfox	75+	Urban/suburban only	Fixed city locations
LoRaWAN	DIY	You deploy where needed	Custom coverage areas
NB-IoT	100+	Cellular footprint	Follow mobile networks
Satellite	Global	Truly everywhere (orbital)	Oceans, poles, deserts

Key Insight: “Operates in 75 countries” means network exists, not ubiquitous coverage. Always test your specific deployment locations.

Interactive Quiz: Match Concepts

Interactive Quiz: Sequence the Steps

🏷️ Label the Diagram

💻 Code Challenge

36.7 Summary

Key Takeaways:

1. Operator-Managed LPWAN: Sigfox is a proprietary network service (like cellular), not a platform you deploy yourself
2. Ultra-Low Power: 10-20 year battery life from ultra-narrow band (UNB) modulation and simple protocols
3. Severe Constraints: 12-byte payload, 140 messages/day uplink, only 4 downlinks/day
4. Coverage Dependency: Works only where Sigfox operators provide coverage (75+ countries claimed, fragmented)
5. Cost-Effective at Small Scale: $1-2/device/year beats LoRaWAN for <1,000 devices
6. Design Philosophy: Compress data aggressively, test in real deployment environment, plan for uplink-only operation

When to Use Sigfox:

• Small infrequent messages (<12 bytes, <140/day)
• Existing operator coverage in deployment area
• No need for network control or infrastructure ownership
• Cost-sensitive deployments (<1,000 devices)

When to Avoid Sigfox:

• Need larger payloads (>12 bytes)
• Frequent updates (>140/day) or bidirectional control
• Coverage gaps in deployment area
• Critical infrastructure requiring network ownership

Common Pitfalls

1. Underestimating Sigfox’s Historical Impact on LPWAN

Sigfox was a pioneer that proved LPWAN commercial viability before LoRaWAN became widely deployed. Understanding Sigfox’s contribution to LPWAN development provides important context for why LoRaWAN made certain design choices differently.

2. Treating the 2022 Acquisition as End-of-Life for Sigfox

Unabiz acquired Sigfox network assets in 2022 and committed to continued operation. While new deployments should consider operator risk, existing Sigfox deployments continue operating and Unabiz has maintained network services.

3. Assuming Sigfox Only Works for Low-Value Applications

Sigfox’s simplicity and low cost suit high-volume, low-margin applications like utility metering and industrial sensors where per-unit economics matter. These are commercially significant markets, not low-value applications.

4. Not Understanding Why Sigfox Chose Managed Network Model

Sigfox’s managed network model eliminated customer infrastructure investment, reducing the barrier to IoT connectivity adoption. Understanding this business model choice explains Sigfox’s go-to-market strategy and how it differed from LoRaWAN’s self-deployable approach.

36.8 What’s Next

Continue your Sigfox learning with these chapters:

Chapter	Focus Area
Sigfox Best Practices	Common deployment mistakes, message limit strategies, and coverage gap workarounds
Sigfox Technology Deep Dive	UNB modulation details, network architecture, Atlas geolocation, and link budgets
Sigfox Worked Examples	Message budget planning, TCO calculations, and duty cycle compliance
LoRaWAN Architecture	Compare Sigfox with user-deployable LPWAN for informed technology selection