A water meter or irrigation sensor joining a LoRaWAN network does not establish that every subsequent measurement will reach the billing database or SCADA application. Radio reception, network-level packet deduplication, application persistence and human alarm acknowledgement are separate reliability layers. This article develops a commissioning method for a field deployment that may use the ATLAS LR-1 gateway. All counts below are illustrative; they are not observed reliability figures for ATLAS hardware or for any named site.
1. Understand the multi-gateway reception model
A LoRaWAN end device normally transmits without selecting or associating with one particular gateway. Several gateways may hear the same uplink and forward their copies into the network infrastructure. The network server correlates/deduplicates receptions before presenting application traffic. Semtech and The Things Stack document this architecture. Adding a second gateway therefore offers potential reception diversity, but it offers genuine redundancy only where both receiving paths work for the critical endpoints. Adjacent coverage footprints are not proof of overlapping coverage. Two gateways that share one power supply, mast or cellular backhaul may also fail together.
2. Confirm the regional plan before calculating coverage
The LoRa Alliance issued RP002-1.0.5 Regional Parameters on 8 October 2025. For a Turkish installation, validate the applicable radio rules, regional frequency plan and hardware version rather than assuming a gateway marketed for multiple international bands is universally configurable. The ATLAS LR-1 product description mentions multi-spreading-factor reception and ADR, while the exact selected device’s frequency variant, channels, antenna and network-server compatibility need project-level verification. A quoted open-area distance is not a contractual guarantee across industrial buildings, hills or buried meter pits. Survey with the intended antenna position and actual endpoints.
3. Define completeness using an explicit denominator
Suppose 120 sensors are scheduled to report once per hour. Over 24 hours, the application expects 120×24=2,880 records. If it stores 2,765 unique measurements, schedule-based completeness is 2,765/2,880≈96.0%, leaving 115 expected records unseen. This figure must not be labelled an RF packet-delivery ratio without further evidence. Some devices may not have transmitted, their clocks may have drifted, or application integration may have dropped records after network receipt. To estimate radio delivery, reconcile endpoint transmission or sequence logs, network-server events and gateway reception metadata. Keep the terms ‘expected’, ‘transmitted’, ‘received by network’ and ‘persisted by application’ separate in the quality report.
4. Deduplicate receptions without deleting legitimate measurements
Imagine the receiving gateways record 4,010 raw reception entries, but the network resolves them to the same 2,765 distinct uplink events. The difference of 1,245 entries represents extra received copies and possibly protocol-level repeats, not additional water consumption. Store enough context to audit this resolution: device identifiers, session context, frame counters, receive times, port and gateway-specific RSSI/SNR. Downstream integrations should also implement idempotency using a record identity appropriate to session changes, restarts and delayed uploads. Never discard an observation merely because its numerical value equals the previous reading: two legitimate temperature observations, or an unchanged cumulative meter counter, can be identical.
5. Inspect distributions, not one universal RSSI number
RSSI characterises received signal strength, while SNR expresses signal relative to noise. Successful decoding depends on spreading factor, bandwidth, interference and the specific receiver. An arbitrary RSSI threshold is therefore not a reliable pass/fail rule for every deployment. Map the count of receiving gateways, SNR/RSSI distributions over time, spread-factor allocation, join reliability and completeness by endpoint. Check antenna placement, cable losses, lightning protection, power continuity and internet backhaul as well. Adaptive Data Rate can be useful for sufficiently stationary devices, whereas rapidly changing radio conditions demand more caution. Test in wet conditions and normal operating hours if these materially affect propagation.
6. Keep network ACK distinct from operational confirmation
A LoRaWAN confirmed uplink requests acknowledgement from the network server. The resulting ACK does not prove that a customer’s database transaction committed or that an operator acknowledged an alarm. Excessive confirmed uplinks also consume scarce downlink airtime and can become counterproductive in large networks. For critical operational alerts, define an application event identifier, measured-at timestamp, stored-at timestamp, retry policy, stale-data indication, escalation path and user acknowledgement. A frame counter is useful but not sufficient by itself for globally unique record identity across new sessions or restarts. Keep delayed historical measurements separate from live instantaneous state in the SCADA dashboard.
7. Commission and specify the ATLAS project correctly
For each critical meter, test one- versus two-gateway coverage, multiple time windows, 24–72 hours of schedule-based completeness, gateway power-loss scenarios, cellular/Ethernet backhaul loss and end-to-end alarm handling. The ATLAS LR-1 LoRaWAN gateway page identifies the offered gateway family. For a technical quotation, provide the deployment country, number and type of endpoints, reporting interval, site layout, antenna elevations, backhaul options and proposed acceptance KPIs. Ask ATLAS technical sales to confirm the exact hardware revision and network integration, rather than requesting an unsupported ‘zero packet-loss’ promise.