12  LoRaWAN ADR & Duty Cycle

In 60 Seconds

LoRaWAN’s Adaptive Data Rate (ADR) algorithm automatically optimizes each device’s spreading factor and transmit power based on recent link quality (SNR/RSSI), while duty cycle regulations (1% in EU868) cap total airtime to 36 seconds per hour – meaning at SF12 you can only send about 14 packets per hour legally. Mastering ADR convergence and duty cycle budgeting is essential for production deployments.

Prerequisites: LoRaWAN Network Architecture | LoRa Modulation

This enables: Common Pitfalls | LoRaWAN Lab

12.1 Learning Objectives

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

• Explain the Adaptive Data Rate (ADR) algorithm and its convergence process
• Calculate link margins and determine optimal spreading factors for a given SNR
• Configure ADR parameters for different deployment scenarios (urban, rural, mobile)
• Compare EU and US duty cycle regulations and their impact on network capacity
• Calculate message budgets under duty cycle constraints for specific spreading factors
• Diagnose ADR convergence problems and apply corrective strategies

Key Concepts

• Adaptive Data Rate (ADR): Network-server-driven algorithm that optimizes each device’s spreading factor and transmit power based on measured link quality, reducing airtime and power consumption.
• Spreading Factor (SF): LoRa modulation parameter (SF7–SF12) trading data rate for range; higher SF means longer range but slower transmission and more duty cycle consumption.
• SNR Margin: Difference between measured signal-to-noise ratio and the minimum demodulation threshold; ADR uses this margin to determine if SF can be lowered.
• Duty Cycle: Regulatory constraint limiting transmit-on time to a fraction of each hour (e.g., 1% in EU868 = 36 seconds/hour), preventing channel congestion.
• ADR Convergence: The process by which the network server adjusts a device’s SF downward over multiple uplinks until the link margin is minimized without packet loss.
• Link Budget: Total permissible path loss calculated as TX power + antenna gains − receiver sensitivity, determining maximum communicable range.
• Frame Counter Reset: Device re-join event resetting MIC validation counters; improper resets cause packet rejection and ADR state loss.

For Beginners: LoRaWAN ADR and Duty Cycle

ADR (Adaptive Data Rate) automatically adjusts how fast each device transmits based on its signal quality, like a conversation where you speak louder when the other person is far away. Duty cycle rules limit how much time a device can spend transmitting, like traffic lights that give each road a fair share of green time.

Sensor Squad: The Smart Speed Controller!

“ADR is like a smart volume control for LoRaWAN!” Sammy the Sensor explained. “When I am close to a gateway with a strong signal, the network server tells me to use a low spreading factor – like speaking quickly. When I am far away with a weak signal, it tells me to slow down and use a higher spreading factor. This way I always use just enough energy to get my message through!”

“Duty cycle is the fairness rule,” Lila the LED added. “In Europe, LoRaWAN devices can only transmit one percent of the time – that is 36 seconds per hour. At SF12, one message takes about 2.5 seconds, so you can only send about 14 messages per hour. At SF7, the same message takes just 50 milliseconds, allowing hundreds of messages per hour!”

Max the Microcontroller said, “The ADR algorithm looks at the last 20 messages from each device and calculates the average signal quality. If the signal has plenty of margin, it lowers the spreading factor to save airtime and battery. If the signal is barely getting through, it raises the spreading factor for more reliability. It is constantly optimizing!”

“Without ADR, you would waste enormous amounts of energy,” Bella the Battery warned. “Imagine using SF12 for a device that is only 100 meters from the gateway – that is like shouting at someone right next to you! ADR automatically optimizes so each device uses the minimum power needed, which can improve my battery life by up to twenty-one times compared to fixed SF12.”

12.2 Expert Deep Dive: Protocol Internals

12.2.1 Adaptive Data Rate (ADR) Algorithm Implementation

For practitioners implementing LoRaWAN networks, understanding the ADR algorithm internals is crucial for optimal performance.

12.2.2 ADR Decision Process

The network server calculates optimal spreading factor using these steps:

1. Signal Quality Measurement (Gateway -> Network Server)

