I started my RARS talk with a radio conversation.
I brought up MeshCore, sent a message over the air, and made contacts with Tony, Finn, and Av. There was no internet in the middle of it. Then I showed a portable repeater built from off-the-shelf parts, tucked into a 3D-printed case with a LiPo battery.
Only after that did I start the slides.
That was the evening’s subject in miniature. MeshCore is interesting as a protocol, but RDUMesh is interesting because people are actually putting the pieces somewhere, powering them, maintaining them, and making the network useful.
Start with the thing that has to work#
Chuck Till had invited me to repeat the mesh-networking presentation I gave at RARSfest. The RARS general membership meeting was on September 8, and I was there to talk about RDUMesh, MeshCore, and the practical work of building a regional mesh.
Live demos are rude in a way that slide decks aren’t. A slide will wait while you find the next bullet. A radio conversation won’t. The equipment has to work, and the explanation has to keep up with what’s happening in the room.
Starting with the radio grounded everything that followed. This wasn’t an abstract diagram about devices that might communicate someday. The audience had just seen a message go out over the local network and come back through actual hardware.
The network is where the work is#
RDUMesh is an informal local community focused on practical mesh networking across the Raleigh-Durham area. I explained the basic promise first: backup messaging that keeps working when the cell network or the internet goes away.
MeshCore gives the network a few distinct jobs. The companion is the device you carry. The repeater is the device that carries traffic farther. Room servers and sensor nodes have more specialized roles. That’s easy enough to say. Operating the network is where the real work is.
Once you get past the radio specifications, the questions get stubbornly physical. Where can a repeater see? Who will keep it powered? What happens when a node goes quiet? How do you fill a coverage gap without turning the channel into noise?
We talked about coverage mapping, war driving, buying and siting advice, repeater maintenance, room servers, sensor etiquette, and the RF tradeoffs that show up as a network grows. A repeater on a map is the visible result of a lot of decisions made before anyone sent a message through it.
That was the part I wanted to make concrete. MeshCore has technical roles and routing behavior, but a working local network is also a community practice. Someone has to build the repeaters. Someone has to put them somewhere useful. Someone has to notice when one stops working.
The other piece of infrastructure was on my shirt#
I wore the DJI Mic 2 transmitter that I’ve been using as a small, practical recorder. Earlier this year, I wrote about the project in “The $59 Voice Recorder That Beats a $159 AI Note-Taker”.
This meeting was the real use of that idea, not a bench test or a staged example. The device recorded while I was giving the talk. I didn’t have to run a second system, babysit a transcription service, or reshape the presentation around the recording.
Afterward, software that runs entirely on my own machine turned the recording into a transcript and notes. The mechanical work happened later, when I was no longer explaining radio routing while also watching a live demonstration.
There is a limit, though. The transcript has no speaker diarization, so it can’t always tell who said what. That’s a gap I’m taking on next: teaching the pipeline to separate the voices, so the review work becomes checking names instead of reconstructing the conversation. I still have to review the result, correct names, resolve ambiguous passages, and decide which details are worth carrying forward. The transcript is source material. Deciding what it means is still my job.
That is a useful boundary. I don’t need the software to pretend it understood the entire room. I need it to preserve enough of the event that I can return to the parts I couldn’t hold on to while I was speaking.
That’s what the recording buys me. I turned the transcript into meeting notes for the key people who couldn’t make it, so they got the talk’s substance without sitting in the room. And the recording is my tuning instrument for the next time I’m invited to give this talk: I can see where the audience leaned in, which parts landed, and which parts I rushed. The questions I answered are the sharpest signal; they show me exactly what needed more explanation, so the next iteration can fix those spots before anyone has to ask.
The talk was about keeping a communication option alive when the cell network or the internet drops out. The recording setup is a quieter piece of local infrastructure, and it solves a related annoyance: the event doesn’t have to vanish just because the room emptied.
By the end of the evening, I’d spoken about repeaters, coverage, power, and the ways people keep a regional network alive. Then the same meeting came back through a local recording path, with its limitations visible rather than hidden behind a polished summary.
The radio carried the talk. The recording lets me go back for the parts I missed while I was busy giving it.