18  LPWAN Common Pitfalls

In 60 Seconds

The most dangerous LPWAN deployment mistakes involve duty cycle violations: EU868 allows only 36 seconds of airtime per hour per sub-band, and developers frequently confuse per-channel limits with per-sub-band aggregation. At SF12, sending every 2 minutes violates regulations. Other critical pitfalls include designing on US915 (no duty cycle) then deploying on EU868 (strict 1% limit), and selecting spreading factor for range without calculating the network capacity impact.

18.1 Learning Objectives

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

  • Calculate duty cycle violation risks by computing time-on-air for different spreading factors and payloads
  • Distinguish per-channel from per-sub-band duty cycle aggregation in EU868 regulation
  • Diagnose region-specific deployment failures when porting designs between US915 and EU868 bands
  • Select spreading factors that balance range requirements against network capacity constraints
  • Evaluate LPWAN technology fit against message frequency, bidirectionality, and mobility requirements
  • Apply duty cycle budgeting to avoid gateway downlink violations in large-scale deployments

LPWAN technologies have limitations that can surprise newcomers. They send very small amounts of data, have strict transmission time limits, and work differently in different countries. This chapter highlights the most common mistakes so you can plan your IoT project with realistic expectations.

“I designed my system to send GPS coordinates every 10 seconds over LoRaWAN, and it works in testing. Ready for production, right?” Sammy the Sensor said proudly.

“WRONG!” Max the Microcontroller caught the mistake. “You forgot the duty cycle! In Europe, you can only transmit 1% of the time on 868 MHz. Each GPS message takes about 1 second to transmit, so you can only send 36 messages per hour – one every 100 seconds, not every 10 seconds. Your system will violate regulations!”

Bella the Battery spotted another issue: “At every-10-seconds transmission, my battery would last about 3 months instead of the 5-year target. You need to send GPS updates much less frequently – maybe every 15 minutes – and use clever tricks like only sending when the position changes significantly.”