For each uplink from device:
  - RSSI (Received Signal Strength Indicator): Measured in dBm
  - SNR (Signal-to-Noise Ratio): Measured in dB
  - Packet count: Last 20 uplinks tracked

2. Link Margin Calculation

Link Margin = SNR - SNR_required(SF)

Required SNR by spreading factor:
SF7:  -7.5 dB
SF8:  -10 dB
SF9:  -12.5 dB
SF10: -15 dB
SF11: -17.5 dB
SF12: -20 dB

Example:
Measured SNR = -8 dB
SF7 required: -7.5 dB
Link Margin = -8 - (-7.5) = -0.5 dB -> SF7 NOT viable

SF8 required: -10 dB
Link Margin = -8 - (-10) = +2 dB -> SF8 viable but marginal

SF9 required: -12.5 dB
Link Margin = -8 - (-12.5) = +4.5 dB -> SF9 safe

Putting Numbers to It

The link margin calculation directly determines whether a spreading factor will work reliably. Each SF step provides approximately 2.5 dB of additional sensitivity, allowing operation at weaker signal levels.

For a sensor with measured SNR = -8 dB:

Testing SF7 demodulation threshold: \[\text{Link Margin}_{\text{SF7}} = -8 \text{ dB} - (-7.5 \text{ dB}) = -0.5 \text{ dB}\]

Negative margin means the signal is 0.5 dB weaker than required — SF7 will fail.

Testing SF8 demodulation threshold: \[\text{Link Margin}_{\text{SF8}} = -8 \text{ dB} - (-10 \text{ dB}) = +2 \text{ dB}\]

Positive margin of 2 dB means the signal is strong enough, but with minimal safety margin — occasional packet loss is likely.

Testing SF9 demodulation threshold: \[\text{Link Margin}_{\text{SF9}} = -8 \text{ dB} - (-12.5 \text{ dB}) = +4.5 \text{ dB}\]

With 4.5 dB margin, SF9 provides a safe operating point but falls short of the typical 10 dB margin target for production reliability. Checking higher SFs: SF10 gives 7 dB margin, SF11 gives 9.5 dB, and SF12 gives 12 dB. The ADR algorithm would select SF12 as the lowest SF meeting the 10 dB target for this device.

3. Optimal SF Selection

def calculate_optimal_sf(snr_measurements):
    """
    ADR algorithm to determine optimal spreading factor

    Args:
        snr_measurements: List of last 20 SNR readings (dB)

    Returns:
        Optimal SF and TX power
    """
    # Use worst-case SNR from last 20 packets (with margin)
    snr_min = min(snr_measurements)

    # Required SNR per SF (dBm)
    sf_requirements = {
        7: -7.5, 8: -10, 9: -12.5,
        10: -15, 11: -17.5, 12: -20
    }

    # Target: 10 dB link margin for reliability
    target_margin = 10

    # Find lowest SF with sufficient margin
    for sf in range(7, 13):
        required_snr = sf_requirements[sf]
        link_margin = snr_min - required_snr

        if link_margin >= target_margin:
            return sf, calculate_tx_power(link_margin)

    # If no SF works with 10 dB margin, use SF12
    return 12, max_tx_power

def calculate_tx_power(link_margin):
    """
    Reduce TX power if excessive link margin
    """
    excess_margin = link_margin - 10  # Keep 10 dB safety

    if excess_margin > 0:
        # Reduce TX power by excess margin (up to 10 dB max reduction)
        power_reduction = min(excess_margin, 10)
        return default_tx_power - power_reduction

    return default_tx_power

4. ADR Command Transmission

Network Server -> Device (via LinkADRReq MAC command):
- New Spreading Factor (SF7-SF12)
- New TX Power (0-15, maps to 2-20 dBm)
- New Channel Mask (enable/disable channels)
- NbRep (number of transmissions for redundancy)

Device acknowledges with LinkADRAns

12.2.3 Real-World ADR Example

Scenario: Sensor initially joins network at default SF12 (conservative)

