This chapter provides comprehensive assessment questions to test and reinforce your understanding of Sigfox technology, deployment considerations, and comparison with alternative LPWAN solutions.
NoteLearning Objectives
By the end of this assessment, you will be able to:
Demonstrate mastery of Sigfox technical specifications
Analyze real-world deployment scenarios
Make informed technology selection decisions
Identify common pitfalls and best practices
1107.2 Prerequisites
Complete all previous Sigfox chapters before this assessment:
Test your understanding across all Sigfox topics covered in this unit.
Question 1: A Sigfox device successfully sends uplink messages but downlink commands never arrive at the device. What is the MOST likely cause?
Option C is most likely - Device configuration issue:
Sigfox Downlink Mechanism:
How downlink works: 1. Device sends uplink message 2. Sigfox backend routes uplink to application server 3. Application server processes data 4. If downlink needed, application server sends downlink command to Sigfox backend within 20 seconds 5. Sigfox backend queues downlink for next device transmission 6. Device must explicitly request downlink on next uplink by setting “downlink flag” 7. After uplink, device opens RX window for 20-25 seconds 8. Backend sends downlink during RX window 9. Device receives and processes downlink
C - MOST LIKELY: Device not listening for downlink (RX window not enabled): - Root cause: Device firmware doesn’t set “request downlink” flag in uplink - Symptom: Uplinks successful, but device never enters RX mode - How this happens: - Firmware developer forgot to enable downlink request bit - Device uses “uplink-only” mode to save power (skips RX window = saves 500-1000 mAh per message) - Default Sigfox library config may have downlink disabled - Fix: Update firmware to set downlink request flag and open RX window - Likelihood: Very common mistake (60-70% of downlink issues)
Why Other Options Are Less Likely:
A - Exceeded daily downlink quota: - Possible if aggressively testing, but question states downlinks “never arrive” (implies 0 received)
B - Backend service outage: - Would affect uplinks too, but question states uplinks ARE working
D - Downlink payload too large: - Would cause backend error, not silent failure at device
Question 2: A building management system needs to monitor 200 temperature sensors. Each sensor should report every 10 minutes. Each message contains temperature (2 bytes), humidity (2 bytes), and battery status (1 byte) = 5 bytes total. Is Sigfox suitable?
Answer: B) No, exceeds 140 messages per day limit per device
Let’s calculate the message requirements:
Messages per device per day: - Frequency: Every 10 minutes - Messages per hour: 60 / 10 = 6 messages - Messages per day: 6 x 24 = 144 messages/day
Why other options are incorrect: - A: While the 5-byte payload fits comfortably in Sigfox’s 12-byte limit, payload size alone doesn’t determine suitability. The message frequency constraint is violated. - C: This is partially correct (reducing to 12-minute intervals would give 120 msg/day), but the question asks “is Sigfox suitable” with the stated requirements, not with modifications - D: Sigfox can technically support building automation, but it’s not the best choice for this application
Alternative solutions: 1. Reduce frequency to every 12 minutes: 120 msg/day 2. Use LoRaWAN instead: No daily message limit 3. Use local mesh network (Zigbee/Thread): Ideal for building automation
Question 3: A smart water meter uses a 2.5 Ah battery and sends one reading per day via Sigfox. Each transmission takes 6 seconds at 40 mA, and the device sleeps at 1 uA otherwise. What is the approximate battery life?
Answer: C) 20+ years (theoretical)
Let’s calculate the energy consumption:
Given: - Battery capacity: 2.5 Ah = 2,500 mAh - Transmission: 1 message/day, 6 seconds, 40 mA - Sleep current: 1 uA (0.001 mA)
Daily energy consumption:
Transmission energy: - TX current: 40 mA - TX duration: 6 seconds = 0.00167 hours - TX energy: 40 mA x 0.00167 h = 0.067 mAh/day
Sleep energy (23h 59m 54s): - Sleep current: 0.001 mA - Sleep duration: ~24 hours - Sleep energy: 0.001 mA x 24 h = 0.024 mAh/day
Total daily energy: - 0.067 + 0.024 = 0.091 mAh/day
Battery life: - 2,500 mAh / 0.091 mAh/day = 27,473 days = 75 years (theoretical)
In practice, accounting for: - Battery self-discharge: ~2-3% per year - Capacity degradation over time - Temperature effects - Sensor measurement power
Practical battery life: 15-25 years
Option C (20+ years) is the closest answer for this ultra-efficient single-daily-message scenario.
Question 4: A startup is evaluating Sigfox vs LoRaWAN for a smart agriculture deployment of 2,000 soil sensors across 500 farms in rural France. The startup has no IoT expertise, minimal budget, and needs to launch in 2 months. Sigfox has excellent coverage in the region. Which technology recommendation is MOST appropriate?
Answer: A) Sigfox because the operator-managed network eliminates infrastructure deployment
Analysis of scenario requirements:
Requirement
Sigfox Fit
LoRaWAN Fit
No IoT expertise
Excellent (zero infrastructure)
Poor (gateway management needed)
Minimal budget
Good ($6/year subscription)
Higher CapEx (gateways)
2-month launch
Excellent (instant coverage)
Poor (gateway deployment time)
Rural France coverage
Excellent (verified)
Unknown (must deploy)
Soil sensors (small data)
Perfect (fits 12 bytes)
Overkill (up to 243 bytes)
Why A is correct: - Zero infrastructure investment - Rapid deployment (activate devices, start collecting data) - No technical team required for network management - Coverage already verified in target region - Soil sensor data fits easily in 12-byte payload
Why B is incorrect: - Soil sensors transmit simple data (moisture, temp, pH) - Higher data rates unnecessary for this use case - LoRaWAN complexity adds deployment risk
Why C is incorrect: - Data privacy is valid but secondary consideration - Basic soil sensor data isn’t valuable IP - 2-month deadline makes private network risky
Why D is incorrect: - NB-IoT costs $24-60/year per device vs $6-10 for Sigfox - Rural cellular coverage often weaker than LPWAN - Question states Sigfox has “excellent coverage”
Question 5: An engineer is designing an IoT sensor for a steel manufacturing plant with heavy electromagnetic interference from welding equipment. The sensor must achieve 15+ km range to reach the nearest base station. Why might Sigfox’s ultra-narrowband (UNB) technology be advantageous?
Answer: B) UNB’s 100 Hz bandwidth concentrates signal energy and filters out wideband interference
Interference Filtering: - Wideband EMI from welding/motors spreads across MHz of spectrum - Sigfox receiver only “listens” to 100 Hz slice - Most interference energy falls outside this narrow passband - Effectively filtered out by the receiver
Signal Concentration: - Same TX power concentrated into narrow channel - Higher energy density at target frequency - Better signal-to-noise ratio despite interference
Why Other Options Are Wrong:
A: Frequency hopping across 1,920 channels: - Partially correct concept but misleading - Sigfox uses channel selection, not continuous hopping - The key advantage is narrow bandwidth, not hopping
C: 868 MHz naturally immune: - Incorrect. 868 MHz has no special immunity - What matters is the signal processing technique
D: Encryption makes signal invisible: - Incorrect. Encryption protects data, not signal integrity - Interference rejection comes from bandwidth filtering
1107.4 Scenario-Based Questions
NoteScenario 1: Message Constraints Analysis
A building management system needs to monitor 200 temperature sensors. Each sensor should report every 10 minutes. Each message contains temperature (2 bytes), humidity (2 bytes), and battery status (1 byte) = 5 bytes total. Is Sigfox suitable?
Click to reveal analysis
Calculation:
Messages per hour: 60 / 10 = 6 messages
Messages per day: 6 x 24 = 144 messages/day
Sigfox limit: 140 messages/day
Result: 144 > 140, exceeds limit by 4 messages/day
Solutions:
Reduce frequency to every 12 minutes: 24/12 x 24 = 120 msg/day
Use LoRaWAN instead: No daily message limit
Use local mesh (Zigbee/Thread): Better for dense indoor deployment
Best choice for this scenario: LoRaWAN or Zigbee, not Sigfox.
NoteScenario 2: Cost Comparison
A logistics company needs to track 10,000 shipping pallets across a country. Each pallet reports location once per day. Compare the 5-year TCO between Sigfox ($8/device + $6/year) and private LoRaWAN ($15/device + $2,000/gateway, need 50 gateways, $500/month network server).
Click to reveal analysis
Sigfox 5-Year TCO:
Devices: 10,000 x $8 = $80,000
Subscription: 10,000 x $6/year x 5 years = $300,000
Total: $380,000
LoRaWAN 5-Year TCO:
Devices: 10,000 x $15 = $150,000
Gateways: 50 x $2,000 = $100,000
Network server: $500/month x 60 months = $30,000
Gateway backhaul: 50 x $30/month x 60 = $90,000
Maintenance estimate: $5,000/year x 5 = $25,000
Total: $395,000
Result: Similar cost, with Sigfox slightly cheaper (~$15,000 less) but consider:
Sigfox: Simpler deployment, operator dependency
LoRaWAN: More control, no message limits, larger payloads
Decision factors beyond cost: - Coverage gaps in deployment area? - Need for firmware updates? - Data privacy requirements? - Message frequency needs?
NoteScenario 3: Power Consumption
A smart agriculture sensor sends 6 readings per day. After 6 months, battery life projections show sensors will deplete in 3 years instead of the designed 10 years. Investigation reveals each sensor requests a downlink after every uplink. What’s wrong?
Click to reveal analysis
Root Cause Analysis:
Without Downlink (Design Target): - 6 uplinks/day x 0.067 mAh = 0.4 mAh/day - Sleep: 0.024 mAh/day - Total: 0.424 mAh/day - Battery life: 2000 mAh / 0.424 = 4,717 days = 12.9 years
With Downlink After Every Uplink (Actual): - 6 uplinks/day x 0.067 mAh = 0.4 mAh/day - 6 RX windows/day x 1.25 mAh = 7.5 mAh/day - Sleep: 0.024 mAh/day - Total: 7.924 mAh/day - Battery life: 2000 mAh / 7.924 = 252 days = 0.69 years (or ~2.5 years with larger battery)
The Problem: - Each downlink RX window consumes ~18x more energy than uplink - Requesting downlink after EVERY uplink is wasteful - Battery drain increased 18x for no benefit
Solution: - Only request downlink when configuration update expected - Typical: Once per week or month, not every message - Battery life recovery: 10+ years achievable
1107.5 Summary and Key Takeaways
1107.5.1 Sigfox Technology Summary
Sigfox provides a complete LPWAN solution through its proprietary network-as-a-service model:
Key Specifications:
Parameter
Value
Uplink payload
12 bytes maximum
Uplink messages
140 per day
Downlink payload
8 bytes maximum
Downlink messages
4 per day
Data rate
100 bps uplink, 600 bps downlink
Range
3-10 km urban, 30-50 km rural
Sensitivity
-142 dBm
Battery life
10-20 years possible
Key Advantages:
Lowest device cost (~$5-15 per module)
Simplest device implementation
No infrastructure investment required
Global coverage through single subscription
Built-in geolocation (Sigfox Atlas)
Key Limitations:
140 messages/day maximum
12-byte uplink payload limit
4 downlink messages/day maximum
Operator dependency (cannot self-deploy)
Proprietary protocol (vendor lock-in)
Coverage gaps in some regions (Asia, Africa)
Best Applications:
Smart metering (water, gas, electricity)
Infrequent asset tracking
Environmental sensors (agriculture, weather)
Smart city infrastructure (waste, parking, lighting)
Any application with < 100 messages/day and small payloads