Choosing Your First LoRaWAN Gateway

Everything else in this LoRaWAN series is software. ChirpStack runs on February. MQTT runs on February. Home Assistant runs on a Pi. The data pipeline, the dashboards, the automation — all of that is configuration and patience. The gateway is the one piece of dedicated hardware the whole thing depends on, and it is worth thinking about properly before buying.

This article is about what I am looking for and why, not a hands-on review. I do not have a gateway yet. When I do, and when it is talking to ChirpStack and I have an opinion about whether the thing is actually any good, I will write that article too. For now: the decision-making process.

What a gateway actually does

Before getting into hardware, it is worth being precise about the gateway’s role, because it is both simpler and more limited than people often expect.

A LoRaWAN gateway is a radio receiver and forwarder. It listens on multiple LoRa channels simultaneously using a concentrator chip, picks up any LoRa packets in range, and forwards them over IP to the network server. That is it. It does not know which devices belong to you. It does not decrypt anything. It does not make decisions about the data. It is a dumb pipe between the radio frequency world and the IP world.

The intelligence lives in ChirpStack: authenticating devices, deduplicating packets that arrive from multiple gateways, and routing data to the application layer. The gateway just moves packets.

This matters for hardware selection because it means that the gateway does not need to be powerful. It needs to be reliable, it needs to be stable, and it needs to speak the packet forwarder protocol that ChirpStack expects. Everything else is secondary.

The concentrator chip question

Under the lid of every LoRaWAN gateway is a concentrator chip that handles the actual radio work. The chip generation matters because it determines how many channels the gateway can listen on simultaneously and how efficiently it does so.

The SX1301 was the original concentrator, found in older hardware. It works, but it is a decade old at this point and the hardware built around it tends to be similarly aged.

The SX1302 and SX1303 are the current generation. They are more power-efficient, run cooler, and have better sensitivity. Any gateway bought new today should be running one of these.

For a homelab deployment, 8 channels is more than adequate. The EU868 band uses 8 uplink channels by default, so an 8-channel gateway can hear everything a compliant device sends. 16-channel gateways exist and are useful for very dense deployments, but for a house and a handful of sensors they add cost without adding anything useful.

Indoor versus outdoor

For a first gateway going inside the house, an indoor unit is the right call. Simpler to install, no weatherproofing concerns, and in a residential setting the coverage from a well-placed indoor gateway is typically more than adequate.

The rule of thumb for LoRaWAN range is roughly 2km in dense urban environments and significantly more in open space. A Manchester terraced house with one indoor gateway at Burnage should cover the house itself and most of the garden without any trouble. Whether it reaches into the greenhouse or the further corners of the property depends on what is in between, but for the initial use cases — environmental sensors, door contacts, basic monitoring — an indoor gateway positioned centrally should be fine.

An outdoor gateway becomes interesting later, once the indoor deployment is working and the question of range becomes real rather than theoretical. The Lighthouse site is a candidate for an outdoor unit at some point, but that is a future problem.

ChirpStack compatibility

Not all gateways integrate cleanly with a self-hosted ChirpStack instance. Some are designed primarily for cloud-managed deployments and make connecting to a local network server unnecessarily complicated. The ChirpStack documentation maintains an explicit hardware support list, and cross-referencing against it before buying is a sensible step.

The two protocols that matter here are the Semtech UDP Packet Forwarder and Basics Station. ChirpStack supports both. Most modern gateways support both too, but it is worth checking. Basics Station is the current preferred approach and is more secure by design, using a WebSocket connection with TLS rather than plain UDP. Either will work; Basics Station is the better default if the gateway supports it.

The shortlist

I have narrowed the options down to two RAK WisGate units. RAKwireless are the most homelab-friendly manufacturer in this space: their documentation is thorough, their community is active, both models appear explicitly on ChirpStack’s hardware support list, and they are available from UK distributors at sensible prices.

RAK7268V2 WisGate Edge Lite 2

The indoor option. 8-channel SX1302-based concentrator, Ethernet and Wi-Fi backhaul, WisGateOS 2, explicit ChirpStack v3 and v4 MQTT bridge support. It sits on a desk or mounts on a wall, takes a standard power supply, and is genuinely straightforward to configure. There is an LTE variant (RAK7268CV2) for deployments without reliable wired connectivity, which is not relevant here but good to know the option exists.

This is the one I am most likely to start with.

RAK7289V2 WisGate Edge Pro

The outdoor option, for if the coverage question ever becomes real. IP67 rated, 8 or 16 channels, same WisGateOS 2 and ChirpStack support as the indoor unit, PoE powered, and compatible with RAK’s Battery Plus solar kit for off-grid deployment. More hardware than a first gateway needs, but worth knowing the upgrade path when the time comes.

What I am not buying

A DIY Pi-based gateway is tempting — a Raspberry Pi with a RAK concentrator HAT is cheap, flexible, and well-supported by ChirpStack — but it introduces more moving parts than a first deployment needs. If the gateway goes down, I want to know it is a network or configuration problem, not a Pi SD card issue or a kernel update that broke the concentrator driver. A dedicated gateway unit is more boring and more reliable, and boring and reliable is what I want from the thing that no packet can get through without.

Single-channel gateways also exist, sometimes marketed as starter kits or development hardware. They are not LoRaWAN gateways in any meaningful sense: they can only receive on one channel at a time, which means they miss most of what a compliant LoRaWAN device sends. They are fine for development and testing with a single device in close range, but they are not a foundation to build on. The money is better spent going straight to an 8-channel unit.

The actual decision

The RAK7268V2 is the gateway I am going to buy. The reasons are: it is on the ChirpStack hardware support list, it runs an SX1302 concentrator, it has solid UK availability and documentation, it connects to ChirpStack over MQTT with TLS, and it is an appropriately-scoped piece of kit for a first deployment. Not the cheapest option, not the most powerful option, but the right one for where this project is.

When it is installed and talking to ChirpStack, that article will cover the actual setup rather than the theory of it.