SenseCAP M2: LoRaWAN Mesh Networking with ChirpStack

Why Mesh Networking Solves Real Deployment Problems

The SenseCAP M2 runs ChirpStack Gateway OS—an OpenWrt-based embedded operating system for LoRa gateways. The gateway ships with SenseCAP's factory firmware, but you can flash ChirpStack Gateway OS to enable mesh networking capabilities through the included ChirpStack Gateway Mesh component. This fundamentally changes deployment economics: you can deploy relay gateways that extend LoRaWAN coverage without internet connectivity at every gateway location.

Here's why this matters: solar-powered relay gateways in remote locations forward packets to internet-connected border gateways. No cellular backhaul required. No monthly connectivity fees. Just LoRa-to-LoRa packet relaying. A single border gateway with internet access can coordinate dozens of relay gateways covering terrain where running Ethernet or cellular would be prohibitively expensive.

Hardware: SenseCAP M2 Multi-Platform Gateway

The SenseCAP M2 uses an MT7628 processor paired with the Semtech SX1302 baseband chip—the latest generation LoRa concentrator. It ships with a 3dBi antenna that's upgradeable to higher gain options when you need extended range. The gateway supports Power over Ethernet (PoE), which means a single Ethernet cable provides both network connectivity and power—no separate power supply needed, simplifying installations significantly.

Connectivity options include Ethernet and WiFi, with optional 4G cellular backhaul if you need it. The gateway supports all standard LoRaWAN frequency plans: EU868, US915, AS923, and IN865.

Why This Gateway Excels as Border Gateway: The SenseCAP M2 works particularly well as a border gateway (the internet-connected hub) in mesh networks. PoE support enables clean installations—mount it anywhere with Ethernet access and it handles all the mesh coordination. ChirpStack Gateway OS v4.7.0+ officially supports the SenseCAP M2, and flashing is straightforward through the web interface. The hardware costs significantly less than industrial gateways while maintaining decent build quality for production deployments.

How ChirpStack Gateway Mesh Actually Works

ChirpStack Gateway Mesh extends LoRaWAN coverage by adding relay gateways that don't need internet connections. These relays forward uplink and downlink packets between your end-devices and border gateways, creating multi-hop coverage across terrain where traditional gateway deployment would be impractical or expensive.

Border Gateway Role: The border gateway runs ChirpStack Gateway OS and maintains internet connectivity. It handles mesh protocol encapsulation and de-encapsulation, forwards LoRaWAN packets to the ChirpStack network server, and acts as the mesh network termination point. The SenseCAP M2 excels in this role because PoE simplifies installation and provides reliable backhaul connectivity.

Relay Gateway Role: Relay gateways require no internet connection. They can run on solar power or batteries in remote locations. Their job is simple: relay packets between end-devices and the border gateway (or other relays in the chain). They run the same ChirpStack Gateway Mesh component but with relay configuration instead of border gateway configuration.

Multi-Hop Capability: The system supports up to 8 hops between an end-device and the border gateway. Each relay in the chain increments the hop count and recalculates the message integrity code (MIC) to maintain security. This means a packet can traverse through 8 relay gateways before reaching the internet-connected border gateway—enough for extensive coverage across large deployments.

How Packets Flow Through the Mesh:

Uplink packets follow this path: End-device transmits a LoRaWAN packet. Relay gateway receives it and encapsulates the packet with mesh protocol headers (adding 14 bytes of overhead). The relay forwards it to the next hop—either another relay or the border gateway. Eventually the border gateway receives the packet, de-encapsulates it back to standard LoRaWAN format, and forwards it to the ChirpStack network server.

Downlink packets reverse this process. The network server sends a downlink to the border gateway, which encapsulates it with mesh headers and forwards through the relay chain until it reaches the end-device.

Security Considerations: The mesh uses an AES128 key shared across all participating gateways. Each packet includes a message integrity code (MIC) for validation. Relays and border gateways must be configured with the same key to participate in the mesh network—gateways with incorrect keys cannot join or relay packets.

No End-Device Firmware Changes: ChirpStack Gateway Mesh operates entirely at the gateway level. Your end-devices use standard LoRaWAN protocol and have no awareness that relays exist in the path. This means existing LoRaWAN devices work without any firmware modifications—you're extending network infrastructure, not modifying device behavior.

Installing ChirpStack Gateway OS on SenseCAP M2

ChirpStack Gateway OS v4.7.0+ bundles everything you need: ChirpStack v4.11.1, ChirpStack Concentratord v4.4.7, ChirpStack Gateway Mesh v4.0.1, OpenWrt v24.10.0, and the LuCI web interface for configuration. This integrated stack means you're not piecing together components from different sources.

