Nostr Web Client

Agreed. I'd want to throttle it back for sure. I feel it should be variable based on local network conditions, but 50% seems like it'd be a reasonable default.

shortwavesurfer2009 3mo ago

The meshtastic team seems to generally agree that if your channel utilization is over 50%, you should be dialing up to a faster preset. So I probably wouldn't do anything more than say 25%.

I think some other fair restrictions would be that you absolutely must be directly connected to it with at least zero hops. You cannot go through another mesh point to get to the node.

That would need you to physically drive to within probably about a mile of the node itself, which is still better than climbing the 200-foot tower, as you mentioned, but would keep the local mesh from just dropping out of the air while updates were occurring.

Reply to this note

Please Login to reply.

Discussion

Dr. Hax 3mo ago

I can work with all of that.

Thanks for talking it through with me. I'm not committing to implement this, but it's good to have some ideas on how to do it and why those were chosen.

shortwavesurfer2009 3mo ago

Yeah, I'm not totally sure it could be implemented right now anyway. I know that the ESP32 can apparently be updated over the air, but I think the ESP32 is also more powerful than the NRS-52 in that regard, because it has Wi-Fi and other stuff like that.

I think you're right in that there would have to be a way to load a firmware from an external storage such as an SD card and your upload would just replace that firmware and then you would tell the system to reboot and load the new firmware from the SD card. Either that or as you mentioned above have two MCUs.

shortwavesurfer2009 3mo ago

And there's nothing even saying you'd have to use the meshtastic presets. You could have like a firmware update preset that would do things like reduce the error correction rate in order to improve the speed at which data is transferred with the full knowledge that you would have to be closer to the node than otherwise normal in order to compensate for that less error correction.

If I remember correctly, one megahertz of Wi-Fi Halo can do like four MBPS, so theoretically you might be able to get a quarter of that or one MBPS with some setting changes. The default for things like ShortFast is 250KHz of bandwidth. If you could actually get a way to pull 1MBPS over the link, that would only require 15 seconds to get the firmware patch across. Even if you double sent everything in order to make absolutely certain it got there, it would only take like 30 seconds.

shortwavesurfer2009 3mo ago

I think if you can figure out a way to get 250kbps (25KB/s) across the link you would be pretty much set.

Drive up to the node, send a command to reboot it into a firmware update preset, send the file up to the node, and then have it reboot and then switch it back to the normal mesh.

The file would probably take somewhere between a minute and two minutes to get across between your node and the node that's receiving the update.

shortwavesurfer2009 3mo ago

I laid out this scenario on the #meshtastic lemmy community as well to see what kind of responses I might come up with.

https://lemmy.zip/post/48637558

Dr. Hax 3mo ago

First hand experience tells me that the BT upgrades frequently fail on the nrf chips. So that bootloader that automatically flips onto OTA update mode on a failed flash would be important if BT was going to be involved in a flash.

shortwavesurfer2009 3mo ago

If I understand this comment correctly, you're looking at 39 KBPS, so it would take about 6 minutes to transfer the file across.

https://mander.xyz/comment/21978075