49  Sigfox Worked Examples

49.1 Learning Objectives

After completing this chapter, you should be able to:

• Calculate Sigfox message budgets for real deployments and verify they stay within the 140-message daily limit
• Design compact 12-byte payload encodings that pack GPS coordinates, temperature, and status into a single Sigfox message
• Evaluate total cost of ownership (TCO) trade-offs between Sigfox subscriptions and LoRaWAN infrastructure for fleet-scale deployments, identifying the break-even point
• Apply UNB link budget calculations to estimate coverage range and diagnose potential dead zones in rural deployments

Key Concepts

• Payload Design Worked Example: Step-by-step process of fitting multiple sensor readings (temperature, humidity, battery voltage, status flags) into 12-byte Sigfox payload.
• Message Budget Example: Daily message allocation calculation for a deployment requiring scheduled readings plus event-driven alerts within 140 message limit.
• Coverage Calculation: Link budget worked example computing maximum range for given TX power, antenna gain, path loss model, and target reception reliability.
• Encoding Techniques: Practical encoding methods including fixed-point scaling (e.g., temperature × 10 stored as uint16), bit masking for flags, and little-endian byte ordering.
• Payload Decoding: Corresponding decoder logic transforming received hex payload back into physical values; typically implemented as JavaScript in cloud platforms.
• Battery Life Calculation: Energy budget worked example estimating battery life given sleep current, TX duration, message frequency, and battery capacity.
• End-to-End Example: Complete worked scenario from sensor reading through payload construction, Sigfox transmission, backend receipt, callback delivery, and application processing.

For Beginners: Sigfox Worked Examples

These worked examples walk through complete Sigfox solutions step by step – from choosing the right message format to calculating battery life and estimating network coverage. Each example uses real numbers and practical constraints so you can apply the same approach to your own Sigfox projects.

Sensor Squad: Crunching the Numbers!

“These worked examples are where theory meets reality,” Sammy the Sensor said. “Take container tracking: 1,000 containers reporting GPS every 4 hours need only 6.7 messages per day – that is just 4.7% of the 140-message quota. And I can pack GPS coordinates, temperature, shock level, battery, and status flags into exactly 12 bytes using integer encoding. Every byte accounted for!”

“The cost comparisons are eye-opening,” Lila the LED added. “For 5,000 parking sensors, Sigfox costs $265,000 over 5 years while LoRaWAN costs $289,600. Sigfox wins by $24,600 at that scale. But the crossover point is around 9,100 sensors – above that, LoRaWAN’s one-time gateway investment beats Sigfox’s recurring subscriptions. Always calculate the break-even before deciding.”

Max the Microcontroller drew a link budget diagram. “The range calculation is fascinating. At 25 km with hilly terrain, Sigfox still has 24.75 dB of link margin – well above the 15 dB safety threshold. That is because ultra-narrowband modulation gives Sigfox -142 dBm receiver sensitivity, which is 5 dB better than LoRaWAN. Those 5 dB translate to about 1.8 times more range!”

“Battery life depends entirely on message rate,” Bella the Battery noted. “At 140 messages per day – the maximum – I drain a 5,000 milliamp-hour battery in just a few months because each message takes 18 seconds of transmit time with triple redundancy. But reduce to about 7 messages per day and I last 5 years. At just 4 messages per day for agriculture sensors, I can go even longer! The worked examples show you exactly how to calculate these trade-offs for your own project.”

In 60 Seconds

These worked examples walk through real Sigfox deployment calculations: a 1,000-container tracking scenario needing 201 messages over 30 days (within budget at 6.7/day), GPS + temperature + status packed into exactly 12 bytes, and cost analysis for large-scale fleet deployments comparing Sigfox subscriptions vs LoRaWAN infrastructure.

49.2 Worked Examples

Worked Example: Sigfox Message Budget for Asset Tracking

Scenario: A logistics company wants to track 1,000 shipping containers using Sigfox. Each container needs to report its location and status during ocean transit (typically 30 days). Can Sigfox meet the tracking requirements within its message limits?

Given:

• Number of containers: 1,000
• Transit duration: 30 days average
• Sigfox uplink limit: 140 messages per day per device
• Sigfox downlink limit: 4 messages per day per device
• Payload size: 12 bytes maximum
• Required tracking data: GPS (8 bytes), temperature (1 byte), shock alert (1 byte), battery (1 byte), status (1 byte) = 12 bytes total