Installation Steps:

First, download the ChirpStack Gateway OS image for SenseCAP M2 from the chirpstack.io downloads page.

Access your SenseCAP M2 web interface—it defaults to DHCP for IP assignment, or use the static fallback IP 192.168.168.1. Navigate to System > Backup/Flash Firmware and upload the ChirpStack Gateway OS image.

Critical step: Deselect "Keep settings and retain current configuration" before flashing. You want a clean install, not a configuration merge that could cause problems. Click Continue and wait approximately 5-10 minutes for the flash and reboot process.

After the gateway reboots, access it via SSH or the web interface for initial configuration. Choose Border Gateway mode (internet-connected) or Relay Gateway mode (no backhaul). Set the mesh AES128 key—this must match across all gateways in your mesh. Configure your frequency plan and region. For border gateways, configure the network server connection details.

Important notes: You can revert to the original SenseCAP firmware by downloading it from the Seeed GitHub repository and flashing it through the same web interface. However, the SenseCAP M2 version of ChirpStack Gateway OS doesn't include the full ChirpStack network server or Node-RED due to the device's memory constraints—it contains only the gateway components needed for mesh functionality.

Real-World Deployment Scenarios

Remote Agricultural Monitoring: Deploy your border gateway at the main building with internet connectivity. Place relay gateways across fields powered by solar panels. End-devices like soil moisture sensors and weather stations connect to the nearest relay, and packets hop back through the relay chain to the border gateway. Running Ethernet or paying monthly cellular fees to every gateway location would be prohibitively expensive—solar-powered relays eliminate these recurring costs entirely.

Industrial Sites with Coverage Gaps: Metal buildings block LoRa signals effectively. Instead of trying to penetrate metal walls at SF12 (slow data rate, high battery drain for devices), place relay gateways inside buildings. Indoor devices connect to the nearby relay using SF7 (fast, efficient), and the relay-to-border gateway link uses SF12 for the long outdoor hop. This dramatically improves both battery life and reliability.

Urban Network Extensions: Mount your border gateway on a building rooftop to cover the downtown area. Add relay gateways in coverage gaps like underground parking structures, subway stations, or dense urban canyons where tall buildings create dead zones. Relay gateways don't need network connectivity—mount them wherever signal is weak, power them via PoE or solar, and they extend coverage without requiring backhaul infrastructure.

Configuration Examples

Border Gateway (Internet-Connected)

[mesh]
enabled=true
signing_key="your-aes128-key-here"

[mesh.border_gateway]
enabled=true

Network server address configured to point at ChirpStack instance (self-hosted or cloud).

Relay Gateway (No Internet)

[mesh]
enabled=true
signing_key="your-aes128-key-here"

[mesh.relay]
enabled=true

No network server configuration needed. Relay only forwards packets between LoRa interfaces.

Multi-Region Support

ChirpStack Gateway Mesh supports AS923 and IN865 regions as of v4.7.0, in addition to EU868, US915, and other standard LoRaWAN bands.

Performance Considerations

Latency impacts: Each relay hop introduces latency due to LoRa transmission air time and processing delays. If you're building a system where actuators need fast response times (like automated irrigation valves or industrial controls), keep the hop count low. For monitoring applications where data arrives every 10-15 minutes anyway, multi-hop latency won't matter.

Packet overhead: The mesh protocol adds 14 bytes of overhead to each uplink packet for encapsulation headers and message integrity codes. This matters because LoRaWAN already has strict payload size limits that vary by spreading factor and region—SF12 in EU868 allows only 51 bytes of application payload. If you're sending 40-byte sensor payloads through a mesh, you're fine. If you're trying to push 200-byte packets, you'll hit limits.

Relay placement strategy: Relay gateways need line-of-sight or near-line-of-sight to the next hop in the chain. Unlike end-devices that can hide behind obstacles and still communicate via SF12, gateway-to-gateway links carrying aggregated traffic need reliable connectivity. Test coverage thoroughly before permanent installation—place a relay temporarily, verify signal quality to the next hop, then mount it permanently.

Power consumption for solar deployments: For solar-powered relay installations, size your panel and battery system for worst-case scenarios rather than average conditions. This means accounting for winter sun angles, shorter days, and consecutive cloudy periods. Undersized solar systems work fine in summer but fail during winter when you need them most. Work with solar power specialists to size components based on your specific latitude, climate, and gateway power requirements.

Comparison to Alternatives

