DEV Community: manthink

The Last Mile of Industrial IoT: An LPWAN Technology Selection Analysis

manthink — Sun, 20 Sep 2026 08:18:51 +0000

Series: ManThink "LoRaWAN Technical Reading" Issue #15 · Industry Trends, Part 5
Keywords: Industrial IoT, last mile, LPWAN selection, LoRaWAN, NB-IoT, private LoRa, DTU, RS-485, Modbus, brownfield retrofit

Opening: A Number Mismatch Everyone Misses

One statistic from the 2026 industrial communication market circulates widely: HMS Networks' twelfth consecutive annual analysis shows Industrial Ethernet accounting for 79% of newly installed nodes worldwide, fieldbus dropping to 14%, and wireless holding steady at 7%.

Many conclude from this that the industrial communication war is over and Ethernet has won.

But the same research bodies (LNS Research, ARC Advisory, and McKinsey's 2025 manufacturing benchmarks) offer another number: roughly 70% of installed industrial control assets have been in service for more than 15 years, and a meaningful share still speaks Modbus RTU over RS-485 — using a 1998-vintage protocol to report data to a controller whose vendor stopped patching firmware decades ago.

Put the two numbers side by side and the structural mismatch of industrial IoT becomes visible:

At the new-node level, Ethernet has indeed won (79%);
At the installed-base level, serial and fieldbus remain dominant (70% of assets older than 15 years, PLC lifespans of 10–20 years, process-industry pumps, transmitters, and valves lasting 20–30 years, and the average age of US manufacturing equipment approaching 20 years).

That is the true nature of the "last mile" problem: it is not "the last stretch of distance" — it is "the last batch of un-digitized assets." These assets share three properties:

Cannot be removed — the injection molder on the line, the compressor in a pharmaceutical cold chain, the pump station at the water plant: removal means downtime, and one unplanned hour on an automotive subassembly line costs five figures in scrap alone;
Cannot be modified — a 1998 PLC may carry qualification documents that took a customer audit six months to obtain. Re-flashing it is not on the table;
Should not be replaced — the equipment itself runs fine. Replacement means paying for an entire machine to serve the accessory need of "getting data online."

So the technology selection question for the industrial IoT last mile was never "which wireless technology is more advanced," but "which retrofit route can bring installed assets online under those three constraints."

This article unpacks the problem: first the true shape of the installed base, then a horizontal comparison of candidate technologies, then a quantified look at four classes of industrial-environment challenges, and finally a selection decision tree you can follow.

1. Know Your Opponent: Why the Installed Base Cannot Be Eliminated

1.1 Modbus: Modest Share, Irreplaceable Position

The 2026 protocol market-share data is misleading. Modbus TCP holds 5% of new industrial Ethernet nodes, and Modbus RTU holds 3% of new fieldbus nodes — apparently "a declining legacy protocol."

But note two facts.

First, those shares have been "stable" for years. Across HMS's historical reports, Modbus RTU's 3% is the flattest curve in the fieldbus category. It plays the role of the "universal connection layer": unlike PROFINET or EtherNet/IP, which mainly serve specific vendor ecosystems, Modbus appears in equipment from virtually every major automation brand. One fact confirms its standing in cost-sensitive segments: in small-PLC and sensor access scenarios, Modbus's share has long hovered around 80%, and a Modbus driver costs roughly one-fifth of an OPC UA driver per device.

Second, the installed base matters far more than new-install share. Equipment lifecycles dictate protocol survival: PLCs 10–20 years, process equipment 20–30 years. Today's 79% Ethernet share of new nodes will not become the "installed majority" until 2036–2046; meanwhile, the tens of millions of Modbus devices still running today will keep serving for another decade or more.

This creates a powerful lock-in effect: new equipment must be compatible with existing Modbus networks, and the existence of those networks makes Modbus the natural choice for new projects. Manufacturers do not replace stable, running systems because a protocol is "outdated" — an upgrade means coordinating a line-wide replacement or maintaining parallel communication infrastructure, both expensive and risky.

1.2 RS-485: The Evergreen Physical Layer

Beneath Modbus RTU sits RS-485, whose longevity comes from three engineering properties:

Property	Value / Behavior	Engineering Meaning
Distance without repeater	1,200 m	Far beyond RS-232 (15 m); covers plant-level spans
Differential signaling	Common-mode noise rejection	First choice for high-EMI plant floors
Bus topology	One master, many slaves	Lowest cabling cost of any industrial bus
Typical slave count	Dozens on one bus	One twisted pair serves a whole metering cabinet

Electricity meters, water meters, heat meters, flow meters, PLCs, variable-frequency drives, environmental monitors, industrial controllers — nearly every industrial metering and control device offers RS-485 terminals. That is not technological inertia; it is three decades of proven reliability.

1.3 The Communication Dilemma of the Installed Base

The problem is "access." A typical wired architecture looks like this:

RS-485 device → Data collector → Industrial switch → Server → Management platform

This architecture works fine for "in-building, newly built, centralized" scenarios, but costs spiral out of control in four situations:

Across floors / buildings / campuses: communication cable + trays + conduit + labor — communication infrastructure becomes a major cost line;
Operational sites: pulling new cable through a running factory means downtime windows and hot-work permits;
Expansion: every new monitoring point adds cable, and maintenance complexity compounds as the network grows;
Remote accessibility: RS-485 is a local protocol by birth; going cloud requires stacking an entire additional system.

That is the precise shape of the last-mile problem: on the device side, an RS-485 bus that runs reliably for 1,200 meters; on the platform side, a modern cloud and historian; and in between, the stretch of road that "carries serial data to the cloud" — the real bottleneck.

2. Candidate Technology Review: The Real Boundaries of Six Routes

The candidates that actually get serious evaluation for that middle stretch are six: private LoRaWAN, NB-IoT, private LoRa (data radios), 4G/5G DTUs, Wi-Fi/BLE, and Wi-SUN. The first four are mainstream; the last two have clear boundaries in industrial settings.

2.1 Six-Dimension Comparison Table

Dimension	Private LoRaWAN	NB-IoT	Private LoRa Radio	4G/5G DTU	Wi-Fi/BLE	Wi-SUN
Spectrum	Unlicensed Sub-GHz	Licensed (operator)	Unlicensed Sub-GHz	Licensed (operator)	2.4/5 GHz unlicensed	Unlicensed Sub-GHz
Network ownership	Self-owned	Operator	Self-owned	Operator	Self-owned	Self-owned
Coverage	5–15 km (site-dependent)	Depends on operator lighting	Point-to-multipoint 3–10 km	Depends on cellular	30–100 m	Several km, Mesh
Power adaptability	10-yr battery or DC	Battery months–years	Requires stable DC (9–30V)	Requires stable DC	High power draw	Low power
Per-message size	Tens of bytes	Hundreds of bytes–KB	Tens of bytes	MB-scale	MB-scale	Hundreds of bytes
Cost structure	CAPEX (one-time gateways)	OPEX (SIM fee × devices × years)	CAPEX (module-level)	OPEX (data plan)	CAPEX	CAPEX
Protocol adaptation	Standard + DTU pass-through	CoAP/MQTT	Serial pass-through (any protocol)	TCP/UDP pass-through	Full IP stack	6LoWPAN
Interference immunity	CSS spread spectrum, strong	Protected licensed band	Implementation-dependent	Licensed band	Congested 2.4G	Strong
Typical role	Campus/plant sensor network	Nationally scattered assets	Point-to-point link replacement	Bulk data / video	High-bandwidth short range	Metering Mesh (North America)

2.2 Route by Route

Private LoRaWAN — the advantages are threefold "ownership": unlicensed spectrum, self-built network, sovereign data. The gateway sits on your own site; coverage is defined by you. It does not depend on whether an operator has lit up NB-IoT on a given mast, and there is no risk of devices going dark en masse because an operator sunsets a service (a real failure category in NB-IoT deployments). The price: up-front CAPEX and gateway operations responsibility that stays with you. CSS modulation gives it natural resistance to narrowband interference, and the Sub-GHz band diffracts around concrete and metal far better than 2.4 GHz.

NB-IoT — the advantage is "no network to build": you use operator infrastructure directly, which suits assets scattered nationwide (shared-bike locks, manhole covers, cross-border logistics). The price: a per-SIM annual fee (OPEX that grows linearly with fleet size), coverage entirely dependent on the operator (indoor, basement, and remote plant areas are often unlit), and service-continuity risk over the device lifecycle. In industrial scenarios where devices cluster on your own site, NB-IoT's advantages are mostly unusable while its disadvantages are fully exposed.

Private LoRa radios (data radios) — the difference from LoRaWAN is the absence of a standard protocol stack: point-to-multipoint transparent pass-through with custom protocols. It suits "stable power, no cellular coverage, private protocol" scenarios, such as water-quality monitoring at a mountain fish farm (24V power available, no cellular signal, Modbus data across 3 km). The price: none of LoRaWAN's standard ecosystem (NS, platforms, certified device pool), with management costs rising at scale.

4G/5G DTUs — the bandwidth route. Tower-crane video monitoring and AGV bulk telemetry can only go here. Using it for metering-grade small messages is economically irrational: you pay for megabytes and transmit tens of bytes.

Wi-Fi/BLE — high-bandwidth short range, suited to AGVs/AMRs and handheld terminals. In industrial sensing the problems are poor 2.4 GHz penetration, high power draw, and the cost of dense AP deployment. A pharmaceutical cold-storage lesson: the insulation is thick metal plate plus polyurethane foam; a Wi-Fi solution attenuated badly inside the chamber and dropped constantly; the final fix was 470 MHz LoRaWAN, where one gateway penetrated 20 cm of cold-storage insulation and covered the entire campus.

Wi-SUN — Sub-GHz Mesh with an installed-base advantage in North American metering, but its ecosystem and device selection are far smaller than LoRaWAN's in industrial scenarios elsewhere; it usually enters evaluation only when a customer explicitly specifies it.

2.3 A Quick-Reference Conclusion Table

Your Scenario	First Choice	Rationale
Devices clustered on your own site; metering/status small messages	Private LoRaWAN	Sovereign coverage, no SIM fees, CSS interference immunity
Assets scattered nationwide, no fixed site	NB-IoT	Trade self-built cost for operator coverage
Point-to-point 3–10 km, stable power, private protocol	Private LoRa radio	Flexible pass-through, no platform dependency
Video / large files / high-frequency waveforms	4G/5G	The only bandwidth answer
Already a nationwide metering Mesh (North American legacy)	Wi-SUN	Legacy continuity

3. Four Classes of Industrial-Environment Challenges: Separating "Works" from "Works for Ten Years"

A selection table only answers "which route." The cruelty of industrial sites is that the numbers on a datasheet and the site three years later are different things. Four challenge classes decide equipment-selection survival.

3.1 Metal and Electromagnetics: Where 15% Packet Loss Comes From

The three least wireless-friendly things on an industrial site: metal structures (reflection, blockage), VFDs and motors (EMI), and dense radio equipment (co-channel interference).

A mining case provides representative measured data: in large-scale mining and petrochemical facilities, commercial off-the-shelf gateways in plastic enclosures showed a 15% packet-loss rate, causing frequent manual resets and on-site technician visits; after switching to a solution with optimized RF shielding and industrial-grade components, packet loss fell to 0.8%, annual downtime dropped from 48 hours to 4, and per-unit annual maintenance cost fell from $1,200 to $150.

LoRaWAN's confidence in such environments comes from the technical layer:

CSS (Chirp Spread Spectrum) modulation spreads signal energy across the whole bandwidth, giving natural immunity to narrowband interference (VFD harmonics, motor arcing) — precisely why it remains viable in "electrically dense" environments;
The Sub-GHz band (470 MHz in China, 868 MHz in Europe) diffracts and penetrates significantly better than 2.4 GHz;
ADR lets weak spots automatically retreat to higher SF for link margin, at the cost of longer airtime;
FEC lets receivers repair damaged packets.

But three disciplines still apply: keep antennas off metal longitudinal axes, stay more than 30 cm from reflective surfaces, and do frequency planning across multiple gateways. In high-EMI environments, consider actively pushing SF down to 7/8 — sacrifice extreme range for shorter time-on-air and lower interference exposure.

3.2 Temperature: What Freezes and Cracks at -80°C Is Not the Sensor

The conventional industrial temperature requirement is -40°C to +85°C, and that number alone is not hard to meet (standard industrial-grade component binning). The traps are in the details:

A 2,000 m² pharmaceutical cold-storage project (three -80°C ultra-low freezers plus one 2–8°C cold room, holding over ¥50M of vaccines and blood products) learned this the hard way: on day one of the LoRaWAN deployment, data from the -80°C chamber was still unstable. Investigation showed the problem was not radio but the rubber jacket of the probe wiring, which hardened and embrittled at ultra-low temperature, causing intermittent contact. The fix: replace with Teflon-jacketed low-temperature shielded cable and pot every terminal with sealant.

The general lesson: cold's failure points are usually in "accessories" — cable, connectors, battery — not the chips on the main board. At selection time, audit wiring, terminals, and packaging with the same rigor as the host. Placement matters too: probe into the chamber, host outside — protecting both measurement accuracy and battery performance in the cold.

3.3 Power Supply: AC Wide-Voltage Is an Underrated Differentiator

Industrial-site power is far dirtier than assumed: voltage fluctuation on shared supplies, harmonics fed back by VFDs, maintenance outages. "Unexpected gateway/DTU reboot interrupting packet forwarding" is a high-frequency failure class, and diagnosing it is extremely expensive at unattended sites.

Here an important selection fork appears — the DTU's power format is effectively doing scenario segmentation for you:

Power Format	Fitted Scenario	Typical Product Form
AC 85–270V wide voltage	Inside power/metering cabinets, drawing site AC directly	Rail-mounted DTU
DC 5–24V	Low-voltage cabinets, instrument boxes	Compact rail DTU
Battery (Li-SOCl₂, 10,800 mAh)	Remote points with no supply	Battery DTU

AC wide voltage (85–270V) means the device can hang inside a power distribution cabinet in any country without a separate adapter — in retrofits, that is the difference between "installable" and "not installable." For battery versions, audit sleep current (industry level ≤5–15 μA) and battery internal-resistance degradation in the cold.

3.4 Operations Inaccessibility: Remote Manageability Is the Industrial-Grade Threshold

Large numbers of industrial points are "install and never visit." Robustel's summary of industrial gateway failure modes is apt: many gateway failures are not caused by the "outdoors" but occur indoors in apparently protected locations — high temperature in metal cabinets, condensation during start/stop cycles, shared-supply fluctuation, motor interference, signal attenuation through the metal cabinet, restricted maintenance access.

That turns remote management from a nice-to-have into a survival requirement. At minimum: remote parameter configuration (via the NS, no site visit), remote firmware upgrade (FUOTA), disconnect-reconnect with data buffering and retransmission (for metering continuity), and remote health visibility (battery level, signal quality, module self-check).

4. The Selection Decision Tree: Five Questions to Fix the Route

Converging the preceding analysis into five questions, answered in order:

Q1. What is the data profile?
    ├─ Video / large files / high-frequency waveforms ───→ 4G/5G DTU. End of analysis.
    └─ Metering / status / alarms (small messages) ───→ Q2

Q2. Are devices clustered or scattered?
    ├─ Scattered nationwide, no fixed site ───────────→ NB-IoT (use operator coverage)
    └─ Clustered on your own site / campus ───────────→ Q3

Q3. Is there deep cellular coverage on site (indoor/basement/metal plant)?
    ├─ Yes, and customer accepts OPEX ───────────────→ NB-IoT viable; recheck at Q4
    └─ No, or network sovereignty required ──────────→ Private LoRaWAN; proceed to Q4

Q4. What interface do the target devices have?
    ├─ RS-485/Modbus, M-Bus, 4-20mA, DI/DO (installed wired assets)
    │    └─→ DTU route: keep original devices, replace only the last hop → Q5
    └─ New sensor points
         └─→ Choose native LoRaWAN sensors directly → Q5

Q5. What is the power condition at the points?
    ├─ Power/metering cabinet (AC available) ────────→ Rail DTU (AC wide voltage)
    ├─ Low-voltage cabinet (DC 5–24V) ──────────────→ Compact rail DTU
    └─ No supply ───────────────────────────────────→ Battery DTU (audit sleep current
                                                        and cold performance)

The tree's three pivotal judgments:

Q2 is the watershed: the distribution shape of devices (clustered vs. scattered) determines the route earlier than any technical parameter. Most industrial scenarios fall on the "clustered" side — which explains why industrial private networks are LoRaWAN's fastest-growing segment.
Q4 is where the money is: if the target devices are RS-485 installed assets, the DTU route expands your sensor sourcing from "LoRaWAN-interface sensors only" to "any wired sensor" — far cheaper, far more options, and not one line of code changes on the original equipment.
Q5 is the final gate to deployment: power format determines the specific model and the installation workload (whether you must provision a separate power supply for the DTU).

5. ManThink's Answer: The DTU Route and EdgeBus

With the methodology covered, here is our own engineering answer. Since its founding in 2014, ManThink has focused on a single positioning: connecting the installed base — low-cost wireless retrofit of wired-interface field devices (RS-485, M-Bus, 4-20mA, 0-10V, DI). The output of that route is a complete DTU product line plus an edge-computing virtual machine that runs inside the DTUs.

5.1 Three DTUs Segmented by Power Condition

Parameter	KC11	KC25	KC21
Positioning	Rail-mounted industrial workhorse	2nd-gen compact rail	Battery-type remote points
Power	AC 85–270V wide voltage	DC 5–24V	4× ER14505 Li-SOCl₂ (10,800 mAh)
Interface	RS-485	RS-485	RS-485
Mounting	DIN rail	DIN rail	Wall-mount (PG7 gland)
Operating class	Class C	Class C	Class A (battery) / Class C (DC)
TX power	22 dBm	22 dBm	22 dBm
RX sensitivity	-142 dBm @SF12	-142 dBm @SF12	-142 dBm @SF12
Temperature	-40 to +85°C	-40 to +85°C	-40 to +85°C
Protection	IP53 (in-cabinet)	Aluminum enclosure	IP65 (outdoor)
Distinguishing feature	Compatible with all RS-485 protocols	Ultra-compact (69×25×25 mm)	Can power external sensors
Deployment scale	100,000+ units deployed	Current generation	Harsh points

The three models cover all three branches of decision-tree Q5: AC from the power cabinet with KC11, DC from the low-voltage cabinet with KC25, and no-supply remote points with the battery KC21 (IP65 outdoor protection, plus the ability to power external water/gas meters — saving a whole supply system).

All support the six regional standards — CN470/EU433/EU868/AS923/AU915/US902 — and connect to any standard LoRaWAN platform: ThinkLink, ChirpStack, or TTN. No lock-in at the gateway or platform layer — the fundamental difference from vendors of "complete closed systems."

5.2 EdgeBus: Why Protocol Adaptation Cannot Be Just "Configuration"

The deepest pit on the DTU route is not radio but protocol adaptation. On the surface, connecting a Modbus meter means configuring a slave address, register map, and data types. In real projects:

Electricity meters speak DL/T 645-2007, water/gas/heat meters speak CJ/T 188, imported instruments speak all manner of proprietary protocols — three address lengths (1/6/7 bytes), three frame formats, each with its own CRC;
You need COV (Change of Value): don't transmit when metering data hasn't changed — saving not just airtime but battery life;
You need threshold logic: report a temperature violation immediately, not at the next cycle;
You need data restructuring: split, scale, and structurally package multiple register values from one 485 frame.

ManThink's answer is EdgeBus (EB): an event-driven edge-computing virtual machine. You write collection logic in TypeScript, compile it to a few hundred bytes of binary, and run it low-power on a Cortex-M0-class MCU. Its runtime model is two periodic events:

Query event: periodically send commands to RS-485 sub-devices and fetch raw data;
Uplink event: periodically package processed data and send it via LoRaWAN.

EB natively supports Modbus (CRC checks, integer/float/BCD read-write), DL/T 645, CJ/T 188, and any custom protocol, and completes COV, alarm triggering, and data restructuring locally at the endpoint — with that logic pushed down to the device, uplink data volume, airtime consumption, and cloud-side parsing burden all fall together.

More important is the change in engineering workflow: EB code is debugged and upgraded entirely online. In real projects you can install the hardware on site first, then push the business logic via FUOTA (multi-bin block-wise, compressed low-power over-the-air upgrade) — decoupling field installation from software debugging. For retrofitting factories that cannot be stopped, this is decisive: hardware installation fits in one maintenance window; protocol adaptation is done slowly from the office.

5.3 A Chain Proven Across 100,000 Units

Assembling the full chain:

Installed RS-485 devices (meters / PLCs / transmitters, untouched)
    ↓ RS-485 / Modbus / DL/T645 / CJ/T188
DTU (KC11/KC25/KC21, EB VM runs protocol parsing & COV locally)
    ↓ LoRaWAN (CN470 private network, CSS interference immunity)
Gateway (GDI51/GDO51/GD61x, per indoor/outdoor and scale)
    ↓ Ethernet / Wi-Fi / 4G backhaul
NS + Platform (ThinkLink, or ChirpStack/TTN — no lock-in)
    ↓
SCADA / BMS / energy management / third-party platforms

The economics of this chain: installed wired assets see zero replacement; only the "last hop" wireless conversion layer is added. Compared with the "replace with native LoRaWAN sensors" route, per-point cost drops sharply; compared with the "replace whole machines" route, the cost differs by an order of magnitude. The KC11 alone passing 100,000 deployed units is the most direct evidence that this route has survived real industrial sites.

6. Five Common Misconceptions

Misconception 1: "79% of new nodes are Ethernet; serial is being phased out."
New-install share and installed base are two different statistical frames. With 70% of in-service assets older than 15 years and process equipment lifespans of 20–30 years, serial devices will keep serving on-site for another decade — "phase-out" is a 2040s topic. The last-mile problem exists precisely inside that time gap.

Misconception 2: "Operator networks are broad; just use NB-IoT on industrial sites."
"Broad coverage" means outdoor ground level. The places industrial assets live — inside power cabinets, basements, deep inside metal plants, remote sites — are exactly where deep cellular coverage is worst. The more practical problem: NB-IoT's OPEX model (SIM annual fee × device count × years) is a continuously growing bill at thousand-point scale, and service continuity over the device lifecycle is not under your control.

Misconception 3: "LoRaWAN capacity is insufficient for industrial point counts."
We did this math in Issue #10: a single gateway carries five-figure node counts at SF7 and hundreds at SF12. Industrial metering messages are "tens of bytes every 15 minutes" — the real bottleneck is coverage, not capacity. Coverage-starved points pushed to SF12 by ADR are the capacity killers, so well-placed gateways are themselves the most effective capacity upgrade.

Misconception 4: "A DTU is just a pass-through module; buy a cheap one."
Pass-through only moves bytes from serial to cloud. What decides project survival is protocol parsing (the address-length differences of DL/T645/CJ188), COV strategy (the key to battery life), FUOTA (the only way to fix logic defects when no one can reach the site), and wide-voltage power (whether it installs in a distribution cabinet). These capability gaps are invisible at selection and visible in year three. The mining case's 15% vs. 0.8% packet-loss gap and the $1,200 vs. $150 annual maintenance gap are the three-year ledger of "cheap off-the-shelf" versus "engineered product."

Misconception 5: "Wireless retrofit means touching the original system — too risky."
The opposite is true: the DTU route is the least invasive of all retrofit paths — original equipment untouched (no re-flashing, only a parallel connection onto the 485 bus), original control systems running as before, wireless layer independently overlaid. The real risk lives in routes that "modify the original system" — that is where qualification documents lapse, SIL ratings need re-assessment, and downtime windows appear.

7. A Closing Clarification

The industrial IoT last mile is often framed as a technology contest: "LoRaWAN or NB-IoT?" This article's argument: that framing itself asks the wrong question.

The real question is: under the three constraints (cannot remove, cannot modify, should not replace), how do you bring in-service installed assets online? Under those constraints:

Data profile routes first (video to 4G/5G, metering to LPWAN);
Device distribution picks the path (clustered → private network, scattered → operator);
Target assets pick the form (RS-485 installed base → DTU route, new points → native sensors);
Power condition picks the model (AC cabinet / DC cabinet / no-supply points).

And technology selection is only the entry ticket. What decides whether a project lives to year five is engineering detail beyond the datasheet: cable that does not embrittle at -40°C, a 0.8% packet-loss rate next to a VFD, a wide-voltage design that draws power directly in the distribution cabinet, and remote upgrade capability that frees protocol adaptation from on-site debugging.

The next decade of industrial digitalization will be fought not in brand-new smart factories but in legacy sites where "the equipment has more seniority than the engineers." Whoever completes the last mile with the lowest invasiveness holds the ticket to this market.

Appendix A: Glossary

Term	Definition
LPWAN	Low-Power Wide-Area Network; umbrella term for LoRaWAN/NB-IoT/Sigfox/Wi-SUN
DTU	Data Transfer Unit; protocol-conversion terminal between serial devices and wireless networks
Modbus RTU	Master-slave serial industrial protocol running on the RS-485 physical layer
DL/T 645	Chinese power-industry standard protocol for multi-function electricity meters
CJ/T 188	Chinese urban-construction standard protocol for household metering instruments (water/gas/heat)
COV	Change of Value; do not upload unchanged data
FUOTA	Firmware Update Over The Air for LoRaWAN
CSS	Chirp Spread Spectrum; the LoRa physical layer, resistant to narrowband interference
ADR	Adaptive Data Rate
EB (EdgeBus)	ManThink's event-driven edge-computing VM; written in TypeScript, runs low-power on MCUs
Installed base	The retrofit market of already-deployed, mostly wired-interface devices
SIL	Safety Integrity Level

Appendix B: References

HMS Networks, Industrial Network Market Analysis 2026 — Ethernet 79% / fieldbus 14% / wireless 7% of new nodes; PROFINET 30%, Modbus TCP 5%, Modbus RTU 3%
LNS Research / ARC Advisory / McKinsey 2025 manufacturing benchmarks — ~70% of installed industrial control assets older than 15 years
QYResearch, Global Industrial DTU Market Research Report 2026 — $709M (2025), $750M (2026), $1,052M (2032), CAGR 5.8%, average price $102, ~6.95M units/year
360iResearch / Data Insights Market, Industrial Wireless DTU Market — $1.37B (2025), CAGR 8.85%
NiceRF, "LoRa, LoRaWAN, NB-IoT, and 4G DTU: Industrial Wireless Solution Selection Analysis" — four-technology comparison and three selection cases
KaaIoT, NB-IoT vs LoRaWAN: which to use for industrial IoT applications? — CAPEX/OPEX structures, coverage behavior, interference immunity
VolleyBoast, Using VoBo in Noisy Industrial Environments — CSS interference immunity and deployment discipline in industrial EMI
Robustel, How to Choose an Industrial LoRaWAN Gateway for Harsh Environments — failure-mode analysis of "hidden harsh" indoor environments
AnyPCBA industrial gateway case — 15% → 0.8% packet loss in high-interference mining sites; 68% TCO reduction over three years
Yunzhibian pharmaceutical cold-storage case study — 470 MHz penetrating 20 cm insulation; -80°C cable-embrittlement lesson
ThinkLink official documentation — KC11/KC25/KC21 DTU specifications, EdgeBus architecture, ManThink company positioning (www.think-link.net)
ManThink, "How to Quickly Connect Traditional RS485 Devices to a LoRaWAN Network" — RS-485 installed-base integration architecture

The LPWAN Market in 2026: LoRaWAN vs NB-IoT vs Sigfox

manthink — Fri, 11 Sep 2026 01:59:05 +0000

From "three-way race" to "one retreat, one hold, one advance" — Sigfox has restructured after bankruptcy, NB-IoT leans heavily on the Chinese market, and LoRaWAN runs away with the private-network segment overseas. The 2026 LPWAN story is not about displacement; it is a marathon between three business models.

1. The Short Version

If you only have 30 seconds to understand the 2026 LPWAN landscape, remember three things:

NB-IoT holds the largest connection count, but it is highly dependent on China — roughly 84% of global NB-IoT connections are in China. Exclude China, and the picture changes completely.
LoRaWAN leads overseas markets and China's private-network segment — LoRa Alliance figures show more than 125 million deployed end devices growing at about 25% per year; outside China, LoRaWAN holds roughly 41% of LPWAN connections, the largest single share.
Sigfox has exited mainstream competition — after its 2022 receivership and acquisition by Singapore's UnaBiz for about €25 million, it was rebranded as "Sigfox 0G Technology" and now plays a supporting role in a multi-protocol convergence strategy, no longer a standalone track.

Research firms disagree widely on total LPWAN connection counts (from roughly one billion to several billion, depending on whether Chinese metering, LTE-M, and private LoRa networks are counted), but the directional conclusion is consistent: NB-IoT and LoRa together account for about 83% of the LPWAN market — a stable duopoly — while Sigfox has retreated into a niche.

2. Technology Profiles

2.1 LoRaWAN: The Open-Ecosystem Private-Network Champion

Foundation: Semtech's LoRa physical layer (chirp spread spectrum) plus the MAC-layer protocol maintained by the LoRa Alliance. It operates in Sub-GHz unlicensed spectrum (EU868, US915, CN470, AS923, etc.) with a star topology and a four-tier architecture: end device — gateway — network server (NS) — application server.

Key parameters:

Data rates of 0.3–50 kbps (DR0–DR5 in EU868); payloads up to ~242 bytes depending on DR
AES-128 end-to-end encryption with OTAA dynamic joining
Class A/B/C device types; battery life of 8–10 years is achievable
ADR (adaptive data rate) plus LR-FHSS long-range frequency hopping for dense deployments

Market position (LoRa Alliance 2025 End of Year Report):

More than 125 million deployed end devices, growing at roughly 25% annually
Around 360 alliance members, with 57 added in 2025
LoRa-family technologies hold roughly 64% of smart-building deployments — precisely because private networks don't depend on operators
The LoRaWAN connectivity market is projected to grow from about US$10.7B in 2025 to about US$44.8B by 2030 (~33% CAGR)

Moat: You can build the network yourself. One open-source gateway (such as the ManThink GD6, with tri-path backhaul and a full protocol stack) plus an open-source NS (ChirpStack) gets you a private network where data never leaves your campus. No cellular technology offers that.

2.2 NB-IoT: The Licensed-Spectrum Regular Army

Foundation: A cellular narrowband technology standardized in 3GPP Release 13 (2016), running in licensed spectrum with a carrier bandwidth of only 200 kHz — deployable in-band, in guard band, or standalone within LTE.

Key parameters:

Peak downlink ~26 kbps; uplink ~15.6 kbps single-tone (higher multi-tone)
Relies on operator base-station coverage; coverage depth roughly 20 dB better than legacy GSM (MCL 164 dB)
Power-saving via PSM, eDRX, and PSA mechanisms
Continued evolution in 3GPP Rel-17/18, with NTN satellite connectivity validated

Market position:

About 84% of global NB-IoT connections are in China, driven by carrier base-station upgrades since 2017 and the policy-backed migration of water and gas metering
NB-IoT and LTE-M together reached roughly one billion active connections by the end of 2025
NB-IoT accounts for roughly 54%–58% of total LPWAN share (with China's weight included)

Moat: The operator network. No gateways to deploy or maintain — insert a SIM card and coverage is the carrier's problem. The price: subscription fees, carrier lock-in, and uncertainty around network sunsetting cycles.

2.3 Sigfox: From Unicorn to "0G Technology Brand"

Foundation: Ultra-narrowband (UNB) modulation with channels only 100 Hz wide, ~100 bps uplink, 12-byte payloads, and a message budget of 140 uplinks and 4 downlinks per day. Radical simplicity buys radical low power and rock-bottom silicon cost.

Rise and fall:

Founded in 2010; peaked at a valuation of about US$1 billion, once mentioned alongside LoRaWAN and NB-IoT as one of the three LPWAN schools
Filed for receivership in January 2022; acquired by Singapore's UnaBiz in April for roughly €25 million (retaining 110 of 174 employees)
UnaBiz's plan was never to "revive Sigfox" but to pursue multi-protocol convergence: rebranded as "Sigfox 0G Technology," it became one option in UnaBiz's LPWAN abstraction layer alongside LoRaWAN, LTE-M, and Wi-SUN — exemplified by Japan's Nicigas gas-metering project, where 90% of sensors use Sigfox and 10% use Cat-M for coverage gaps

Today: The 0G network covers 70+ countries and over a billion people, with roughly 20 million devices still in service. It retains unique value in ultra-low-cost asset tracking (single-use logistics trackers, cold-chain tags). But the narrative of Sigfox as a mainstream rival to LoRaWAN and NB-IoT is over.

3. The 2026 Market in Numbers

Counting methodologies vary across research firms; sources are cited for cross-reference:

Dimension	Figure	Source
LoRaWAN deployed end devices	125M+, ~25% annual growth	LoRa Alliance 2025 EOY Report
LoRa Alliance membership	~360 (57 added in 2025)	LoRa Alliance
NB-IoT geographic concentration	~84% of connections in China	IEEE ComSoc Technology Blog (2026.3)
LPWAN share outside China	LoRaWAN ~41%, #1	IEEE ComSoc Technology Blog (2026.3)
Long-range IoT connectivity revenue (2025)	NB-IoT ~$6.2B (43.5%), LoRaWAN ~$4.5B (31.8%), LTE-M ~$2.1B (14.9%), Sigfox & others ~$1.4B (9.9%)	PW Consulting market report
LoRaWAN connectivity market forecast	~$10.7B (2025) → ~$44.8B (2030), 33.1% CAGR	Industry forecast (cited by IEEE ComSoc)
Duopoly concentration	NB-IoT + LoRa ≈ 83% of LPWAN	IoT Analytics (baseline, structure persists)
Sigfox/0G network	70+ countries, ~20M devices in service	Sigfox/UnaBiz official

Three cautions when reading these numbers:

"LoRa" and "LoRaWAN" are not the same count. Cumulative LoRa chipset shipments (700M+) far exceed LoRaWAN protocol connections (125M) — many proprietary-protocol devices also use the LoRa PHY.
China's weight inverts conclusions. Include China and NB-IoT is the runaway leader; exclude it and LoRaWAN leads overseas. Global product planning must split the markets.
Revenue share ≠ connection share. NB-IoT's revenue share (~43%) is lower than its connection share (~54%–58%) because many Chinese metering connections carry very low ARPU.

4. Three Dividing Lines

Dividing line 1: China vs. the rest — two parallel markets

China is NB-IoT's home turf: carrier-led base-station coverage and policy-driven metering migration (smart water/gas meter penetration above 80% in tier-1 cities) make NB-IoT the default in public utilities.

Overseas markets (Europe, North America, Southeast Asia, Latin America) never saw comparable carrier NB-IoT investment. LoRaWAN took roughly 41% of connections there on the strength of private networks and an open ecosystem, with growth led by smart buildings, smart agriculture, asset tracking, and campus deployments.

For product companies: in China, plan for NB-IoT and LoRaWAN coexisting; globally, LoRaWAN's ecosystem advantage is more pronounced.

Dividing line 2: The Sigfox lesson — great technology is not a great business

Sigfox's UNB technology remains unmatched on ultra-low power and ultra-low cost. Why did it fall?

Closed ecosystem: Chip supply, base stations, and the cloud were all controlled by one company; partners could only act as distributors — a stark contrast to the LoRa Alliance's 360-member open model
Single business model: Selling connectivity alone, without end-to-end vertical solutions, stalled growth in an industry that demands solutions
Capital mismatch: The heavy-asset "build the network first, find customers later" model burned out over IoT's long adoption cycle

UnaBiz's post-acquisition pivot answers each lesson: no more single-technology evangelism, but an LPWAN abstraction layer that mixes networks by coverage, cost, and use case. "Customers don't care which LPWAN they use — they care about getting devices online at a sensible cost." Every IoT professional should keep that sentence.

Dividing line 3: Convergence is the 2026 theme

The LPWAN market is moving from "picking sides" to "combining":

Amazon Sidewalk: a consumer-grade LoRa-based shared network already covering 95% of the US population, expanding into Canada and Mexico in 2026 — Big Tech chose the LoRa PHY as the foundation for mass consumer IoT
Hybrid networking as the norm: 1NCE (cellular) and Netmore (LoRaWAN) announced integrated global coverage; UnaBiz's 0G abstraction spans Sigfox/LoRaWAN/LTE-M
Satellite NTN for coverage gaps: 3GPP Rel-17/18 takes NB-IoT to direct-to-satellite; the LoRa camp's LR1121 chipset supports Sub-GHz + 2.4 GHz + satellite S-band
LoRaWAN keeps evolving: LR-FHSS lifts dense-deployment capacity by an order of magnitude, and the 2025 Regional Parameters update tripled the top data rate

5. An Engineer's Selection Guide

Decision dimension	Choose LoRaWAN	Choose NB-IoT	Choose Sigfox/0G
Deployment model	Self-built private network	Operator network	Operator network (70+ countries)
Data sovereignty	Fully yours	Data transits carrier	Data transits carrier
Max payload	~242 B	~1600 B (theoretical)	12 B
Downlink capability	Weak (Class A) / strong (Class C)	Fairly strong	Very weak (4 msgs/day)
Mobility / handover	Weak (designed for static nodes)	Moderate	Weak
Traffic cost	CAPEX + zero fees	SIM subscription	Subscription (lowest)
Entry threshold	One gateway is enough	Depends on carrier coverage	Depends on carrier coverage
Ecosystem openness	Open alliance, 360+ members	3GPP standard, operator-led	Single-vendor technology (UnaBiz-operated)
Typical use cases	Buildings, campuses, agriculture, factories	City-scale metering, municipal assets	One-way tracking, cold-chain tags

Three questions for a quick decision:

Does data need to leave your site? No → LoRaWAN private network; Yes → next question
Is there stable operator coverage at the deployment site? Yes, and the project is urban → evaluate NB-IoT; No (remote, basement, cross-border) → LoRaWAN or hybrid
Uplink-only, 12 bytes per message enough, cost squeezed to the limit? Yes → evaluate Sigfox/0G; No → back to the first two questions

A pragmatic trend is dual-mode hybrid: LoRaWAN collects campus sensors at the access layer while backhaul runs over 4G/Ethernet; or core assets use NB-IoT for guaranteed coverage while high-density sensing uses LoRaWAN for cost control. ManThink's GD6 gateway does this at the hardware level — LoRaWAN access plus Ethernet/Wi-Fi/4G tri-path backhaul, one device filling both network roles.

6. The ManThink Perspective: The Engineering Dividend of Private Networks

As a device vendor in the LoRaWAN camp, our read of the landscape is direct: LoRaWAN's long-term value lies in connecting the installed base.

A huge share of sensors in industrial and building environments are wired (RS-485, M-Bus, 4-20mA, DI/DO). When retrofitting them for wireless, operator networks are neither economical nor controllable. A LoRaWAN private network lets integrators expand their sourcing from "LoRaWAN-interface sensors only" to "any wired sensor," completing retrofits at low cost with a gateway plus wireless conversion modules (such as Edge-Bus architecture DTUs).

That is why GD6 exists as an open-source gateway and ThinkLink as a lightweight NS plus application platform: once the connectivity market settled into a duopoly, the real competition moved to lowering the entry barrier for private networks — a network in five minutes, template-based sensor onboarding, event-driven low-power edge logic. The market data backs this direction: the main engine of LoRaWAN's 25% annual growth is precisely private and enterprise-built networks.

7. Conclusion

The 2026 LPWAN market has no winner-take-all outcome:

NB-IoT wins on carrier infrastructure and Chinese metering — the "public-utility-grade" choice
LoRaWAN wins on open ecosystem, private deployment, and overseas markets — the "enterprise-autonomy-grade" choice
Sigfox lost its standalone track, but its UNB technology lives on as "0G" inside a multi-protocol convergence ecosystem

For engineers and decision-makers, the question was never "which technology is better" but "which route fits your data sovereignty, deployment environment, and cost structure" — and increasingly, the right answer is a combination, not a side.

References

_1. LoRa Alliance 2025 End of Year Report (Feb 2026) — 125M devices, 360 members

IEEE ComSoc Technology Blog (Mar 2026) — NB-IoT share 54%–58%, China ~84% of global NB-IoT, LoRaWAN ~41% outside China
PW Consulting, Worldwide Long Range IoT Connectivity Market 2026 — revenue share by technology
Light Reading, "Sigfox rescued from receivership by Singapore's UnaBiz" (Apr 2022) — receivership and acquisition details
Stacey on IoT, "UnaBiz has a nice plan for Sigfox" — 0G convergence strategy and the Nicigas case
Sigfox/UnaBiz official site — 0G network coverage data
IoT Analytics — 83% duopoly baseline (historical)
ThinkLink knowledge base — ManThink market positioning and product line_

# LoRaWAN Device Classes: Class A, B, and C Compared — A Selection Guide

manthink — Fri, 28 Aug 2026 07:42:19 +0000

Introduction: Why do water meters, streetlights, and gateways look different on the same network?

Open the datasheet of any LoRaWAN device and you will find a line item: Device Class. Water meters say Class A. Smart streetlights might be Class B. Relay cabinets and gateways are Class C.

These letters are not marketing labels. They are the LoRaWAN specification's three conventions for how a device receives downlink data — and they directly determine:

how long the device can run on a battery;
how quickly it receives commands sent by the platform;
how you should plan power supply and maintenance for the project.

One sentence captures the essence: in LoRaWAN, uplink is easy, downlink is expensive. Sending data is cheap for a device; but to "always hear the platform talking," the radio receiver must stay on — and a receiver's power draw is typically a hundredfold or more above deep sleep. Class A/B/C are the protocol's three answers to this conflict.

This article explains all three mechanisms and gives you a selection table you can use directly in your next project.

1. First, understand the conflict: why is downlink so hard?

LoRaWAN is a low-power wide-area network (LPWAN). Its typical endpoint is a battery-powered sensor, with a design goal of "one battery lasting 5–10 years."

To achieve that, the device must spend the vast majority of its life in deep sleep — and a sleeping device is deaf. It cannot hear any call from the gateway. If the platform must be able to send commands at any time (remote switch-off, changing the reporting interval), the receiver has to stay on continuously, and battery life immediately shrinks from "a decade" to "a few months."

Power consumption and downlink responsiveness are natural adversaries. Class A, B, and C are not three "technologies" — they are three compromise points along this axis: from "spend nothing on downlink" (A), to "wake up on a schedule to check for commands" (B), to "always online" (C).

2. Class A: Listen only after speaking — the lowest-power baseline

Mechanism: the two receive windows

Class A is the mandatory baseline for all LoRaWAN devices — whatever class a device claims, it always implements Class A behavior first.

The logic is simple: the device sleeps deeply and only briefly opens two receive windows after it has sent an uplink:

Device      ──uplink──►  Gateway/NS
              │
              │ wait RECEIVE_DELAY1 (default 1 second)
              ▼
            RX1 window opens (brief)
              │ if nothing, wait another second
              ▼
            RX2 window opens (brief)
              │ if still nothing
              ▼
            back to deep sleep

RX1: opens about 1 second after the uplink ends, typically on the same (or similar) frequency and rate as the uplink;
RX2: follows about 1 second later, using the region's fixed frequency and rate (e.g., EU868's RX2 is fixed at 869.525 MHz / DR0; check your Regional Parameters).

Both windows are short; once closed, the device returns to sleep. In other words, the network can only reach a Class A device by "hitching a ride" — it must wait for the device to speak first. Downlink payloads queue at the NS until the next uplink opens RX1/RX2.

Characteristics and use cases

Dimension	Performance
Power	Lowest of the three; deep sleep dominates
Downlink timing	Only after uplink; cannot be woken on demand
Downlink latency	Bound by reporting interval: hourly reports → up to ~1 hour wait
Typical supply	Primary battery (lithium), life of 8–10 years achievable

Use cases: water/gas/electricity meters, temperature/humidity and soil sensors — anything that is "sense and report, with almost no downlink." This is why Class A dominates the LoRaWAN sensor ecosystem.

3. Class B: Scheduled listening — the middle ground

Mechanism: Beacon sync + Ping Slots

Class B adds a "wake up on schedule and take a look" mechanism on top of Class A:

Beacon synchronization: gateways periodically broadcast Beacons; after receiving one, the device aligns with network time — from then on, it "knows what time it is."
Ping Slots: with time sync in place, the device briefly opens a receive window at periodic fixed moments (Ping Slots), listening for downlink addressed to it. Nothing? Back to sleep. Something? Receive and process.

The Ping Slot period is configurable (the specification defines several tiers from seconds up to 128 seconds): shorter period → more responsive downlink, but more wake-ups and higher power.

        After Beacon sync, the device's timeline:
  ──┬────┬────┬────┬────┬──►
    │    │    │    │
  Ping  Ping  Ping  Ping      ← scheduled brief windows
  Slot  Slot  Slot  Slot
   (awake for milliseconds, deep sleep the rest)

Characteristics and use cases

Dimension	Performance
Power	Slightly above Class A (Beacon reception + Ping Slot wake-ups)
Downlink timing	Can be scheduled into Ping Slots; no longer fully dependent on uplink
Downlink latency	Bounded: at worst one Ping Slot period
Deployment requirement	The network side must support Beacon broadcast — gateway and NS both; not something a device can do alone

Use cases: smart streetlights (seasonal on/off schedules pushed remotely), devices needing periodic time sync, monitoring points that must receive downlink within minutes. Class B is comparatively rare in practice, largely because of this deployment threshold: the whole chain (device–gateway–NS) must support it.

4. Class C: The "real-time mode" — for mains-powered devices

Mechanism: receiving everything except while transmitting

Class C abandons the "sleep to save power" idea altogether: the radio receiver stays on almost continuously, closing only for the instant of uplink transmission (to avoid self-jamming), then immediately returning to receive mode.

  ──RX──RX──RX──│TX│──RX──RX──RX──RX──►
              (receiver off only while transmitting)

With this, commands from the platform arrive almost instantly — downlink latency drops from "minutes/hours" to "seconds."

The cost: power is dominated by RX current

This is the account every engineer must run. A radio receiver typically draws milliamps to tens of milliamps, while a Class A device in deep sleep draws microamps — three to four orders of magnitude apart.

There is a well-established engineering conclusion (not a protocol prohibition): Class C is generally unsuitable for primary-battery devices. A primary cell (e.g., lithium thionyl chloride) cannot sustain continuous RX current; without a complete power-lifecycle budget, no multi-year lifetime claim is credible.

Hence Class C's typical supplies: mains power, PoE, or large rechargeable batteries.

Dimension	Performance
Power	Highest of the three; average current dominated by RX
Downlink timing	Anytime, near real-time
Downlink latency	Seconds
Typical supply	Mains / PoE / always-on

Use cases: relays and control cabinets (remote switching), industrial real-time monitoring, actuators — and LoRaWAN gateways themselves (a gateway, as an "always-on" device, is naturally Class C in behavior).

5. Side-by-side comparison

Dimension	Class A	Class B	Class C
Receive timing	RX1/RX2 after uplink only	Uplink windows + periodic Ping Slots	Continuous except while transmitting
Downlink capability	Weakest (rides on uplink)	Scheduled, bounded latency	Near real-time
Downlink latency	Next uplink (minutes–hours)	At worst one Ping period (seconds–minutes)	Seconds
Power	Lowest	Slightly above A	Highest (RX-dominated)
Typical supply	Primary battery	Battery (capacity uprated accordingly)	Mains/PoE
Battery-life magnitude	5–10 years	Years (depends on Ping period)	Not applicable to primary batteries
Network-side requirements	None special	Gateway + NS must support Beacons	None special
Typical devices	Utility meters, temp/humidity sensors	Smart streetlights	Relays, actuators, gateways

One point worth emphasizing: the device class does not change regional data-rate definitions, nor can it bypass local transmission regulations — it is a MAC-layer receive-behavior convention, independent of the physical-layer parameters (SF/BW/CR — see Article 4 in this series).

6. Selection: ask yourself three questions

Question 1: Does this device need to receive downlink commands?

Almost never (report-only) → Class A, no hesitation.
Yes, but waiting minutes is fine → see Question 2.
Yes, with second-level response (control) → Class C, and plan mains/PoE supply.

Question 2: Is the device battery-powered?

Yes, and must last 5+ years → Class A; if periodic downlink is genuinely required, evaluate Class B and budget the power carefully.
Mains/always-on → Class C is available; enjoy real-time downlink.

Question 3 (for Class B): Does the infrastructure support it?

Do the gateway and NS support Beacon broadcast? Without it, Class B exists only on paper.

A practical rule of thumb: sensors default to Class A, actuators default to Class C, and consider Class B only for the middle ground. This matches the product mix you see across most LoRaWAN vendors today.

7. Three common misconceptions

Misconception 1: "Class C is more advanced — pick it and you're safe."

Class C is not an upgrade; it is a different trade-off. Configuring a battery sensor as Class C means burning its battery on RX current — lifetime drops from a decade to months, while also consuming gateway downlink capacity. Choosing the wrong class costs more directly than choosing the wrong SF.

Misconception 2: "Class A devices can never receive downlink."

False. A Class A device receives downlink in the RX1/RX2 windows after every uplink — ACKs, MAC commands, and configuration changes all fit in these windows. Only the timing is tied to uplink. In practice, with a sensible reporting interval and command queuing, Class A handles most configuration-delivery needs.

Misconception 3: "Class is baked into the device and cannot change."

Class is MAC-layer behavior. Many devices (especially configurable DTUs and modules) support Class A/C switching, letting you choose dynamically by project phase: Class C during commissioning for real-time provisioning, back to Class A in production for power savings. Just make sure the switching logic matches the power supply.

8. Engineering practice tips

Power budget first: whatever the class, run the power-lifecycle estimate first (RX/TX/sleep current × time share), then pick battery capacity — especially for Class B and C. "Back-of-envelope lifetime promises" are the top source of after-sales disputes.
Trim downlink requirements: audit every "needs real-time downlink" requirement. Many so-called real-time controls degrade gracefully to "deliver configuration on next report" — which Class A satisfies.
Mind the downlink bottleneck: a typical gateway has 8 channels and 16 demodulators — 16 parallel uplink packets but often only a single downlink channel. Many Class C devices plus frequent downlink will squeeze that resource; plan downlink traffic density accordingly.
Activation is special: during OTAA, the Join Accept itself is delivered in RX1/RX2 — even Class C devices follow Class A timing during activation. This is yet another reflection of A being the baseline.

Conclusion

Class A/B/C are, at their core, three lines LoRaWAN draws between "low power" and "downlink responsiveness": A pushes power to the minimum and queues the downlink; B trades time synchronization for bounded downlink latency; C trades mains power for second-level response.

Once you internalize this main axis, you can look at any LoRaWAN device's class label and immediately infer its power supply, downlink capability, and appropriate use cases — a skill more valuable than memorizing any parameter.

Written by the ManThink technical team. ManThink is committed to open-source and reliable LoRaWAN infrastructure: the GD6 open-source gateway (ESP32-S3 + SX1302) supports global bands and mainstream network servers, and the in-house EdgeBus edge-computing engine supports Class A/C mode switching to connect sensors to LoRaWAN at minimal power.

LoRa Physical Layer Parameters: How SF, BW, and CR Shape Range and Data Rate

manthink — Wed, 26 Aug 2026 01:37:51 +0000

Introduction: Same sensor, but 2 km for one team and 15 km for another?

A recurring puzzle in LoRaWAN projects: identical sensors and gateways, yet one customer reports "coverage of only 2 km" while another claims "we reach 15 km." Antennas and mounting aside, the most overlooked cause is the configuration of three LoRa physical-layer parameters — Spreading Factor (SF), Bandwidth (BW), and Coding Rate (CR).

LoRa's core design philosophy is "trading bandwidth for distance." Unlike WiFi or 4G, which chase high throughput, LoRa spreads the signal so the receiver can demodulate it at much lower signal-to-noise ratios. But how much spreading, and how, is governed by SF, BW, and CR.

This article explains these parameters thoroughly: what each one is, how it affects range and data rate, the concrete numbers, and how to make trade-offs in real projects.

1. SF (Spreading Factor): The "gear" for range

What is the spreading factor

The Spreading Factor (SF) defines how many chips (chirp symbols) each data bit is expanded into. Each step up in SF doubles the number of chips per symbol:

At SF12, each data bit is represented by 4096 chips — the signal is "spread out" 32 times relative to SF7. The receiver can therefore pull it out of the noise at much weaker signal levels, and the communication range grows accordingly.

Why larger SF means longer range

A larger SF brings two direct benefits:

Lower (more negative) receiver sensitivity. SF7 sensitivity is roughly −124.5 dBm; SF12 reaches about −137 to −141 dBm (values vary slightly with link-budget assumptions). Every 3 dB of sensitivity gain roughly doubles the theoretical range.
Higher processing gain. The spread signal is stretched in time, and correlation demodulation at the receiver yields processing gain, improving robustness against interference.

The cost is rate and airtime: larger SF means lower data rate and longer time-on-air per packet.

How fast is each tier, really

Measured with the calculation engine (BW = 125 kHz, CR = 4/5):

From SF7 to SF12, the rate drops by nearly 19×. That is the physical-layer conflict between "long range" and "high throughput" made concrete.

One common point of confusion: although larger SF means longer symbol duration, different SFs are orthogonal — signals on different SFs can coexist on the same channel without interfering. This orthogonality is exactly why a gateway can demodulate multiple SF streams concurrently.

2. BW (Bandwidth): The "accelerator" for rate

What is modulation bandwidth

Bandwidth (BW) is the actual frequency span occupied by the LoRa signal. The most common setting in LoRaWAN is 125 kHz, with 250 kHz and 500 kHz also available.

The relationship with data rate is straightforward: doubling BW halves the symbol duration and doubles the rate. Measured (SF7, CR = 4/5):

Combination	PHY data rate
SF7 / 125 kHz	≈ 5.47 kbps
SF7 / 250 kHz	≈ 10.94 kbps

But there is no free lunch: a wider BW also widens the receiver's noise bandwidth, raising the noise floor, degrading sensitivity, and shortening range. BW is an "accelerator" — floor it and you gain speed but lose endurance (range).

How BW is used in LoRaWAN

The vast majority of regional DR0–DR5 definitions are based on 125 kHz;
Some regions (e.g., EU868) define DR6 as SF7 / 250 kHz, as a higher-rate tier;
The 500 kHz tier rarely appears as a device data rate in the LoRaWAN standard; it is more common in gateway uplink test scenarios.

3. CR (Coding Rate): The "insurance" for reliability

What is the coding rate

The Coding Rate (CR) is the forward error correction (FEC) redundancy ratio in LoRa, with four possible values:

What it does

CR lets the receiver recover the original data even when some bits are corrupted by interference. The worse the signal and the more interference, the more redundancy is needed. The cost: lower effective rate and longer time-on-air — each extra redundancy bit reduces coding efficiency.

The LoRaWAN standard defaults to CR = 4/5 (coding rate offset 1), which already provides good anti-ber capability at the highest effective rate. In practice, CR is rarely the parameter you tune day-to-day, but understanding it helps diagnose issues like "why is my over-the-air time longer than estimated."

4. LDRO: The overlooked fourth parameter

When a single symbol lasts longer than 16 ms (typical in low-rate scenarios such as SF11/SF12 with 125 kHz), long transmissions can cause crystal oscillator frequency drift that affects demodulation. In that case, Low Data Rate Optimization (LDRO) should be enabled, adding redundancy bits in the header to combat clock drift.

Note: LDRO is not a coding rate. It does not change rate calculation itself; it is simply a reliability switch for low-rate scenarios. Most LoRaWAN stacks (including the Semtech reference implementation) set LDRO automatically based on SF and BW, so manual intervention is rarely needed.

5. Quantified comparison: Time-on-air for a 13-byte packet

Time-on-air directly determines channel occupancy and battery life — arguably the single most important number for a project. Measured with the calculation engine (13-byte payload, CR = 4/5, explicit header):

Combination	Time-on-air	Ratio vs SF7
SF7 / 125 kHz	≈ 46.3 ms	1×
SF12 / 125 kHz	≈ 1155.1 ms	≈ 25×

The same temperature/humidity reading takes 46 ms at SF7 but 1.15 s at SF12 — a 25× difference. For battery-powered devices, this means:

Under duty-cycle limits, SF12 devices can transmit far less frequently per hour;
Power consumption rises (longer RF transmit time);
Channel occupancy at the gateway grows, reducing network capacity.

Industry capacity estimates confirm this: on the same 8-channel gateway with the same reporting interval, a network of all-SF7 devices can theoretically host 20× more nodes than an all-SF12 network (different models give SF7 ≈ 787k vs SF12 ≈ 29k devices; exact figures depend on the assumed SF distribution, but the conclusion is consistent).

6. Real-world trade-offs: Why there is no "best" setting

Put SF, BW, and CR together, and the core problem is a four-corner trade-off:

Want range → raise SF (e.g., SF12), lower BW;
Want throughput → lower SF, raise BW;
Want reliability → raise CR;
Want low power / high capacity → use low SF and short packets.

You cannot win all four at once. This is exactly why LoRaWAN designed ADR (Adaptive Data Rate) — the network side measures the actual signal quality received by gateways and automatically assigns each device the most suitable SF: good signal → drop to SF7 for higher rate, lower power, and freed-up channels; weak signal → move up to SF11/SF12 to protect coverage. ADR is the most cost-effective way to resolve the range-vs-rate dilemma.

Two common engineering misconceptions

Mistake 1: Locking everything to SF12 for coverage.

The sensitivity advantage of SF12 is real, but the cost is a three-way hit to rate, power, and capacity. The right approach: let ADR adapt first, then pin high SF only for the few weak-signal devices — never a network-wide one-size-fits-all.

Mistake 2: Assuming chip support means LoRaWAN support.

Chip capability ≠ protocol capability. For example, the SX1262 radio supports SF5, but the current LoRaWAN Regional Parameters do not define SF5/SF6 as standard data rates — devices cannot join using SF5. SF selection must satisfy both "chip support" and "Regional Parameters definition."

7. Configuration recommendations for project teams

Default to ADR: enable ADR after join so the network adapts SF to real signal conditions — the best return on effort.
Tier by use case: allow SF10–SF12 for long-range reporting (remote agriculture, mountain monitoring); push dense urban deployments (smart buildings) down to SF7–SF9.
Keep packets small: a LoRaWAN frame maxes out at 255 bytes, but airtime grows linearly with payload — don't send 50 bytes when 13 will do. Data compression and change-of-value (COV) reporting significantly extend battery life.
Budget airtime up front: before deployment, calculate device airtime × transmit frequency and check against regional duty-cycle limits (e.g., EU868's 1% rule) to avoid running out of channel capacity later.
Validate in the real environment: theoretical sensitivity differences ≠ field coverage differences. Metal structures, foliage, and terrain all take their toll — a field test across SFs is the most reliable check.

Conclusion

SF, BW, and CR are the three knobs of the LoRa physical layer. They determine how far, how fast, and how reliably the same radio hardware can communicate. Understanding them lets you make deliberate trade-offs among range, rate, power, and capacity — instead of being carried away by "LoRa transmits far."

The good news for LoRaWAN developers: the network side (NS) and ADR already automate most of the tuning. Your job is to understand the principles, set the boundaries, and let the system find the balance.

Written by the ManThink technical team. ManThink is committed to open-source and reliable LoRaWAN infrastructure. Its GD6 open-source gateway (ESP32-S3 + SX1302) covers CN470 / EU868 / US915 / AS923 and other global bands, with ADR, OTA, and support for mainstream network servers.

LoRaWAN Device Activation Explained: OTAA vs ABP

manthink — Mon, 17 Aug 2026 08:44:16 +0000

Before a LoRaWAN device can send or receive any data, it must complete a process called activation — the step where the device obtains its network address and session keys. The activation method you choose affects security, deployment complexity, and day-to-day operations.
The LoRaWAN specification defines two activation methods: OTAA (Over-The-Air Activation) and ABP (Activation By Personalization). This article breaks down how each works, compares them side by side, and gives practical selection guidance.

OTAA: Over-The-Air Activation

OTAA is the recommended activation method. Devices ship without session keys and complete authentication over the air after the first power-up.

How It Works

OTAA activation happens in three steps:

1. The device sends a Join Request

The device transmits a Join Request carrying:

The Join Request is authenticated with a MIC (Message Integrity Code) computed using the AppKey, ensuring the message was not tampered with.

2. The network server validates and sends a Join Accept

On receiving the Join Request, the network server:

Looks up the device's AppKey (and NwkKey on LoRaWAN 1.1) by JoinEUI/AppEUI
Verifies the MIC to confirm message integrity
Checks the DevNonce to prevent replay (each DevNonce can only be used once)
On success, assigns a DevAddr (32-bit device network address)
Generates a Join Nonce (network-server-side random value)
Builds and encrypts a Join Accept message with the AppKey The Join Accept carries:

3. The device derives its session keys

The device decrypts the Join Accept with its AppKey, then derives session keys from the AppKey, JoinNonce, DevNonce, and NetID.
LoRaWAN 1.0.x (1.0.2 / 1.0.3 / 1.0.4) derives two keys:

NwkSKey (Network Session Key): MIC computation for MAC-layer messages and MAC command encryption
AppSKey (Application Session Key): application payload encryption Simplified derivation:

LoRaWAN 1.1 introduces key separation, deriving four keys:

FNwkSIntKey: Forward Network Session Integrity Key
SNwkSIntKey: Serving Network Session Integrity Key
NwkSEncKey: Network Session Encryption Key
AppSKey: Application Session Key LoRaWAN 1.1 renames AppEUI to JoinEUI and separates the NwkKey from the AppKey, enabling network-level and application-level key separation — the foundation for secure roaming.

OTAA Security Properties

Keys never travel over the air: AppKey/NwkKey are provisioned on the device and network server; session keys are derived independently on both sides. Only the encrypted Join Accept crosses the air interface.
DevNonce replay protection: each DevNonce can be used exactly once; servers track used values.
Key rotation: a device can re-join at any time to obtain fresh session keys.
Roaming support: LoRaWAN 1.1's key separation design enables cross-network roaming.

ABP: Activation By Personalization

ABP skips the join procedure entirely. Devices are pre-provisioned with all communication parameters at manufacture and start sending immediately after power-up.

What Is Pre-Provisioned

The following must be written to the device before shipping and registered on the network server in advance:

ABP devices do not need a DevEUI, JoinEUI, or AppKey (unless you plan to migrate to OTAA later).

How It Works

An ABP device goes straight to work after power-up:

Uses the pre-configured DevAddr as its source address
Computes MICs with NwkSKey and encrypts MAC commands with NwkSKey
Encrypts/decrypts application data with AppSKey
Starts transmitting on default channels There is no Join Request / Join Accept handshake.

The Frame Counter Problem

ABP devices must manage their uplink (FCntUp) and downlink (FCntDown) frame counters. Network servers track these counters to prevent replay attacks — if a device reboots and its counter resets below the value the server last recorded, its frames will be rejected.
Two common approaches:

Server-side reset: reset the device's frame counters manually on the platform (fine for debugging)
Device-side persistence: store counters in non-volatile storage and resume from the last value after reboot (required for production)

OTAA vs ABP: Side-by-Side

| Dimension                    | OTAA                                                           | ABP                                                                                 |

| ---------------------------- | -------------------------------------------------------------- | ----------------------------------------------------------------------------------- |
| Security | High — keys derived over the join procedure, never transmitted | Low — keys must be written at manufacture and registered server-side; exposure risk |
| Key rotation | Yes — re-join to obtain fresh keys | No — keys are fixed; changing them requires reflashing devices |
| DevAddr assignment | Dynamically assigned by network server | Fixed at manufacture; uniqueness must be managed manually |
| Deployment complexity | Device only needs root keys; server handles the rest | Both device and server need full pre-configuration |
| Time to first packet | Join procedure first (typically 5–15 seconds) | Instant — works right after power-up |
| Frame counter management | Starts from zero after join; no conflict issues | Must be managed carefully; reboot may cause rejected frames |
| Roaming | Supported (LoRaWAN 1.1 key separation) | Not supported |
| LoRaWAN 1.1 | Fully supported — 1.1 relies on OTAA | Not recommended under 1.1 |
| Deployment scale | Suitable for production fleets | Suitable for small tests |
| Network switching | Change JoinEUI to join another network | Requires reflashing all parameters |

Which One Should You Use?

Use OTAA when

Production deployments — any fleet beyond a handful of devices should be OTAA
Security matters — sensitive data or compliance requirements
Large scale — DevAddr is dynamically assigned, avoiding conflicts
Roaming is needed — cross-network or multi-region deployments
LoRaWAN 1.1 networks — 1.1's security features depend on OTAA

ABP is acceptable when

Development and debugging — validate device communication quickly without the join handshake
Teaching and demos — simplify the flow so students focus on data exchange
Very small, fixed deployments — one or two devices in a controlled environment with low security requirements
Uplink-only scenarios — devices only transmit, with minimal key-management needs (still weigh the security trade-off)

A Common Misconception

"ABP saves power because there's no join procedure."
Not really. The join procedure costs very little — one Join Request and one Join Accept, typically completed in a few seconds. Compared to a device's multi-year battery life, the energy of the join phase is negligible. What ABP actually saves is development-time configuration effort — and in production that convenience comes at the cost of lower security and higher operational overhead.

Practical Notes

OTAA in Practice

DevEUI must be globally unique: use an IEEE EUI-64 derived from the device MAC; never hardcode a default value
Store AppKey securely: it's the root key — compromise means the device's entire communication can be decrypted. Prefer a secure element, or at least the MCU's flash encryption
Persist DevNonce: it must live in non-volatile storage and keep incrementing across reboots. A rollback causes the network server to reject Join Requests
Implement join retry with backoff: avoid hammering the channel if the network is temporarily unreachable
Listen in the join windows: Join Accept arrives in RX1 (default 5 s) and RX2 after the Join Request; the device must be listening

ABP in Practice

Persist frame counters: store FCntUp and FCntDown in non-volatile storage (RTC backup registers, flash, or EEPROM)
Plan DevAddr carefully: the 7-bit NwkID must match the network server's NetID; the 25-bit address must be unique within the network
Protect keys in manufacturing: ABP keys are written at manufacture — keep them out of production logs and test records
Never commit keys to public repos: if you share code on GitHub or similar, don't hardcode NwkSKey and AppSKey

Working with the ThinkLink Platform

On ThinkLink:

OTAA devices: register DevEUI and AppKey on the platform; the device joins automatically after power-up
ABP devices: register DevAddr, NwkSKey, and AppSKey; the device communicates immediately
The platform shows join status and frame counters for every device
If a frame counter conflict occurs, reset it from the device management page

Summary

Bottom line: use OTAA in production, ABP only for debugging and teaching. If you have more than ten devices, or if devices sit in environments you can't physically control, OTAA is the only sensible choice.
Written against the LoRaWAN 1.0.4 and 1.1 specifications. Protocol details follow the LoRa Alliance specification documents; operational advice draws from ThinkLink platform experience.
ThinkLink is the IoT platform product from ManThink, providing LoRaWAN network management, device operations, and data services.

ManThink Launches GD6 Open-Source LoRaWAN Gateway: ESP32-S3 + SX1302 Indoor Solution

manthink — Thu, 06 Aug 2026 02:14:32 +0000

ManThink has officially released the GD6 (GD61x series), an open-source indoor LoRaWAN gateway. The gateway is built around an ESP32-S3 MCU with an optional Semtech SX1301 or SX1302 concentrator, integrating Ethernet, Wi-Fi, and optional 4G multi-link backhaul. It covers major LoRaWAN regional bands worldwide — including CN470, EU868, AS923, and US915 — supports the full protocol stack (UDP Packet Forwarder, MQTT Bridge, and Basic Station), and delivers its complete web configuration system and firmware management capabilities as an open-source platform.

GD6 is positioned as a cost-effective indoor LoRaWAN gateway for developers, system integrators, and IoT solution providers. It is suitable for smart buildings, campus networks, small industrial sites, prototyping, and academic research.

Design Philosophy

Building a LoRaWAN gateway is not primarily a hardware challenge — the SX1302 + ESP32 combination is well-established. The real challenge lies in balancing "works out of the box" with "deeply customizable."

Most commercial gateways lock their configuration systems inside closed apps or cloud backends, limiting the parameters developers can tune. Pure DIY solutions offer flexibility but lack engineered configuration workflows and reliable OTA mechanisms, making them difficult to deploy in production.

GD6 takes a different approach: the hardware is designed and manufactured to commercial standards, but the configuration system, management interfaces, and firmware upgrade mechanisms are fully open. You can unbox a GD6, connect the antenna and power, and have it online in 5 minutes through the web interface. At the same time, you can integrate it into your own operations stack via REST API and remote MQTT, or even build and flash custom firmware.

It's a gateway that works out of the box — and can also be taken apart and modified.

Hardware

GD6's hardware design centers on three goals: sufficient performance, deployment flexibility, and convenient power.

MCU: ESP32-S3-WROOM-1 (N8R8)

8 MB QIO Flash + 8 MB Octal PSRAM, both running at 80 MHz. The ESP32-S3's dual-core processor handles multi-channel LoRa transceiving while simultaneously running the web console, TLS-encrypted communication, and MQTT remote configuration. The 8 MB PSRAM ensures the gateway doesn't drop packets or lag under high channel load.

LoRa Concentrator: SX1301 or SX1302

GD6 offers two concentrator options, identified directly by the model suffix:

Suffix 1: Semtech SX1301 — the classic solution, mature and stable
Suffix 2: Semtech SX1302 — lower power consumption, higher sensitivity

Both use an A-type LoRa architecture: single LoRa antenna, 8 frequency channels, 65 sub-channels, half-duplex.

RF Versions: Covering Major Global Bands

The 4 and 8 in the model number indicate the RF frequency range, not the number of channels. The region code must match the RF hardware and local regulations — you cannot convert a gateway from one frequency band to another through software alone.

Backhaul: Ethernet + Wi-Fi + Optional 4G

Ethernet: W5500, 10/100 Mbps, RJ45, supports DHCP or static IP
Wi-Fi: ESP32-S3 integrated 2.4 GHz, supports AP + STA concurrently
4G (optional): LTE Cat 1, miniPCIe interface, module is swappable for different carrier bands

Ethernet is the default priority link; when the primary link fails, the gateway automatically switches to the backup. Models with 4G (indicated by G in the model number) have triple-link backhaul; models without 4G (indicated by N) have dual-link.

The Wi-Fi AP mode operates independently of the backhaul link, providing a local configuration and recovery entry point. The default hotspot SSID is LGW-Config, password lgw12345678, management address 192.168.4.1.

Power Supply: Three Options

Type-C 5V: convenient for desktop debugging
DC terminal 5–24V: wide-voltage input for industrial sites

PoE (AG configuration only): power and data over a single RJ45 cable

Connecting multiple power sources simultaneously is not recommended.

Protocol Support

GD6 supports three mainstream uplink protocols, covering virtually all LoRaWAN network servers:

Semtech UDP Packet Forwarder — The classic protocol with the broadest compatibility. Configure the server address, uplink/downlink ports, and timeout parameters to connect.

MQTT Bridge — Forwards LoRa data via MQTT, supporting mutual TLS, CA certificates, and client certificates. Suitable for enterprise deployments with data security requirements. The MQTT Bridge uses an independent connection that does not interfere with the remote configuration channel.

Basic Station — Semtech's recommended next-generation gateway protocol, supporting LNS direct connection or CUPS bootstrap. Authentication options include TLS + Token or mTLS (client certificates). Compatible with TTN/TTI, ChirpStack, and other major network servers.

All three protocols are switched from the "LNS Configuration" page in the web console. Switching the uplink driver triggers a gateway reboot — confirm no OTA or configuration write is in progress before switching.

Open Source: What's Open

GD6's firmware and web configuration system are open-sourced on GitHub: github.com/ManThink/gd6-open.

The open-source design spans several layers:

Complete Web Configuration System
A bilingual (Chinese/English) web console covering network backhaul, LoRaWAN server, RF parameters, system logs, firmware upgrades, file system management, and user management. All configuration items are exposed via REST API for programmatic management.

Independent Remote MQTT Configuration Channel
Through a dedicated MQTT connection, you can remotely read and write permitted configuration items and trigger reboots without physical device access. This channel is completely independent from the data-forwarding MQTT Bridge, using separate connections and credentials. To prevent lockout from remote misconfiguration, the remote channel cannot modify its own Broker settings. Suitable for large-scale gateway operations.

A/B Dual-Partition OTA
GD6 uses an A/B dual firmware partition design. During upgrades, new firmware is written to the inactive partition, verified, and then the boot partition is switched. Even if an upgrade is interrupted or fails, the device boots from the original partition — no bricking. Firmware .bin files can be built independently and flashed via the web interface.

Accessible File System
Configuration files under /spiffs can be viewed and managed from the web console. Configuration JSON takes effect after reboot, supporting deep customization. Note: the web/ directory's static files should not be modified carelessly — overwriting them may render the console inaccessible, and a factory reset will not restore them.

Configuration Workflow

From power-on to online, the process typically takes under 5 minutes:

Power up: Connect the LoRa antenna (antenna must be connected before power-on), then power via Type-C or DC terminal
Connect to the gateway:

Via Ethernet: find the gateway address in your router's DHCP list, open it in a browser
Via Wi-Fi: connect to the LGW-Config hotspot, navigate to http://192.168.4.1

Log in: use the default password wifi!0804, then change it immediately in User Management
Configure backhaul: set up network connection on the "Ethernet" or "Wi-Fi" page
Configure LNS: select the uplink protocol on the "LNS Configuration" page, enter the network server address and port
Set frequency band: confirm the region and sub-band on the "Frequency & RF" page, apply, and restart the LoRa service

No serial cable needed, no command line required. If a configuration error makes the web console inaccessible, the REC button performs a factory reset — hold for 2 seconds, the device resets and reboots. Network and LoRaWAN configurations are restored to defaults; the written Gateway EUI is preserved.

Application Scenarios

Smart Buildings & Campuses
GD6's indoor design and Wi-Fi backhaul suit office buildings and industrial parks. A single gateway can cover one floor of LoRaWAN devices — temperature/humidity monitoring, personnel positioning, energy management. Ethernet provides stable backhaul; Wi-Fi serves as backup.

Small Industrial Sites
The 5–24V wide-voltage power input adapts to industrial power conditions. Models with 4G can deploy in warehouses and workshops without wired network infrastructure, using 4G as primary or backup link. The miniPCIe 4G module is swappable for local carrier bands.

Development & Prototyping
The ESP32-S3's performance and open-source configuration system make GD6 suitable as a LoRaWAN development platform. Developers can manage gateways in bulk via REST API, customize configurations through the file system, and quickly set up test environments to verify device communication.

Education & Research
Universities and research institutions can use GD6 to build LoRaWAN lab environments. Students can explore gateway internals through the web console and file system rather than facing a closed black-box device.

Multi-Region Global Deployment
GD614 and GD618 cover major global frequency bands, and the 4G module is swappable by region — suitable for cross-regional project deployment. The region code in the model number clearly identifies the supported LoRaWAN regional parameters.

Technical Specifications

Model Numbering

GD6 model format: GD61{4|8}-A{N|G}-{Region}-{Version}-{1|2}:

Example: GD618-AG-AS923-N-2 = 800 MHz+ RF, with 4G and PoE, AS923 region, default version, SX1302 concentrator.

Integration with ThinkLink Platform

GD6 is the native gateway hardware for the ThinkLink IoT platform. When used with ThinkLink, you can register gateways with one click and auto-sync Gateway EUI, visually manage devices, thing models, and automation rules through the platform, remotely push configurations without on-site visits, and monitor gateway status and backhaul links in real time.

At the same time, GD6's full protocol stack support means you're free to connect to any third-party LoRaWAN network server — TTN/TTI, ChirpStack, LoRiot, or a self-hosted LNS are all compatible.

Learn More

GD6 Open-Source Repository (firmware + web config): github.com/ManThink/gd6-open
GD61x Specifications & User Guide: think-link.net/docs/zh/Device/LoRaWANGateway/gd61x-user-guide
GD6 Configuration Guide: think-link.net/docs/zh/Device/LoRaWANGateway/gd6-configuration-guide
ThinkLink Platform Website: www.think-link.net
ManThink Website: www.manthink.cn

ManThink — Making IoT development more efficient.

ThinkLink Integrated Device Library: No Device Left Behind — Retrofitting Starts with a Search

manthink — Tue, 21 Jul 2026 01:55:52 +0000

Covering 29+ verified field devices across metering, industrial sensing & control, building & environment, and smart agriculture. Search by name, model, or protocol — every device comes with complete integration documentation.

Why a "Device Catalog"?

In IoT projects, the hardest part isn't the technology itself — it's figuring out "can I connect this device?"

The client's site has a Schneider Electric power meter with Modbus RTU. Can it go LoRaWAN?
A heating retrofit project uses CJ/T 188 heat meters on an M-Bus. How do you take them wireless?
An Acrel multi-circuit power meter — how many circuits per collector? In the traditional LoRaWAN ecosystem, answering these means: digging through sensor datasheets, scouring ChirpStack codec repositories, writing your own parsing scripts — every step costs time.

ThinkLink's Integrated Device Library was built to solve exactly this.

Device-First Search Logic
The core philosophy is simple: don't start from platform features — start from what's in the field.
Open https://www.think-link.net/zh/devices/ and you'll see a clean search interface:

Search by device name — type "ADW2xx" or "three-phase meter", go straight to the target
Filter by model — exact model matching supported
Filter by protocol — Modbus RTU / DL/T 645 / CJ/T 188 / native LoRaWAN, at a glance No need to understand ThinkLink's architecture first. No need to know what EdgeBus is. Whatever device you're holding, start there.

Four Categories Covering Mainstream Retrofitting Scenarios

1. Metering (11 devices)

Covers the most common meter types for building energy monitoring and heating/water metering.

2. Industrial Sensing & Control (12 devices)

Industrial sites are characterized by diverse device types, inconsistent protocols, and harsh environments. The library covers the complete sensing chain from temperature, level, and RPM to oil spill detection, with KC11/KC21 collectors providing a unified RS-485-to-LoRaWAN access layer.

3. Building & Environment (5 devices)

4. Smart Agriculture (1 device, packed with capability)

A single KC21 supports up to 3 soil sensors, covering multi-dimensional farmland sensing in one deployment.

Three Access Paths, One Card Tells the Whole Story

Every device card on the library shows not just the name, model, category, and protocol — it also labels the access path:

And every device card comes with complete integration documentation. Click "View Integration Guide" on any card and you'll jump directly to that device's step-by-step manual, which covers:

Wiring diagrams (which wire goes to which KC collector terminal)
EdgeBus configuration (function codes, register addresses, data formats)
Thing model parsing scripts (pre-written JS parsing logic)
Parameter configuration tables (upload interval, read interval, COV thresholds, slave address)
Key caveats (e.g., DL/T 645's +0x33 offset encoding, CZ580's register unlock command)

More Than a List — It's an Integration Decision Tool

The library's value goes beyond "looking things up" — it helps integrators make technical decisions:

Scenario 1: A client says "We have Acrel ADW2xx meters and want energy monitoring."
→ Search the library → Confirm Modbus RTU protocol → Open the integration guide → Learn that 1 KC21 handles 1 ADW2xx with 4 circuits uplinked independently → Assess feasibility in under 10 minutes.

Scenario 2: A heating retrofit project has Jingquan LXSY-15E cold water meters on site.
→ Search "CJ188" → Confirm KC22 + M-Bus + EdgeBus access → The guide provides complete frame format, data identifiers, and thing model parsing → No need to dig through the CJ/T 188 national standard.

Scenario 3: Comparing a weighing transmitter vs. ultrasonic level sensor for the right fit.
→ Search both devices → Compare accuracy, response time, power requirements, and integration complexity from the documentation → Make an informed selection based on actual parameters.

A Growing Device Ecosystem

ThinkLink's device library is not static. Every time a new device is validated for integration, its documentation is added. The library currently covers:

Protocols: Modbus RTU, DL/T 645-2007, CJ/T 188-2004, native LoRaWAN
Collectors: KC11 (220 VAC powered, Class C), KC21 (battery powered, IP65), KC22 (M-Bus dedicated)
Brands: Schneider Electric, Acrel, ZENNER, Huizhong, Elitech, Renke, Zhuowen, Disen, Dianyingpu, Shenling, GXHY, Tianwei, Ringder, and more

If you have a device not yet listed, ThinkLink's EdgeBus framework supports rapid adaptation. Using EBHelper's JSON configuration or EBSDK's TypeScript scripting, most Modbus RTU devices can be protocol-adapted and added to the library within 30 minutes.

Conclusion

The ThinkLink Integrated Device Library is more than the number "29 verified devices." Its real value lies in:

Lowering the technical evaluation barrier — integrators don't need to become LoRaWAN experts first; just look up the device by name to know if it works
Shortening project startup time — the complete path from wiring to data-on-platform is already documented for every device
Eliminating repeated trial-and-error — DL/T 645 offset encoding, M-Bus parity settings, sensor-specific unlock commands — all battle-tested knowledge is baked into the docs, no need to rediscover it on every project Start from the device, not the platform. That's ThinkLink's answer to the IoT retrofit market.

GDI52x New Industrial Indoor LoRaWAN Gateway Released: Simplifying Reliable IoT Connectivity

manthink — Fri, 10 Jul 2026 07:37:46 +0000

With the rapid development of industrial digitalization, smart buildings, and energy management systems, more and more devices need to be connected to IoT platforms.

From environmental sensors and smart meters to industrial instruments and automation equipment, massive amounts of field data need to be collected, transmitted, and managed efficiently.

However, real-world IoT deployments often face several challenges:

Complex wiring and high installation costs;
Legacy equipment without network connectivity;
Harsh environments requiring reliable hardware;
Different projects requiring flexible platform integration.

To address these challenges, ManThink introduces the GDI52x Industrial Indoor LoRaWAN Gateway, a next-generation gateway designed for reliable IoT connectivity in industrial and commercial applications.

GDI52x combines LoRaWAN wireless connectivity, RS485 wired device integration, flexible power options, and edge computing capabilities to provide a complete and scalable IoT access solution.

Industrial Aluminum Alloy Design for Reliable Long-Term Operation

In industrial IoT applications, gateway equipment needs to operate continuously and reliably under different environmental conditions.

The GDI52x adopts an industrial-grade aluminum alloy enclosure, providing enhanced mechanical strength, improved heat dissipation, and a professional industrial appearance.

The robust enclosure design makes GDI52x suitable for:

Industrial equipment rooms;
Smart building infrastructure;
Control cabinets;
Commercial IoT deployments.

With a durable hardware design, GDI52x provides a stable foundation for long-term IoT operation.

High-Performance LoRaWAN Connectivity for Large-Scale IoT Deployment

As a professional LoRaWAN gateway, GDI52x provides reliable wireless connectivity for a wide range of low-power IoT devices.

It can connect with:

Temperature and humidity sensors;
Water leakage sensors;
Smart meters;
Door sensors;
Industrial monitoring devices;
Wireless IoT terminals.

GDI52x supports multiple LoRaWAN frequency bands, including CN470, EU868, US902, AU915, AS923, and other regional standards, making it suitable for global IoT deployments.

With powerful LoRa processing capability, GDI52x supports multi-channel concurrent communication and provides reliable data collection for large-scale IoT networks.

Wireless and Wired Integration with Built-in RS485 Interface

Many industrial and building automation systems already have large numbers of RS485 / Modbus devices installed.

These devices are reliable and widely used, but they often lack direct connectivity to modern IoT platforms.

To simplify digital transformation, GDI52x integrates an RS485 communication interface.

Through RS485, users can connect:

Smart energy meters;
Industrial instruments;
PLC systems;
Building automation devices;
Existing Modbus RTU equipment.

By combining LoRaWAN wireless communication and RS485 wired integration, GDI52x enables seamless connection between new IoT devices and existing infrastructure.

This allows enterprises to upgrade existing systems without replacing large amounts of installed equipment.

Flexible Power Supply for Different Deployment Environments

Different IoT projects have different power requirements.

GDI52x supports DC 5-24V wide voltage input, as well as multiple power options including POE and Type-C.

This flexible design allows deployment in:

Industrial control cabinets;
Electrical rooms;
Building management systems;
Smart facility environments.

Simplified installation helps reduce project deployment time and maintenance costs.

Multiple Communication Options and Platform Compatibility

GDI52x supports multiple network backhaul methods:

Ethernet;
WiFi;
4G.

Whether deployed in a connected enterprise network or a remote location without wired infrastructure, GDI52x provides flexible communication options.

The gateway supports mainstream LoRaWAN ecosystems and protocols, including:

ThinkLink;
ChirpStack;
The Things Network (TTN);
Basic Station;
GWMP.

Users can select cloud platforms, private deployments, or local management solutions according to project requirements.

Edge Computing Capability for Smarter IoT Management

Beyond being a LoRaWAN gateway, GDI52x also supports built-in ThinkLink edge capabilities.

The gateway can provide:

Data processing;
Device management;
Historical data storage;
Dashboard visualization;
Data model management.

This enables users to build complete IoT solutions from device connection to data management and intelligent applications.

By reducing system complexity, GDI52x helps enterprises accelerate IoT deployment.

Applications Across Multiple Industries

Smart Buildings

Applications include:

Environmental monitoring;
Water leakage detection;
Energy management;
Facility monitoring.

Industrial IoT

Applications include:

Equipment monitoring;
Industrial data acquisition;
Remote maintenance.

Smart Property Management

Applications include:

Basement monitoring;
Public facility management;
Remote operation and maintenance.

Energy Management

Applications include:

Smart meter data collection;
Energy analysis;
Digital energy management.

GDI52x

Industrial Indoor LoRaWAN Gateway for the Next Generation of IoT Connectivity

Connect wireless devices.

Integrate legacy systems.

Build smarter IoT applications.

ManThink continues to provide complete IoT solutions based on LoRaWAN, edge computing, and IoT platforms, helping enterprises build reliable and scalable digital systems.

GDI52x — Making IoT Connectivity Simpler, More Flexible, and More Reliable.

Smart Building IoT Retrofit Case for a Power Company Office Building

manthink — Thu, 02 Jul 2026 08:44:34 +0000

1. Project Background

The office building includes multiple subsystems:

HVAC and chilled/hot water systems
Electrical distribution rooms
Office environments across multiple floors
Plumbing and drainage systems

Existing issues:

Environmental data collected manually
Hidden risks such as leakage are not detectable in real time
Systems operate in isolation without unified integration

2. System Objectives

The goal is to build a low-maintenance, scalable monitoring system enabling:

Real-time environmental sensing
Infrastructure risk detection
Unified data integration
Event-based alerting

3. System Architecture

Built on ThinkLink, the system consists of four layers:

1. Sensor Layer

Temperature & humidity sensors
Pipe temperature sensors
Rope-type water leakage sensors

2. Edge Access Layer (DIN-rail DTU)

Multi-sensor data aggregation
Protocol conversion and normalization
Local anomaly detection (e.g., water leakage)
Offline buffering and retransmission

3. LoRaWAN Network Layer

Based on LoRaWAN:

Multi-floor building coverage
Low-power long-term operation
Reduced cabling complexity
Suitable for harsh indoor environments

4. ThinkLink Platform Layer

Device management
Real-time visualization
Alarm and event handling
Historical data analytics

4. Results

Early detection of water leakage events
Visibility into HVAC pipeline conditions
Continuous environmental monitoring
Shift from inspection-based to event-driven maintenance

5. Key Takeaway

The value of the system lies not in adding sensors, but in restructuring the monitoring logic:

From fragmented systems → unified platform
From manual inspection → automated sensing
From reactive maintenance → real-time alerting
From experience-based → data-driven operations

End-to-End IoT Solution: A Full-Stack LoRaWAN Architecture from Sensors to Platform

manthink — Mon, 22 Jun 2026 03:35:37 +0000

In traditional IoT deployments, system architecture is often fragmented: sensor vendors provide devices, communication modules require third-party integration, and platform systems must repeatedly adapt protocols and data models. This fragmented approach leads to long deployment cycles, high integration costs, and complex on-site commissioning.

ManThink has developed a true full-stack IoT product ecosystem based on years of experience in LoRaWAN and industrial IoT, covering the entire chain from edge sensing to cloud applications.

We redefine IoT architecture through a four-layer structure:

1. Sensing Layer: Multi-Protocol Sensor System

We provide a wide range of industrial and smart city sensors, including:

Temperature, humidity, water leak, level, and pressure sensors
Utility metering devices (electricity, water, gas meters)
Digital input, analog input, and pulse signal acquisition
Industrial equipment status monitoring interfaces

These sensors support both wired and wireless integration, enabling seamless retrofit of legacy systems with minimal rewiring.

2. Edge Access Layer: DTU Data Acquisition Units (KC / KS Series)

Between field devices and the network, we provide standardized DTU gateways:

RS485 / Modbus / M-Bus / pulse / 4–20mA support
LoRaWAN wireless transmission
Embedded EdgeBus edge computing engine
Local protocol parsing and preprocessing

The DTU layer transforms heterogeneous devices into unified data models and performs edge-level intelligence, significantly reducing cloud-side integration complexity.

3. Network Layer: LoRaWAN Gateway System

We offer indoor and outdoor LoRaWAN gateway solutions:

Multi-channel concurrent reception
4G / Ethernet / WiFi backhaul
Deployable in buildings, campuses, and city-scale networks
Compatible with ChirpStack and private network servers

Gateways serve not only as communication nodes but also as critical infrastructure for reliable and scalable IoT connectivity.

4. Platform Layer: ThinkLink IoT Platform

Based on the ThinkLink platform, we provide a unified data and application layer:

Device lifecycle management
Data ingestion, storage, and visualization
Rule engine and alert system
MQTT and API-based bidirectional communication
Rapid development of industry applications (smart buildings, energy, industry)

ThinkLink transforms raw device data into actionable business intelligence.

Key Advantages

Full-stack integrated delivery from sensors to cloud
Seamless retrofit for legacy industrial systems
Edge + cloud collaborative architecture
Reduced integration time and deployment cost
Scalable architecture for city and enterprise deployments

Application Scenarios

Smart buildings and facility management
Industrial remote monitoring
Energy, water, and gas metering systems
Urban infrastructure monitoring
Factory digital transformation

Conclusion

As IoT and LoRaWAN adoption accelerates, system integration capability becomes a decisive factor for project success.

ManThink delivers a unified full-stack architecture that integrates sensing, connectivity, and platform management into one cohesive ecosystem—enabling fast, scalable, and repeatable IoT deployments.

We welcome sensor manufacturers, system integrators, and solution providers to collaborate with us in accelerating intelligent infrastructure transformation.

KS32 LoRaWAN Dry Contact Collector Industrial Wireless IO Solution for Legacy Signal Acquisition

manthink — Thu, 18 Jun 2026 07:34:05 +0000

1. Overview

KS32 is a LoRaWAN-based dry contact input acquisition device designed for industrial and infrastructure monitoring applications. It provides 6-channel digital input (DI) interfaces, enabling direct acquisition of dry contact signals from field devices and transmitting status data over LoRaWAN networks.

The device is designed to address a common challenge in industrial retrofit scenarios:

How to reliably collect distributed dry contact signals without rewiring or PLC expansion.

KS32 enables wireless acquisition of ON/OFF status signals from legacy equipment and integrates them into modern IoT platforms such as ThinkLink, ChirpStack, and The Things Network (TTN).

2. Key Features

6-channel dry contact (DI) input interface
LoRaWAN Class A communication protocol
Support for multiple frequency bands (CN470 / EU433 / EU868 / AS923 / AU915 / US915)
Built-in 10800mAh lithium battery, up to 6 years battery life
IP65 protection rating for industrial and outdoor environments
Event-driven uplink and periodic reporting mechanism
Compatible with ThinkLink, ChirpStack, and TTN network servers

3. System Architecture

KS32 operates as a wireless edge acquisition node in a standard LoRaWAN network architecture:

Field Dry Contact Devices
↓
KS32
↓ (LoRaWAN)
LoRaWAN Gateway
↓
Network Server (ThinkLink / ChirpStack / TTN)
↓
Application Layer (SCADA / Dashboard / API / Cloud System)

This architecture eliminates the need for traditional wired IO extensions while maintaining compatibility with existing industrial systems.

4. Working Principle

4.1 Dry Contact Acquisition

KS32 supports 6 independent digital input channels. Each channel continuously monitors the state of an external dry contact circuit.

Logic “0”: contact closed
Logic “1”: contact open

State transitions are recorded locally and transmitted to the network server.

4.2 Event-Driven and Periodic Reporting

KS32 supports two uplink modes:

Event-triggered reporting: uplink is generated immediately when any DI state changes
Periodic heartbeat reporting: uplink is sent at a configurable interval when no event occurs

The default reporting interval is configurable via network server commands.

4.3 Signal Filtering and Stability Control

To ensure reliability in industrial environments, KS32 implements:

Pulse width filtering to suppress electrical noise and false triggering
Throttling window control to prevent uplink storms in high-frequency switching scenarios

These mechanisms improve data stability in noisy electrical environments.

5. Typical Applications

KS32 is designed for industrial retrofit and distributed signal acquisition scenarios, including but not limited to:

Pump Station Monitoring

Pump running status detection
Fault alarm signal acquisition
Valve open/close feedback

Building Automation Systems

Door and cabinet monitoring
Alarm system integration
HVAC system status feedback

Utility Metering Systems

Water meter pulse output acquisition
Gas meter pulse signal monitoring
Legacy meter digital signal conversion

Industrial Equipment Monitoring

Motor run/stop status
Production line signal collection
Remote equipment status monitoring

6. Installation and Deployment

KS32 is designed for wall-mounted installation with simplified deployment steps:

Fixed installation using mounting backplate
No external power wiring required (battery-powered design)
LoRaWAN network join via OTAA/ABP modes
Configuration via network server downlink commands

7. Value Proposition

KS32 provides a dedicated wireless IO layer for industrial digitalization by:

Eliminating long-distance IO cabling requirements
Enabling rapid retrofit of legacy equipment
Reducing deployment cost in distributed signal systems
Supporting scalable IoT integration through LoRaWAN infrastructure

It acts as a bridge between traditional dry contact systems and modern IoT platforms.

8. Conclusion

KS32 is designed to simplify industrial signal acquisition in retrofit environments. By converting dry contact signals into standardized LoRaWAN data, it enables reliable, low-power, and scalable integration of legacy equipment into IoT systems.

How to Quickly Connect Traditional RS485 Devices to a LoRaWAN Network

manthink — Tue, 16 Jun 2026 10:08:17 +0000

RS485 and Modbus RTU remain widely used in industrial automation, building management, energy monitoring, and smart utility projects. While these devices are reliable and cost-effective, they often face challenges when organizations attempt to integrate them into modern IoT systems. Issues such as extensive cabling, high installation costs, and limited remote management capabilities can slow down digital transformation efforts. This article explains how LoRaWAN DTUs, LoRaWAN gateways, and the ThinkLink platform can help connect traditional RS485 devices to an IoT network quickly and efficiently.

Why Are So Many Devices Still Using RS485?

RS485 is one of the most widely adopted communication interfaces in industrial environments.

Common RS485-enabled devices include:

Electricity meters
Water meters
Heat meters
Flow meters
PLCs
Variable frequency drives
Environmental monitoring devices
Industrial controllers

RS485 offers excellent stability, strong anti-interference performance, and low deployment costs, making it a long-term industry standard.

In addition, many RS485 devices support the Modbus RTU protocol, simplifying data communication and integration.

However, as more organizations pursue digital transformation initiatives, connecting these devices to cloud platforms and remote monitoring systems has become increasingly important.

Challenges of Traditional RS485 Networks

A typical wired architecture looks like this:

RS485 Device

↓

Data Collector

↓

Industrial Switch

↓

Server

↓

Management Platform

Although reliable, this approach presents several challenges.

High Cabling Costs

Devices located across multiple floors, buildings, or industrial zones require significant amounts of communication cabling.

Installation expenses often include:

Communication cables
Cable trays
Conduits
Labor costs

For large projects, communication infrastructure can become a major cost component.

Complex Retrofit Projects

Many factories and commercial buildings are already operational.

Installing new communication lines may require production interruptions or construction work in active areas.

Limited Scalability

Adding new monitoring points often requires additional wiring and engineering work.

As the network grows, maintenance becomes more complicated.

Limited Remote Accessibility

Traditional RS485 networks are designed primarily for local communication.

Additional systems are usually required to enable cloud connectivity and remote monitoring.

How LoRaWAN Enables Wireless Connectivity for RS485 Devices

LoRaWAN is a low-power wide-area networking technology designed for long-range and low-cost communication.

By using a LoRaWAN DTU, RS485 device data can be collected, converted, and transmitted wirelessly.

The overall architecture is:

RS485 Device

↓

LoRaWAN DTU

↓

LoRaWAN Gateway

↓

LoRaWAN Network Server

↓

ThinkLink Platform

↓

PC, Mobile App, or Third-Party System

This approach eliminates the need for extensive communication cabling while providing reliable connectivity.

The Role of a LoRaWAN DTU

Data Collection

The DTU reads data directly from RS485 devices.

Supported protocols typically include:

Modbus RTU
Standard serial communication protocols
Custom protocols

Protocol Conversion

The DTU converts device data into a LoRaWAN-compatible format for wireless transmission.

Wireless Communication

Collected data is transmitted through the LoRaWAN network to a gateway.

This enables communication across large facilities, industrial sites, and commercial buildings.

Remote Management

When integrated with the ThinkLink platform, users can access:

Real-time monitoring
Historical data storage
Alarm management
Visualization dashboards
Remote maintenance capabilities

Typical Application Scenarios

Remote Electricity Meter Reading

Many smart electricity meters provide RS485 interfaces.

Using a LoRaWAN DTU, users can remotely monitor:

Energy consumption
Voltage
Current
Power usage
Peak and off-peak consumption

without manual inspections.

Pump Station Monitoring

Water supply and wastewater facilities often contain distributed pump stations.

LoRaWAN connectivity enables monitoring of:

Pressure
Flow rate
Liquid level
Equipment operating status

while supporting automatic alarm notifications.

PLC Data Collection and Cloud Integration

Industrial facilities often rely on PLC-based control systems.

A LoRaWAN DTU can collect PLC register data and send it to the cloud without modifying the existing control infrastructure.

Building Energy Management

Commercial buildings and industrial parks can centrally collect data from:

Electricity meters
Water meters
Heat meters
HVAC systems

This data can then be analyzed through the ThinkLink platform to support energy efficiency initiatives.

Why Are More Projects Choosing LoRaWAN?

Lower Deployment Costs

Wireless communication significantly reduces cabling and installation expenses.

Preserve Existing Investments

Existing RS485 devices can remain in service.

Wide Coverage

A single LoRaWAN gateway can often cover an entire building, campus, or industrial site.

Easy Expansion

New devices can be added without redesigning communication infrastructure.

Simplified Maintenance

Centralized device management reduces operational workload.

Conclusion

For industrial facilities, smart buildings, and energy management projects that already rely on RS485 devices, LoRaWAN provides an efficient and cost-effective modernization path.

By combining LoRaWAN DTUs, LoRaWAN gateways, and the ThinkLink platform, organizations can enable remote monitoring, data collection, and intelligent management without replacing existing equipment, accelerating their Industrial IoT and digital transformation initiatives.