I built a LoRa analyser because I was sick of guessing
Debugging a LoRa link used to go like this. A node stops reporting. I swap the antenna. I move the gateway. I drop the spreading factor. Something improves, or it doesn’t, and I have no idea why. The band is invisible and every fix is a guess.
So I built the thing I kept wishing I had. LoRaScope is a small radio that listens to the band and shows you what is actually on the air: LoRa, MeshCore and LoRaWAN, with live switching between them. No gateway, no network server, nothing in the path. The radio hears the packet, the box decodes it, and it shows up on a screen.
The product site is lora.dd.com.au. This is the field note version of what it does and why.
What you see
Who is talking, how often, how loud (RSSI and SNR), how busy the channel is and whether the link is healthy. That is the whole point, and it is surprising how much of the guesswork evaporates once you can just look.
For LoRaWAN and MeshCore it reads the headers without any keys. DevAddr, frame counter, port, airtime. You cannot see the payload without the session keys, but you do not need it to find the node that is hogging the channel, or to notice that a device is rejoining every ten minutes. When you do have the keys, it decrypts everything.
Decoding on the box, or in the browser
Plain binary payloads and encrypted ones decode on the device itself and go straight to its screen. That covers the sensors I build and most of what I run into in the field: a few bytes of packed fields, sometimes sealed with a symmetric key.
For anything more involved there is a JavaScript plugin runtime in the browser. You write a small decoder against the live feed, reload, and your packets show up as fields instead of hex. Site-specific formats, odd vendor encodings, a protocol nobody documented. It is the same feed the rest of the dashboard uses, so a plugin’s output goes into the plots and the logs like everything else.
Walking the site
The dashboard is served from the box, so a laptop or a phone on the same WiFi is all you need. But a lot of LoRa problems are about where you are standing, so there is a screen on the device as well.
It also has GPS and a ping test. Walk away from the other end, press ping, and distance, RSSI and SNR come up on the screen and get written to the SD card with the position. A range survey becomes one trip with the box in your hand, and nobody has to sit at the far end reading numbers over the phone.
Everything else gets logged to SD too, raw frames and decoded, and you can browse and plot the captures in the browser afterwards.
The other things I lean on
Bandwidth, duty cycle and airtime per station. That is usually the number you actually need, and it is the one people are most often surprised by.
Channel scanning, so you find out what is where before you pick a frequency. There is a LoRaWAN mode that hunts join requests and uplinks across the sub-band.
Emulation. The box can pretend to be a hub or a repeater so you can test a single node in isolation without touching the field hardware.
Handing it to an agent
Everything the browser can see and do is also exposed over telnet and REST. That was a deliberate choice, and it paid off sooner than I expected.
I had a run of packet corruption on the bench. Rather than sit there reading hex, I gave an AI agent the telnet and REST addresses and let it watch the feed, form a hypothesis, inject a test packet, and look at what came back. It ran that loop on its own and found the fault. The full session is written up on the LoRaScope site: How I let an AI debug my LoRa network.
An analyser you can only look at is a screen. One you can query and drive is an instrument, and that is the difference for anyone who wants to automate their testing.
What building it covered
I am building LoRaScope to sell. I am also building it because it is a compact demonstration of the work I do for clients.
The firmware is C++ on an ESP32. Getting three protocols onto one radio meant pulling apart the binary framing for each and writing decoders that run on a microcontroller. The decrypt path is AES, with the key handling that goes with it. There is a capture store on SD with an API over the top, a web dashboard served from flash, and the telnet and REST surface that makes the agent story possible.
The same skills show up on client work in different clothes: ESP-IDF and Zephyr firmware, LoRa and BLE, binary protocol design and reverse engineering, encryption on constrained devices, device provisioning, and the database and API end that the data lands in.
If you have a flaky mesh, a gateway that hears nothing, or a binary protocol nobody has documented, that is the sort of problem I take on. The LoRa and LoRaWAN work I do is described in more detail here, or just get in touch.