Uplink #	RSSI (dBm)	SNR (dB)	Current SF	Link Margin	Network Action
1	-95	+5	SF12	+25 dB	Collect data
5	-96	+4	SF12	+24 dB	Collect data
10	-94	+6	SF12	+26 dB	Collect data
20	-95	+5	SF12	+25 dB	Command: Switch to SF9
25	-96	+4	SF9	+16.5 dB	Excellent
30	-95	+5	SF9	+17.5 dB	Excellent
40	-94	+6	SF9	+18.5 dB	Command: Switch to SF7
45	-95	+5	SF7	+12.5 dB	Good (10+ dB margin)

Result: Battery life improves by 23x (SF12 -> SF7)!

12.2.4 ADR Limitations and Pitfalls

When ADR Fails

1. Mobile Devices:

Problem: Device moves from gateway A (strong signal) to gateway B (weak signal)
- ADR at A: SF7 (fast, short range)
- Device moves to B: Signal degrades
- Still using SF7 -> messages lost
- Takes 20+ uplinks to readjust -> unacceptable for mobile

Solution: Disable ADR for mobile devices, use SF10-SF12

2. Interferer Appears:

Problem: New Wi-Fi access point near gateway
- Before: SNR +10 dB, SF7 optimal
- After: SNR -5 dB (interference), SF7 fails
- ADR takes 20 uplinks to detect -> 20 lost messages

Solution: Faster ADR response (reduce convergence window) or use SF9-SF10 for critical apps

3. Weather Changes:

Problem: Heavy rain increases path loss by 5-10 dB
- Clear weather: SF7 with +12 dB margin
- Heavy rain: Margin drops to +2 dB -> packet loss spikes
- ADR eventually adjusts to SF9, but 10-20 packets lost

Solution: Use higher default SF in regions with severe weather

12.2.5 Best Practices for ADR

1. Enable ADR for stationary devices (sensors, meters)
2. Disable ADR for mobile devices (asset trackers, vehicles)
3. Set ADR_ACK_LIMIT = 64 (default) for good convergence
4. Monitor failed uplink ratio -> if >5%, ADR not working well
5. Manually set SF for critical devices where packet loss unacceptable

12.2.6 ADR Best Practices by Deployment Type

Deployment	ADR Setting	Installation Margin	NbTrans	Notes
Urban IoT	Enabled	15 dB	2	Interference-resistant
Rural Sensors	Enabled	5 dB	1	Battery-optimized
Industrial	Enabled	12 dB	2	Balanced reliability
Mobile Assets	Disabled	N/A	1	Fixed SF9-SF10
Critical Alarms	Enabled	20 dB	3	Maximum reliability

12.3 Duty Cycle Regulations and Fair Access Policy

LoRaWAN operates in unlicensed ISM bands, subject to strict duty cycle regulations:

12.3.1 EU Regulations (ETSI EN 300.220)

Sub-bands and Duty Cycles:

Frequency (MHz)	Duty Cycle	Max TX Power	Usage
865.0 - 868.0	1% (36 sec/hour)	25 mW (14 dBm)	G1 channels (uplink)
868.0 - 868.6	1%	25 mW	G channels (uplink)
868.7 - 869.2	0.1% (3.6 sec/hour)	25 mW	G2 channels (uplink)
869.4 - 869.65	10% (6 min/hour)	500 mW (27 dBm)	G3 downlink (gateways)

Practical Impact:

Example: SF10, 50-byte payload, 370 ms airtime

1% duty cycle (G1 channels):
- Max airtime: 3600 sec/hour x 1% = 36 sec/hour
- Messages allowed: 36000 ms / 370 ms = 97 messages/hour
- Minimum interval: 370 ms x 100 = 37 seconds between messages

0.1% duty cycle (G2 channels):
- Max airtime: 3600 sec/hour x 0.1% = 3.6 sec/hour
- Messages allowed: 3600 ms / 370 ms = 9.7 messages/hour
- Minimum interval: 370 ms x 1000 = 370 seconds (6.2 minutes!)

12.3.2 US Regulations (FCC Part 15)

Unlicensed ISM Band: 902-928 MHz