Cellular backhaul: Adding 4G connectivity to every gateway location solves the backhaul problem but introduces monthly data fees that compound across your deployment. Ten gateways with cellular backhaul means ten monthly SIM card bills forever. Cellular also requires signal availability—rural areas often lack reliable coverage, defeating the purpose. Power consumption increases significantly with cellular modems running continuously compared to LoRa-only relays. For deployments where some locations have Ethernet and others don't, mesh relays eliminate recurring costs entirely.

Proprietary LoRaWAN repeaters: Vendor-specific repeater solutions exist but lock you into proprietary protocols and hardware. Most support only single-hop or limited multi-hop configurations, while ChirpStack Gateway Mesh handles up to 8 hops. The hardware costs more because you're buying specialized equipment instead of commodity gateways running open-source firmware. When the vendor discontinues the product line or raises prices, you're stuck.

Point-to-point backhaul (WiFi, microwave): WiFi bridges or microwave links provide high-bandwidth backhaul but require precise aiming and clear line-of-sight. Installation complexity increases significantly—you're aligning directional antennas and dealing with interference. LoRa relays use omnidirectional antennas that don't require aiming. Quality point-to-point gear typically costs more than commodity LoRaWAN gateways configured as relays. For simple packet forwarding where bandwidth isn't a concern, LoRa mesh wins on simplicity and cost.

Limitations

Mesh doesn't eliminate internet connectivity entirely: Border gateways still require internet backhaul to forward packets to the network server. Mesh networking extends coverage from those internet-connected points—it doesn't magically make internet access unnecessary. You're reducing the number of backhaul connections needed, not eliminating them completely.

8-hop maximum chain length: The protocol supports up to 8 relay hops between an end-device and the border gateway. For very large deployments spanning dozens of kilometers, you'll need to deploy multiple border gateways with internet connections rather than building extremely long relay chains. Plan your topology with this constraint in mind.

No quality-of-service or traffic prioritization: The mesh treats all packets equally—there's no mechanism to prioritize critical traffic over routine monitoring data. If you're running high-traffic deployments where hundreds of devices transmit frequently, relay gateways can become congestion points. The system works best for typical monitoring applications where devices transmit every few minutes, not real-time streaming scenarios.

Duty cycle regulations still apply: European ISM bands impose 1% duty cycle limits on most channels. Heavy relay traffic forwarding packets through the mesh counts against these limits. A relay gateway forwarding traffic from 50 end-devices can hit duty cycle restrictions if those devices transmit too frequently. The relay gateway itself becomes the bottleneck, not because of processing power, but because of legal transmission time limits.

What I Provide

Services:

• Mesh network design and topology planning for your terrain and coverage requirements
• Gateway placement optimization based on RF propagation modeling
• ChirpStack infrastructure setup (self-hosted or cloud deployment)
• Solar power system sizing for remote relay installations
• Security configuration and network server integration
• Performance testing and troubleshooting

You own everything:

• Complete source code for any custom integrations or data pipelines
• Self-hosted infrastructure (or cloud if you prefer)
• All configuration files and documentation
• No ongoing licensing fees or vendor lock-in

Hardware (you source):

• LoRaWAN gateways suitable for mesh deployment
• Solar panels and battery systems for relay gateways
• Outdoor enclosures and mounting hardware
• Antennas matched to your coverage requirements

I don't sell hardware. I specify what you need based on your deployment requirements, help you source it from distributors, and configure the open-source software stack to build a reliable mesh network that solves your coverage problems.

Open Source Advantages

ChirpStack Gateway OS is fully open source—you can inspect every line of code running on your gateways. Need to modify behavior for a specific requirement? Fork the repository and customize it. No vendor permission required, no licensing negotiations, no waiting for feature requests to be prioritized.

Open source also means no vendor lock-in. Proprietary gateway vendors force firmware updates, deprecate features, or raise licensing fees. With ChirpStack, you control when (or if) to upgrade. The software keeps working indefinitely because you have the source code. If the project maintainers change direction, the community can fork and continue development.

No per-gateway licensing fees matter at scale. Deploy 10 gateways or 1,000—the cost remains the same. Proprietary systems charge per gateway or per message, turning successful deployments into escalating expenses. ChirpStack charges nothing beyond the server infrastructure you'd need anyway.

The SenseCAP M2 hardware officially supports open-source firmware. Seeed maintains compatibility with ChirpStack Gateway OS releases, publishing updated device support files when new hardware revisions ship. This isn't a hack or an unofficial port—it's a supported configuration.

This combination delivers full control: open hardware platform running open-source software, deployed in a mesh topology that eliminates recurring backhaul costs. You own the entire stack from hardware to firmware to network server.