1111  Sigfox Scenarios and Common Mistakes

1111.1 Introduction

⏱️ ~12 min | ⭐⭐ Intermediate | πŸ“‹ P09.C10.U02

Understanding when Sigfox works and when it fails is critical for successful IoT deployments. This chapter explores real-world scenarios where Sigfox’s constraints become limiting factors and common mistakes that cost money and time.

NoteLearning Objectives

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

  • Identify scenarios where Sigfox is not suitable
  • Understand the impact of message limits on application design
  • Recognize coverage dependency risks before deployment
  • Avoid common Sigfox deployment mistakes
  • Calculate message requirements for your applications

1111.2 What Would Happen If… (Scenarios)

WarningUnderstanding Sigfox Limitations Through Scenarios

1111.2.1 Scenario 1: β€œWhat if your sensor needs to send data every second?”

The Problem:

Requirement: Temperature sensor sending updates every 1 second
Messages needed: 1 msg/sec Γ— 60 sec Γ— 60 min Γ— 24 hr = 86,400 msg/day

Sigfox limit: 140 messages/day

Reality check: 86,400 Γ· 140 = 617Γ— OVER the limit!

What Actually Happens: - Sigfox network REJECTS messages after 140/day quota - Device sends, but messages disappear into the void - No error notification (device doesn’t know it failed) - Billing still charged (subscription doesn’t refund)

Solution: Use a different technology: - LoRaWAN: Unlimited messages (duty cycle limited, but ~1,000+/day possible) - Wi-Fi: Real-time streaming (if power available) - NB-IoT: High-frequency cellular (but expensive)

Takeaway: Sigfox is for β€œhourly updates” not β€œreal-time monitoring.”

1111.2.2 Scenario 2: β€œWhat if you need to send a photo from a wildlife camera?”

The Math:

Typical photo size: 500 KB = 500,000 bytes
Sigfox payload: 12 bytes/message
Messages needed: 500,000 Γ· 12 = 41,667 messages

Time required (at 140 msg/day): 41,667 Γ· 140 = 298 days per photo!

What Actually Happens: - Completely impossible to send images via Sigfox - Even tiny 10KB thumbnails need 833 messages = 6 days - Sigfox is data, not media

Solution: - Use Sigfox as trigger, then switch networks: 1. Motion detected β†’ Sigfox sends "Camera 23 triggered" (12 bytes) 2. Backend receives alert β†’ Sends downlink: "Upload photo" 3. Camera wakes up β†’ Switches to Wi-Fi/4G β†’ Uploads photo 4. Returns to Sigfox sleep mode - This hybrid approach uses Sigfox for 99% of time (cheap, low power) and Wi-Fi/4G only when needed (expensive, but rare).

1111.2.3 Scenario 3: β€œWhat if Sigfox coverage doesn’t exist in your deployment area?”

The Problem:

You deploy 5,000 sensors in rural Africa
Sigfox coverage map shows: πŸ”΄ NO COVERAGE

Device behavior:
β€’ Sensors wake up every hour βœ“
β€’ Transmit Sigfox message βœ“
β€’ No base station receives it ❌
β€’ Data lost forever ❌

What Actually Happens: - Devices waste battery transmitting into the void - You’ve paid $12/device Γ— 5,000 = $60,000 for useless hardware - Sigfox subscription fees still charged (network exists globally, just not there) - CANNOT deploy your own Sigfox base station (proprietary network)

Critical Difference from LoRaWAN:

Sigfox:                      LoRaWAN:
─────────                    ────────
No coverage? You're stuck.   No coverage? Deploy your own gateways!
Cannot extend network.       Buy gateways ($200-1,500 each).
Must use Sigfox towers.      Full control of infrastructure.

Solution: - Pre-Deployment: ALWAYS verify coverage before buying Sigfox devices - Coverage Check: Visit https://www.sigfox.com/coverage and test with pilot devices - Alternatives: If no coverage, choose LoRaWAN or NB-IoT instead