Parameter	Limit	Notes
Duty Cycle	None (but Fair Access Policy applies)	No explicit duty cycle
Max EIRP	4W (36 dBm) with FHSS	Frequency hopping required
Dwell Time	400 ms per channel	Must hop channels
Hop Channels	50+ channels	LoRaWAN uses 64 or 72 channels

LoRaWAN Fair Access Policy (US):

Recommendation: Uplink duty cycle 4% or less (even though not regulated)
- Prevents network saturation
- Allows fair sharing of spectrum
- Max ~2 minutes of airtime per hour

12.3.3 Duty Cycle Violation Consequences

What Happens If You Violate Duty Cycle?

Regulatory:

• EU: Fines up to 10,000 EUR+ per violation
• FCC: Fines, equipment seizure, spectrum ban
• Enforcement: Automatic monitoring systems detect violations

Network:

• The Things Network: Device automatically blocked
• Private networks: Self-inflicted interference, packet loss
• Other users: Your transmissions cause collisions

Technical:

• Module firmware enforces duty cycle (cannot bypass)
• Attempted transmission queued until duty cycle resets
• Confirmed messages may fail if ACK arrives during duty cycle block

12.3.4 Calculating Message Budget

Example: Smart meter (EU 868 MHz, G1 channel, 1% duty cycle)

def calculate_max_messages(sf, payload_bytes):
    """
    Calculate maximum messages per hour under 1% duty cycle
    """
    # Airtime table for EU868, BW=125kHz (milliseconds)
    airtime_table = {
        7: {10: 41, 20: 51, 50: 72},
        8: {10: 72, 20: 92, 50: 133},
        9: {10: 144, 20: 185, 50: 247},
        10: {10: 247, 20: 329, 50: 452},
        11: {10: 454, 20: 617, 50: 865},
        12: {10: 908, 20: 1233, 50: 1745}
    }

    # Find closest payload size
    closest_payload = min([10, 20, 50], key=lambda x: abs(x - payload_bytes))
    airtime_ms = airtime_table[sf][closest_payload]

    # 1% duty cycle = 36,000 ms per hour
    duty_cycle_budget_ms = 36000

    max_messages = duty_cycle_budget_ms / airtime_ms
    min_interval_sec = (airtime_ms / 1000) * 100  # 1% = 100x wait

    return int(max_messages), min_interval_sec

# Examples:
# SF7, 20 bytes: (705 msg/hr, 5.1 sec interval)
# SF10, 50 bytes: (79 msg/hr, 45.2 sec interval)
# SF12, 50 bytes: (20 msg/hr, 174.5 sec = 2.9 min interval)

Key Insight: Higher spreading factors severely limit message frequency under duty cycle constraints. This is another reason why ADR is critical!

12.4 Understanding Check: Class A Firmware Updates

Scenario: A municipal water utility has deployed 5,000 LoRaWAN smart meters (Class A devices) across the city. Each meter reports usage once per hour. A critical security patch requires a firmware update - the new firmware is 100 KB. The utility needs to update all meters within 2 weeks.

Think about:

1. Why is the Class A receive window architecture a problem for large file transfers?
2. How many downlink messages would each meter need to receive the full firmware?
3. What trade-offs exist between Class A, Class B, and Class C for this scenario?

The Math:

• Firmware size: 100 KB = 100,000 bytes
• LoRaWAN payload: ~100 bytes per message (average)
• Messages needed: 100,000 / 100 = 1,000 downlink messages per meter
• At 1 uplink/hour: 1,000 hours = 41 days per device
• For 5,000 meters sequentially: Impossible within 2 weeks

Update Strategy	Receive Windows	Battery Impact	Time to Update 5,000 Meters
Class A	After uplink only (3 sec total)	Lowest	41 days x sequential = Months
Class B	Scheduled + uplink windows	Medium	~1 week with coordination
Class C	Always listening	Highest (mains power needed)	1-2 days

Practical Takeaway: Class A is perfect for sensors sending data upward, but firmware updates require either patient sequential updates, Class B coordination, or Class C power availability.

Interactive: LoRaWAN Adaptive Data Rate (ADR) Animation

12.5 ADR Tuning for Specific Deployment Types