Step 1: Define tracking requirements

Location updates needed:
- Port departure: 1 message
- Ocean transit: Position every 4 hours = 6 per day × 30 days = 180 messages
- Port arrival: 1 message
- Total location: 182 messages over 30 days

Event alerts:
- Temperature excursion: Up to 5 events
- Shock/impact: Up to 10 events
- Door open/close: Up to 4 events
- Total events: ~19 messages

Grand total: 182 + 19 = 201 messages per transit

Step 2: Check against Sigfox daily limits

Sigfox limit: 140 messages per day
Required per day (transit): 6 location + ~0.6 events = 6.6 messages/day

6.6 messages/day << 140 messages/day limit

VERDICT: Well within daily limit (using only 4.7% of quota)

Step 3: Optimize message payload (12-byte constraint)

Standard GPS: Latitude (4 bytes) + Longitude (4 bytes) = 8 bytes
Temperature: Signed integer (-40 to +85C) = 1 byte
Shock level: 0-255 scale = 1 byte
Battery: 0-100% = 1 byte
Status flags: Door, motion, alarm = 1 byte

Total: 8 + 1 + 1 + 1 + 1 = 12 bytes (exactly fits!)

Example encoded message:
41.8902N, -87.6245W, 23C, no shock, 87%, door closed
Hex: 41 B9 45 C8 A7 B9 0A 17 00 57 00 00

Step 4: Calculate 5-year cost comparison

Sigfox Solution:
- Hardware (Sigfox module): 1,000 × $15 = $15,000
- Subscription: 1,000 × $2/year × 5 = $10,000
- Total 5-year: $25,000 ($25/container)

Cellular (NB-IoT) Solution:
- Hardware: 1,000 × $25 = $25,000
- SIM + data: 1,000 × $60/year × 5 = $300,000
- Total 5-year: $325,000 ($325/container)

Sigfox savings: $300,000 (92% cost reduction)

Result: Sigfox is ideal for this use case - the container tracking requirements use only 4.7% of the daily message quota, the 12-byte payload fits perfectly, and the 5-year cost is 92% lower than cellular alternatives.

Key insight: Sigfox excels when you can design your data to fit the 12-byte payload constraint. GPS coordinates can be encoded efficiently (8 bytes covers global positioning to ~1 meter accuracy). The 140 messages/day limit is rarely a constraint for asset tracking applications that update hourly or less frequently. Calculate your actual message needs - many applications use less than 10% of the Sigfox quota.

Worked Example: Sigfox vs LoRaWAN TCO for Smart Parking

Scenario: A city is deploying 5,000 parking sensors across downtown. Each sensor detects vehicle presence and sends status updates. The city needs to choose between Sigfox and LoRaWAN based on 5-year total cost of ownership.

Given:

• Number of sensors: 5,000
• Message frequency: Event-driven (car arrives/departs) + hourly heartbeat
• Average messages per sensor per day: 20 (10 car events + 14 heartbeats, within 140 limit)
• Payload: 5 bytes (sensor ID, status, battery, timestamp)
• Deployment area: 15 km² downtown area
• Sigfox coverage: Available from regional operator
• LoRaWAN: Would require private gateway deployment

Step 1: Calculate Sigfox costs

Hardware:
- Sigfox sensor modules: 5,000 × $18 = $90,000
- Installation: 5,000 × $25 = $125,000

Subscription (5 years):
- Annual fee: 5,000 × $2/year = $10,000/year
- 5-year total: $10,000 × 5 = $50,000

Infrastructure: $0 (uses operator network)

Sigfox Total 5-Year: $90,000 + $125,000 + $50,000 = $265,000
Per sensor: $53

Step 2: Calculate LoRaWAN costs

Hardware:
- LoRaWAN sensor modules: 5,000 × $22 = $110,000
- Installation: 5,000 × $25 = $125,000

Gateway infrastructure:
- Gateways needed (15 km² / 2 km² coverage each): 8 gateways
- Gateway cost: 8 × $1,200 = $9,600
- Gateway installation (rooftop): 8 × $500 = $4,000
- Gateway internet backhaul: 8 × $50/month × 60 = $24,000

Network server:
- Cloud LoRaWAN service: $200/month × 60 = $12,000
  OR
- Self-hosted: $5,000 initial + $2,000/year maintenance = $15,000

Operations:
- Gateway maintenance: $1,000/year × 5 = $5,000