1111.2.4 Scenario 4: β€œWhat if you need bidirectional control (two-way communication)?”

The Setup:

Smart irrigation system:
β€’ Sensor sends soil moisture: "35% dry" (uplink)
β€’ Cloud decides: "Turn on water for 10 minutes" (downlink needed)

Sigfox Downlink Constraints:

Downlink limit: 4 messages/day per device
100 irrigation zones in field
Daily commands needed: 100 zones Γ— 2 watering cycles = 200 downlinks

Reality: 200 needed Γ· 4 allowed = 50Γ— OVER LIMIT

What Actually Happens: - Only 4 zones can receive commands per day - Other 96 zones never get β€œturn on” command - Crops die from lack of water - Sigfox is fundamentally uplink-biased (sensors β†’ cloud)

Solution: - LoRaWAN Class C: Unlimited downlinks (device always listening) - NB-IoT: True bidirectional communication - Hybrid: Sigfox for monitoring, local controller for actuation (no downlink needed)

Takeaway: Sigfox is for sensing, not control. If you need to tell devices what to do frequently, choose a different technology.

1111.2.5 Scenario 5: β€œWhat if the device moves between countries?”

The Setup:

Shipping container tracking across borders:
Rotterdam (Netherlands) β†’ Hamburg (Germany) β†’ Warsaw (Poland) β†’ Moscow (Russia)

What Actually Happens:

βœ“ Rotterdam: Sigfox works (strong coverage)
βœ“ Hamburg: Sigfox works (strong coverage)
βœ“ Warsaw: Sigfox works (moderate coverage)
❌ Moscow: NO COVERAGE (Russia blocked Sigfox)

From Warsaw onward: Device goes dark

Critical Limitation: - Sigfox coverage is fragmented globally - Only 72 countries have operators (vs. 190+ for cellular) - Coverage gaps in: China, Russia, much of Africa, parts of Asia

Solution for Global Tracking: - Cellular IoT (NB-IoT/LTE-M): Works in 190+ countries - Dual-mode devices: Sigfox primary, cellular fallback - Regional deployments only: Keep to Western Europe/US where coverage is strong

Takeaway: Sigfox is multi-national, not global. Verify coverage in ALL deployment countries before committing.

1111.3 Common Mistakes (Avoid These Pitfalls!)

Caution7 Sigfox Mistakes That Will Cost You Money

1111.3.1 Mistake 1: β€œI’ll deploy now and check coverage later”

What Developers Think: - β€œCoverage maps show my city is covered, so I’m good!”

What Actually Happens: - Coverage maps show estimated outdoor coverage - Your sensors are in basements (20-30 dB attenuation) - 40% of devices never connect - You’ve already purchased 10,000 units ($120,000 wasted)

Correct Approach:

BEFORE mass deployment:
1. Buy 50-100 test devices
2. Deploy at ACTUAL installation locations
3. Monitor for 1 month: message success rate
4. Accept only if >95% success rate
5. THEN order production quantities

Cost: $500-1,000 for pilot test saves $50,000-$120,000 in failed deployments.

1111.3.2 Mistake 2: β€œI’ll fragment my data across multiple messages”

What Developers Think: - β€œI need to send 50 bytes, so I’ll split into 5 messages (5 Γ— 12 = 60 bytes)”

What Actually Happens:

Day 1:
β€’ Send message 1/5: βœ“ Received
β€’ Send message 2/5: βœ“ Received
β€’ Send message 3/5: ❌ LOST (interference)
β€’ Send message 4/5: βœ“ Received
β€’ Send message 5/5: βœ“ Received

Backend receives 4/5 messages β†’ Incomplete data β†’ Corrupted/unusable

Problems: - No guaranteed delivery order (messages may arrive out of sequence) - Packet loss (1-5% typical) breaks fragmented data - Message reassembly logic adds complexity and failure points - Uses 5Γ— your daily quota (5 messages vs. 1)

Correct Approach:

βœ… Compress data to fit 12 bytes:
   β€’ Use 2-byte integers (not 4-byte floats)
   β€’ Pack multiple values into single bytes
   β€’ Send deltas (change from last reading, not absolute values)
   β€’ Use lookup tables for common states

Example:
   ❌ Temperature: 23.456Β°C β†’ 4 bytes (float)
   βœ… Temperature: 23Β°C β†’ 1 byte (int, Β±127 range)

   ❌ GPS: 40.7128Β° N, 74.0060Β° W β†’ 16 bytes (doubles)
   βœ… GPS: Encoded grid reference β†’ 6 bytes (custom encoding)

Takeaway: Design your data format for 12 bytes. Don’t fight Sigfox’s constraints.

1111.3.3 Mistake 3: β€œI’ll use Sigfox for real-time alerts”

What Developers Think: - β€œWhen fire is detected, sensor sends Sigfox alert immediately!”

What Actually Happens:

Fire detected at 10:00:00
β†’ Sigfox transmission starts at 10:00:01
β†’ Message duration: ~2 seconds (100 bps, 12 bytes)
β†’ Network processing: 5-10 seconds
β†’ Backend receives alert: 10:00:13 (13-second delay)

But that's BEST CASE. Typical delays:
β€’ Message collision: Retry after 30-60 seconds
β€’ Base station backhaul: +5-20 seconds
β€’ Backend processing: +5 seconds
β€’ Push notification: +2 seconds

Total latency: 30-90 seconds common, up to 5 minutes possible

Problem for Real-Time Scenarios: - Fire alarm: 90-second delay = dangerous - Panic button: 90-second delay = unacceptable - Car crash detection: 90-second delay = life-threatening

Correct Approach:

For real-time alerts:
βœ… Use NB-IoT: 1-3 second latency
βœ… Use LoRaWAN: 2-5 second latency
βœ… Use Wi-Fi: <1 second latency

For non-urgent monitoring:
βœ… Use Sigfox: Daily temperature readings
βœ… Use Sigfox: Hourly tank levels
βœ… Use Sigfox: Weekly battery status

Takeaway: Sigfox is for reporting, not alerting. Use faster technologies for time-critical applications.

1111.3.5 Mistake 5: β€œI can build a private Sigfox network for my campus”

What Developers Think: - β€œLoRaWAN has private networks, so I can deploy Sigfox base stations on my university campus!”

What Actually Happens:

❌ IMPOSSIBLE - Sigfox is a CLOSED proprietary system

 LoRaWAN:                         Sigfox:
────────                         ───────
βœ… Open standard (LoRa Alliance) ❌ Proprietary (Sigfox company)
βœ… Buy gateways ($200-1,500)     ❌ Cannot purchase base stations
βœ… Deploy anywhere you want      ❌ Must use Sigfox-operated network
βœ… Run your own network server   ❌ Cloud backend is Sigfox-only
βœ… Full control                  ❌ Zero infrastructure control

Why This Matters:

Scenario: Sigfox operator coverage is weak on your campus

LoRaWAN solution:
β†’ Buy 3 gateways ($1,500)
β†’ Install on rooftops
β†’ Full coverage achieved in 1 week

Sigfox solution:
β†’ Contact Sigfox operator
β†’ Request base station deployment
β†’ Operator evaluates business case
β†’ Decision: "Not enough subscribers to justify"
β†’ You're stuck with poor coverage FOREVER

Correct Approach: - If you need network control β†’ Choose LoRaWAN or NB-IoT - If you’re OK with operator dependency β†’ Sigfox is fine - For critical infrastructure β†’ Always use controllable technology

Takeaway: Sigfox is a service, not a platform. You’re renting, not owning.

1111.3.6 Mistake 6: β€œSigfox is cheaper than LoRaWAN for all deployments”

What Developers Think: - β€œ$1/year subscription vs. $500 gateway? Sigfox is always cheaper!”

