LoRaWAN Link Check: Built-In RF Testing You Already Have

How LoRaWAN Temperature and Humidity Sensors Enable Cold Chain Equipment Performance Analysis

Short Answer
You do not need to buy a field tester to measure LoRaWAN RF performance. Three diagnostic tools are already built into the protocol and into standard gateway software:

• LinkCheckReq — a MAC command any Class A device can send. The network replies with link margin in dB above the demodulation floor and the number of gateways that heard the request. That is a headroom measurement and a redundancy measurement, from a device you already own.
• DevStatusReq — the network server polls each device for battery level and the demodulation SNR of the last received request. ChirpStack and The Things Stack can do this on a schedule, giving you fleet-wide health monitoring with no extra hardware.
• Gateway-side spectrum scan and built-in network server — supported gateways ship with a radio front-end scanner for interference diagnosis, and a built-in LNS that lets you validate coverage on a site with no internet connection at all.

The single most useful number is link margin. RSSI tells you received power. Link margin tells you how many dB of headroom you have before the link stops working — which is the number that predicts whether a node survives a new machine, a parked truck, or a season of vegetation growth.
Buy a dedicated field tester when you are doing multi-site commissioning and need exportable, repeatable acceptance evidence. For validating and monitoring a single site, the built-in tools are enough.

Every article about LoRaWAN RF testing starts by selling you something

Search for LoRaWAN RF testing and you will find product pages. Handheld field testers at ₹20,000 to ₹80,000. Tablet-format bidirectional testers. Lab-grade conformance testers that cost more than the network you are trying to deploy.

Some of that equipment is genuinely excellent, and later in this article we will be specific about when it is worth the money. But the framing is misleading, because it implies that LoRaWAN arrives with no diagnostic capability and you must bolt one on.

That is not the case. LoRaWAN has carried link diagnostics in the specification since version 1.0. Every compliant Class A device implements the MAC command layer. Every mainstream network server exposes device status. Most gateway images include a spectrum scanning utility from the Semtech reference toolset. The tools are already installed on hardware you have already paid for.

The reason nobody uses them is not that they are inadequate. It is that they are undocumented in plain language, buried in specification PDFs, and exposed through interfaces that assume you already know what you are looking for.

This article fixes that. If you are planning where to physically mount hardware, start with our [LoRaWAN gateway and sensor placement guide] — that covers height, Fresnel zone, RSSI and SNR thresholds and the survey walk-test process. This article is about the diagnostic layer: what the network can tell you about itself, before and after that hardware goes up.

1. LinkCheckReq: the site survey tool inside the specification :

LinkCheckReq is a MAC command with command identifier 0x02. It is initiated by the end device, carries no payload, and is used to validate connectivity. The network server responds with LinkCheckAns, which contains exactly two pieces of information.

The two values you get back :

That is a remarkably dense pair of numbers for a two-byte answer.

Margin answers: how much headroom does this node have? A frame that arrives 20 dB above the demodulation floor can lose 20 dB of signal — a truck parked outside, a new steel rack, a door that is now kept closed — and still get through. A frame arriving at 2 dB of margin is already living on the edge, even if it is currently working perfectly.

GwCnt answers: what happens when a gateway fails? A node heard by three gateways survives one going offline. A node heard by exactly one gateway is a single point of failure that nobody has noticed yet, because right now it works.

Neither of those questions is answerable from an RSSI reading.

How to trigger it

The mechanism varies by device, and this is where practical friction appears.

On modules with an AT command interface, link check is typically a single command. On the Seeed LoRa-E5 (STM32WLE5) family, for example, the AT command specification exposes a link check function that returns the demodulation margin and gateway count directly to the serial console. Most module vendors — Murata, RAK, Seeed, Ai-Thinker — expose something equivalent.

On commercial sensor products, availability is inconsistent. Some vendors expose link check through their configuration app or NFC tool; many do not expose it at all, because the firmware handles MAC commands internally and never surfaces the result to the user. This is the main practical limitation of the technique and we address it honestly in the limitations section below.

On a purpose-built canary node, you have full control. A cheap development board flashed with a LoRaWAN stack and configured to send a link check on a schedule is the single most cost-effective diagnostic tool in a LoRaWAN deployment. It costs a fraction of a commercial field tester and it can be left permanently on site.

Reading the number :

There is no formal standard for what constitutes a good link margin, because it depends on how much environmental change your site will experience. As a working framework for industrial deployments:

Cross-reference this with gateway count. A node at 10 dB margin heard by three gateways is in better shape than a node at 14 dB heard by one.

2. Link margin, RSSI and SNR: which number answers which question

These three get used interchangeably and they are not interchangeable.

The practical distinction: RSSI and SNR describe conditions now. Link margin describes durability. A commissioning report full of RSSI readings tells you the network worked on the day of the survey. A commissioning report with link margins tells you which nodes will still be working in eighteen months.

For specific RSSI and SNR threshold values, dead-zone cutoffs and how to interpret the combinations of good and poor readings, see the threshold tables in our [gateway and sensor placement guide]. We will not restate them here.

3. DevStatusReq: fleet health from the network server

Where LinkCheckReq is initiated by the device, DevStatusReq (command identifier 0x06) runs the other direction. The network server requests status; the device answers with DevStatusAns.

What comes back

Battery status, encoded in a single byte:

Radio margin, a signed value representing the demodulation signal-to-noise ratio in dB, rounded to the nearest integer, for the last successfully received DevStatusReq. The field is a 6-bit signed integer with a range of −32 to +31.

Note the difference from LinkCheckAns: that margin describes the uplink as heard by the gateways, while DevStatusAns margin describes the downlink as heard by the device. Together they characterise both directions of the link, which matters for reasons covered in section 5.

Why this is the most underused tool in LoRaWAN operations :

ChirpStack supports periodically requesting device status using DevStatusReq, and when the status is available it is exposed to the application server on every received uplink. The Things Stack offers equivalent scheduled status requests.

That means, with a configuration change and no new hardware, you get:

• Battery telemetry across the entire fleet, so you replace cells on a schedule instead of discovering a dead node during an audit
• Downlink SNR per device, so you can see which nodes are struggling to receive before they stop receiving configuration changes and ADR instructions
• A time series of both, so degradation shows up as a trend rather than an incident

Most deployments never enable it. The single highest-value configuration change available to an existing LoRaWAN network is usually switching on periodic device status and graphing the result.

One caution on interval. Every DevStatusReq costs a downlink, and every DevStatusAns costs an uplink slot and battery. Polling every device every hour is wasteful and will measurably shorten battery life on a large fleet. Daily is sufficient for most industrial deployments; weekly is defensible for stable environments.

Gateway-side tools: spectrum scan and built-in network server

Spectrum scanning :

The Semtech UDP packet forwarder toolset includes utilities for testing the radio front end, among them a spectrum scanner. It is available on gateways whose hardware supports it, it is run locally from the command line, and it outputs results to a CSV file.

That interface is exactly why nobody uses it — it does not scale to a network of gateways and there is no dashboard. But for the specific job of diagnosing a suspected interference problem at one site, it is the correct tool and it is already on the device.

Interference in the sub-GHz ISM band is a real and under-diagnosed cause of LoRaWAN underperformance in Indian industrial environments. Variable frequency drives, industrial heating equipment, poorly filtered switch-mode supplies and non-compliant imported wireless gear all contribute. A site where RSSI looks acceptable but packet loss is high is an interference problem, not a coverage problem, and no amount of raising the gateway will fix it. A spectrum scan tells you that in ten minutes.

Some commercial field testers now offer a noise scan function that checks signal noise across channels and reports which channel is cleanest — the Milesight FT101 is an example. That is the same diagnostic, packaged more conveniently.

Built-in network server

Many modern gateways ship with a built-in LoRaWAN network server. Its usual purpose is small standalone deployments, but its most useful property during commissioning is different: it lets you test coverage on a site with no internet connection.

For Indian deployments this is not a niche case. New industrial construction, rural cold storage, sites where the leased line arrives three weeks after the equipment does, and facilities where IT will not grant network access to a contractor's device — all of these are routine. A gateway with a built-in LNS and a canary node lets you complete a full coverage validation and hand over survey data before backhaul exists.