LoRaWAN Total 5-Year: $110,000 + $125,000 + $9,600 + $4,000 + $24,000 + $12,000 + $5,000 = $289,600
Per sensor: $57.92

Step 3: Compare and analyze

Cost Summary:
- Sigfox 5-year: $265,000
- LoRaWAN 5-year: $289,600
- Difference: $24,600 (LoRaWAN costs 9.3% more)

Operational Comparison:
                    Sigfox          LoRaWAN
Infrastructure      None            8 gateways to maintain
Deployment time     2 weeks         2 months (gateway install)
Coverage guarantee  Operator SLA    Self-managed
Scalability         Unlimited       May need more gateways
Network control     None            Full control

Step 4: Break-even analysis

Putting Numbers to It

The break-even calculation determines the fleet size where LoRaWAN’s upfront infrastructure cost is offset by Sigfox’s recurring subscriptions:

LoRaWAN fixed costs (5-year): \[C_{fixed} = \$9{,}600 + \$4{,}000 + \$24{,}000 + \$12{,}000 + \$5{,}000 = \$54{,}600\]

Per-device costs:

• LoRaWAN: \(\$22 + \$25 = \$47\) (no subscription)
• Sigfox: \(\$18 + \$25 + (\$2 \times 5) = \$53\) (includes 5-year subscription)

Break-even point where costs equal: \[N \times \$53 = \$54{,}600 + N \times \$47\] \[N \times (\$53 - \$47) = \$54{,}600\] \[N = \frac{\$54{,}600}{\$6} = 9{,}100 \text{ sensors}\]

Worked example at different scales:

1,000 sensors: Sigfox $53k vs LoRaWAN $102k → Sigfox wins by $49k
5,000 sensors: Sigfox $265k vs LoRaWAN $290k → Sigfox wins by $25k
9,100 sensors: Sigfox $482k vs LoRaWAN $482k → Break-even!
15,000 sensors: Sigfox $795k vs LoRaWAN $760k → LoRaWAN wins by $35k

Above 9,100 devices, each additional sensor adds $6 to LoRaWAN’s advantage.

Result: For this 5,000-sensor deployment, Sigfox is $24,600 cheaper with zero infrastructure management. However, if the city expands to 10,000+ sensors, LoRaWAN would become more economical due to its zero per-device recurring fees.

Key insight: The Sigfox vs LoRaWAN decision depends heavily on scale. Below ~9,000 devices, Sigfox’s operator model eliminates infrastructure complexity and reduces TCO. Above that threshold, LoRaWAN’s gateway investment becomes amortized across enough devices to beat Sigfox’s subscription fees. Always calculate the crossover point for your specific deployment - it varies based on gateway costs, coverage area, and local Sigfox subscription rates.

Worked Example: Sigfox UNB Link Budget for Remote Agricultural Monitoring

Scenario: A vineyard deploys soil moisture sensors across 50 km of hilly terrain in rural France. The nearest Sigfox base station is 25 km away. Will the UNB (Ultra-Narrow Band) technology provide reliable connectivity at this extreme range?

Given:

• Distance to base station: 25 km
• Frequency: 868 MHz (RC1 Europe)
• Sigfox TX power: 14 dBm (25 mW, EU limit)
• Device antenna gain: 0 dBi (simple wire antenna)
• Base station antenna gain: 6 dBi (omnidirectional tower)
• Base station height: 30 meters
• Terrain: Hilly rural with vineyard rows
• Sigfox receiver sensitivity: -142 dBm (UNB advantage)
• Required link margin: 15 dB (for weather, seasonal foliage)

Step 1: Calculate free-space path loss

\[FSPL = 20 \log_{10}(d_{km}) + 20 \log_{10}(f_{MHz}) + 32.45\]

For 25 km at 868 MHz:

FSPL = 20 × log10(25) + 20 × log10(868) + 32.45
FSPL = 28.0 + 58.8 + 32.45 = 119.25 dB

Step 2: Add terrain and environmental losses

Hilly terrain (non-line-of-sight): +12 dB
Vegetation (vineyard canopy): +4 dB
Weather margin (rain fade at 868 MHz): +2 dB
Total additional losses: +18 dB

Total path loss = 119.25 + 18 = 137.25 dB

Step 3: Calculate link budget

