1120  Sigfox Best Practices and Common Mistakes

1120.1 Introduction

⏱️ ~20 min | ⭐⭐ Intermediate | πŸ“‹ P09.C10.U01b

This chapter covers critical best practices and common pitfalls when deploying Sigfox IoT solutions. Understanding these scenarios and mistakes will help you avoid costly deployment failures and design more robust Sigfox applications.

NoteLearning Objectives

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

  • Identify scenarios where Sigfox is inappropriate and recommend alternatives
  • Avoid the 7 most common Sigfox deployment mistakes
  • Design payload encoding strategies that fit within 12-byte constraints
  • Evaluate coverage requirements before committing to Sigfox deployments
  • Calculate total cost of ownership for Sigfox vs LoRaWAN at different scales
NoteKey Takeaway

In one sentence: Sigfox success requires understanding its hard constraints (12 bytes, 140 messages/day, 4 downlinks, operator coverage) and designing around them rather than fighting them.

Remember this rule: Before deploying Sigfox, always (1) verify coverage in production environment with pilot devices, (2) design payloads to fit 12 bytes, (3) plan for uplink-only operation, and (4) calculate 5-year TCO including subscription fees.

1120.2 Prerequisites

Before diving into this chapter, you should be familiar with:

  • Sigfox Introduction: Understanding Sigfox fundamentals, message limits, and basic use cases provides essential context for these best practices
  • LPWAN Fundamentals: Knowledge of low-power wide-area network characteristics helps you understand Sigfox’s design constraints
  • LoRaWAN Fundamentals: Comparing with LoRaWAN enables informed technology selection decisions

1120.3 What Would Happen If… (Scenarios)

WarningUnderstanding Sigfox Limitations Through Scenarios

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

1120.3.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).

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

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

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

1120.4 Common Mistakes (Avoid These Pitfalls!)

Caution7 Sigfox Mistakes That Will Cost You Money

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

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

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

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

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

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

1120.5 Payload Encoding 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

1120.7 Summary

Key Takeaways:

  1. Message Limits Are Hard Constraints: 140 uplinks/day and 4 downlinks/day cannot be exceededβ€”design around them
  2. Payload Encoding Is Critical: Use scaled integers, not floats; fit everything in 12 bytes to avoid fragmentation
  3. Coverage Must Be Verified: Pilot test in production environment with real devices before mass deployment
  4. Latency Is Not Real-Time: 30-90 second typical latency makes Sigfox unsuitable for emergency applications
  5. No Private Networks: Sigfox is operator-managedβ€”you cannot deploy your own infrastructure
  6. TCO Varies by Scale: Sigfox wins for <1,000 devices; LoRaWAN becomes cheaper at scale
  7. Downlinks Are Expensive: Battery drain from listening mode makes frequent downlinks impractical

Best Practice Checklist:

1120.8 What’s Next

In the next chapter, we’ll explore:

  • Sigfox Technology: Ultra-narrow band modulation details, network architecture components, and Atlas geolocation capabilities