Lila the LED added a third trap: “Don’t forget that LoRaWAN payload is limited to about 50-250 bytes depending on your data rate. Some developers try to send JSON strings like {\"latitude\": 51.5074, \"longitude\": -0.1278} – that’s 40 bytes of text! Encode it as binary (4 bytes each) and you save 80% of your payload. Every byte counts in LPWAN!”

18.2 Common Pitfalls

Avoid these common mistakes when deploying LPWAN solutions.

Pitfall: Exceeding EU868 Duty Cycle Limits

The Mistake: Developers design applications that transmit too frequently without calculating time-on-air, leading to duty cycle violations. The device either silently drops messages (causing data loss) or violates regulations (risking fines and interference with other users).

Why It Happens: The EU868 band enforces a strict 1% duty cycle per sub-band. This means a device can transmit for a maximum of 36 seconds per hour per sub-band. Developers often calculate message frequency without considering spreading factor’s impact on airtime:

SF 20-byte ToA Max msgs/hr (1%) Common mistake
SF7 56 ms 643 messages “I can send every 5 seconds” - Wrong!
SF9 185 ms 194 messages “Hourly updates are fine” - Usually OK
SF12 1318 ms 27 messages “Every 2 minutes” - Violation!

A developer sending 50-byte payloads every 5 minutes at SF12 (ToA ~2.5 seconds) accumulates 30 seconds of airtime per hour - seemingly within 1%. But if the device also sends join requests, confirmed uplinks with retries, or MAC commands, total airtime easily exceeds the limit.

The Fix: Calculate duty cycle budget precisely and monitor usage:

  1. Calculate ToA accurately: Use the formula ToA = (8 + max(ceil((8*PL - 4*SF + 28 + 16 - 20*H) / (4*(SF-2*DE))), 0) * (CR+4)) * Ts + Tpreamble Or use online calculators: LoRa Airtime Calculator

  2. Budget all transmissions:

    Example budget (SF10, 125 kHz, 1 hr):
- 24 sensor readings (50 bytes): 24 x 370 ms = 8.9 sec
- 2 confirmed uplinks (ACK retry): 2 x 2 x 370 ms = 1.5 sec
- 1 join request (worst case): 1 x 1318 ms = 1.3 sec
- MAC command responses: ~0.5 sec
Total: 12.2 seconds (34% of 36-sec budget) - Safe

  3. Implement airtime tracking: Store cumulative airtime per sub-band and block transmission if approaching limit

  4. Use multiple sub-bands: EU868 has 8 channels across different sub-bands. Spread transmissions to multiply your effective budget

Regulatory consequences: Violations can result in fines up to 10,000 EUR in EU countries. More practically, excessive airtime causes collisions affecting all nearby LoRaWAN devices.

Pitfall: Ignoring Sub-Band Duty Cycle Aggregation

The Mistake: Developers assume duty cycle applies per-channel and freely hop between channels, not realizing that EU868 regulations aggregate duty cycle across entire sub-bands. A device hopping across 8 channels in the same sub-band still counts all airtime against a single 1% limit.

Why It Happens: LoRaWAN uses channel hopping to spread interference and improve reliability. Developers see 8 default channels (868.1, 868.3, 868.5 MHz in g1, plus others) and assume:

  • “Each channel has its own 1% limit” - Wrong!
  • “Hopping between channels resets my duty cycle” - Wrong!
  • “I can send 8x more by using all channels” - Wrong!

EU868 sub-band structure:

Sub-band g  (863.0-865.0 MHz): 1.0% duty cycle - Includes 863.x channels
Sub-band g1 (865.0-868.0 MHz): 1.0% duty cycle - Includes 868.1/868.3/868.5
Sub-band g2 (868.0-868.6 MHz): 1.0% duty cycle - Overlaps with g1!
Sub-band g3 (868.7-869.2 MHz): 0.1% duty cycle - Very limited!
Sub-band g4 (869.4-869.65 MHz): 10% duty cycle - Best for downlinks

The three most common LoRaWAN channels (868.1, 868.3, 868.5 MHz) all fall within g1 sub-band. Hopping between them provides NO additional duty cycle budget.

The Fix: Design for sub-band, not channel, duty cycle:

  1. Map your channels to sub-bands: Know which sub-band each channel belongs to
  2. Track airtime per sub-band: Even with channel hopping, sum all transmissions in same sub-band
  3. Use channels in different sub-bands: Configure device to use channels across g1 AND g2 AND g4 (if gateway supports)
  4. Leverage g4 for downlinks: The 10% duty cycle sub-band (869.525 MHz) is ideal for gateway-to-device communication

Correct duty cycle calculation:

Device uses channels 868.1, 868.3, 868.5 (all in g1):
- 10 messages on 868.1: 10 x 200 ms = 2 sec
- 10 messages on 868.3: 10 x 200 ms = 2 sec
- 10 messages on 868.5: 10 x 200 ms = 2 sec
Total g1 airtime: 6 seconds (NOT 2 seconds per channel!)
g1 limit: 36 seconds/hour
Status: 16.7% of budget used (OK)

If developer thought per-channel: "Only 5.6% used" - Dangerous underestimate!

US915 has different rules (no duty cycle, but dwell time limits). Always verify regional parameters.

Pitfall: Designing for US915 and Deploying in EU868 Without Duty Cycle Planning

The Mistake: Developers build and test LPWAN applications using US915 frequencies (which have no duty cycle restrictions), then deploy in Europe where EU868’s strict 1% duty cycle causes message drops, join failures, and regulatory violations.

Why It Happens: The US915 and EU868 bands have fundamentally different regulatory constraints:

Parameter US915 EU868
Duty cycle None (FCC Part 15) 1% per sub-band (ETSI EN 300.220)
Max TX time/hour Unlimited 36 seconds (1% of 3600s)
Dwell time limit 400ms (frequency hopping) None
Channels 64 uplink + 8 downlink 8-16 typical

A device sending 20-byte payloads every 2 minutes works perfectly on US915:

US915: 30 msgs/hour x any SF = OK (no limit)
EU868 SF10: 30 msgs/hour x 370 ms = 11,100 ms = 11.1 sec (OK, 31% of budget)
EU868 SF12: 30 msgs/hour x 1,318 ms = 39,540 ms = 39.5 sec (VIOLATION — 110% of budget)

The Fix: Design for the most restrictive region (EU868) first:

  1. Calculate worst-case airtime: Use SF12 ToA for capacity planning, even if ADR will optimize
  2. Budget for all transmissions: Include joins, retries, MAC commands, not just data uplinks
  3. Test with duty cycle enforcement: Enable LMIC_setClockError() or equivalent to simulate regulatory limits
  4. Implement airtime tracking: Maintain per-sub-band counters and block TX when approaching limits

EU868 transmission budget calculator:

Hourly budget: 36,000 ms (1% of 3,600,000 ms)

SF7  (56 ms/msg):   643 messages/hour max
SF9  (185 ms/msg):  194 messages/hour max
SF10 (370 ms/msg):   97 messages/hour max
SF12 (1318 ms/msg):  27 messages/hour max

Safe design rule: Plan for 50% of budget to handle retries
SF10 practical limit: ~48 msgs/hour
SF12 practical limit: ~13 msgs/hour

Multi-region deployment strategy: Use ADR aggressively in EU868 (lower SF = more messages allowed), configure region-specific transmission intervals, and implement graceful degradation when duty cycle budget is exhausted.

Pitfall: Selecting LoRaWAN SF Based on Range Alone Without Considering Network Capacity

The Mistake: Developers select spreading factor solely based on required range (e.g., “I need 10 km, so I’ll use SF12”), ignoring that higher SF dramatically reduces network capacity and increases collision probability in shared deployments.

Why It Happens: Range-focused selection ignores the network-level impact of spreading factor:

  • SF selection charts typically show only range, not capacity
  • Single-device testing doesn’t reveal multi-device collision rates
  • Gateway capacity depends on total airtime, not message count
  • Collision probability scales with time-on-air (longer packets more likely to overlap)

Network capacity comparison for single 8-channel gateway:

SF ToA (20 bytes) Capacity/channel/hour Total gateway capacity Collision rate (100 devices)
SF7 56ms 643 msgs ~5,000 msgs/hr 0.3%
SF9 185ms 194 msgs ~1,500 msgs/hr 1.1%
SF10 370ms 97 msgs ~750 msgs/hr 2.2%
SF12 1318ms 27 msgs ~216 msgs/hr 7.8%

A 100-device network sending every 10 minutes (600 msgs/hour): - At SF7: 12% gateway utilization, <1% collisions - At SF10: 80% gateway utilization, 3-5% collisions - At SF12: 278% utilization - NETWORK COLLAPSE (messages dropped)

The Fix: Balance range against capacity using ADR and network planning:

  1. Enable ADR: Let network server optimize SF per device based on actual link quality
  2. Plan for SF distribution: Assume 30% SF7-8, 40% SF9-10, 30% SF11-12 in typical deployments
  3. Add gateways for capacity, not just coverage: One gateway covers 10km range but may only support 200 devices at SF12
  4. Use link budget, not distance: Calculate required SF from TX power, antenna gains, path loss, and fade margin

Link budget example:

Example: 5 km urban deployment
TX Power: 14 dBm
TX Antenna gain: +2 dBi
RX Antenna gain: +2 dBi
Path Loss (urban, 868 MHz, 5 km): ~120 dB
Fade Margin: 10 dB
RX Sensitivity (SF12, 125 kHz BW): -137 dBm

Link Budget = TX_Power + TX_Antenna + RX_Antenna - Path_Loss - Fade_Margin - RX_Sensitivity
           = 14 + 2 + 2 - 120 - 10 - (-137) = 25 dB margin

This margin is sufficient for SF12. ADR will likely optimize to SF9
after 50 uplinks if actual measured margin exceeds 20 dB.

Rule of thumb: If more than 20% of devices need SF12, add another gateway rather than accepting reduced capacity.

Pitfall: Assuming LPWAN Means “Always Low Power”

The Mistake: Believing that using LoRa or any LPWAN technology automatically guarantees multi-year battery life, then being surprised when batteries drain in weeks.

Why It Happens: LPWAN marketing emphasizes “10+ year battery life” without clarifying that this assumes proper power management: aggressive sleep modes, infrequent transmissions (1-4 per hour), and avoiding continuous sensing. Developers who poll sensors frequently or use Class C mode negate all power benefits.

The Fix: Calculate your actual power budget before deployment. A LoRa radio transmitting at SF12 consumes approximately 120 mA for 1.3 seconds per message. At 1 message per hour with proper sleep (1 µA), a 2×AA cell (3,000 mAh at 3 V) lasts approximately 10 years. At 1 message per minute the same pack lasts roughly 6 months. Continuous Class C listening (receive current ~15 mA) drains 2×AA batteries in approximately 2 weeks. Always model the full duty cycle — transmit, receive windows, and sleep — before selecting battery capacity.

Pitfall: Treating All LPWAN Technologies as Interchangeable

The Mistake: Selecting LPWAN technology based solely on range claims, then discovering fundamental protocol mismatches with application requirements (e.g., Sigfox’s 140 messages/day limit for a parking sensor that changes state 50 times daily).

Why It Happens: LPWAN technologies appear similar at a high level (long range, low power) but have vastly different design centers: LoRaWAN for flexibility and private networks, Sigfox for ultra-simple sensors with infrequent updates, NB-IoT for carrier-grade reliability and mobility.

The Fix: Match technology to your specific requirements:

  1. Message frequency: Sigfox limits to 140 uplinks/day; LoRaWAN is limited by duty cycle (~500-2,000/day at SF10 on EU868); NB-IoT has no protocol-level message count limit.
  2. Bidirectional needs: Sigfox allows only 4 downlinks/day; LoRaWAN Class A/B/C and NB-IoT support symmetric communication.
  3. Mobility: Only LTE-M and NB-IoT support seamless handoff between cells.
  4. Coverage: NB-IoT requires carrier infrastructure; LoRaWAN can be self-deployed with private gateways.

A European utility company is deploying 500 LoRaWAN smart meters across a residential neighbourhood. Each meter reports consumption every 30 minutes using SF10 (20-byte payload). Calculate whether this design violates EU868 duty cycle limits.

Given:

  • 500 meters, each on SF10 (spreading factor 10)
  • Payload: 20 bytes (meter ID + reading + timestamp)
  • Frequency: EU868 (g1 sub-band, 1% duty cycle limit)
  • Transmission interval: 30 minutes (2 messages per hour, 48 per day)
  • Time-on-air (ToA) for 20 bytes at SF10: 370 ms

Step 1: Calculate hourly airtime per meter

Hourly messages: 2 (every 30 minutes)
Airtime per message: 370 ms
Hourly airtime per meter: 2 × 370 ms = 740 ms = 0.74 seconds
EU868 g1 limit: 36 seconds per hour (1% of 3,600 seconds)
Per-device utilisation: 0.74 / 36 = 2.06% of individual budget — OK

The duty cycle violation occurs at the gateway, not the individual meters. Let’s calculate the aggregated downlink load if confirmed uplinks are used:

\[\text{Hourly gateway downlink airtime} = 500 \text{ meters} \times 2 \text{ msgs/hr} \times 370 \text{ ms} = 370{,}000 \text{ ms/hr}\]

Converting to duty cycle percentage: \[\text{Duty cycle} = \frac{370{,}000 \text{ ms}}{3{,}600{,}000 \text{ ms/hr}} \approx 10.3\%\]

That is more than 10× the 1% g1 limit. Even if five gateways share the load: \[370{,}000 \div 5 = 74{,}000 \text{ ms/gateway/hr} \approx 2.1\% \text{ — still 2× over the limit}\]

Switching to unconfirmed uplinks eliminates the ACK requirement entirely, dropping gateway downlink airtime to near zero for routine readings. Reserve the g4 sub-band (869.525 MHz, 10% duty cycle) for essential configuration downlinks.

Step 2: Check gateway downlink budget (the critical constraint)

If meters use confirmed uplinks (require ACK from gateway):
  - Gateway must send 500 ACKs every 30 minutes = 1,000 ACKs/hour
  - ACK ToA at SF10: ~370 ms
  - Total gateway downlink airtime: 1,000 × 370 ms = 370,000 ms/hr
  - g1 limit: 36,000 ms/hour (1% of 3,600,000 ms)
  - Gateway utilisation: 370,000 / 36,000 ≈ 1,028% — VIOLATION!

The problem: Each individual meter is well within its personal duty cycle budget (2%), but the gateway’s downlink duty cycle is violated by roughly 10×. This is the most common EU868 pitfall in large deployments.

Solution: Switch to unconfirmed uplinks (no ACKs required), use application-layer delivery tracking, and reserve the g4 sub-band (869.525 MHz, 10% duty cycle) for essential downlink commands. With this change, gateway downlink airtime drops to near zero for routine readings.

Compare LoRaWAN, Sigfox, NB-IoT, and LTE-M for a battery-powered logistics tracking application. You need to track 10,000 shipping containers globally with 10-year battery life.

Criterion LoRaWAN Sigfox NB-IoT LTE-M Weight
Global Coverage Private (must deploy) 72 countries 100+ countries 100+ countries Critical
Message Limit ~500-2000/day (duty cycle) 140/day Unlimited Unlimited High
Battery Life 10+ years 10+ years 5-10 years 3-5 years Critical
Mobility Support None (reconnect) Regional only Full handoff Full handoff Critical
Cost per Device/Year €5-10 (private) €10-15 (operator) €12-20 (operator) €25-40 (operator) Medium
Deep Indoor Penetration Excellent Excellent Good Fair Medium

Decision Matrix:

  • LoRaWAN: Best if you control infrastructure (warehouses, ports). 10-year battery life, lowest recurring cost (€5/year), but requires gateway deployment at every location. Not suitable for global mobility.

  • Sigfox: Good for infrequent updates (1-2 per day) with 72-country coverage. 140 message/day limit is marginal for real-time tracking (hourly updates = 24 msgs/day, leaving no margin for alerts). Operator bankruptcy risk.

  • NB-IoT: Best for global logistics. 100+ countries with carrier roaming, unlimited messages, 5-10 year battery, and full mobility support. €12-20/year is acceptable for high-value cargo. Deep penetration works in metal containers.

  • LTE-M: Use only if you need voice (driver communication) or >100 kbps data (firmware updates). Battery life (3-5 years) requires larger/heavier batteries, increasing cost.

Best For:

  • Local campus tracking → LoRaWAN (private network)
  • National tracking, infrequent updates → Sigfox
  • Global tracking, daily updates → NB-IoT
  • Fleet vehicles with power → LTE-M
Common Mistake: Confusing Per-Channel with Per-Sub-Band Duty Cycle in EU868

The Error: A developer deploys a LoRaWAN network with 8 end-devices, each transmitting on a different channel from the default EU868 set (868.1, 868.3, 868.5 MHz). They assume each channel has its own 1% duty cycle budget and calculate: “Each device uses only 2% of its channel’s budget, so I have plenty of headroom.”

Why It Fails: EU868 regulation enforces duty cycle limits on sub-bands, not individual channels. The three most common LoRaWAN channels (868.1, 868.3, 868.5 MHz) all belong to the same sub-band (g1), which has a cumulative 1% limit. All transmissions across these channels count against the same 36-second-per-hour budget.

The Calculation Error:

Developer's assumption (WRONG):
  8 devices × 2% per channel = 16% total (spread across 8 channels)

Reality (CORRECT):
  8 devices × 2% duty cycle = 16% of g1 sub-band limit
  g1 allows only 1% (36 seconds/hour)
  Actual usage: 16% × 36 seconds = 5.76 seconds/hour per device
  8 devices: 8 × 5.76 = 46 seconds/hour
  Violation: 46 / 36 = 128% of sub-band limit

Real-World Consequence: In a 2019 smart parking deployment in Barcelona, the network operator received regulatory warnings from the Spanish spectrum authority (CNMC) after residents reported Wi-Fi interference. Investigation revealed 500 parking sensors were collectively exceeding g1 duty cycle limits by 3×, causing self-interference and violating ETSI EN 300.220 regulations. The fix required firmware updates to reduce transmission frequency and add channels from g4 sub-band (869.525 MHz, 10% duty cycle).

Correct Approach:

  1. Map your channel plan to sub-bands (consult LoRaWAN Regional Parameters spec)
  2. Sum all airtime within each sub-band separately
  3. Use channels from different sub-bands to multiply budget (e.g., add g4 channels)
  4. Reserve g4 (10% duty cycle) for gateway downlinks to maximise uplink budget

18.3 Key Takeaways

18.4 Label the Diagram

:

18.5 Real-World Case Study: EU868 Duty Cycle Violation in Smart Parking

A European smart city deployed 8,000 LoRaWAN parking sensors in 2020 across a historic city centre. Within 3 months, the city received a complaint from the national spectrum regulator and discovered that 40% of their devices were violating EU868 duty cycle limits.

The Design:

Original specification:
  Sensor: occupancy change detection (magnetometer)
  Message size: 8 bytes (status + battery level)
  Expected message rate: 5 state changes/day average (car arrives/departs)
  Spreading factor: SF10 (chosen for deep urban coverage)
  Time-on-air (8 bytes, SF10): 330 ms per message
  Daily airtime: 5 × 330 ms = 1,650 ms — well within duty cycle

What Went Wrong:

  1. Firmware bug: The sensor firmware included a “heartbeat” message every 15 minutes to confirm the sensor was alive, even when no state change occurred.
Actual message rate:
  Heartbeats: 96 per day (24 hours × 4 per hour)
  State changes: 5 per day (average)
  Confirmed uplinks with ACK retry: 10% of messages need 1 retry → ~10 extra
  Join requests after deep sleep: 2 per day (session lost during sleep)
  Total: 96 + 5 + 10 + 2 = 113 messages/day

Hourly airtime calculation:
  Average: 113 / 24 ≈ 4.7 msgs/hr; peak (8 AM): ~12 msgs/hr
  Peak hour: 12 messages × 330 ms = 3,960 ms = 3.96 seconds
  Sub-band g1 limit (1%): 36,000 ms per hour
  Per-device utilisation: 3.96 / 36 = 11% — within limits for one device

  BUT: All 8,000 sensors use g1 sub-band (868.1/868.3/868.5 MHz)
  Gateway downlink ACKs also count against each gateway's g1 budget:
    Peak: 12 ACKs × 330 ms = 3,960 ms per sensor per peak hour
    8,000 sensors ÷ 25 gateways = 320 sensors per gateway
    Gateway peak downlink: 320 sensors × 12 msgs × 330 ms = 1,267,200 ms/hr
    g1 limit per gateway: 36,000 ms/hr
    Gateway utilisation: 1,267,200 / 36,000 = 3,520% — MASSIVE VIOLATION!
  1. Root cause: The gateway’s duty cycle was violated, not individual sensors. Each gateway had to serve 320 sensors × 12 peak ACKs = 3,840 downlinks/hour at 330 ms each = 1,267 seconds — more than 35× the 36-second limit.

The Fix (Deployed Over 6 Weeks):

Change Impact
Removed heartbeat (replaced with daily keepalive) 96 → 1 heartbeat/day (−99%)
Switched to unconfirmed uplinks (no ACK needed) Eliminated gateway downlink burden
Added g4 sub-band (869.525 MHz, 10% duty cycle) for essential downlinks 10× more downlink capacity
Enabled ADR (SF10 → SF7 for devices near gateways) 6× less airtime per message

Post-Fix Results:

Sensor daily airtime: 6 messages × 56 ms (SF7) = 336 ms — 0.001% duty cycle
Gateway daily downlinks: 2 per sensor (join + config) = 640 per gateway
Gateway hourly downlink: (640/24) × 330 ms ≈ 8,800 ms — 24% of g4 limit (safe)
Regulatory complaint: Resolved, no fine assessed (first offence + rapid remediation)

Key Lesson: Duty cycle violations in LoRaWAN deployments almost always occur on the gateway downlink, not the sensor uplink. Confirmed uplinks force the gateway to send ACKs, and the gateway’s duty cycle is shared across every device it serves. For large deployments (>1,000 devices), use unconfirmed uplinks with application-layer delivery tracking, and reserve the g4 sub-band (10% duty cycle) for essential downlink commands.

18.6 Summary

This chapter covered LPWAN pitfalls and best practices:

  • Duty cycle regulations: EU868 enforces 1% per sub-band, not per channel
  • Regional differences: US915 has no duty cycle but has 400 ms dwell time limits per frequency hop
  • Spreading factor trade-offs: Higher SF = more range but reduced network capacity and higher collision probability
  • Battery life reality: Advertised 10-year life requires proper sleep mode management and infrequent transmissions
  • Technology selection: Match LPWAN technology to specific message frequency, bidirectionality, and mobility requirements

18.7 What’s Next

Chapter Focus Why Read It
LPWAN Overview Introduction to LPWAN technologies and their design centres Establish the baseline before diving into pitfall avoidance
LPWAN Technology Selection Decision framework for choosing among LoRaWAN, Sigfox, NB-IoT, and LTE-M Apply pitfall awareness to concrete technology-choice decisions
LPWAN Link Budget Range and margin calculations for LPWAN deployments Determine the minimum spreading factor your deployment actually needs
LoRaWAN Overview LoRa modulation, network architecture, and Class A/B/C device classes Deepen understanding of the LoRaWAN protocol underlying the EU868 pitfalls
NB-IoT Fundamentals Cellular LPWAN: coverage, power saving mode, extended discontinuous reception Assess NB-IoT as the duty-cycle-free alternative for high-reliability needs
WSN Overview Sensor network design patterns and energy management See how LPWAN fits into broader wireless sensor network architectures

LPWAN Fundamentals Series:

LPWAN Technologies:

Architecture:

Interactive Tools:

Learning Hubs: