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

Radio Remi, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

You will be able to:

Explain: If the record says payload size was reduced, retry policy was bounded, ADR history was rechecked after final placement, and the owner must retest after antenna or reporting-interval changes, the fix remains auditable.
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: A reviewer should ask whether the plan still has margin when the weakest installed devices use the slowest expected setting and when alarms cluster instead of arriving evenly.

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.

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.

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.

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.

Major section

Overview: Start From The Symptom

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.
If the field location forces a slower radio setting, the same payload consumes more airtime and leaves less room for bursts.

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

Major section

Overview: Start From The Symptom (continued)

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?".

That symptom-led record also protects later maintainers.
If a missing-reading incident is closed only as "coverage improved," the next firmware or payload change can repeat the mistake.
If the record says payload size was reduced, retry policy was bounded, ADR history was rechecked after final placement, and the owner must retest after antenna or reporting-interval changes, the fix remains auditable.

Major section

Practitioner: Prove Airtime, Payload, ADR, And Class Fit

A reviewer should ask whether the plan still has margin when the weakest installed devices use the slowest expected setting and when alarms cluster instead of arriving evenly.

Worked Review: Lab Payload Fails In Production A payload works near the gateway, but final placement causes slower data rates.

Airtime review combines schedule, payload size, data rate, retries, joins, downlinks, regional limits, and remaining margin.

Major section

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

Some LoRaWAN pitfalls are not visible in application dashboards.

A release can drift because channel plans, credentials, or reset behavior were never recorded.
A good under-the-hood review separates the layers in the evidence.
The release record should also define the recovery path.

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

Major section

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

If an ABP device resets and reuses stale state, the gateway trace may still look healthy while replay protection correctly rejects traffic.

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.".
Counter repair, credential replacement, channel-mask correction, ADR rollback, and receive-window tuning are different fixes with different owners.
OTAA evidence Keep join records, credential ownership, accepted and rejected frame examples, and recovery behavior after reset.
A downlink promise can fail because receive windows are wrong.

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.

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.

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.

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.
Most LoRaWAN failures do not begin as mysterious radio problems.

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?

AApprove the release because LoRaWAN is associated with long range.

BRequest data-rate, payload-size, regional-limit, gateway-hearing, and ADR evidence for the affected flow.

CAssume gateway hardware failed without checking payload size or data-rate changes.

DIncrease every payload so diagnostics contain more fields.

Show answer

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

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. What is the best review response?

AApprove the release because the payload worked during lab testing.

BTreat the failure as a gateway hardware problem without checking payload size.

CCheck restrictive payload fit and require compact fallback layout if needed.

DDisable frame counters so larger application messages can be accepted.

Show answer

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

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?

AFrame-counter and session-state behavior before and after reset.

BA new dashboard color scheme for rejected frames.

CA promise that the same firmware worked on another project.

DMore application fields in every uplink.

Show answer

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

Print reference

Answers

Answer key.

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