LoRa & LoRaWAN · Study deck

LoRaWAN Common Pitfalls

A car-park sensor begins draining its battery after a firmware update.

Radio Remi is your guide for this deck.

common
iotclass.org

After studying this chapter

Learning objectives

You will be able to:

  • Explain: If OTAA devices rejoin successfully but the application sees no data, the join path and application routing evidence should be checked separately rather than merged into one "network problem.".
  • Explain: The useful question is therefore not "does LoRaWAN have long range?" but "which symptom changed, what evidence moved, and what smallest correction restores margin without hiding the cause?".
  • Explain: The reviewer separates radio hearing from network acceptance, checks counter rollback and session state, then requires OTAA or persistent counter handling with reset testing before release.
  • diagnose LoRaWAN deployment symptoms from evidence
iotclass.org

Major section

Start Simple

The real cause might be a larger message, more retries, a failed join, or a battery that now spends longer awake.

  • The support owner should write the exact symptom first.
  • A late command may be normal for a sleeping unit but unsafe for a task that expects instant control.
  • If it moves an antenna, repeat weak-place and weather tests.

Key terms

High power use
High power use is not poor reach.

Why it matters

If the fix reduces message size, repeat the field path and battery check.

iotclass.org

Major section

Start Simple (continued)

A repeated status record may be harmless unless it starts the same work twice.

  • A later team can then compare the same fault instead of starting from a guess.
  • A clear unknown state can be safer than a smooth but false history.
  • A failed join is not a late report.
  • A late report is not a missed command.
Device class review should be tied to downlink timing and power assumptions, not to habit or convenience.
Device class review should be tied to downlink timing and power assumptions, not to habit or convenience.
iotclass.org

Major section

Start Simple (continued)

Under the Hood explains airtime limits, device classes, rate control, frame checks, and reset behavior.

  • High power use is not poor reach.
  • They may share a cause, but each needs its own observed result.
  • A pattern can reveal a common change.
  • One symptom can still have several linked causes.
Device class review should be tied to downlink timing and power assumptions, not to habit or convenience.
Device class review should be tied to downlink timing and power assumptions, not to habit or convenience.
iotclass.org

Major section

Start Simple (continued)

If the fix reduces message size, repeat the field path and battery check.

  • Practitioner uses a repeatable fault record.
  • When a LoRaWAN deployment disappoints, begin with the symptom instead of guessing the cause.
  • Missing uplinks, late commands, failed joins, high battery drain, duplicate records, and poor ADR behavior each point to different evidence.
Device class review should be tied to downlink timing and power assumptions, not to habit or convenience.
Device class review should be tied to downlink timing and power assumptions, not to habit or convenience.
iotclass.org

Major section

Overview: Start From The Symptom

That symptom-led record also protects later maintainers.

  • Most LoRaWAN failures do not begin as mysterious radio problems.
  • Twelve-byte status reports every fifteen minutes means 96 routine uplinks per device per day before retries, joins, alarms, or confirmed messages are counted.
  • A broad claim such as "long range and low power" is not enough.

Why it matters

For example, a parking sensor fleet that looks fine in a workshop can fail after installation because the review bundled several assumptions together.

Useful pitfall review starts with a symptom, maps it to likely causes, requests narrow evidence, and records the correction.
Useful pitfall review starts with a symptom, maps it to likely causes, requests narrow evidence, and records the correction.
iotclass.org

Major section

Overview: Start From The Symptom (continued)

If the field location forces a slower radio setting, the same payload consumes more airtime and leaves less room for bursts.

  • The useful question is therefore not "does LoRaWAN have long range?" but "which symptom changed, what evidence moved, and what smallest correction restores margin without hiding the cause?".
  • If a missing-reading incident is closed only as "coverage improved," the next firmware or payload change can repeat the mistake.
  • For example, a parking sensor fleet that looks fine in a workshop can fail after installation because the review bundled several assumptions together.
iotclass.org

Major section

Under The Hood: Preserve Activation, Counters, And Release Evidence

Counter repair, credential replacement, channel-mask correction, ADR rollback, and receive-window tuning are different fixes with different owners.

  • Some LoRaWAN pitfalls are not visible in application dashboards.
  • A release can drift because channel plans, credentials, or reset behavior were never recorded.
  • The release record should also define the recovery path.

Why it matters

A downlink promise can fail because receive windows are wrong.

Activation review separates OTAA join evidence, ABP exceptions, frame counters, reset behavior, replay protection, and recovery records.
Activation review separates OTAA join evidence, ABP exceptions, frame counters, reset behavior, replay protection, and recovery records.
iotclass.org

Major section

Under The Hood: Preserve Activation, Counters, And Release Evidence (continued)

OTAA evidenceKeep join records, credential ownership, accepted and rejected frame examples, and recovery behavior after reset.

  • A good under-the-hood review separates the layers in the evidence.
  • If an ABP device resets and reuses stale state, the gateway trace may still look healthy while replay protection correctly rejects traffic.
  • ABP exceptionDocument why ABP is used, how counters persist, how replay protection is preserved, and how recovery is tested.
