48  Sigfox Scenarios and Common Mistakes

In 60 Seconds

Sigfox’s 140 messages/day limit means a sensor needing updates every second (86,400/day) exceeds capacity by 617x. This chapter explores real-world failure scenarios where Sigfox’s constraints become blocking, common deployment mistakes, and how to calculate whether your application fits within Sigfox’s hard limits.

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

Learning Objectives

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

• Evaluate scenarios where Sigfox constraints make it unsuitable for specific IoT applications
• Analyze the impact of message limits on application design and data throughput
• Diagnose coverage dependency risks before committing to deployment
• Distinguish common Sigfox deployment mistakes from best practices
• Calculate message requirements and validate feasibility for your applications

Key Concepts

• Common Sigfox Mistakes: Frequent implementation errors including ignoring payload byte limits, exceeding daily message budget, improper frequency initialization, and callback misconfiguration.
• Scenario Analysis: Evaluating Sigfox deployment scenarios to determine feasibility, identify constraints, and design appropriate payload and message strategies.
• Payload Overflow: Attempting to send more than 12 bytes in an uplink message; Sigfox silently truncates or rejects oversized payloads requiring careful size management.
• Budget Exhaustion: Exceeding 140 uplinks per day causes subsequent messages to be dropped; application logic must track and manage daily message consumption.
• Frequency Configuration: Devices must be configured for correct regional frequency (EU: 868 MHz, US: 902 MHz) matching the deployment network zone.
• Callback Errors: Misconfigured HTTPS callbacks cause data loss; common issues include incorrect URL, missing authentication, and payload format mismatch.
• Technology Mismatch: Deploying Sigfox for applications requiring high data rate, frequent messages, or large payloads results in poor user experience and workarounds.

For Beginners: Sigfox Scenarios and Mistakes

Sigfox’s extreme simplicity is both its strength and its limitation. This chapter presents scenarios where Sigfox works well (infrequent, tiny messages from many devices) and where it does not (real-time monitoring, large data transfers). Learning from common deployment mistakes helps you use Sigfox where it truly shines.

Sensor Squad: When Sigfox Says No!

“Let me tell you about the time someone tried to send a photo through Sigfox,” Sammy the Sensor chuckled. “A wildlife camera tried to send a 500 KB photo through my 12-byte message slot. That is like trying to mail an elephant through a letterbox! It would take 41,667 messages and nearly 300 days to send one photo. The lesson? Sigfox is for tiny data – a temperature reading, a location ping, a yes-or-no status. Not pictures!”

“I learned about message limits the hard way,” Lila the LED admitted. “I was blinking every second trying to report my status, but Sigfox only allows 140 messages per day. At one message per second, I would need 86,400 messages – that is 617 times over the limit! After message 140, everything I sent just vanished into thin air. Now I only report once an hour, and I have plenty of messages to spare.”

Max the Microcontroller nodded wisely. “The biggest mistake I see is people not testing in the real deployment environment. A sensor works perfectly on your desk near a window, but put it underground in a metal box and the signal drops by 40-50 dB. That can take you from perfect coverage to zero connectivity. Always test where you will actually install – not where it is convenient.”

“And do not forget about coverage!” Bella the Battery warned. “Sigfox coverage is not everywhere like cellular. If you deploy 5,000 sensors in a region without Sigfox towers, they will just waste my energy transmitting into the void. Unlike LoRaWAN, you cannot deploy your own Sigfox base stations. Always check the coverage map first – it saves money and saves me!”

48.2 What Would Happen If… (Scenarios)

Understanding Sigfox Limitations Through Scenarios

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

---

48.2.2 Scenario 2: “What if you need to send a photo from a wildlife camera?”

Putting Numbers to It

Sending images through Sigfox’s 12-byte payload reveals why LPWAN technologies specialize in tiny data packets, not media:

Typical photo: 500 KB = 500,000 bytes

\[\text{Messages needed} = \frac{500{,}000 \text{ bytes}}{12 \text{ bytes/message}} = 41{,}667 \text{ messages}\]

\[\text{Time at 140 msg/day} = \frac{41{,}667}{140} = 298 \text{ days per photo}\]

Worked example: Wildlife camera sending 10 KB thumbnail:

10,000 bytes ÷ 12 = 833 messages needed
833 ÷ 140 = 6 days to transmit one tiny thumbnail

Battery impact: 833 × 0.083 mAh = 69 mAh per image
With 2000 mAh battery: Only 29 images before replacement!

LPWAN is designed for telemetry (numbers, status), not media (photos, video). Use cellular/Wi-Fi for images.

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

---

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

---

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

---

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

48.3 Common Mistakes (Avoid These Pitfalls!)

7 Sigfox Mistakes That Will Cost You Money

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

---

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

---

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

---

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

---

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

---

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

---

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

48.3.8 Interactive: Message Budget Calculator

viewof mbInterval = Inputs.range([1, 1440], {value: 60, step: 1, label: "Report interval (minutes)"})
viewof mbEvents = Inputs.range([0, 100], {value: 10, step: 1, label: "Extra events per day"})