What Actually Happens:

SMALL DEPLOYMENT (100 devices):
───────────────────────────────
Sigfox (5 years):
β€’ Devices: 100 Γ— $12 = $1,200
β€’ Subscription: 100 Γ— $1/year Γ— 5 = $500
β€’ Total: $1,700 βœ“ WINNER

LoRaWAN (5 years):
β€’ Devices: 100 Γ— $15 = $1,500
β€’ Gateway: 1 Γ— $500 = $500
β€’ Network server: $0 (self-hosted)
β€’ Total: $2,000

Sigfox wins for small deployments.

LARGE DEPLOYMENT (10,000 devices):
──────────────────────────────────
Sigfox (5 years):
β€’ Devices: 10,000 Γ— $12 = $120,000
β€’ Subscription: 10,000 Γ— $1/year Γ— 5 = $50,000
β€’ Total: $170,000

LoRaWAN (5 years):
β€’ Devices: 10,000 Γ— $15 = $150,000
β€’ Gateways: 100 Γ— $500 = $50,000
β€’ Network server: $5,000/year Γ— 5 = $25,000
β€’ Total: $225,000 (STILL more)

BUT at 20,000+ devices:
────────────────────────
Sigfox: $12/device + $5 subscription Γ— 20,000 = $340,000
LoRaWAN: $15/device Γ— 20,000 + $100k infra = $400,000

Crossover: ~50,000 devices, LoRaWAN becomes cheaper

Hidden Sigfox Costs: - Subscription fees compound over time (LoRaWAN infrastructure is one-time) - Geographic coverage gaps require dual deployments - Vendor lock-in (cannot switch operators if service degrades)

Correct Approach:

Use Sigfox when:
βœ… <1,000 devices
βœ… Deployment in strong coverage areas
βœ… No critical dependence on uptime

Use LoRaWAN when:
βœ… >1,000 devices (economies of scale)
βœ… Need network control
βœ… Coverage gaps exist
βœ… Critical infrastructure

1111.3.7 Mistake 7: β€œI don’t need to test in production environment”

What Developers Think: - β€œSensors work on my desk, they’ll work in the field!”

What Actually Happens:

Lab testing (desk environment):
β€’ Distance to window: 2 meters
β€’ Interference: None
β€’ Message success: 100% βœ“
β€’ RSSI: -95 dBm (excellent)

Field deployment (reality):
β€’ Sensors installed in metal boxes
β€’ Underground in manholes
β€’ Inside concrete buildings
β€’ Near electrical substations (interference)

Results:
β€’ Message success: 60% ❌
β€’ RSSI: -130 dBm (barely functional)
β€’ Battery drain: 3Γ— higher (constant retransmissions)

Real-World Attenuation:

Environment             Signal Loss
────────────           ────────────
Free space (line of sight)    0 dB (baseline)
Inside building               10-20 dB
Underground/basement          20-30 dB
Metal enclosure              30-40 dB
Underground + metal           40-50 dB

Sigfox sensitivity: -126 dBm
Strong signal from base station: -90 dBm
Margin: 36 dB

If device is underground in metal box: -90 dBm - 50 dB = -140 dBm
Result: BELOW SENSITIVITY β†’ No connectivity ❌

Correct Approach:

Testing protocol:
1. Lab test (proof of concept)
2. Outdoor test (verify range)
3. PILOT TEST IN ACTUAL DEPLOYMENT ENVIRONMENT:
   β†’ Install 50-100 devices
   β†’ In exact locations (not "similar" locations)
   β†’ Monitor for 30 days
   β†’ Measure: success rate, RSSI, battery drain
   β†’ Acceptance: >95% success, RSSI >-120 dBm
4. Only then: Mass production

NEVER skip step 3!

Takeaway: Field conditions are 10-100Γ— harsher than lab. Always pilot test in production environment before scaling.

1111.4 Additional Pitfalls

CautionPitfall: Using Float Encoding for Payload Data

