How I let an AI debug my LoRa network
I hit a massive run of packet corruption on a live LoRa network. Frames were arriving mangled, links were flaky, and the usual guesswork — swap the antenna, move the gateway, twiddle the spreading factor — was getting nowhere. So I stopped guessing and put an AI agent on the radio.
This is that session, start to finish. It’s also the reason LoRaScope is built the way it is: not as a screen you stare at, but as an instrument an agent can drive.
Get eyes on the band first
Before the AI could do anything, I needed to see what was actually on the air. I pulled the logs off the analyser and opened the live traffic view.
Every packet on the band was streaming in, fully decoded — RSSI, SNR, source, payload, timestamps. No gateway in the path, no network server; just the one radio listening and the analyser turning raw airtime into readable frames. The corruption was right there in the feed: good frames, then a burst of garbage, then good frames again. A pattern, not random noise.
That’s the prerequisite for any of this. You can’t reason about a fault you can’t see, and you can’t show a fault to an agent if the fault isn’t exposed as data.
Point the AI at the interface
LoRaScope exposes its live feed and its controls over telnet and REST — the same surface a human uses through the browser, but machine-readable. So rather than read the screen myself, I gave the agent the URLs and let it look.
It monitored the live packet stream itself. It queried the capture store for history. It read link health and bandwidth stats as structured data. Then it started doing what agents are good at: forming hypotheses and testing them.
The agent would see a burst of corruption, notice something about the timing or the source, and fire its own pretend transmit — an injected test packet — to see what came back. Did the corruption follow a particular sender? Did it happen on a particular channel? Did a clean injected frame get mangled the same way? It ran that loop — watch, guess, inject, observe — over and over, far faster than I could have by hand.
That’s the bit that matters. Most analysers are observe-only. An agent with observe-only tools can summarise a fault, but it can’t interrogate one. Being able to transmit — to ask the band a question and read the answer — is what turned a passive log review into an active investigation.
Emulate the other end
Halfway through, the suspect shifted from one node to the link itself. To test that I needed to be the other side of the link — without disturbing the field hardware.
This is where Emulate came in. I set the analyser to pretend to be a HUB, then a Repeater, and ran the real node against it. Now the node was talking to me, not to the production hub, and I could characterise the link in isolation. Same radio, same firmware stack, but I controlled both ends.
The corrupted traffic got captured once and replayed as many times as the investigation needed — by me, by the agent, again and again until the pattern was cornered. Reproducible by construction, not “wait for it to happen again.”
What actually closed the loop
I’m not going to pretend the agent solved it in one shot. What it did was something more useful: it held the whole picture at once — the live feed, the capture history, the link stats, the injected test results — and iterated against a captured fault until the cause was obvious. The thing I’d have done with a notepad and a week of site visits, it did in an afternoon, against a fault I’d captured once.
That’s the pitch, really. LoRaScope is the radio-layer tool an agent can drive: monitor, reason, inject, observe, in a loop, autonomously. No gateway required, no proprietary SDK — just telnet and REST, and any agent or script you care to point at it.
If you want the same instrumentation on your site — the analyser itself, or the expertise to wire an agent into your LoRa network — see the analyser, the AI & automation page, or reach out directly.