RAK's field tester documentation makes the same point about its own hardware: the tester can work against a gateway's built-in network server, enabling field tests at sites with limited or no internet access.

The blind spot: uplink-only testing and why downlink fails differently

This is the most consequential item in this article, and it is the reason surveys pass and deployments fail.

Uplink-only testing can approve a site that will fail in production. A gateway hearing a device does not guarantee that the device can reliably receive what the network needs to send back.

Downlink is the harder path, for three structural reasons:

The network chooses one gateway. An uplink may be received by several gateways, and the network only needs one of them to succeed. A downlink is transmitted by a single selected gateway at specific RX1 or RX2 settings. Redundancy that protects your uplink does not protect your downlink.

Class A receive windows are unforgiving. End devices open short receive windows immediately after an uplink and are asleep the rest of the time. If the downlink is not received inside that window — because of RF conditions, timing drift, or configuration mismatch — it is simply missed. There is no retry within that transaction.

Downlink capacity is duty-cycle constrained. In IN865 and other duty-cycle-limited regions, gateway transmit time is a shared, finite resource. A network with many devices requesting confirmations and ADR adjustments can exhaust downlink capacity in ways that never show up in uplink statistics.

What breaks when downlink is weak

• ADR stops working. The network calculates an optimal data rate and sends LinkADRReq — which the device never receives. Nodes stay stuck at high spreading factors, burning battery and consuming airtime.
• Configuration changes silently fail. You change a reporting interval from the dashboard; the device never gets it. The dashboard shows the intended value. The device keeps its old one.
• Confirmed uplinks retry endlessly. A device awaiting an acknowledgement that never arrives will retransmit, multiplying airtime consumption and destroying battery life.
• Join failures at commissioning. OTAA requires a downlink JoinAccept. A device that can transmit but not receive will never join, which is a confusing failure mode because the gateway logs show the join request arriving.

How to test the direction that matters

• Use DevStatusReq — its margin value is a downlink measurement by definition, since it reports the SNR at which the device received the request.
• Send a confirmed uplink from your canary node and check that the acknowledgement arrives. Success proves the round trip; failure isolates the direction.
• Trigger a LinkCheckReq. Receiving the answer at all proves the downlink path works from the selected gateway at that position.
• Test at the actual sensor position and mounting orientation, not at head height in the middle of the aisle.

A validation workflow using only built-in tools

This assumes you have already selected a gateway position using the survey process in our [placement guide]. This is the diagnostic layer on top of that.

Step 1 — Establish a reference. Place your canary node directly beneath the gateway. RSSI should be very strong, in the region of −15 to −25 dBm, with SNR in the high teens to around 20 dB. Trigger a link check and record the margin. This is your ceiling — every other reading on site is measured against it.

Step 2 — Link check at each planned sensor position. Not a walk-through of the general area. Each actual mounting point, at the actual height, with the device in the orientation it will be installed. Record link margin and gateway count. This is your commissioning record.

Step 3 — Test the downlink at every marginal position. Anywhere link margin falls below roughly 8 dB, send a confirmed uplink and verify the acknowledgement returns. A position that passes uplink and fails downlink is a position that will fail in production.

Step 4 — Sweep spreading factors where margin is thin. Devices with configurable data rate can send packets across different spreading factors to assess signal quality at each. This tells you whether a marginal position is recoverable through ADR settling at a higher SF, or whether it needs a physical fix.

Step 5 — Run a spectrum scan if the numbers do not add up. High packet loss with acceptable RSSI is interference. Scan the band from the gateway before you start moving hardware around.

Step 6 — Enable periodic device status and leave it running. Commissioning is one day. Degradation happens over months — new equipment installed, batteries ageing, seasonal changes, sensors relocated by people who did not read the survey. Scheduled DevStatusReq turns that from a surprise into a trend line.

Steps 1 through 5 cost nothing but time. Step 6 costs a configuration change.

When a dedicated field tester is genuinely worth buying

Built-in diagnostics are not a complete substitute for purpose-built hardware. Buy a field tester when:

You commission multiple sites per year. A systems integrator doing twenty deployments needs speed and repeatability more than cost savings. Purpose-built testers capture RSSI, SNR, packet loss, data rate and timing behaviour while moving through a site, and turn those into map-based coverage views or indoor scatter plots.

You need exportable acceptance evidence. Standardised test sessions exporting to CSV or PDF create repeatable documentation for handover and audit. Assembling equivalent evidence from console logs is possible but slow, and it looks like what it is.

You are testing bidirectionally as standard practice. Tools designed specifically to measure both uplink and downlink performance on site, without needing a laptop or backend access, remove the manual work described in section 5.

You need GPS-tagged outdoor coverage mapping. For smart city, agricultural or utility deployments across large areas, walk and drive testing with automatic geotagging is not reasonably replicable with a canary node and a notebook.

You are doing conformance or pre-certification work. That is a different category entirely — bench instruments that can simulate a gateway, simulate a device, operate in non-signalling mode to measure RF performance, and run test procedures tracking the LoRa Alliance certification suite. If you are designing hardware rather than deploying it, you already know this.

Reasonable market options span roughly ₹25,000 for basic handheld units to well above ₹1,00,000 for professional bidirectional tablets, with conformance testers an order of magnitude beyond that. A dev board canary node costs a few thousand rupees.

Limitations of built-in diagnostics

Stated plainly, because the point of this article is not to pretend the free tools are equivalent to paid ones.

Vendor exposure is inconsistent. LinkCheckReq is in the specification, but whether a given commercial sensor lets you trigger it and see the result is entirely up to that vendor's firmware and configuration tool. Many handle MAC commands internally and never surface them. Always confirm before assuming.

There is no built-in mapping or visualisation. You get numbers in a console. Turning them into a coverage heat map is manual work — a floor plan, a spreadsheet and colour coding. Field testers automate exactly this.

Spectrum scanning is command-line and does not scale. Fine for one gateway with a suspected problem; unworkable across a network of thirty.

Diagnostics consume airtime and battery. Every link check is an uplink and a downlink. Aggressive polling degrades the thing you are measuring. This is a real constraint on large fleets in duty-cycle-limited bands.

Built-in tools do not measure absolute RF performance. They tell you about the link as the network experiences it. They cannot tell you that a gateway's receive sensitivity has degraded, that an antenna connector is corroded, or that a device is transmitting below its rated power. Those need conducted measurements with instruments.

Link margin has no formal standard. The interpretation table earlier in this article is a working framework based on deployment experience, not a specification-defined threshold. Treat it as a starting point and calibrate against your own site history.

MACNMAN LoRaWAN gateways and diagnostics

MACNMAN Technologies manufactures LoRaWAN gateways, temperature and humidity sensors, RS485-to-LoRaWAN converters and 4–20 mA-to-LoRaWAN converters in Nashik, natively on the IN865 frequency plan used in India.

[VERIFY — replace with confirmed capability from firmware and gateway documentation:

• whether MACNMAN sensors expose LinkCheckReq via AT command or configuration tool
• whether MACNMAN gateways ship with a built-in network server
• whether the Semtech spectrum scan utility is present in the gateway image
• which network servers are supported and what they surface from DevStatusAns]

Because we support deployments in India directly, we can help interpret survey data from an actual site rather than a datasheet. If you have a deployment where the numbers do not make sense — nodes that join but do not receive, packet loss with good RSSI, or batteries failing far ahead of specification — talk to our team.

[Explore MACNMAN IN865 LoRaWAN gateways →]

Frequently asked questions

Q:What is LinkCheckReq in LoRaWAN? LinkCheckReq is a MAC command, >> identifier 0x02, that an end device sends to validate its connectivity. The network server replies with LinkCheckAns, containing the link margin in dB of the received request and the number of gateways that successfully received it. It has been part of the LoRaWAN specification since version 1.0 and requires no additional hardware.

Q: What is a good link margin for LoRaWAN?

>> There is no specification-defined threshold. As a working framework, 15 dB and above is healthy, 8–15 dB is adequate in stable indoor environments, 3–8 dB is marginal and will fail intermittently once conditions change, and below 3 dB should be treated as a dead zone. Always read link margin alongside gateway count — a node heard by one gateway is a single point of failure regardless of its margin.

Q: How do I check LoRaWAN signal quality without a field tester?

>> Use a canary node — an inexpensive development board or a spare sensor running your LoRaWAN stack — to trigger LinkCheckReq at each planned sensor position and record the link margin and gateway count. Enable periodic DevStatusReq on your network server for ongoing fleet health. For interference, run the spectrum scan utility included in most gateway images.

Q:Do I need a LoRaWAN field tester?

>>For validating and monitoring a single site, no — the built-in diagnostics are sufficient. Buy one if you commission multiple sites per year, need exportable acceptance documentation for handover or audit, require GPS-tagged outdoor coverage mapping, or want bidirectional testing without manual work.

Q:What does gateway count mean in LinkCheckAns?

>> It is the number of gateways that successfully received your device's LinkCheckReq. It measures redundancy. A node heard by three gateways continues working if one fails; a node heard by exactly one has no fallback, even if its signal quality is currently excellent.

Q:What is the difference between link margin and RSSI?

>> RSSI is received signal power in dBm — it describes conditions at the moment of measurement. Link margin is how many dB above the demodulation floor the frame arrived — it describes how much degradation the link can absorb before failing. RSSI tells you the network works today; link margin tells you whether it will still work after the environment changes.

Q: How do I monitor LoRaWAN network health after deployment?

>> Enable periodic DevStatusReq on your network server. ChirpStack supports scheduled device status requests and exposes the result on every uplink; The Things Stack offers equivalent functionality. You get battery level and downlink SNR per device as a time series, which surfaces degradation as a trend rather than a failure. Daily polling is sufficient for most industrial deployments.

Q: Why does my LoRaWAN sensor uplink but not receive downlinks?

>>Downlink is the constrained direction. Uplinks may be received by several gateways, but downlinks are transmitted by one selected gateway at specific RX1 or RX2 settings, and Class A devices listen only in short windows immediately after an uplink. Weak downlink typically shows up as ADR failing to settle, configuration changes not taking effect, confirmed uplinks retrying endlessly, or OTAA joins failing despite the join request appearing in gateway logs.

Q: Can I test LoRaWAN coverage without an internet connection?

>> Yes. Gateways with a built-in network server let you run a complete coverage validation with no backhaul at all — useful for new construction, rural sites, or facilities where network access has not been provisioned. Pair the gateway's built-in LNS with a canary node and record link margin at each position.

Q: What is DevStatusReq used for?

>> The network server uses DevStatusReq (identifier 0x06) to ask a device for its battery level and radio status. The device replies with DevStatusAns containing a battery byte — 0 for externally powered, 1–254 for battery level, 255 if unmeasurable — and the demodulation SNR in dB of the last successfully received request. It is the basis of fleet-wide health monitoring.

Q: Does running diagnostics affect battery life?

>> Yes. Each link check consumes an uplink and a downlink, and each device status exchange does the same. On a large fleet in a duty-cycle-limited band such as IN865, aggressive polling measurably shortens battery life and consumes shared downlink capacity. Poll daily rather than hourly unless you are actively troubleshooting.

Performance Analysis 5: Spatial Temperature Mapping and Hot Zone Detection

This is the performance analysis dimension that single-point monitoring is structurally incapable of providing — and the one that most directly affects product integrity in ways that go undetected under standard compliance monitoring.

Why Single-Point Monitoring Misses Product Risk

A cold room with a single temperature probe positioned at the regulatory-required monitoring point — typically at mid-height in the centre of the room, away from the door — reads the temperature that the refrigeration system is designed to produce at that point. This reading complies with FSSAI requirements and generates no alerts.

What it does not reveal:

• Product stored on the shelving unit nearest the entry door may be 3–6°C warmer than the monitoring probe reads, due to thermal infiltration from door openings
• Product stored near the ceiling may be warmer than mid-height product, due to natural thermal stratification in rooms with poor air circulation
• Product stored directly in front of the evaporator air discharge may be overcooled, with surface freezing occurring in a product specified for refrigerated (not frozen) storage
• Corner zones with poor airflow may have localised warm pockets that persist even when the room average is within specification

None of these conditions trigger a single-point alert. All of them affect product quality and shelf life.

Multi-Point LoRaWAN Sensor Array for Spatial Mapping

A multi-point LoRaWAN sensor deployment — five to nine sensors per large cold room, positioned at different heights, depths, and proximity to door and evaporator — generates a spatial temperature dataset that can be visualised as a heat map updated at every sensor transmission interval.

Recommended sensor positions for spatial mapping in a large cold room:

With this array, the spatial temperature map reveals:

• Stratification gradient: The temperature difference between ceiling sensor and floor sensor indicates the degree of thermal stratification. In a well-mixed room, this should be less than 1°C. A gradient above 2°C indicates poor air circulation — typically from blocked evaporator airflow, accumulated product blocking fan discharge, or fan failure.
• Door infiltration radius: The temperature differential between the door-adjacent sensor and the far-zone sensor during and after door events quantifies the thermal infiltration load and identifies how far into the room warm air penetrates.
• Evaporator distribution uniformity: The temperature differential across multiple zones on the same horizontal plane indicates whether the evaporator is distributing cooled air uniformly or creating cold and warm zones.

This spatial dataset also directly supports HACCP critical control point analysis — demonstrating not just that the room was within range, but that specific product storage zones were within range throughout the monitoring period.

Performance Analysis 6: Energy Efficiency Analysis

Cold storage electricity costs are dominated by refrigeration — approximately 70% of total facility energy consumption. Within that, compressors account for roughly 72% of refrigeration electricity. Energy efficiency analysis using temperature and humidity data identifies where electricity is being consumed inefficiently and what operational or maintenance changes would reduce it.

Door Activity and Thermal Load Analysis

Each door-open event imposes a thermal load on the refrigeration system — the compressor must remove the heat and moisture that entered during the door-open period. The magnitude of this load is proportional to door-open duration, ambient temperature, and the temperature differential between chamber and ambient.

By correlating door-event logs with the temperature recovery data from the nearest sensor, the analytics platform can calculate the thermal load imposed by each door event and aggregate this by shift, by day, and by door location. This analysis typically reveals:

• Which doors impose the highest thermal load per event (often loading bay doors with large differential and long open times)
• Which operational shifts create the highest aggregate door load (often early morning shift when loading peaks)
• Whether scheduling high-frequency door activity during cooler periods (early morning, late evening) would meaningfully reduce compressor load

Scheduling peak loading operations during cooler ambient periods can reduce compressor cycling by 15–25%, directly reducing electricity consumption without any change to equipment.

Defrost Timing Optimisation

Fixed-timer defrost cycles — for example, defrost every six hours regardless of frost accumulation — are the default setting on most refrigeration controllers. In practice, frost accumulation rate varies with door opening frequency, ambient humidity, and stored product moisture content. During low-traffic periods, frost accumulation may be minimal; during peak door-opening periods, it may be rapid.

Temperature sensor data reveals the actual frost accumulation rate between defrost cycles through the supply-return differential trend. When this differential narrows faster than baseline between successive defrosts, frost is accumulating more rapidly than the defrost timer accounts for. When it narrows more slowly, the defrost cycle is running more frequently than the actual frost load requires.

Adjusting defrost frequency to match actual measured frost accumulation — rather than a fixed timer — reduces unnecessary defrost energy consumption (each defrost cycle consumes energy to heat the coils and disturbs chamber temperature) while ensuring that frost never accumulates to the point where airflow is restricted.

The KPI Framework: What Metrics Cold Chain Operators Should Track

Effective cold chain performance analytics requires a defined set of KPIs — metrics that are measurable from sensor data, meaningful for equipment health assessment, and actionable when they deviate from baseline.

Primary Equipment Performance KPIs

Key Specifications and What They Mean for Your Deployment

Input Specification

LoRaWAN Specification