The Mistake: Encoding sensor readings as IEEE 754 floats (4 bytes each), wasting precious payload space and leaving no room for essential data.

Why It Happens: Developers use familiar data types from desktop/server programming without considering Sigfox’s 12-byte constraint:

Naive payload design (floats):
- Temperature: 23.5Β°C as float = 4 bytes
- Humidity: 65.2% as float = 4 bytes
- Latitude: 51.5074 as float = 4 bytes
- Longitude: -0.1278 as float = 4 bytes
Total: 16 bytes β†’ EXCEEDS 12-byte limit!

Result: Must fragment across 2 messages, doubling daily quota usage

The Fix: Use scaled integers and bit-packing to fit all data in 12 bytes:

Optimized payload design (integers):
- Temperature: 235 (Γ—0.1 = 23.5Β°C) as int16 = 2 bytes
- Humidity: 652 (Γ—0.1 = 65.2%) as uint16 = 2 bytes
- Latitude: 515074 (Γ—0.0001) as int24 = 3 bytes
- Longitude: -1278 (Γ—0.0001) as int24 = 3 bytes
- Battery: 34 (Γ—0.1V = 3.4V) as uint8 = 1 byte
- Status flags: packed bits = 1 byte
Total: 12 bytes βœ“ FITS!

Design rules: 1. Temperature: 1 byte (-40 to +85Β°C) or 2 bytes (0.1Β°C resolution) 2. GPS: 6 bytes total (3 bytes lat + 3 bytes lon) gives ~10m accuracy 3. Percentages: 1 byte (0-100) or 2 bytes (0.01% resolution) 4. Timestamps: 2 bytes relative (seconds since last message) vs 4 bytes absolute

CautionPitfall: Forgetting Device Registration Before First Transmission

The Mistake: Deploying Sigfox devices without completing PAC (Porting Authorization Code) registration on the Sigfox backend, resulting in messages that transmit but are never delivered to the application.

Why It Happens: Unlike Wi-Fi or Bluetooth which β€œjust work,” Sigfox requires explicit device registration linking each device’s unique ID to a subscription:

Device lifecycle (often missed):
1. Purchase Sigfox module β†’ Device has unique ID + PAC code
2. Register device on backend.sigfox.com using ID + PAC ← OFTEN SKIPPED!
3. Associate device with Device Type and Callback URL
4. Configure payload parser (how to decode 12-byte messages)
5. THEN device can transmit successfully

What happens without registration:
- Device transmits message βœ“
- Base station receives message βœ“
- Cloud checks device registry β†’ ID not found ❌
- Message SILENTLY DROPPED β†’ never reaches your application
- No error feedback to device (it thinks transmission succeeded)

The Fix: Establish a device provisioning workflow before deployment: 1. Batch registration: Import CSV with Device IDs and PACs before shipping devices 2. Verify registration: Use Sigfox backend API to confirm device status before field deployment 3. Test transmission: Send test message from each device and verify arrival in callbacks 4. PAC security: Store PAC codes securelyβ€”they’re single-use and cannot be recovered if lost 5. Device Type setup: Ensure correct Device Type is assigned with proper callback configuration 6. Transfer awareness: If purchasing pre-owned devices, ensure PAC transfer from previous owner

1111.5 Summary

This chapter covered critical scenarios and mistakes that reveal Sigfox’s limitations:

  • Message limits (140 uplink, 4 downlink) make Sigfox unsuitable for real-time or high-frequency applications
  • Payload size (12 bytes) requires efficient encoding - don’t fragment data across messages
  • Coverage dependency means you cannot extend the network yourself
  • Downlink constraints make bidirectional control applications impractical
  • Latency (30-90 seconds typical) disqualifies Sigfox for emergency/safety applications
  • Cost crossover occurs around 9,000-50,000 devices where LoRaWAN becomes cheaper

1111.6 What’s Next

Continue learning about Sigfox with these related chapters: