LoRaWAN Gateways and Meshtastic

Why LoRaWAN gateways are important infrastructure, why they are not Meshtastic repeaters, and how MeshAtlas should classify them.

Meshtastic infrastructure is a complete site: radio, antenna, feed line, power, enclosure, mounting, configuration and a plan for maintenance. This guide concentrates on one part of that system while showing how it affects the others. Product availability and firmware support change, so confirm the exact device revision and current documentation before purchasing or installing equipment.

Quick comparison

Option	Type or characteristic	Best use
RAK WisGate	Multi-channel LoRaWAN gateway	Community and commercial IoT
Milesight	Indoor/outdoor gateway families	Managed sensor deployments
Kerlink	Carrier and industrial gateways	Professional networks
Dragino	Accessible gateway products	Small community and DIY IoT
MikroTik LoRa	Router-integrated concentrators	Sites already using MikroTik
Seeed SenseCAP Gateway	Packaged LoRaWAN gateway	Rapid IoT deployment

Same modulation, different network

Meshtastic and LoRaWAN can both use LoRa chirp spread-spectrum radios, but their protocols and network architectures are different. A LoRaWAN end device talks to one or more gateways, which forward received frames to a network server. Meshtastic nodes exchange Meshtastic packets and may relay them through managed flooding. A LoRaWAN gateway does not become a Meshtastic repeater merely because it can hear the same frequency range.

For this part of the installation, write down the assumption, test it at the intended site and retain the result with the node record. Infrastructure becomes reliable through repeatable measurements and maintainable choices, not through a single impressive component.

What a concentrator does

A proper LoRaWAN gateway normally contains a multi-channel concentrator capable of listening to multiple frequencies and spreading factors at once. It timestamps and forwards packets over Ethernet, Wi-Fi or cellular backhaul. The network server handles deduplication, security, device sessions and routing to applications. Meshtastic boards usually contain a single LoRa transceiver and run an entirely different firmware and packet format.

Common gateway families

RAK WisGate, Milesight, Kerlink, Dragino, Seeed SenseCAP and MikroTik LoRa products are common infrastructure families. They range from inexpensive indoor gateways to rugged carrier-grade outdoor devices with cellular failover and remote management. Selection depends on channel plan, regional certification, backhaul, enclosure rating, antenna arrangement and the chosen LoRaWAN network server—not on Meshtastic compatibility.

Can the systems share a site?

Yes. A tower, rooftop, power system and internet connection may host both a LoRaWAN gateway and a Meshtastic node. They should have separate compatible radios and usually separate antennas or a carefully engineered RF system. Because they may transmit in nearby licence-exempt spectrum, airtime and receiver desensitization must be considered. Physical co-location does not create protocol interoperability.

How MeshAtlas should list them

A useful directory should label LoRaWAN gateways separately and record whether they belong to a public community network, a private organization or an unknown operator. Public gateway coordinates may be approximate for security. Listings should identify frequency plan, coverage status and network affiliation where the operator has provided it. They should never promise that a Meshtastic user can connect through that gateway.

Choose the correct technology

Use LoRaWAN for structured sensor fleets, device provisioning and application-server integration. Use Meshtastic for decentralized messaging, position sharing and community mesh operation. Some projects legitimately need both: LoRaWAN gathers water or weather measurements while Meshtastic gives volunteers human communication. The shared LoRa physical layer can simplify site planning, but governance, security and traffic engineering remain separate.

Planning and commissioning

Begin with the purpose, users, expected coverage, legal region, site access and acceptable outage time. Draw the power and RF paths before assembly. Confirm that every radio and antenna is the correct frequency version. Configure a conservative hop limit and telemetry rate, then bench-test power failure and reboot recovery. At the site, test communication in both directions from representative user locations rather than relying only on the signal shown beside the infrastructure node.

Record the hardware model and revision, firmware version, region and modem preset, antenna, coax length, power source, battery chemistry, mounting date and responsible operator. Photograph the finished installation and cable entries. Label anything another maintainer could disconnect. For public or shared sites, avoid publishing exact sensitive coordinates unless the owner has approved it.

Establish a baseline after commissioning: battery high and low values, normal enclosure temperature, typical channel utilization, neighboring nodes heard and several repeatable test paths. Future observations are useful only when they can be compared with healthy behavior. A gradual fall in received signal may indicate water in a connector or a moving antenna long before the node disappears entirely. Store the baseline with the site record and repeat it after any material hardware or firmware change.

Common mistakes

Buying for advertised range or transmit power before surveying terrain and antenna placement.
Ignoring receiver performance, feed-line loss, power noise, condensation or winter energy production.
Using a specialized node role merely because the device is fixed or elevated.
Assuming a vendor enclosure, antenna or maximum output is automatically legal in every country.
Installing equipment that cannot be safely reached, opened, updated or recovered after a failure.

Procurement and standardization

Do not order a fleet from a product title alone. Confirm the exact MCU, LoRa transceiver, supported frequency, antenna connector, board revision and firmware target on a sample unit. The same commercial name may cover regional or hardware variants. Flash the current stable firmware, export a known-good configuration and run the sample continuously before buying more. For an outdoor product, inspect the real gasket, glands, mounting pieces and battery arrangement rather than judging only the radio specification.

Standardization is valuable even when another board is marginally cheaper. A small network that uses one radio platform, one connector family, one battery type and a limited set of fasteners needs fewer spares and fewer field tools. Keep at least one tested replacement for inaccessible or important sites. If a product becomes unavailable, qualify its replacement on the bench and on one non-critical site before changing the rest of the network.

Testing before permanent installation

Run a staged test. First verify programming, charging and recovery on the bench. Next operate the complete assembly outdoors at reachable height through several temperature and weather cycles. Finally test it at the intended site using the intended antenna, cable and power system. Send acknowledged direct messages in both directions and observe neighboring nodes over time. A single successful packet is not evidence of dependable coverage.

Simulate failure while the node is still accessible. Remove input power, partially discharge the battery, interrupt the network connection where relevant and verify that the node returns without manual intervention. Check that a firmware update does not erase the legal region or restore an unsafe power setting. Measure receiver behavior while nearby chargers, network devices and other transmitters are active. Quiet bench conditions can conceal site-generated interference.

Lifecycle and responsible operation

Every installation needs an owner and a retirement plan. Record who may change the configuration, how faults are reported and when the site will be inspected. Remove dead batteries and abandoned hardware instead of leaving them on roofs or hills. Respect property access, protected areas and visual-impact requirements. A community node should have a recognizable name or contact route without exposing personal details unnecessarily.

Review the configuration when firmware, regulation or local network practice changes. More relaying, more telemetry and more internet bridging are not automatically improvements; they consume shared spectrum. Use the minimum traffic and complexity that achieve the site’s purpose. When evidence shows that a node adds collisions or duplicates coverage without benefit, change its role, reduce traffic or relocate it. Good infrastructure is cooperative as well as technically functional.

Sources and further reading

What to read next

This article is technical guidance, not electrical, structural or legal certification. Follow national radio and building rules, equipment instructions and site-owner requirements. Use qualified installers for tower climbing, mains wiring, grounding and lightning-protection work.