mirror of
https://github.com/meshtastic/meshtastic.git
synced 2024-11-09 23:24:10 -08:00
Fixed slug
This commit is contained in:
parent
bf575e9de2
commit
2b04e22a8b
|
@ -1,19 +1,19 @@
|
|||
---
|
||||
title: Why Meshtastic Uses Managed Flood Routing
|
||||
description: "Why Meshtastic Uses Managed Flood Routing"
|
||||
slug: meshtastic-opposition-to-nextnav-proposed-changes
|
||||
slug: why-meshtastic-uses-managed-flood-routing
|
||||
authors: [thebentern, GUVWAF]
|
||||
tags: [meshtastic]
|
||||
date: 2024-08-17T12:00
|
||||
date: 2024-08-18T12:00
|
||||
hide_table_of_contents: false
|
||||
image: "/design/web/social-preview-1200x630.png"
|
||||
---
|
||||
|
||||
|
||||
Designing a low-bandwidth wireless mesh network to run on low-power microprocessors with limited memory is challenging. Arguably the simplest mesh routing protocol is Flood Routing: each radio receiving a packet will rebroadcast this again, up to a certain hop limit. Although Meshtastic is based on this, there are a few subtle, but significant enhancements. Most importantly, before a node rebroadcasts, it waits a short while and listens if anyone else is rebroadcasting already. If so, it won’t rebroadcast again. Therefore, “Managed Flood Routing” would be a better name. For more details on the enhancements, please review our [documentation](https://meshtastic.org/docs/overview/mesh-algo/).
|
||||
|
||||
|
||||
## Many of our decisions are based empirical data from *Meshtasticator* simulations
|
||||
### Many of our decisions are based empirical data from [Meshtasticator](https://github.com/GUVWAF/Meshtasticator) simulations
|
||||
|
||||
![https://github.com/GUVWAF/Meshtasticator](/img/blog/route_plot.png)
|
||||
|
||||
{/* truncate */}
|
||||
|
|
Loading…
Reference in a new issue