{
  const scheduled = Math.floor(1440 / mbInterval);
  const total = scheduled + mbEvents;
  const limit = 140;
  const pct = (total / limit * 100).toFixed(1);
  const ok = total <= limit;
  const color = ok ? "#16A085" : "#E74C3C";
  const minInterval = Math.ceil(1440 / (limit - mbEvents));

  return html`<div style="background: linear-gradient(135deg, #2C3E50 0%, #34495E 100%); color: white; padding: 20px; border-radius: 8px; font-family: Arial, sans-serif; max-width: 480px;">
    <div style="font-size: 16px; font-weight: bold; margin-bottom: 12px;">Sigfox Daily Message Budget</div>
    <div style="display: grid; grid-template-columns: 1fr 1fr; gap: 6px; font-size: 13px;">
      <div>Scheduled messages:</div><div style="text-align:right">${scheduled}/day</div>
      <div>Event messages:</div><div style="text-align:right">${mbEvents}/day</div>
      <div>Total messages:</div><div style="text-align:right; font-weight:bold">${total}/day</div>
      <div>Daily limit:</div><div style="text-align:right">${limit}/day</div>
    </div>
    <div style="margin-top: 12px; padding: 10px; background: ${color}; border-radius: 6px; text-align: center; font-weight: bold;">
      ${pct}% utilization -- ${ok ? "WITHIN LIMIT" : "EXCEEDS LIMIT!"}
    </div>
    ${!ok ? html`<div style="font-size: 12px; margin-top: 6px; color: #E67E22;">Min safe interval: every ${minInterval} minutes</div>` : html``}
  </div>`;
}

48.4 Additional 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

Worked Example: Calculating Message Budget for Event-Driven Application

Scenario: You’re deploying 500 door sensors in a warehouse. Each sensor reports door open/close events plus hourly heartbeat. Will Sigfox work?

Requirements Analysis:

1. Heartbeat Messages:
   • Frequency: Every hour
   • Per day: 24 messages
   • Purpose: Confirm device is alive, report battery status
2. Event Messages:
   • Average: 10 door events per day per sensor (warehouse operations)
   • Peak: 30 events per day (busy season)
   • Each event: 1 open + 1 close = 2 messages

Message Budget Calculation:

Normal Operations (Average Day):

Heartbeat: 24 messages
Door events: 10 events × 2 messages = 20 messages
Total: 44 messages/day

Sigfox limit: 140 messages/day
Utilization: 44/140 = 31% ✓ PASS (69 messages spare)

Peak Operations (Busy Day):

Heartbeat: 24 messages
Door events: 30 events × 2 messages = 60 messages
Total: 84 messages/day

Utilization: 84/140 = 60% ✓ PASS (56 messages spare)

Extreme Scenario (Malfunction/Testing):

Door stuck in oscillation (open/close rapidly):
- 1 event per minute = 60 events/hour
- 60 × 2 = 120 messages/hour
- 120 messages in first hour already at 86% of daily limit!

Heartbeats: 24 messages
Faulty door: 120 messages (first hour only)
Total: 144 messages/day

Utilization: 144/140 = 103% ✗ EXCEEDS LIMIT by 4 messages

Risk Analysis:

Scenario	Probability	Messages/Day	Sigfox Fit	Risk Level
Normal ops	80%	44	✓ Pass	Low
Busy season	15%	84	✓ Pass	Low
Equipment fault	4%	144	✗ Fails	High
Security breach	1%	200+	✗ Fails	Critical

Design Solutions:

Solution 1: Rate Limiting (Recommended)

Implement device-side rate limiting:
- Max 60 event messages/day (30 events)
- If exceeded, buffer events and send summary
- Heartbeat reduces to 6/day during high activity
- Emergency override: Allow burst to 140 with no heartbeat

Daily budget allocation:
- Heartbeat: 24 messages (adjustable down)
- Events: 60 messages
- Errors/alerts: 20 messages
- Reserve: 36 messages (emergency burst)
Total: 140 messages exactly

Solution 2: Message Aggregation

Instead of separate open/close messages:
- Send one message every 15 minutes with event summary
- Payload (12 bytes):
  - Door ID: 2 bytes
  - Event count: 1 byte (0-255)
  - Status flags: 1 byte (currently open/closed, errors)
  - Battery: 1 byte
  - Last event timestamp: 4 bytes
  - Checksum: 1 byte
  - Reserved: 2 bytes

Messages per day:
- Aggregated updates: 96 (every 15 min)
- Heartbeat: 24
- Total: 120 messages/day ✓ Within 140 limit with margin

Solution 3: Hybrid Approach

Use Sigfox for normal monitoring + local LoRaWAN for high-frequency:
- Sigfox: Daily summaries, battery status, long-term trends
- LoRaWAN gateway (local): Real-time door events, alarms
- Cost: $500 gateway + $15/device (vs $12 Sigfox-only)
- Benefit: Handles unlimited event frequency locally

