The demonstration is convincing: a sensor sends a reading, the gateway receives it, and the dashboard updates. Then the device is mounted behind a metal tank, inside its intended enclosure, at the far end of the building. The operation is now depending on an installation that the demonstration never tested.
A wireless coverage survey closes that gap before a broad rollout. It asks whether the proposed locations and configurations deliver useful messages under representative site conditions. The output should be an installation decision with known limits, not a colored map that implies every point in the building has been proven reliable.
Test the mounted device rather than the product category
A useful survey starts with a specific device, radio protocol, antenna arrangement, enclosure, mounting position, gateway configuration, and intended reporting behavior. A handheld development board at head height is not automatically representative of a finished sensor inside a case beside machinery.
Write down the conditions the business actually needs to observe. A gateway test during an empty shutdown may not represent a normal production shift, filled storage area, or closed service door. Those conditions are candidates to test, not an invitation to assume that any one object caused every missing message.
The survey does not require testing every imaginable future configuration. It does require stating which configurations and operating periods were examined and which were not. If the business later moves the gateway or fills an area with new equipment, the original acceptance record should make the need for review obvious.
Measure delivery before interpreting signal indicators
Received signal strength and signal-to-noise ratio can help interpret a radio link. The Things Network's LoRaWAN documentation describes RSSI and SNR for that protocol. Their readings are useful evidence, but a strong-looking value on a received packet does not account for messages that never arrived.
Keep a record of the messages the test device was expected to send. Use identifiers or a test log that lets the reviewer distinguish an absent message from a duplicate. Compare those records with gateway reception and application arrival where the system exposes both.
If two gateways receive the same test message, count it once for application delivery rather than as two successful messages. Define how the observation window handles late arrivals and keep them identifiable. Otherwise duplicate receptions or an extended wait can make two location tests look more comparable than they are.
The business may care about delay as much as eventual receipt. A report that arrives too late to support the intended inspection or operating decision should not be counted as a timely success merely because it appeared later. Define the useful reporting window with the owner of that monitoring task before interpreting the results.
- Map the locationsIdentify mounting position, enclosure, obstructions, and the intended operating need.
- Test the configurationUse representative hardware, antenna, payload, timing, and gateway settings.
- Compare deliveryReconcile expected messages with gateway and application records.
- Accept or reviseRecord limits, retest changed positions, and assign a commissioning owner.
Work through one obstructed location
Consider an illustrative greenhouse service area using wireless condition monitoring. It is not a client case study or a claim about a particular product's range. The proposed node is near metal equipment, and the team wants to compare its original mounting position with an accessible alternative.
In one hypothetical observation window, the device log records 100 expected test messages and the application receives 82 distinct corresponding messages. That is 82 divided by 100, or 82 percent delivery for that window. The figure is not a universal pass mark or a measurement of year-round availability.
The commissioning technician checks whether the gateway recorded the missing messages. If the gateway has them but the application does not, the unresolved issue is not established as a radio coverage problem. The technical team investigates the relevant delivery stage before changing antennas or moving equipment.
For a location comparison, the technician documents the changed mounting position and retains the device and configuration references. Tests are repeated over relevant operating conditions, with enough observation to answer the actual monitoring question. A better result is a candidate improvement to verify, not proof that a short trial predicts every future state of the site.
If a location remains unsuitable, the installation record says so. The owner can consider another gateway position, another approved communications method, or a wired alternative. The system does not label an untested location green to make the rollout plan look complete.
Build a survey record someone can repeat
The site-survey matrix should make both the successful and unsuccessful tests reproducible:
- Location: a stable point ID, installation height and orientation, enclosure, nearby obstructions, and a photo or drawing reference.
- Configuration: device and firmware, protocol settings, antenna, gateway identity and position, payload, and reporting interval.
- Observation window: start and end, relevant site conditions, expected message count, and any test interruption.
- Results: distinct messages received, missing or duplicate messages, arrival timing, and available RSSI/SNR records with their protocol context.
- Decision: intended monitoring use, acceptance criteria, unresolved limitations, responsible reviewer, and required retest.
Avoid comparing two test windows as if only position changed when the reporting rate, payload, gateway, or operating state also changed. Those differences belong in the record, even when they make the conclusion less tidy.
Let the survey determine the rollout boundary
Ordinary tools can reconcile message identifiers, calculate delivery ratios, and keep configuration versions. AI can summarize the observations, identify missing survey points, or draft a commissioning note. It should not invent observations between tested points or declare an installation accepted from an appealing visualization.
LoRaWAN's published limitations are a useful reminder that a low-power radio system has deployment constraints. Other protocols have their own requirements. A monitoring survey does not establish suitability for a safety function or time-critical machine control.
Start with one difficult area, record the decision, and retain a manageable retest plan. Coverage work is successful when the operator knows where the system is useful, where evidence is incomplete, and what must be checked when the installation changes.
Sources & further reading
Primary references checked October 19, 2026. Examples are illustrative, not reported client outcomes.
- The Things Network: RSSI and SNRFirst-party LoRaWAN background on received signal strength and signal-to-noise ratio. Do not generalize its radio characteristics or numerical limits to other protocols.
- The Things Network: LoRaWAN limitationsProtocol-specific limits and deployment responsibility. A site survey must use the chosen system's actual requirements and applicable radio rules.