Uplink Link Budget:
────────────────────────────────────
TX power (sensor):           +14 dBm
TX antenna gain:             +0 dBi
Path loss:                   -137.25 dB
RX antenna gain (base):      +6 dBi
────────────────────────────────────
Signal at receiver:          -117.25 dBm

Sigfox sensitivity:          -142 dBm
Link margin available:       24.75 dB
Required margin:             15 dB
Excess margin:               9.75 dB

Step 4: Compare with LoRaWAN at same distance

LoRaWAN SF12 sensitivity: -137 dBm (best case)
Signal at receiver: -117.25 dBm
LoRaWAN margin: 19.75 dB

Sigfox margin: 24.75 dB
Sigfox advantage: +5 dB (1.8x better range)

Step 5: Validate with Sigfox triple-redundancy

Sigfox transmits each message 3 times on different frequencies:
- If 1 transmission fails (interference), 2 others likely succeed
- Effective reliability at 24.75 dB margin: >99.9%

Per-transmission success probability at 24.75 dB margin: ~99%
3 independent transmissions: 1 - (0.01)³ = 99.9999%

Result: The vineyard sensors will work reliably at 25 km range with 24.75 dB link margin (9.75 dB excess). Sigfox’s -142 dBm sensitivity provides 5 dB advantage over LoRaWAN SF12, enabling this extreme-range rural deployment.

Key Insight: Sigfox’s ultra-narrow band (100 Hz) modulation concentrates transmission energy, achieving -142 dBm sensitivity versus LoRa’s -137 dBm at SF12. This 5 dB advantage translates to ~1.8x range extension, making Sigfox ideal for sparse rural deployments where base stations are far apart. The triple-redundancy transmission pattern further improves reliability in challenging RF environments.

Check Your Understanding: Link Budget Fundamentals

Worked Example: Sigfox Duty Cycle and Message Timing Compliance

Scenario: A cold chain logistics company tracks 500 refrigerated containers. Each container has sensors for temperature, door status, and GPS location. The company wants to maximize tracking frequency while staying within Sigfox’s 140 messages/day limit and EU duty cycle regulations.

Given:

• Sigfox payload: 12 bytes maximum
• Sigfox uplink limit: 140 messages per day per device
• EU868 duty cycle: 1% (36 seconds per hour TX time)
• Sigfox frame duration: ~6 seconds per frame (including preamble, payload at 100 bps, and guard time), 3 frames per message = ~18 seconds total TX time
• Required data: GPS (6 bytes), temperature (2 bytes), door status (1 byte), battery (1 byte), timestamp (2 bytes) = 12 bytes

Step 1: Calculate maximum message rate under duty cycle

EU868 duty cycle limit: 1% = 36 seconds/hour TX time
Sigfox total TX time per message: ~18 seconds (3 frames x ~6 seconds each)
Max messages/hour (duty cycle): 36 / 18 = 2 messages/hour
Max messages/day (duty cycle): 2 x 24 = 48 messages/day

Step 2: Compare with Sigfox network limit

Sigfox network limit: 140 messages/day
EU duty cycle limit: 48 messages/day (with triple transmission)
Binding constraint: EU duty cycle (48/day)

The EU868 1% duty cycle limit (48 messages/day with triple transmission) is more restrictive than the Sigfox 140-message network limit. The cold chain schedule below uses 140 messages as the Sigfox network ceiling, but in practice EU devices are limited to ~48 messages/day by duty cycle regulations. In the US (FCC Part 15, no duty cycle mandate), the 140/day Sigfox limit applies. Always check both constraints for your deployment region.

Step 3: Design optimal tracking schedule

Container states and tracking needs:
────────────────────────────────────
1. Stationary at warehouse: Low priority
   - 1 message every 4 hours = 6 messages/day

2. In transit (truck/ship): High priority
   - 1 message every 10 minutes during active hours
   - Active period: 12 hours/day
   - Messages: 72 messages/day

3. Temperature alarm: Critical
   - Immediate transmission on threshold breach
   - Reserve: 20 messages/day for alarms

4. Door open/close events: Important
   - Max 10 events/day typical
   - Reserve: 15 messages/day

Total allocation:
- Stationary: 6
- Transit tracking: 72
- Temperature alarms: 20
- Door events: 15
- Buffer: 27 (for retries, unexpected events)
────────────────────────────────────
Total: 140 messages/day (exactly at limit)

Step 4: Optimize payload encoding

GPS encoding example:

