--- title: Will Renaming My Node Every Hour Break the Mesh? The Airtime Math description: A node named after the live temperature would add about 49 s of mesh airtime a day, by my math. The radio rebooted on every rename, so I shelved it. image: https://willcurran.com/hubfs/will-curran-brand/node-rename-airtime-featured.png --- [Skip to content](https://willcurran.com/blog/node-rename-airtime-math#main) [Will Curran](https://willcurran.com/) [Home](https://willcurran.com/) [Portfolio](https://willcurran.com/portfolio) [Press](https://willcurran.com/media) [Blog](https://willcurran.com/blog) [Favorites](https://willcurran.com/favorites) [Speaking](https://willcurran.com/speaking) [Consulting](https://willcurran.com/consult) [Hire Will](https://willcurran.com/hire) [Writing](https://willcurran.com/blog) Mesh & radio — Will Renaming My Node Every Hour Break the Mesh? The Airtime Math [Subscribe](https://willcurran.com/blog/subscribe) Mesh & radio # Will Renaming My Node Every Hour Break the Mesh? The Airtime Math I wanted a mesh node whose name showed the live temperature, so I did the airtime math first: about 49 extra seconds a day by my estimate, less than one hourly weather post. The math said yes, but the firmware dropped the first rename and rebooted the node on every one, so I ... ![](https://willcurran.com/hs-fs/hubfs/will-curran-brand/will-curran-avatar.jpg?width=44&height=44&name=will-curran-avatar.jpg) Will Curran Aug 3, 2026 · 7 min read On this page ![An abstract node name tag reading WX, 110 degrees and a sun symbol, with a short marigold airtime bar labelled about 0.4 seconds, beside the title Do the airtime math.](https://willcurran.com/hs-fs/hubfs/will-curran-brand/node-rename-airtime-featured.png?width=1600&height=900&name=node-rename-airtime-featured.png) In August I wanted a weather node on the mesh whose name was the weather: something like `WX Station - 110°`, with a little sky emoji as its short name. Renaming a node puts a packet on the air, so before I built it I did the math. Renaming on every one-degree change, worst case once an hour, would add about 49 seconds of airtime a day across the region by my estimate, or 0.057% of the day. The math said yes. I ran it for about two hours one evening and shelved it the same night. ## The worry came first When I wrote the idea down, the second line was: "Hopefully it doesn't blow up the mesh haha." Half a joke. A LoRa mesh is one shared channel. Every second my node spends talking is a second nobody else nearby can, and every packet gets passed along by other people's radios too. On a channel that is already 17 to 24% busy, one chatty node is a bad neighbor. I come from events, and this is the same habit as checking the power draw before you plug a rig into somebody else's circuit. You don't find out by tripping the breaker. You add it up first. ## The airtime math, in plain words A LoRa packet's time on air depends on its size and the radio settings. The mesh I was on uses a medium-range preset: spreading factor 9, 250 kHz of bandwidth, coding rate 4/5, and a 16-symbol preamble. Three steps get you from bytes to seconds: - **One symbol** takes 2^SF divided by the bandwidth. At SF9 and 250 kHz that is 512 / 250,000, about 2 ms. - **The preamble** is the 16 symbols plus 4.25 more for sync, about 41 ms. - **The payload** is 8 symbols plus groups of 5, one group for roughly every 4.5 bytes at SF9. A rename goes out as a node-info packet. With a three-digit temperature in the name, I estimated that packet at 141 bytes, which works out to 168 payload symbols. Add it up and one rename is about 0.4 seconds on air. That 0.4 seconds is only my radio. Other nodes repeat the packet so it reaches the edges of the mesh, so the real cost is the airtime times a relay multiplier. I ran three: 4x, 8x and 15x, which is about 1.5, 3.1 or 5.8 seconds of regional airtime per rename. I used 8x as the middle case. ## Only rename when the number changes The design decision that kept the cost low: the node renames only when the temperature, rounded to a whole degree, changes. If the name would come out the same, it sends nothing. Re-sending an identical name costs zero packets, because it never goes out. Nodes already announce themselves on their own. At one every three hours that is 8 node-info packets a day, about 24.7 seconds of regional airtime. On my 141-byte estimate, the worst case for my idea was a degree change every hour, 24 renames a day, about 74.0 seconds. The difference is +49.3 seconds a day, 0.057% of the day. For scale, I compared it with something the mesh already accepts: an hourly weather text post. That packet is 104 bytes, about 0.3 seconds on air, and at the same 8x relay it comes to about 58.3 seconds a day. My worst-case estimate came in under one hourly weather post, a kind of traffic the mesh already lives with. One thing I deliberately didn't do was turn down the node's broadcast interval to make the name show up faster. That adds about 16 more attempts a day, roughly another 49 seconds, and the firmware throws most of them away anyway. ![Horizontal bar chart of estimated regional airtime in seconds per day. Baseline NodeInfo, 8 a day: 24.7 seconds. Hourly renames, worst case 24 a day: 74.0 seconds. Added by renaming, highlighted: plus 49.3 seconds, 0.057 percent of the day. The hourly weather post the mesh already accepts: 58.3 seconds.](https://willcurran.com/hs-fs/hubfs/will-curran-brand/node-rename-airtime-airtime-compare.png?width=1440&height=1012&name=node-rename-airtime-airtime-compare.png) ## Then I plugged it in The channel math held up. It also wasn't the whole story, and I found that out within the first hour. The first live rename updated the name to a 108° reading, and then nothing happened on the mesh. The firmware has its own gates on node-info broadcasts. Node-info broadcasts closer together than a firmware window get silently dropped (between about 21 and 33 minutes on my mesh that day), and above 40% channel utilization it won't send at all. My first rename sat there and reached the mesh about 31 minutes later. The second surprise was worse. Every rename rebooted the node, a 7-second soft reboot that nothing announced. Renaming hourly meant up to 24 reboots a day: 24 times a day the node drops off the mesh and comes back, to change one number. That was the evening's verdict. I shut it off the same night, about two hours after I started. The node kept a fixed name with a static ⛅ as its short name. I disabled the timer and kept the code and the notes. ## What I took from it **Math clears the channel, not the device.** The airtime numbers answered the question I asked, which was whether the mesh could afford it. They said nothing about what the radio would do with the request. A good production checks the power draw before plugging in, and then somebody stands next to the gear once it's live and watches what it actually does. I did the first part well and learned the second part the hard way, for about two hours. **Emoji are bytes, not characters.** The short name holds 4 bytes. The sun, in its usual form, does not fit: ☀️ with the invisible variation selector after it is 6 bytes. The command-line tool I was using counts characters, not bytes, so it would have happily accepted the sun and the radio would have cut it off mid-character on air. Count the encoded length, not what you see. **A stale temperature is a lie.** A name that says 110° when the reading is an hour old is worse than a name with no number. The design dropped the temperature from the name whenever the reading was more than 5 minutes old, or outside a 15 to 130 °F sanity range, and fell back to a plain name. ## Build it yourself What it does: renames a mesh node so its long name carries the current temperature and its short name carries a sky emoji, but only when the rounded number changes. The parts: - **A temperature source**: a local weather station or any weather feed you trust. - **A small always-on computer** that can talk to your node through the mesh firmware's command-line tool or API. - **A script on a timer**, hourly at most. How the pieces fit: each run reads the temperature, rounds it to a whole degree, picks an emoji (rain 🌧, night 🌙, cloudy ☁, partly cloudy ⛅, sun ☀, unknown 🌡), and builds the name. If the name matches the last one it set, it stops. If the reading is stale or out of range, it drops the number. It checks the UTF-8 length of both names before sending: 39 bytes for the long name and 4 for the short one on my firmware. Leave the node's broadcast interval alone. Before you run it, do your own airtime math with your preset, packet size and a realistic relay count. Then watch the node through its first few renames. On my firmware, broadcasts inside the firmware's window, which ranged from about 21 to 33 minutes that day, were dropped, and every rename rebooted the node. Yours may differ. Find out on purpose. Give this to your AIHelp me decide whether a mesh node that renames itself with the live temperature is safe for a shared LoRa channel, and then build it. First, compute LoRa time on air for my preset (spreading factor, bandwidth, coding rate, preamble) and my node-info packet size, multiply by a relay factor I give you, and compare the added airtime per day against the node's normal node-info broadcasts and against one hourly text post. Then write a script that runs at most hourly, reads the temperature, rounds it to a whole degree, and renames the node only when the rounded name changes. Drop the number if the reading is older than 5 minutes or outside a sane range. Validate both names by UTF-8 byte length, not character count, and avoid emoji with a variation selector. Do not change the broadcast interval. Log every rename and every node restart, and tell me to watch the first few renames on the real device before leaving it running. If you have run a node like this and found firmware that renames without a reboot, I would like to hear about it. NoteWritten October 2026, about work from August 2026. Filed under [Mesh & radio](https://willcurran.com/blog/tag/mesh-radio) ![](https://willcurran.com/hs-fs/hubfs/will-curran-brand/will-curran-avatar.jpg?width=64&height=64&name=will-curran-avatar.jpg) Will Curran I spent sixteen years building one company, and I have been in the event industry since 2007. These days I write about the technology I actually use — trucks, radios, home infrastructure, and the tools that survive past the first invoice. [All posts by Will →](https://willcurran.com/blog/author/will-curran) Get the next one by email One email per post. No digest, no sponsors. [← Previous An E-Ink Truck Dashboard That Admits When It Doesn't Know](https://willcurran.com/blog/eink-truck-dashboard) [Next → How I Rebuilt willcurran.com With Claude Design and Claude Code](https://willcurran.com/blog/how-i-rebuilt-my-website-with-ai) ## Related reading [Mesh & radio Trivia Over LoRa: a game show on a slow, lossy radio mesh 8 min read](https://willcurran.com/blog/trivia-over-lora) [Will Curran](https://willcurran.com/) [LinkedIn — 29,339+ followers](https://www.linkedin.com/in/willcurran) [GitHub](https://github.com/rancur) [YouTube](https://www.youtube.com/channel/UCJgscc27l4fpkWx1SeK05xg/) [Spotify](https://open.spotify.com/user/rancur) [SoundCloud DJ mixes](https://www.soundcloud.com/thewillsee) [Twitch](https://www.twitch.tv/thewillsee) [Last.fm](https://www.last.fm/user/default) [Trakt — movies & TV](https://trakt.tv/users/willcurran) [Goodreads](https://www.goodreads.com/user/show/55302838-will-curran) [Will See Music](https://www.thewillsee.com) [Arizona Meshtastic](https://azmsh.net) [Electric Forest Meshtastic](https://efmesh.com) © 2026 Will Curran — All rights reserved. [RSS](https://willcurran.com/blog/rss.xml) [Back to top](https://willcurran.com/blog/node-rename-airtime-math#main) ```json { "@context" : "https://schema.org", "@type" : "BlogPosting", "author" : { "@type" : "Person", "name" : "Will Curran", "url" : "https://willcurran.com/blog/author/will-curran" }, "dateModified" : "2026-10-21T23:43:50.504Z", "datePublished" : "2026-08-03T16:00:00.000Z", "headline" : "Will Renaming My Node Every Hour Break the Mesh? The Airtime Math", "image" : [ "https://willcurran.com/hubfs/will-curran-brand/node-rename-airtime-featured.png" ], "mainEntityOfPage" : { "@id" : "https://willcurran.com/blog/node-rename-airtime-math", "@type" : "WebPage" }, "publisher" : { "@type" : "Organization", "logo" : { "@type" : "ImageObject", "url" : "https://willcurran.com/hubfs/image-1.png" }, "name" : "Will Curran LLC" } } ```