Physical and Environmental

⚠️ Pre-publication check: Insert Macnman-specific datasheet values for all specifications above before publishing. Replace any placeholder figures with the actual product specifications.

Frequently Asked Questions

Q: Will connecting the Macnman converter affect my existing flow meter reading or the PLC input?

No. The converter connects in series with the 4-20mA loop and reads the loop current without modifying it. The existing PLC or panel meter continues to receive the same signal it always has, with no change in reading or behaviour. The converter adds a small series resistance (typically 10–50 Ω) to the loop, which may marginally reduce the loop voltage headroom — verify that the loop power supply has sufficient compliance voltage for the additional drop, particularly on loops already operating near their maximum cable resistance budget.

Q: My flow meter outputs a pulse signal, not 4-20mA. Will this converter work?

No — this converter is specifically designed for 4-20mA analogue current loop signals. Pulse-output flow meters (turbine meters with frequency output, water meters with reed switch pulse, etc.) require a pulse-input LoRaWAN converter. Contact us to identify the correct product for pulse-output applications.

Q: What LoRaWAN network server do I need?

Any LoRaWAN-compliant network server works — The Things Stack Community Edition (free for most deployments), ChirpStack (open-source, self-hosted), AWS IoT Core for LoRaWAN, or Azure IoT Hub. For Indian deployments on IN865, verify that your chosen network server is configured with the IN865 frequency plan. The Things Stack Community Edition supports IN865 out of the box.

Q: How far can the converter transmit from the flow meter to the gateway?

In open outdoor environments with the gateway antenna mounted at 10+ metres above ground, reliable transmission ranges of 3–10 km are achievable. Inside industrial buildings with concrete and steel structures, practical range is typically 300–1,500 m depending on the number and type of obstacles between converter and gateway. See our [LoRaWAN Gateway and Sensor Placement Guide] for detailed guidance on gateway siting and antenna height to maximise coverage.

Q: How often does the converter send data, and can I change it?

The default transmission interval is configurable at commissioning — common defaults are 15 or 30 minutes. The interval can be changed after deployment via a LoRaWAN downlink command from the network server, without physically accessing the converter. Shorter intervals (5 minutes) give better data resolution but reduce battery life proportionally. For applications where real-time flow monitoring is critical, external power supply enables continuous high-frequency operation without battery life concerns.

Q: Does the converter work inside a metal junction box or control panel?

The converter's radio signal is significantly attenuated by a metal enclosure. If the converter must be installed inside a metal box, use an external antenna connected to the converter via an SMA extension cable routed through a cable gland in the enclosure. The converter body can be inside the box; the antenna must be outside it with a clear path toward the gateway.

Q: Is LoRaWAN legal to use in India?

Yes. LoRaWAN operating on the IN865 frequency plan (865–867 MHz) falls under India's unlicensed spectrum allocation for Short Range Devices as per WPC (Wireless Planning and Coordination) regulations. No individual licence is required for IN865 LoRaWAN devices operating within the specified power limits. Verify current WPC regulations before deployment, as spectrum rules are subject to revision.

Q: What happens to data if the LoRaWAN network is temporarily unavailable?

The converter continues to sample the 4-20mA loop at the configured interval regardless of network availability. However, standard LoRaWAN Class A devices do not buffer failed uplinks — if the gateway is offline or out of range during a transmission, that reading is lost. For applications where data continuity during network outages is critical, select a converter variant with local data buffering capability, or specify a gateway with cellular failover backhaul. See our [LoRaWAN Gateway Placement Guide] for gateway selection guidance.

Summary: What the Macnman Converter Actually Replaces

The Macnman 4-20mA to LoRaWAN Converter is not a sensor. It does not measure flow. Your existing flow meter does that — accurately, continuously, and with whatever certification it was installed under.

What the Macnman converter replaces is the infrastructure cost of getting that measurement to a system that can use it:

The data that was already being measured — that 4-20mA signal sitting on the loop terminals of your flow meter right now — becomes available to your cloud platform, your SCADA, your energy management dashboard, and your maintenance alert system. Without a single new metre of cable.