44 Sigfox Best Practices

In 60 Seconds

Sigfox success hinges on designing around its hard constraints: 12-byte payloads, 140 messages/day, 4 downlinks, and operator-dependent coverage. This chapter covers the 7 most common deployment mistakes, payload encoding strategies, coverage verification procedures, and 5-year TCO calculations vs LoRaWAN.

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

Learning Objectives

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

Diagnose scenarios where Sigfox constraints (message limits, payload size, latency) make it unsuitable and justify alternative technology selections
Classify the 7 most common Sigfox deployment mistakes and formulate mitigation strategies for each
Design payload encoding strategies using scaled integers and bit-packing to fit within 12-byte constraints
Assess coverage requirements through structured pilot testing before committing to Sigfox deployments
Calculate and compare 5-year total cost of ownership for Sigfox vs LoRaWAN at different deployment scales

Key Concepts

Payload Optimization: Encoding sensor data efficiently within Sigfox’s 12-byte limit using bit packing, fixed-point arithmetic, and differential encoding techniques.
Message Budget Management: Distributing 140 daily uplink allowances across application events, scheduled readings, and alert conditions without exceeding daily limits.
Antenna Design: Proper antenna selection and placement for Sigfox UNB; quarter-wave and PCB antennas optimized for 868/915 MHz Sigfox frequencies.
Coverage Validation: Testing device coverage using Sigfox backend tools and network statistics before production deployment; identifying weak coverage zones.
Device Registration: Sigfox device provisioning process including backend registration, PAC (Porting Authorization Code) entry, and callback configuration.
Callback Setup: Configuring Sigfox backend callbacks to forward uplinks to application servers via HTTP/HTTPS webhooks, AWS IoT, or other integrations.
Error Handling: Application-level strategies for handling missed Sigfox messages given the limited duty cycle and potential reception failures.

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

For Beginners: What is Sigfox?

Think of Sigfox like sending postcards instead of phone calls. When you send a postcard, you write a short message (only so much fits on a card!), drop it in the mailbox, and it travels a long distance to reach your friend. You can’t have a conversation back and forth – postcards are one-way, simple messages. But they’re super cheap to send and work even in remote areas where phone signals don’t reach.

Sigfox works the same way for IoT devices. A sensor in a farmer’s field might send a tiny message once per hour: “Soil moisture: 45%”. That’s it – just 12 bytes (about the length of a text emoji and a few words). The message travels many kilometers to reach the Sigfox tower using very little battery power. Perfect for simple monitoring where you don’t need instant updates or two-way conversations.

The key trade-offs: Sigfox is incredibly cheap (around $1 per device per year!) and uses almost no battery power, but you’re limited to 140 messages per day and only 12 bytes per message. It’s like having a strict “140 postcards per day” limit. If you need to send photos, have conversations, or send updates every second, Sigfox won’t work – you’d need Wi-Fi or cellular instead. But for checking a temperature sensor once per hour across thousands of devices? Sigfox is brilliant and affordable.

Sensor Squad: Seven Mistakes to Avoid!

“I have seen developers make the same mistakes over and over,” Sammy the Sensor sighed. “The worst one? Deploying thousands of devices without checking coverage first. They test on their desk by the window – perfect signal! Then they install sensors underground in metal manholes – zero signal. A $500 pilot test could have saved $120,000 in wasted hardware. Always test where you will actually deploy!”

“My pet peeve is data fragmentation,” Lila the LED said. “Developers try to send 50 bytes by splitting it across five messages. But if one message gets lost – and about 1 in 20 does – the whole data set is ruined. Plus, five messages eat up your daily quota five times faster. The right approach? Compress your data to fit 12 bytes. Use 1-byte integers instead of 4-byte floats. Temperature does not need four decimal places!”

Max the Microcontroller raised his hand. “Never use Sigfox for emergency alerts! I have seen people design panic buttons on Sigfox because it is cheap. But Sigfox has 30 to 90 seconds of latency – sometimes up to 5 minutes. For a fire alarm or panic button, that delay could be life-threatening. Use NB-IoT or LoRaWAN for anything time-critical.”

“And please, do not waste my energy on downlink acknowledgments!” Bella the Battery pleaded. “Each downlink forces me to stay awake listening for 25 seconds at 50 milliamps. That is 17 times more power than just sending an uplink. Requesting an acknowledgment for every message would cut my lifespan from 10 years to under 2 years. Design for fire-and-forget – trust Sigfox’s built-in triple transmission for reliability.”

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

44.3 What Would Happen If… (Scenarios)

Understanding Sigfox Limitations Through Scenarios

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

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

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

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

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

44.4 Common Mistakes (Avoid These Pitfalls!)

7 Sigfox Mistakes That Will Cost You Money

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

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

Putting Numbers to It

Payload encoding efficiency can dramatically affect how much data fits in 12 bytes. Compare float vs integer encoding:

\[\text{Float encoding}: 4 \text{ bytes/value} \implies \frac{12}{4} = 3 \text{ values max}\]

\[\text{Integer encoding (2-byte)}: 2 \text{ bytes/value} \implies \frac{12}{2} = 6 \text{ values max}\]

Worked example for temperature + humidity + battery:

Float approach: 3 × 4 bytes = 12 bytes (exactly full, no room for extras)
Integer approach: Temperature (1 byte, -40 to 85°C) + Humidity (1 byte, 0-100%) + Battery (1 byte, 2.0-4.2V × 100) = 3 bytes
Result: 9 bytes remaining for device ID (4 bytes), timestamp (2 bytes), and 3 reserved bytes

Integer encoding provides 4x better space efficiency: 3 bytes used (9 remaining) versus 12 bytes fully exhausted (0 remaining).

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

44.4.4 Mistake 4: “Downlinks are free, I’ll use them for acknowledgments”

What Developers Think:

“I’ll request a downlink ACK for every uplink to confirm delivery!”

What Actually Happens:

Downlink costs:
• Battery: Device must listen for 20-25 seconds after uplink
• Power consumption: 50-100 mA RX mode vs. 0.001 mA sleep
• Daily cost: ~1,800 mWh per downlink vs. 0.2 mWh uplink-only

Battery life calculation:
• 10-year battery (2,500 mAh): Uplink only
• 2-year battery: With daily downlink ACKs
• 6-month battery: With hourly downlink ACKs

Financial cost:
• Maintenance: Replacing 10,000 batteries every 2 years
• Labor: $20/battery replacement
• Total: 10,000 × $20 = $200,000 every 2 years

vs. uplink-only: $0 for 10 years (no battery changes)

Additional Downlink Problems:

Limited to 4/day (can’t ACK every message if sending >4/day)
Downlink uses 8 bytes (even smaller than uplink)
Downlink failure rate ~5% (not guaranteed delivery anyway)

Correct Approach:

❌ Don't use downlinks for: ACKs, heartbeats, routine confirmations
✅ DO use downlinks for:
   • Firmware update triggers (once/year)
   • Configuration changes (rare)
   • Emergency shutdown commands (critical only)
   • Sensor calibration updates (occasional)

Takeaway: Treat downlinks as expensive and scarce. Design uplink-only applications whenever possible.

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

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

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

44.5 Payload Encoding Pitfalls

Pitfall: 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

Pitfall: 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

44.6 Related Chapters

Continue Learning

Now that you understand Sigfox best practices and common mistakes, explore these related topics:

Prerequisite chapter:

Sigfox Introduction: If you haven’t read the fundamentals yet, start here for Sigfox basics, message limits, and use case evaluation

Next recommended chapters:

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: Optimizing Payload Encoding for Multi-Sensor Device

Scenario: You’re building a greenhouse monitor that needs to send temperature, humidity, soil moisture, light intensity, CO2 level, and battery voltage via Sigfox’s 12-byte payload.

Naive Approach (Fails):

Using 32-bit floats for everything:
- Temperature: 4 bytes (IEEE 754 float)
- Humidity: 4 bytes
- Soil moisture: 4 bytes
- Light intensity: 4 bytes
- CO2: 4 bytes
- Battery: 4 bytes
Total: 24 bytes → EXCEEDS 12-byte limit by 100%!

Optimized Approach (Fits):

Temperature (-40 to +60°C, 0.1°C precision):
- Range: 100°C × 10 = 1,000 values
- Storage: 2 bytes (int16: -400 to +600)
- Encoding: temp_int = temperature * 10
- Decoding: temperature = temp_int / 10.0
Humidity (0-100%, 0.1% precision):
- Range: 1,000 values (0.0 to 100.0)
- Storage: 2 bytes (uint16: 0 to 1,000)
- Encoding: hum_int = humidity * 10
Soil Moisture (0-100%, 1% precision):
- Range: 101 values
- Storage: 1 byte (uint8: 0 to 100)
- Encoding: soil_int = round(moisture)
Light Intensity (0-100,000 lux, logarithmic):
- Use logarithmic scale for efficiency
- Storage: 1 byte (0-255 maps to 0-100k lux exponentially)
- Encoding: light_byte = min(255, int(log10(lux + 1) * 51))
- Decoding: lux = 10^(light_byte / 51.0) - 1
- Why logarithmic? Human perception and plant needs follow log scale
CO2 Level (300-5,000 ppm, 10 ppm precision):
- Offset encoding (subtract minimum)
- Range: 4,700 ppm / 10 = 470 values
- Storage: 2 bytes (uint16: 0 to 470)
- Encoding: co2_int = (co2_ppm - 300) / 10
- Decoding: co2_ppm = (co2_int * 10) + 300
Battery Voltage (2.0-4.2V, 0.01V precision):
- Range: 2.2V × 100 = 220 values
- Storage: 1 byte (uint8: 0 to 220)
- Encoding: batt_byte = (voltage - 2.0) * 100
- Decoding: voltage = (batt_byte / 100.0) + 2.0
Status Flags (8 boolean states):
- Storage: 1 byte (8 bits):
  - Bit 0: Alarm triggered
  - Bit 1: Door open
  - Bit 2: Low battery warning
  - Bit 3: Sensor error
  - Bit 4: Heater on
  - Bit 5: Fan on
  - Bits 6-7: Reserved
Message Counter (tracks message order):
- Storage: 1 byte (0-255, wraps around)

Final Payload:

Byte 0-1:   Temperature (int16)
Byte 2-3:   Humidity (uint16)
Byte 4:     Soil moisture (uint8)
Byte 5:     Light intensity (uint8, log scale)
Byte 6-7:   CO2 level (uint16, offset)
Byte 8:     Battery voltage (uint8)
Byte 9:     Status flags (8 bits)
Byte 10:    Message counter (uint8)
Byte 11:    Checksum (optional, or reserved)
Total: 12 bytes exactly ✓

Example Encoding Code (Python):

import struct
from math import log10

def encode_greenhouse_payload(temp, humidity, soil, lux, co2, voltage, flags, counter):
    temp_int = int(temp * 10)
    hum_int = int(humidity * 10)
    soil_byte = int(soil)
    light_byte = min(255, int(log10(lux + 1) * 51))
    co2_int = int((co2 - 300) / 10)
    batt_byte = int((voltage - 2.0) * 100)

    # Pack into 12 bytes (little-endian)
    payload = struct.pack('<hHBBHBBBx',  # x = 1 padding byte
                          temp_int, hum_int, soil_byte, light_byte,
                          co2_int, batt_byte, flags, counter)
    return payload

# Example usage:
payload = encode_greenhouse_payload(
    temp=22.5, humidity=65.0, soil=78, lux=12000, co2=850,
    voltage=3.7, flags=0b00000011, counter=42
)
print(f"Payload: {payload.hex()}")

Results:

Before optimization: 24 bytes (couldn’t use Sigfox)
After optimization: 12 bytes (perfect fit!)
Precision loss: Minimal and acceptable for greenhouse monitoring
Message frequency: Every 10 minutes = 144 msgs/day, which exceeds the 140/day limit. Adjust interval to every 10.3 minutes (1,440 min / 140 = 10.29 min) to stay within the quota

Key Insights:

Floats are wasteful: 4 bytes vs. 1-2 bytes for scaled integer
Choose precision wisely: Does temperature really need 0.0001°C? No.
Logarithmic scales: Perfect for exponential-range sensors
Offset encoding: Subtract minimum value to reduce range
Bit packing: Store 8 boolean flags in 1 byte instead of 8 bytes

Interactive Quiz: Match Concepts

Interactive Quiz: Sequence the Steps

🏷️ Label the Diagram

💻 Code Challenge

44.7 Summary

Key Takeaways:

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

Best Practice Checklist:

Verify Sigfox coverage in ALL deployment locations
Design payloads to fit 12 bytes using integer encoding
Plan for uplink-only operation (minimize downlinks)
Calculate 5-year TCO including subscription fees
Pilot test 50-100 devices for 30 days before mass deployment
Register devices on backend.sigfox.com before first transmission
Accept 30-90 second latency for all messages

Common Pitfalls

1. Not Validating Payload Size Before Encoding

Implementing sensor data encoding without first calculating total byte count often leads to payloads exceeding 12 bytes. Design the encoding scheme on paper first, calculate exact byte usage, then implement — not the reverse.

2. Using Floating Point for Payload Values

Storing temperature as a float (4 bytes) wastes payload space. Use fixed-point encoding: temperature × 10 stored as int16 (2 bytes) covers −3276.8°C to +3276.7°C with 0.1°C resolution. Apply this principle to all sensor values to minimize payload size.

3. Not Testing Callback Reliability

Sigfox callbacks to application servers can fail for various reasons (SSL errors, server downtime, payload format issues). Always implement retry mechanisms and dead letter queues at the application server level, and test callback delivery under realistic conditions.

4. Designing Applications That Need More Than 140 Messages Per Day

If an application genuinely requires more than 140 daily messages, Sigfox is the wrong technology. Don’t design workarounds (encoding multiple readings per message, alternative communication channels for overflow) — select appropriate technology from the start.

44.8 What’s Next

Now that you understand Sigfox best practices and common deployment pitfalls, continue with these chapters:

Order	Chapter	Focus
1	Sigfox Technology Deep Dive	UNB modulation details, network architecture, and Atlas geolocation
2	Sigfox Worked Examples	Message budgets, TCO calculations, and link budget analysis
3	Sigfox Assessment	Comprehensive quiz covering all Sigfox topics
4	LoRaWAN Architecture	Compare with user-deployable LPWAN alternative