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.