iotclass.org

Major section

Under The Hood: Preserve Activation, Counters, And Release Evidence (continued)

If OTAA devices rejoin successfully but the application sees no data, the join path and application routing evidence should be checked separately rather than merged into one "network problem.".

  • Regional profileRecord region, sub-band, channel mask, join channels, data-rate policy, gateway forwarding, and network-server limits.
  • The reviewer separates radio hearing from network acceptance, checks counter rollback and session state, then requires OTAA or persistent counter handling with reset testing before release.
  • A downlink promise can fail because receive windows are wrong.
iotclass.org

Major section

Find the Reporting-Interval Regression before Moving the Antenna

A day contains 1,440 minutes, so the device sent 1,440 divided by 15 = 96 scheduled uplinks.

  • The new schedule sends once a minute, producing 1,440 uplinks.
  • This common configuration mistake multiplies the scheduled count by 15 even though each useful payload remains small.
  • The new one uses 144 s.
Useful pitfall review starts with a symptom, maps it to likely causes, requests narrow evidence, and records the correction.
Useful pitfall review starts with a symptom, maps it to likely causes, requests narrow evidence, and records the correction.
iotclass.org

Major section

Find the Reporting-Interval Regression before Moving the Antenna (continued)

For an illustrative LoRaWAN test with 0.1 s measured airtime per transmission, the old schedule uses 9.6 s of transmit airtime per day.

  • Neither calculation includes joins, retries or downlinks, and neither establishes compliance with the installed regional rules.
  • Those common omissions can make the spreadsheet look better than the current trace.
  • A second common error is enabling confirmation on every periodic reading without budgeting the return traffic.
The release packet makes recurring mistakes visible before they become field failures.
The release packet makes recurring mistakes visible before they become field failures.
iotclass.org

Major section

Find the Reporting-Interval Regression before Moving the Antenna (continued)

A common troubleshooting error is moving the antenna before checking counts, which can hide a schedule regression behind better signal.

  • LoRaWAN downlinks require receive opportunities and network resources; requesting many acknowledgements does not make them free.
  • It leaves the fifteenfold schedule increase untouched.
  • Duplicate LoRaWAN copies need server and application checks before they are counted as separate sensor transmissions.
  • These pitfalls illustrate why a narrow fault record is useful.
The release packet makes recurring mistakes visible before they become field failures.
The release packet makes recurring mistakes visible before they become field failures.
iotclass.org

Deck summary

Key takeaways

The real cause might be a larger message, more retries, a failed join, or a battery that now spends longer awake.

  • A repeated status record may be harmless unless it starts the same work twice.
  • Under the Hood explains airtime limits, device classes, rate control, frame checks, and reset behavior.
  • If the fix reduces message size, repeat the field path and battery check.
  • That symptom-led record also protects later maintainers.
iotclass.org

Retrieval practice

Recall check 1 of 3

Radio Remi says: answer from memory, then check your reasoning.

Q1A LoRaWAN deployment has missing readings after devices move from the lab bench to final placement. Which first review step keeps the diagnosis bounded?

ARequest rate, payload, region, gateway reception, and ADR evidence.
BApprove release because the technology is associated with long range.
CAssume gateway failure before checking rate or payload changes.
DEnlarge each payload to add diagnostics because the extra bytes make failures easier to identify in the field.
Show answer

Answer: A LoRaWAN pitfall review starts with a symptom and asks for narrow evidence before assigning the cause.

iotclass.org

Retrieval practice

Recall check 2 of 3

Radio Remi says: answer from memory, then check your reasoning.

Q2A payload works near the gateway but fails after final installation when the network selects a slower data rate. How should the team respond to the installed payload failure at a slower data rate?

AApprove the release because the payload worked during lab testing.
BTreat the failure as a gateway hardware problem because the installed position exposes a weak gateway receiver.
CDisable frame counters so larger application messages can be accepted.
DCheck restrictive payload fit and require compact fallback layout if needed.
Show answer

Answer: D Payload review should be based on the restrictive production setting, not only the lab condition.

iotclass.org

Retrieval practice

Recall check 3 of 3

Radio Remi says: answer from memory, then check your reasoning.

Q3ABP devices are heard by gateways after a reset, but the network server rejects the frames. Which evidence should the reviewer request first?

ARefresh dashboard colors used for rejected uplink frames.
BCite successful firmware from another deployment as proof.
CAdd fields to each uplink without inspecting session counters.
DCompare counter and session state before and after reset.
Show answer

Answer: D Activation and counter behavior are operational release evidence, not only setup details.

iotclass.org

Print reference

Answers

Answer key.

  1. A · LoRaWAN pitfall review starts with a symptom and asks for narrow evidence before assigning the cause.
  2. D · Payload review should be based on the restrictive production setting, not only the lab condition.
  3. D · Activation and counter behavior are operational release evidence, not only setup details.
iotclass.org