• Latitude 48.8566N = 488566 = 0x07 0x74 0x26 (3 bytes)
• Longitude 2.3522E = 23522 = 0x00 0x5B 0xE2 (3 bytes)
• Resolution: 0.0001 degrees = approximately 11 meters (sufficient for container tracking)

Step 5: Calculate battery impact of message rate

Energy per Sigfox message (including 3x redundant transmissions):
- TX current: 50 mA
- TX duration per message: 3 frames × ~6 seconds each = 18 seconds total
- Energy per message: 50 mA × 18s = 900 mAs = 0.25 mAh

Daily consumption at 140 messages:
- TX energy: 140 × 0.25 = 35 mAh
- Sleep (3 uA × 24h): 0.072 mAh
- Total daily: 35.07 mAh

Battery life with 5000 mAh battery:
- Theoretical: 5000 / 35.07 = 142.6 days = ~4.7 months
- With 70% usable capacity: 99.8 days = ~3.3 months

For 5-year operation, reduce to:
- Target daily energy: 5000 × 0.7 / (5 × 365) = 1.92 mAh/day
- Messages/day: (1.92 - 0.072) / 0.25 = ~7.4 messages/day
- Update every ~3.2 hours (acceptable for stationary containers)

Result: The cold chain system can achieve 10-minute tracking intervals during transit (72 messages) plus temperature alarms and door events, staying within the 140 messages/day Sigfox limit (though EU duty cycle restricts to ~48/day). At maximum rate (140 messages/day), battery life with a 5,000 mAh cell is only ~3-5 months. For 5-year battery life, reduce to ~7 messages/day (every ~3.2 hours), which is suitable for stationary monitoring but not high-frequency transit tracking.

Key Insight: In EU868, duty cycle regulations (48 messages/day with triple transmission) are actually more restrictive than the 140 messages/day Sigfox network limit. In the US (no duty cycle), the 140/day Sigfox limit applies. Always check both constraints for your deployment region. For cold chain, prioritize temperature alarms (immediate) over regular position updates (can be less frequent). The 12-byte payload constraint requires careful data encoding - GPS coordinates fit in 6 bytes using scaled integers with 11-meter resolution.

49.3 Related Chapters

Continue Learning

Explore related Sigfox topics:

Previous chapters:

• Sigfox Introduction: Fundamentals, business model, and common mistakes
• Sigfox Technology: UNB modulation, network architecture, and Atlas geolocation

Next chapter:

• Sigfox Assessment: Test your knowledge with comprehensive quizzes

Related topics:

• LoRaWAN Architecture: Alternative LPWAN for comparison
• Network Planning: General network design principles

Common Mistake: Ignoring Duty Cycle vs. Message Limit Interaction

The Mistake: Developers assume that because EU868 ISM band has a 1% duty cycle limit (36 seconds of transmission per hour), Sigfox’s 140 messages/day limit is the only constraint. In reality, these two limits interact in ways that can break your design if you don’t calculate both.

Example Failure Case: High-Frequency Asset Tracker

Initial Design (Flawed):

• Update frequency: Every 6 minutes
• Messages per hour: 60 / 6 = 10 messages/hour
• Messages per day: 10 × 24 = 240 messages/day
• Developer notices: 240 > 140 daily limit, reduces to every 10 minutes
• New frequency: 6 messages/hour, 144 messages/day

Developer’s conclusion: “144 messages/day is close to 140 limit, but I’ll add retry logic to skip some messages. Should work!”

What Actually Happens:

Each Sigfox transmission consists of 3 redundant transmissions on different frequencies (triple transmission for reliability): - Single message TX time: ~6 seconds - Triple transmission: 6 seconds × 3 = 18 seconds per Sigfox message

Duty Cycle Calculation (The Hidden Constraint):

EU868 1% duty cycle per hour: - Allowed TX time: 1% × 3600 seconds = 36 seconds/hour - Sigfox messages per hour at 18 seconds each: 36 / 18 = 2 messages/hour max - Daily maximum (duty cycle): 2 × 24 = 48 messages/day

Collision of Constraints:

Constraint	Limit	Developer’s Design	Result
Sigfox daily messages	140/day	144/day	⚠️ Slightly over
EU868 duty cycle	48/day	144/day	❌ 3x over limit!

Actual Deployment Outcome:

• Device attempts to send 144 messages/day (every 10 minutes)
• After ~2 messages/hour, duty cycle is exhausted
• Device queues remaining 4 messages/hour (8 hours × 4 = 32 messages piled up overnight)
• Next hour starts, device attempts to clear backlog + new messages
• Backlog keeps growing → device crashes after 3 days with 96 messages in queue

The Correct Calculation:

Step 1: Calculate Duty Cycle Limit (Most Restrictive)

For Sigfox triple-transmission (18 seconds): - EU868 1%: 36 seconds/hour ÷ 18 seconds/message = 2 messages/hour = 48 messages/day - US902 (no duty cycle, but spectrum etiquette): Effectively unlimited but polite usage ~100/day

Step 2: Apply Sigfox Network Limit

Sigfox allows 140 messages/day globally, but duty cycle may be more restrictive: - Europe (EU868): min(48, 140) = 48 messages/day (duty cycle wins) - USA (US902): min(140, ~100) = 140 messages/day (Sigfox limit wins) - Asia (AS923): Varies by country; Japan 1% = 48/day, Singapore 0.1% = 4.8/day

Step 3: Design for Most Restrictive

Region	Duty Cycle	Sigfox Limit	Effective Daily Max	Safe Design Target
EU868	48/day	140/day	48/day	40/day (17% margin)
US902	None	140/day	140/day	120/day (14% margin)
AS923 (Japan)	48/day	140/day	48/day	40/day (17% margin)
AS923 (Singapore)	4.8/day	140/day	4.8/day	4/day (20% margin)

Corrected Design:

For global deployment, design for worst case (Singapore AS923 0.1% = 4 messages/day): - Update interval: 6 hours (4 updates/day) - Fits Singapore: 4 ≤ 4.8 ✓ - Fits Europe: 4 ≤ 48 ✓ - Fits USA: 4 ≤ 140 ✓ - Works globally without region-specific firmware

Best Practice Rule:

safe_messages_per_day = min(
    sigfox_limit,              // 140 messages/day
    duty_cycle_limit,          // varies by region
    reliability_buffer * 0.85   // 15% margin for retries
)

Always calculate both constraints and use the minimum as your design limit. Never assume the 140 message/day limit is the only thing that matters.

Red Flag: If your region isn’t in the Sigfox documentation with explicit duty cycle guidance, assume 1% duty cycle (EU868 standard) as safe default until confirmed otherwise. Assuming “unlimited” based on US902 experience will break your product in other markets.

49.4 Interactive: Sigfox vs LoRaWAN TCO Calculator

viewof numDevices = Inputs.range([100, 20000], {value: 5000, step: 100, label: "Number of devices"})
viewof sigfoxHw = Inputs.range([5, 30], {value: 18, step: 1, label: "Sigfox hardware ($/device)"})
viewof sigfoxSub = Inputs.range([1, 12], {value: 2, step: 0.5, label: "Sigfox subscription ($/yr)"})
viewof lorawanHw = Inputs.range([10, 40], {value: 22, step: 1, label: "LoRaWAN hardware ($/device)"})
viewof gwCost = Inputs.range([500, 3000], {value: 1200, step: 100, label: "Gateway cost ($)"})
viewof gwCount = Inputs.range([1, 50], {value: 8, step: 1, label: "Gateways needed"})

