This is the multi-page printable view of this section. Click here to print.
Field notes
2026
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.
Pretend to be the hub: testing a LoRa node in isolation
A node was dropping off the mesh intermittently. The obvious move — pull it, bring it to the bench, test it against the hub — wasn’t available. The hub was live, serving the rest of the site, and pulling that would have taken half the network down with it. So I didn’t. I became the hub.
This is Emulate mode in LoRaScope, and it’s the fastest way I know to test a node without disturbing the network it lives in.
The problem with testing in place
Passive capture — just listening to the band — tells you what a node is sending and whether it’s getting through. What it can’t tell you is what the node does in response to the hub. Missed acknowledgements, retry storms, join retries, weird downlink behaviour — those only show up when there’s something on the other end answering back. And the one thing answering back in production is the hub you can’t touch.
So you need a second hub. Or you need to be the hub.
Be the hub
Emulate mode turns the analyser into the other end of the link. The same radio that captures traffic can transmit, so I matched the node’s radio profile — sync word, spreading factor, bandwidth, coding rate, frequency — set the analyser’s identity to the hub’s, and started emulating.
Now the node was talking to me. Its uplinks came through decoded in real time, and I could send downlink responses on command. Same radio, same firmware stack, but both ends of the link were under my control. The production hub carried on serving the site, oblivious.
The fault I was chasing only appeared under specific conditions — particular sequences of acks and retries that the node handled badly. In production those sequences happened by chance, maybe once an hour. Emulating, I could reproduce them on demand: send this, withhold that, watch the node’s next move. What was a “wait for it to happen” fault became a “make it happen now” fault.
Emulate a repeater too
It’s not just hubs. Half the time the suspect isn’t either end of a link but the hop in the middle — a repeater. Emulate lets me stand in for the repeater as well: the node talks to me as if I’m the repeater, and I can forward (or deliberately mangle, or drop) frames to see how the node and the far end behave. Great for characterising mesh routing without risking the real mesh.
Why this beats a second radio on a laptop
You can absolutely test a node with a second LoRa radio and a laptop full of scripts. I’ve done it. It works, and it’s slow. You’re hand-rolling the hub behaviour, hand-decoding the frames, hand-timing the responses. Emulate gives you the hub behaviour and the decoded feed in one tool, and — this is the part that matters to me — the same surface is exposed over telnet and REST. So an agent can drive the emulated hub responses automatically: the node uplinks, the agent reads it, decides what to answer, injects the downlink, watches the result. The watch-guess-inject-observe loop from the AI debugging session works exactly the same way here, just with me (or the agent) playing the other end.
When to reach for it
- A node misbehaves but the hub is production-critical — don’t touch the hub, be the hub.
- You’re bringing up a new node and there’s no hub yet — emulate one to exercise the node end-to-end.
- You suspect a repeater is mangling frames — emulate the repeater and inject deliberately to reproduce it.
- You want to regression-test node firmware against a known set of hub behaviours — capture once, replay forever.
The pattern is the same every time: both ends of the link under your control, the real network undisturbed, and the fault reproducible on demand instead of on luck.
Emulate is part of the Scope analyser, and it’s agent-controllable over telnet and REST — see AI & automation. If you want this kind of isolated, reproducible testing on your site, reach out.