A LoRaWAN sensor network was the answer to gathering readings from a large site without pulling cable to every sensor. These five posts run from cutting an enclosure for the node to data that never showed up on the server.

All five start the same way. The checker reports zero, the gateway stays quiet, the server answers OK every time. The pass signal came first and the problem came after it.
Standing the node up
What has to work before anything goes on the air: a box for three boards, and a gateway that understands what the box is saying.
- LoRaWAN Sensor Node Enclosure - Zero Interference and Still Unbuildable The interference check kept reporting 0 mm3 while assembly failed five times, and it finally cleared a case whose screw bosses had vanished.
- LoRaWAN Sensor Network Join Failure - A Sync Word Behind Total Silence The packet capture showed nothing, not even a CRC error. The cause was one LoRaWAN Public toggle on the gateway - after two modules had already been written off as faulty.
Adding sensors, adding devices
The two problems that arrive once the radio works: the real sensors are on site, and someone asks how many devices will fit.
- LoRaWAN Sensor Network Testing - A Modbus Slave Simulator on a PC A PC program impersonating several slave IDs on one serial port, which is where four contradictions in the vendor protocol document surfaced.
- LoRaWAN Sensor Network Polling - 30 Devices From 42 Seconds to 30 Letting 30 devices transmit on their own forces the interval to five minutes. Server-driven Class C polling that does not wait for replies cut a round to 30 seconds.
The last stretch to the server
After the whole thing started running alone inside the gateway. The radio worked, the sensors worked, and half the data disappeared.
- LoRaWAN Sensor Network Uplink Loss - OK Every Time, Half the Data Gone Sent every five minutes, acknowledged every time, stored once every ten. Three theories built on partial logs were wrong, and a line-by-line comparison of the full record explained everything at once.
What the LoRaWAN sensor network series comes down to
One thing repeats across all five parts. An automated check, a silent radio, and an OK response all look like the absence of a problem, and none of them is evidence.
- A checker reporting zero is not the same as a part you can assemble
- The failures that leave no log are the expensive ones - silence does not record its cause
- Vendor documents contradict themselves, and the simulator built to stand in for hardware becomes the tool that proves it
- An OK on every send does not mean anything was stored, and rules built on partial logs were wrong three times
A pass signal is not evidence. The cause only appeared after the full record was compared line by line.
Contact
- Email: [email protected]
- Instagram: https://www.instagram.com/going.sen/
- Website: https://intosen.com/kr/consult/
Comments
Enter a nickname to leave a comment, or sign in with Google or GitHub.