The default ADR algorithm assumes stationary devices with stable RF conditions – a reasonable assumption for building-mounted sensors but a poor fit for mobile, agricultural, or intermittent-use applications. The following guidance addresses the three most common deployment types that require ADR parameter adjustments.

Deployment Type 1: Fixed urban sensors (default ADR works well)

For stationary devices in urban environments (air quality monitors, parking sensors, waste bins), the default ADR settings are appropriate. The 20-uplink convergence window captures the stable channel conditions, and the 10 dB link margin provides sufficient buffer for weather-related fading (rain attenuation: 1–3 dB at 868 MHz) and seasonal foliage changes (2–5 dB when trees are in full leaf vs bare).

Deployment Type 2: Agricultural sensors (seasonal variation)

Agricultural sensors experience dramatic RF environment changes between seasons. A soil moisture sensor in a wheat field may have line-of-sight to the gateway at planting (March, crop height 0 cm) but be surrounded by 1.5 m wheat stalks at harvest (August). The crop canopy adds 8–15 dB of attenuation.

Season	Crop height	Path loss increase	ADR-selected SF	Actual SF needed
Spring (planting)	0 cm	0 dB	SF7	SF7
Early summer	60 cm	4 dB	SF7	SF8
Mid-summer	120 cm	10 dB	SF8	SF10
Late summer (harvest)	150 cm	14 dB	SF9	SF11
Post-harvest	0 cm	0 dB	SF7	SF7

The problem: ADR converges over 20 uplinks, which at 1 report per hour takes 20 hours. Crop growth is gradual, so ADR can track it. But harvest happens in a single day – the path loss drops 14 dB instantly. ADR takes 20 hours to converge downward from SF11 to SF7, wasting airtime and battery during that period.

Recommended ADR settings for agriculture:

• Increase link margin from 10 dB to 18 dB (absorbs seasonal variation without SF changes)
• Reduce ADR convergence window from 20 to 10 uplinks (faster response to sudden changes)
• Set ADR_ACK_LIMIT to 32 (allow more unacknowledged uplinks before reverting to SF12)

Deployment Type 3: Mobile asset trackers (ADR should be disabled)

For devices that move between locations (livestock trackers, logistics pallets, bicycle-share trackers), ADR creates a dangerous feedback loop:

1. Tracker moves closer to a gateway; ADR reduces to SF7
2. Tracker moves away; packets at SF7 are lost
3. After ADR_ACK_LIMIT failures, device reverts to SF12
4. SF12 succeeds but consumes 32x more airtime than SF7
5. Device moves closer again; ADR reduces to SF7
6. Cycle repeats – device oscillates between SF7 and SF12

This oscillation wastes 40–60% more battery than using a fixed SF. The recommended approach for mobile devices:

Option A: Fixed SF based on worst-case range
  Measure max distance from any gateway in the deployment area
  Select SF that provides reliable coverage at that range + 6 dB margin
  Example: Urban bike-share, max 3 km from gateway
    Path loss at 3 km: ~130 dB
    Required sensitivity: -130 + 6 = -136 dBm
    SF9 sensitivity: -136 dBm (exact match)
    Use fixed SF10 for additional margin

Option B: Application-layer adaptive SF (not standard ADR)
  Device measures RSSI of received downlinks
  If RSSI > -100 dBm: use SF7
  If -100 > RSSI > -115: use SF9
  If RSSI < -115: use SF11
  Changes take effect immediately (no 20-uplink convergence)
  Battery savings vs oscillation: 35--50%

Key insight: ADR is an optimization, not a requirement. Disabling ADR and using a fixed spreading factor is often the correct choice for non-stationary devices. The airtime penalty of a fixed SF10 (vs optimal SF7) is far less than the penalty of ADR oscillation between SF7 and SF12.

Worked Example: Agricultural Sensor ADR Convergence Analysis

Scenario: A 500-acre vineyard deploys 200 LoRaWAN soil moisture sensors. Sensors initially join at SF12 (conservative default) and report every 30 minutes. Gateway is centrally located on a 15-meter tower.

Sensor Distribution:

• Group A (50 sensors, 0-500m from gateway): RSRP -85 dBm, SNR +12 dB
• Group B (100 sensors, 500-2000m): RSRP -105 dBm, SNR +2 dB
• Group C (50 sensors, 2000-4000m, hill obstruction): RSRP -125 dBm, SNR -8 dB

ADR Convergence Timeline:

Day 1 (All devices at SF12):

• Airtime per message (20-byte payload): 1,320 ms
• Messages per hour: 200 sensors × 2 = 400 messages
• Total airtime: 400 × 1.32 s = 528 seconds/hour
• Duty cycle usage (1% = 36 sec/hour limit): 528 / 36 = 14.7× OVER LIMIT
• Result: Massive collisions, 38% packet loss

After 20 uplinks (10 hours) - ADR kicks in:

Group A → SF7 (ADR assigns after detecting +12 dB SNR):

• Required SNR for SF7: -7.5 dB
• Link margin: +12 - (-7.5) = 19.5 dB (excellent)
• New airtime: 56 ms (24× faster!)
• Energy per message: 56 ms × 120 mA = 6.72 mAs vs SF12: 158.4 mAs (96% energy savings)

Group B → SF9 (ADR assigns after detecting +2 dB SNR):

• Required SNR for SF9: -12.5 dB
• Link margin: +2 - (-12.5) = 14.5 dB (good)
• New airtime: 247 ms (5.3× faster than SF12)
• Energy savings: 81%

Group C → Stays SF12 (ADR retains after detecting -8 dB SNR):

• Required SNR for SF12: -20 dB
• Link margin: -8 - (-20) = 12 dB (adequate)
• Airtime: 1,320 ms (unchanged)

Day 2+ (ADR optimized):

• Group A (SF7): 50 × 2 × 0.056s = 5.6 s/hour
• Group B (SF9): 100 × 2 × 0.247s = 49.4 s/hour
• Group C (SF12): 50 × 2 × 1.32s = 132 s/hour
• Total airtime: 187 s/hour
• Duty cycle usage: 187 / 36 = 5.2× over (still high, but manageable with TDMA)
• Packet loss: Reduced to 4.8% (acceptable)

Battery Life Impact (2,000 mAh battery, 48 messages/day):

• Group A (SF7): 48 × 6.72 mAs = 322 mAs/day = 0.09 mAh/day → 61 years (limited by self-discharge)
• Group B (SF9): 48 × 46.8 mAs = 2,246 mAs/day = 0.62 mAh/day → 8.8 years
• Group C (SF12): 48 × 158.4 mAs = 7,603 mAs/day = 2.11 mAh/day → 2.6 years

Key Takeaway: ADR reduced Group A battery consumption by 96% (61 years vs 2.6 years) while maintaining reliable delivery. Without ADR, all sensors would waste energy using SF12 unnecessarily.

Decision Framework: When to Enable vs Disable ADR

Deployment Scenario	ADR Setting	Target Margin	NbTrans	Rationale
Stationary urban sensors (parking, waste bins)	Enabled	12-15 dB	2	Interference-resistant, optimize for battery
Stationary rural sensors (agriculture, environment)	Enabled	5-8 dB	1	Clean RF, maximize battery life
Indoor stationary (building automation)	Enabled	18-20 dB	3	Fading margin for people/furniture movement
Mobile assets (vehicle trackers, livestock)	Disabled	N/A	1	Signal changes too fast for ADR convergence
Critical alarms (fire, security)	Enabled	25 dB	4	Redundancy over efficiency
Seasonal deployment (agriculture with crop growth)	Enabled	18 dB	2	Higher margin absorbs seasonal variation

Decision Rules:

Enable ADR when:

1. Device is stationary (signal quality stable over weeks)
2. Battery life is critical (>5 year target)
3. Deployment has overlapping gateway coverage (ADR picks best gateway automatically)
4. Message frequency is <4 per hour (allows time for ADR to converge)

Disable ADR when:

1. Device is mobile (signal changes faster than ADR can track)
2. Deployment is temporary (<6 months, convergence time not worth it)
3. Mission-critical application where packet loss is unacceptable (use fixed high SF)
4. Testing/debugging (fixed SF simplifies analysis)

Adjust Link Margin when:

• Urban with high interference: Increase margin to 15-18 dB
• Seasonal variation (crops, foliage): Increase margin to 18 dB to absorb 8-15 dB crop attenuation swing
• Rural with clear line-of-sight: Decrease margin to 5 dB to maximize battery life
• Weather extremes (heavy rain): Increase margin by 3-5 dB for rain attenuation

Example ADR Configuration (The Things Network):

// Enable ADR with custom margin (default: 10 dB)
LMIC_setAdrMode(1);  // Enable ADR
LMIC_setLinkCheckMode(1);  // Enable link check to feed ADR algorithm

// For agricultural deployment with seasonal variation:
LMIC.adrTxPow = 14;  // Start with 14 dBm (don't reduce power aggressively)
// Network server will auto-adjust SF based on margin target

Common Mistake: Using fixed SF9 “to be safe” for all devices, regardless of signal quality. This wastes 5-10× more energy than ADR-optimized SF7 for nearby devices while still underutilizing SF12 for distant devices.

Common Mistake: Enabling ADR on Mobile Asset Trackers Causes Battery Drain Oscillation

The Error: A bike-share system deployed LoRaWAN GPS trackers on 5,000 bicycles with ADR enabled (default setting). Trackers reported position every 5 minutes while in use. Battery life was only 4 months instead of the expected 18 months.

What Went Wrong - The ADR Oscillation Trap:

Cycle 1 (Bike parked near gateway, 200m):

• RSRP: -90 dBm, SNR: +10 dB
• ADR converges after 20 uplinks (100 minutes): SF7 assigned
• Airtime: 56 ms, energy: 6.72 mAs per message

Cycle 2 (Bike ridden 3 km away, weak signal):

• RSRP: -120 dBm, SNR: -5 dB
• SF7 is now inadequate (requires SNR > -7.5 dB)
• Packets LOST for 20 uplinks (100 minutes) → device increments FCnt but network never receives
• After ADR_ACK_LIMIT failures (64 by default), device reverts to SF12

Cycle 3 (Bike parked again, SF12 overkill):

• RSRP: -90 dBm (good signal, but using SF12)
• Airtime: 1,320 ms (24× more than needed!)
• Energy: 158.4 mAs (24× waste)

Cycle 4 (ADR re-converges to SF7):

• After 20 uplinks at good signal, ADR drops back to SF7
• Then bike moves again → repeat oscillation

Battery Impact:

• Good signal periods (50% of time): Using SF12 when SF7 would work = 24× energy waste
• Poor signal periods (50% of time): 20 packet losses before SF adjustment
• Average energy: (158.4 × 0.5) + (6.72 × 0.5) = 82.56 mAs (vs optimal 6.72 mAs for static SF9)
• Battery life: 2,000 mAh / (82.56 × 0.023 mAh/day × 288 msgs/day) = 4.2 months

The Fix:

1. Disable ADR: LMIC_setAdrMode(0);
2. Use fixed SF9: Covers 90% of urban bike-share operating radius (0-5 km)
3. Result: Fixed SF9 uses consistent 46.8 mAs per message
4. Battery life: 2,000 / (46.8 × 0.013 × 288) = 11.4 months (2.7× improvement)
5. Further optimization: Use application-layer adaptive SF based on GPS distance from last known gateway

Lesson: ADR assumes stationary devices with stable signal quality. For mobile devices, ADR oscillation between SF extremes wastes 40-60% more battery than using a fixed spreading factor based on worst-case distance. Disable ADR for any device that moves more than 500 meters during its operating lifetime.

Try It Yourself: ADR Configuration for Your Deployment

Challenge: Configure ADR settings for a mixed deployment with different device types.

Given Scenario:

• 100 stationary parking sensors (urban, 0.5-2 km from gateway)
• 50 mobile asset trackers (vehicles, 0-5 km range)
• 20 agricultural soil sensors (rural, 2-8 km from gateway)

Your Tasks:

1. For each device type, decide: Enable or disable ADR?
2. If ADR disabled, what fixed SF would you use?
3. Calculate expected battery life difference between ADR-enabled and fixed SF12
4. Estimate network capacity impact (messages/hour per gateway)

