LoRaWAN sensor design, from the board to the network server.
A LoRaWAN sensor is more than a board: it needs a radio module, firmware that joins a network, a gateway and a network server, and a company with no radio engineers has to find all four. We designed a four-channel node and ran it through an indoor gateway into a self-hosted ChirpStack server, and one unit is on trial in an operational plant room.
Just want monitoring deployed, not a custom build? See Paqett →
The problem
The usual trouble with a LoRaWAN project is the number of parts that must agree. The module, the gateway software, the network server and the sensor firmware each come from a different source, and a fault can sit in any of them. We would typically set up the whole path ourselves, so that a problem in the radio link is not mistaken for one in the sensor. The decisions we would settle with you include what the sensor must measure, how often it should report, where the gateway can go, how devices are registered on the server and how the data leaves it for your own systems. Those shape the module, the battery and the network design.
LoRaWAN is not always the right radio, and for a project we would also consider NB-IoT and BLE, depending on where the device sits and how its data has to travel. Mechanical and enclosure design would be scoped with you at the start. On the server side we would decide how uplinks are decoded, how a silent device is noticed and how the data is stored and exported, so that your own systems can use it. Gateway placement matters as much as the node, so we would agree where the gateway sits and what it connects through before the node is designed around an assumption about signal. Keys and device identities need care, and we would set out how they are generated, stored and loaded onto devices during production.
What we've built
Four-channel LoRaWAN node, run through an indoor gateway and our own network server
A battery-powered temperature node on a RAK3172 module (STM32WL), reaching an indoor gateway that forwards its uplinks to ChirpStack, with readings stored in a telemetry database on our own server. One unit is on trial; it is not a product, and no fleet or customer sits behind it.
Field trial: a single unit in an operational plant room.
| Layer | What we did | Detail |
|---|---|---|
| Node | A custom PCB carrying the RAK3172 module, four temperature channels and a battery. | Four channels |
| Gateway | An indoor LoRaWAN gateway running Basic Station. | Basic Station into ChirpStack |
| Network server | ChirpStack receives the uplinks, with a telemetry database alongside it, both on a self-hosted server. | |
| Joining | Join attempts back off from 30 s up to 1 h, and to 4 h after 11 h, so a node does not retry constantly while the gateway is out of reach. |
How working with us goes
- 01 Scope We agree what has to be built, where it lives and where the data goes.
- 02 Prototype Working hardware and firmware on your bench, tested against real conditions.
- 03 Pilot A small batch on real sites, with fixes folded back into the design.
- 04 Production Design for manufacture, a production run, and support once it is in the field.
Related
Low-power IoT design ·IoT dashboards and data pipelines ·Legionella monitoring ·Embedded firmware development · All sectors →
Need a LoRaWAN sensor designed?
Custom hardware, firmware and software, from first sketch to production.
Talk to us about your project alessio.grespi@gmail.comWant it deployed, ready to run?
If an existing service might do instead of a new sensor, ask about Paqett, the white-label monitoring company we also run.
See Paqett →