{
  const years = 5;
  const installCost = 25;
  const gwBackhaul = 50; // per month per gateway
  const netServer = 200; // per month
  const gwMaint = 1000; // per year

  const sfTotal = numDevices * (sigfoxHw + installCost) + numDevices * sigfoxSub * years;
  const lwFixed = gwCount * gwCost + gwCount * 500 + gwBackhaul * gwCount * 12 * years + netServer * 12 * years + gwMaint * years;
  const lwTotal = numDevices * (lorawanHw + installCost) + lwFixed;
  const diff = sfTotal - lwTotal;
  const breakeven = Math.round(lwFixed / ((sigfoxHw + installCost + sigfoxSub * years) - (lorawanHw + installCost)));
  const winner = diff < 0 ? "Sigfox" : "LoRaWAN";
  const savings = Math.abs(diff);

  return html`<div style="background: linear-gradient(135deg, #f8f9fa, #e9ecef); padding: 1.5rem; border-radius: 8px; border-left: 4px solid #3498DB; font-family: system-ui;">
    <div style="display: grid; grid-template-columns: 1fr 1fr 1fr; gap: 1rem;">
      <div style="background: white; padding: 1rem; border-radius: 6px;">
        <div style="color: #7F8C8D; font-size: 0.85rem;">Sigfox 5-Year TCO</div>
        <div style="font-size: 1.5rem; font-weight: 700; color: #16A085;">$${(sfTotal/1000).toFixed(0)}k</div>
        <div style="color: #7F8C8D; font-size: 0.8rem;">$${(sfTotal/numDevices).toFixed(0)}/device</div>
      </div>
      <div style="background: white; padding: 1rem; border-radius: 6px;">
        <div style="color: #7F8C8D; font-size: 0.85rem;">LoRaWAN 5-Year TCO</div>
        <div style="font-size: 1.5rem; font-weight: 700; color: #E67E22;">$${(lwTotal/1000).toFixed(0)}k</div>
        <div style="color: #7F8C8D; font-size: 0.8rem;">$${(lwTotal/numDevices).toFixed(0)}/device</div>
      </div>
      <div style="background: white; padding: 1rem; border-radius: 6px;">
        <div style="color: #7F8C8D; font-size: 0.85rem;">Winner</div>
        <div style="font-size: 1.5rem; font-weight: 700; color: #2C3E50;">${winner}</div>
        <div style="color: #7F8C8D; font-size: 0.8rem;">Saves $${(savings/1000).toFixed(0)}k</div>
      </div>
    </div>
    <div style="background: white; padding: 0.8rem; border-radius: 6px; margin-top: 1rem; text-align: center;">
      <span style="color: #7F8C8D; font-size: 0.85rem;">Break-even point: </span>
      <span style="font-weight: 700; color: #2C3E50;">${breakeven > 0 ? breakeven.toLocaleString() + " devices" : "N/A"}</span>
      <span style="color: #7F8C8D; font-size: 0.85rem;"> — Above this, LoRaWAN is cheaper</span>
    </div>
  </div>`;
}

Interactive Quiz: Match Concepts

Interactive Quiz: Sequence the Steps

🏷️ Label the Diagram

💻 Code Challenge

49.5 Summary

These worked examples demonstrated:

1. Message Budget Planning: Asset tracking with 12-byte payloads fitting GPS, temperature, and status within 140/day limit (using only 4.7% of quota)
2. TCO Analysis: 5,000-sensor parking deployment showing Sigfox $24K cheaper than LoRaWAN at this scale, with crossover at 9,100 sensors
3. Link Budget Calculations: 25 km rural range achievable with 24.75 dB margin using -142 dBm UNB sensitivity
4. Duty Cycle Compliance: EU868 1% limit allows only 2 messages/hour (at 18 seconds each with triple transmission), restricting EU deployments to ~48 messages/day – more restrictive than the 140/day Sigfox limit

Key Insights:

• Sigfox is most cost-effective for <10,000 devices over 5 years
• 12-byte payload constraint is manageable with efficient encoding (integers not floats)
• 140 messages/day limit rarely constrains typical IoT applications
• Link budget margins sufficient for challenging RF environments

49.6 Knowledge Check

Quiz: Sigfox Worked Examples

Common Pitfalls

1. Not Working Through Examples Step by Step

Jumping to the answer without writing out intermediate steps leads to arithmetic errors and misses learning opportunities. Work through each step explicitly, including unit conversions, scaling factors, and byte count checks.

2. Skipping Payload Encoding Validation

Writing encoding code without validating against known test vectors allows silent encoding bugs. Create test vectors with known input/output pairs and verify your encoder/decoder against them before relying on production data.

3. Not Connecting Battery Life to Message Rate Trade-offs

Battery life examples that only vary battery capacity miss the most important variable: message rate. Adding one message per day to a 140/day deployment has no battery impact; adding 140 messages doubles energy consumption. Always explore message rate sensitivity in battery life examples.

4. Assuming Worked Examples Cover All Edge Cases

Textbook examples show typical scenarios. Real deployments encounter edge cases: negative temperatures, GPS coordinates near ±180° meridian, battery at exactly 2.0V threshold, multiple sensors saturating simultaneously. After working through standard examples, identify and test edge cases.

49.7 What’s Next

Direction	Chapter	Description
Previous	Sigfox Technology	UNB modulation, network architecture, and Atlas geolocation
Next	Sigfox Assessment	Comprehensive quizzes covering all Sigfox concepts
Related	LoRaWAN Architecture	Alternative LPWAN for TCO and link budget comparison
Related	Sigfox Introduction	Fundamentals, business model, and common deployment mistakes