Built-In LoRaWAN RF Testing: How Checking Signal at the Mounting Point Makes Deployments Work First Time
Short Answer
Built-in RF testing lets a LoRaWAN sensor measure its own radio link at the exact spot where it is being mounted, and show the result to the installer on a phone. Instead of surveying a site with a separate tester and hoping the sensor behaves the same way later, the installer sees signal quality from the real device, in its final position, before the last screw goes in.
With the Macnman Maya app, the installer sees:
- RSSI and SNR at the mounting point
- A link check result: link margin and the number of gateways that heard the device
- A clear decision on site: mount here, move it, or fix the coverage, made on the day rather than three weeks later on a dashboard
The result is fewer site revisits, fewer silent dead nodes, battery life closer to the datasheet figure, and a commissioning record you can hand to the customer.
Why Sensors That Passed the Survey Still Fail
Most LoRaWAN projects follow the same sequence. Someone surveys the site, picks gateway positions, and confirms coverage with a tester carried at head height through the aisles. Weeks later, an installer mounts the sensors. The sensor ends up:
- inside a metal control panel with the door closed
- behind a steel rack or in a cold room with insulated sandwich panels
- at floor level in a parking bay, or inside a tank chamber or sump
Any of those spots can lose 10 to 20 dB or more compared with the open aisle where the survey was done. The survey said the area had coverage. It never tested the mounting point.
Then the installer leaves. On the network server, the sensor either never joins, joins but settles at SF12, or reports intermittently. In many Indian projects:
- the installer is a contractor, not the engineer who planned the network
- the person with access to the network server is in another city
- the site’s internet backhaul may not even be live yet
So the problem is found as a data gap during the first week of operation, and fixing it costs a second site visit.
This is the gap built-in RF testing closes: feedback from the actual device, at the actual position, while the installer is still standing there. For the wider list of things that go wrong on LoRaWAN projects, see The Real Challenges of Deploying a LoRaWAN Network.
What Built-In RF Testing Actually Measures
A built-in RF test sends a short exchange between the sensor and the network, then reports what each side measured. Each number answers a different question:
| Metric | What it tells you | Measured by |
|---|---|---|
| RSSI (dBm) | How strong the network’s reply was when it reached the sensor | Sensor (downlink) |
| SNR (dB) | How far that reply sat above the background noise | Sensor (downlink) |
| Link margin (dB) | How much headroom the sensor’s uplink had above the point where it would fail | Network (uplink) |
| Gateway count | How many gateways heard the sensor | Network (uplink) |
| Join status | Whether the full two-way exchange works at all | Both |
The important detail is direction. RSSI and SNR shown on the phone describe the downlink, the network talking to the sensor. Link margin and gateway count describe the uplink, the sensor talking to the network. A position can be fine in one direction and weak in the other, and a weak downlink is exactly what breaks joins, configuration changes and adaptive data rate (ADR) later.
The protocol side of this, including the LinkCheckReq and DevStatusReq MAC commands, is explained in detail in LoRaWAN Link Check: Built-In RF Testing You Already Have. This article is about using those measurements during installation.
Six Ways Built-In RF Testing Improves a LoRaWAN Deployment
1. The right mounting point, first time
Moving a sensor one metre during installation costs nothing; moving it after handover costs a site visit. With a live reading on the phone, the installer can try the planned spot, then the other side of the pillar, then the top of the panel instead of the bottom, and pick the best one in minutes.
2. Downlink problems caught before handover
A sensor that can transmit but cannot receive will look healthy in gateway logs and still fail in service. The join, configuration downlinks and ADR all depend on the sensor hearing the network. A successful join and link check at the mounting point proves the round trip works from that exact position.
3. Battery life protected
A sensor at a weak position settles at a high spreading factor, and every packet then costs far more energy. At SF12, a small packet takes around 25 times longer on air than at SF7. Fixing a marginal position on the day keeps the sensor at a low spreading factor and keeps battery life close to the datasheet figure. Model the difference with the LoRaWAN Battery Life Calculator.
4. Single points of failure exposed
Gateway count tells you whether a sensor depends on one gateway. A critical sensor heard by only one gateway goes dark the day that gateway loses power. Seeing a gateway count of 1 at a critical point during installation is the cue to adjust the position or plan a second gateway.
5. A commissioning record anyone can repeat
Recording RSSI, SNR, link margin and gateway count at each position turns installation into evidence. The customer gets a handover sheet showing every sensor passed at its final position, and the next technician has a baseline to compare against. This matters on audited sites such as cold chain, pharma and utilities, where “it was working when we left” is not enough.
6. Faster troubleshooting later
The same test used at installation becomes the first diagnostic step when something changes. A new machine, a relocated rack or monsoon vegetation can all change a link. A technician can rerun the test from the phone and compare it with the commissioning record, without needing a laptop or network server access.
Installation Workflow With the Macnman Maya App
This workflow assumes gateway positions are already planned. If they are not, start with the LoRaWAN Gateway and Sensor Placement Guide.
- Prepare before going on site. Make sure the gateway is powered and connected to the network server, each sensor is registered with its DevEUI and AppKey, and the IN865 frequency plan is set on both sides.
- Take a reference reading. Run the test with a sensor close to the gateway. This shows the best case and confirms the gateway and server are working before you blame any position.
- Hold the sensor in its final position. Use the real mounting point, height and orientation. If it goes inside a panel, test with the door closed. If it goes in a cold room, test with the room door closed.
- Connect over Bluetooth and run the test in Maya. Read RSSI, SNR, link margin and gateway count.
- Repeat two or three times. Readings vary by a few dB between packets. Decide on the typical value, not the best one.
- Fix and retest if the position is marginal. Use the fixes listed in the next section, in order of cost.
- Confirm the first uplink on the network server. This proves the data reaches the application, not just the gateway.
- Record the result. Write down the position, RSSI, SNR, link margin, gateway count and spreading factor in the commissioning sheet, with a photo of the mounted sensor.
The Maya app configuration guide covers connecting to a sensor and the status LED meanings.
Where Installation Testing Matters Most
| Installation | Why it is risky | What to test | Typical Macnman device |
|---|---|---|---|
| Cold room or freezer | Insulated metal panels, closed doors | Door closed, sensor at final height | MacSync LTS X1 temperature and humidity sensor |
| Control panel or MCC room | Steel enclosure | Panel door closed | RS485 to LoRaWAN converter |
| Tank, sump or underground chamber | Concrete, metal lids, below ground level | Lid closed | LoRaWAN ultrasonic level sensor |
| Parking bay | Ground level, vehicles parked on top | With a car over the sensor | LoRaWAN parking sensor |
| Outdoor pole or rooftop | Distance, trees, monsoon season | Final height and direction | Outdoor sensors with an outdoor LoRaWAN gateway |
Seasonal change is worth planning for outdoors. Wet foliage and heavy rain can reduce signal, so leave extra margin on outdoor links. See Impact of the Weather on Long-Range LoRaWAN Networks.
What Built-In Testing Does Not Replace
Built-in RF testing checks a mounting point; it does not plan a network. Be clear about its limits:
- It is not a pre-deployment survey. You still need a plan for where gateways go before installers arrive.
- It is a snapshot. It shows the link on the day. Ongoing health still needs network-side monitoring, such as scheduled device status requests on the network server.
- It does not draw a coverage map. Turning readings into a heat map is still manual work.
- It does not diagnose interference. Good RSSI with heavy packet loss points to interference, which needs a spectrum scan from the gateway.
- Each test uses a little battery. Running a few tests at installation is negligible; running them constantly is not.
Built-In Testing vs Field Tester vs Network Server Data
| - | Built-in test (Maya) | Dedicated field tester | Network server data |
|---|---|---|---|
| Tests the real device in its real position | Yes | No, tests a separate device | Yes, but after installation |
| Feedback while the installer is on site | Yes | Yes | Only if someone is watching the server |
| Needs extra hardware | No | Yes | No |
| Coverage mapping and reports | Manual | Built in | Manual |
| Best used for | Installation and quick troubleshooting | Multi-site surveys and formal acceptance | Long-term monitoring |
Most projects benefit from all three: the network server for monitoring, a field tester for large surveys, and built-in testing at every single mounting point.
Built-In RF Testing on Macnman LoRaWAN Devices
Macnman designs and manufactures LoRaWAN sensors, gateways and converters in India for the IN865 band. Our devices are configured over Bluetooth with the Maya app, and Maya shows RSSI, SNR and link check results during installation. Installers can confirm every position before they leave site, using the same phone they use to configure the device.
To see it on your own site, request a LoRaWAN pilot kit, browse the Macnman product range, or request a quote and a product engineer will help plan your deployment.
Frequently Asked Questions
What is built-in RF testing in a LoRaWAN sensor?
Built-in RF testing is a feature that lets a LoRaWAN sensor measure its own radio link to the network and report the result. It typically shows RSSI and SNR of the network’s reply at the sensor, plus the link margin and gateway count from a link check. Because the real device is tested in its real position, the result reflects actual installed conditions.
How do I check LoRaWAN signal strength before mounting a sensor?
Hold the sensor in its final position, height and orientation, then run a signal test from its configuration app or tool. With Macnman sensors, connect over Bluetooth in the Maya app and run the test. Repeat it two or three times, and mount only if link margin and gateway count are acceptable.
What is a good link margin when installing a LoRaWAN sensor?
As a working framework, 15 dB or more is healthy, 8–15 dB is adequate in stable indoor spaces, 3–8 dB is marginal and should be fixed before leaving site, and below 3 dB should be treated as no coverage. There is no specification-defined threshold, so adjust these bands to your site’s history.
Why does my LoRaWAN sensor not join after installation?
The most common causes are wrong registration keys, a mismatched frequency plan, or a weak downlink at the mounting position. The gateway may hear the join request while the sensor cannot hear the join reply. Testing at the mounting point shows whether the two-way link works there.
Can a LoRaWAN sensor work inside a metal panel?
Often only with help. A closed steel enclosure blocks much of the signal. Test with the panel door closed. If the result is marginal, mount the sensor outside the panel, or use an external antenna routed through a cable gland.
Does built-in RF testing replace a site survey?
No. A site survey decides where gateways go before installation. Built-in testing checks each sensor’s actual mounting point during installation. Both are needed, and long-term health should still be monitored from the network server.
Does running RF tests drain the sensor battery?
A few tests during installation and occasional troubleshooting have a negligible effect. Each test is a short uplink and downlink exchange, so running tests continuously would shorten battery life. Use the test at installation and when diagnosing a problem.
Do I need a field tester if my sensors have built-in RF testing?
For installing and checking sensors on a single site, built-in testing is usually enough. A dedicated field tester is still worth it for multi-site surveys, GPS-tagged outdoor coverage maps, and formal acceptance reports that need standardised exports.