What to Observe:

• How device mobility affects ADR suitability
• Trade-offs between battery life and network capacity
• When fixed SF is better than “automatic” optimization
• Impact of environment (urban vs rural) on SF selection

Expected Insights:

• Parking sensors: ADR enabled, expect SF7-SF8 (excellent battery, high capacity)
• Asset trackers: ADR disabled, fixed SF9 (avoid oscillation)
• Agricultural sensors: ADR enabled with 18 dB margin (handles seasonal variation)

How It Works: ADR Convergence Process

The ADR algorithm follows a precise convergence process to optimize each device:

1. Data Collection Phase: Network server records SNR and RSSI from the last 20 uplink messages
2. Margin Calculation: Computes link margin = measured SNR - required SNR for current SF
3. Decision Logic: If margin > target (10 dB), reduce SF by 1-2 steps; if margin < target, increase SF
4. Command Transmission: Send LinkADRReq MAC command in next available downlink window
5. Device Response: Device acknowledges with LinkADRAns and applies new settings
6. Verification: Monitor next 5-10 uplinks to confirm stable operation at new SF

This closed-loop feedback ensures each device uses minimum resources while maintaining reliable communication.

Interactive Quiz: Match Concepts

Interactive Quiz: Sequence the Steps

12.6 Concept Relationships

Concept	Relationship	Connected Concept
Adaptive Data Rate (ADR)	Optimizes by adjusting	Spreading Factor (SF7-SF12)
Spreading Factor	Determines	Airtime and Battery Consumption
Link Margin	Drives decisions in	ADR Algorithm
Duty Cycle (1%)	Limits capacity at	High Spreading Factors (SF11-SF12)
Network Server	Calculates and sends	LinkADRReq MAC Commands
Device Mobility	Breaks assumptions of	ADR Convergence

🏷️ Label the Diagram

💻 Code Challenge

12.7 Summary

This chapter covered ADR and duty cycle optimization:

• ADR Algorithm: Uses 20 uplinks to calculate optimal SF based on link margin
• Link Margin Target: 10 dB for reliability, adjustable per deployment
• ADR Limitations: Fails with mobile devices, sudden interference, weather changes
• EU Duty Cycle: 1% (36 sec/hour) on main sub-bands
• US Regulations: No duty cycle but 400ms dwell time and frequency hopping
• Message Budget: Higher SF = fewer messages possible under duty cycle

12.8 See Also

• LoRaWAN Network Architecture - How network server handles ADR centrally
• Device Classes - Why Class A devices benefit most from ADR
• Link Budget Calculation - Understanding SNR and RSSI measurements
• Common Pitfalls - ADR mistakes and how to avoid them
• LoRa Modulation - How spreading factors affect sensitivity

12.9 Knowledge Check

Quiz: LoRaWAN ADR and Duty Cycle

Common Pitfalls

1. Disabling ADR for Stationary Devices

Disabling ADR on permanently fixed devices wastes significant energy and airtime. ADR converges within 20 transmissions for static devices and can reduce airtime by up to 21x. Only disable ADR for genuinely mobile devices.

2. Forcing Maximum TX Power Always

Setting devices to always transmit at maximum power without ADR increases battery consumption and co-channel interference. Let ADR reduce TX power when link margin allows; devices close to gateways benefit most from power reduction.

3. Ignoring Duty Cycle When Planning Message Rate

Designing without calculating duty cycle consumption leads to regulatory violations or dropped messages. Always calculate: time_on_air × messages_per_hour ≤ channel duty cycle limit (1% EU868 = 36s/hour).

4. ADR Convergence on Very Infrequent Transmissions

ADR requires approximately 20 consecutive uplinks for convergence. If devices transmit once per day, ADR convergence takes weeks. For very low message-rate devices, manually configure a conservative fixed SF rather than relying on ADR.

12.10 What’s Next

Next Topic	Description
Common Pitfalls	Common LoRaWAN deployment mistakes and how to avoid them
LoRaWAN Lab	Hands-on simulation exercises with ADR and duty cycle
Practice Exercises	Test your knowledge of ADR optimization and duty cycle budgeting