Cost-Benefit Analysis (500 devices over 5 years):

Approach	Device Cost	Infrastructure	Subscription	Total	Risk
Sigfox Only (Rate Limited)	$6,000	$0	$5,000	$11,000	Medium (some data loss)
Sigfox + Aggregation	$6,000	$0	$5,000	$11,000	Low (no data loss)
Hybrid (Sigfox + LoRaWAN)	$7,500	$500	$2,500	$10,500	Very Low (redundant)
LoRaWAN Only	$7,500	$2,000	$0	$9,500	Low (single network)

Recommendation for This Use Case:

Choose Solution 2 (Message Aggregation):

• Stays within Sigfox constraints
• No data loss during peak periods
• Lowest cost ($11,000)
• Simple deployment (no gateways)

Only choose Hybrid/LoRaWAN if:

• Security monitoring requires <5 sec response
• Budget allows $10,500
• IT team can manage gateway infrastructure

Key Insights:

1. Always calculate peak load: Average is misleading. Design for 95th percentile + 20% margin.

2. Rate limiting is essential: Device-side intelligence prevents quota exhaustion during anomalies.

3. Aggregation beats fragmentation: One summary message every 15 minutes is better than 30 individual event messages.

4. Reserve capacity: Always keep 20-30% of daily quota for unexpected events, firmware updates, retries.

5. Monitor utilization: Track daily message count remotely. Alert at 80% utilization to catch issues before hitting 140 limit.

48.5 Concept Relationships

Concept	Builds On	Enables	Common Confusion	Real-World Impact
140 Message/Day Limit	Duty cycle regulations, UNB transmission time	Application design (hourly vs real-time), battery optimization	Limit isn’t arbitrary - driven by 1% duty cycle physics	Every 10 min = 144/day (fails); hourly = 24/day (safe with 116 message margin)
12-Byte Payload Constraint	UNB 100 bps data rate, 2-second transmission time	Binary encoding, data compression strategies	12 bytes ≠ 12 characters - use binary not ASCII	Temperature as float = 4 bytes; as int16 = 2 bytes (saves 50% payload)
4 Downlink/Day Limit	Battery drain from 20-25 sec RX windows	Uplink-only architectures, autonomous devices	Each downlink costs 1,800 mWh vs 0.2 mWh uplink-only	Daily ACKs reduce 10-year battery to <1 year
Operator Coverage Dependency	Proprietary network, no self-deployment allowed	Technology selection, pilot testing requirements	Coverage maps show estimates not guarantees	Barcelona waste: 99.7% urban; rural farm: 40% success (unusable)
Cost Crossover Point	Subscription accumulation vs gateway amortization	Scale-based technology selection	Cheapest at small scale ≠ cheapest at large scale	<1K: Sigfox wins; >10K: LoRaWAN infrastructure amortizes

48.6 See Also

Learn from related deployment scenarios and alternatives:

• Sigfox Introduction - 12-byte encoding strategies, Barcelona waste management case study
• Sigfox Technology Deep Dive - UNB modulation physics, link budget calculations explaining range
• LoRaWAN Overview - User-deployable alternative with unlimited messages and 242-byte payloads
• LPWAN Comparison - Decision framework for choosing Sigfox vs LoRaWAN vs NB-IoT
• Sigfox Best Practices - Proven strategies for successful Sigfox deployments

Interactive Quiz: Match Concepts

Interactive Quiz: Sequence the Steps

🏷️ Label the Diagram

💻 Code Challenge

48.7 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

Common Pitfalls

1. Sending Debug Data Via Sigfox in Development

Using Sigfox to transmit diagnostic or debug information during development exhausts the daily message budget without delivering business value. Use serial console or Bluetooth for development debugging; reserve Sigfox transmissions for validated application data.

2. Not Handling Sigfox Transmission Return Codes

Sigfox AT command transmission functions return status codes indicating success or failure. Ignoring return codes means firmware continues as if messages were sent when they weren’t. Always check return codes and implement application-level retry logic.

3. Designing for Single Successful Reception

Sigfox sends each message 3 times for redundancy, but reception isn’t guaranteed. Applications must tolerate missing messages by designing around eventual consistency rather than guaranteed delivery. Time-series data with missing samples is normal, not exceptional.

4. Attempting Real-Time Tracking Over Sigfox

Asset tracking with GPS position updates every minute requires 1440 messages/day — 10x the Sigfox limit. Real-time tracking is fundamentally incompatible with Sigfox. Design position reporting to match Sigfox’s capabilities: daily summary or check-in on events.

48.8 What’s Next

Chapter	Focus Area
Sigfox Introduction and Basics	Core concepts, business model, and 12-byte encoding strategies
Sigfox Technology Deep Dive	UNB modulation physics, link budget calculations, and network architecture
Sigfox Examples and Assessment	Worked examples, payload design exercises, and knowledge checks
LoRaWAN Overview	User-deployable alternative with unlimited messages and 242-byte payloads