meshtastic
[Feature Request]: Enhance telemetry algorithm
Platform
Cross-Platform
Description
Currently the telemetry is rate limited in two ways.
- Hard limit for clients at 25% channel utilization
- Scaling broadcast interval when online node count over 40 (and faster telemetry when under 10) nodes. Keep these as they are.
Larger meshes see a lot of telemetry data that congests the mesh when node counts are over about 100 nodes. People are buying multiple meshtastic devices and even though they may have one "main" node, they have several more in their house turned on for telemetry, testing, sky node, car tracking, etc. They care about this telemetry data but not everyone else on the mesh necessarily does.
My idea is to update the broadcast interval to a 2 hour hard limit for standard telemetry (currently 1 hour default, 30min minimum) that follows the user set hop count, and then add zero hopped telemetry at 1/4 the rate (30min) of the set broadcast interval.
Similar situation with position data but 6 hour broadcast minimum with hop limit, 1/4 rate for zero hopped position, + smart position settings. This is important as even though a node may stay stationary for some time, a new node looking for it may come into the area and doesnt want to wait the full 6 hours to find out someone is close by.
This allows people with multiple nodes and nodes within their neighborhood to get more frequent telemetry (and position) updates while not carrying that forward into the rest of the mesh, especially through mountain routers (and this is the most beneficial part, NONE of the extra telemetry can make it through a router but expected/set telemetry still will).
This still allows all messages out to the rest of the mesh as well as periodic telemetry on the rest of the mesh nodes at a controllable rate that is less frequent to the less relevant nodes.
This doesnt help with the meshes where people refuse to update their firmware (but it could help with meshes with too many routers), but should help keep longfast viable for the general public in a city and usable for enthusiasts without switching to a faster preset or channel.
Exact minimum window is up for debate. Maybe instead of 2 hours we want 4 hours with 30min zerohop.
Maybe an even faster zero hop time can be used, say 15min with 2-4 hours for regularly hopped telemetry. This would incentivize people to update their firmware to get the more frequent local data. All of this would remain scaled in reflection to current online node count and/or channel utilization as it currently is.
I do not agree on limiting position. We are using the nodesin rescue operations and are in need of positions of the team members every 5 minutes
I do not agree on limiting position. We are using the nodesin rescue operations and are in need of positions of the team members every 5 minutes
This wouldn't and isn't supposed to affect you at all.
Its for larger mesh networks that are public and doesn't affect smart position in any way. Smart position set to 10m 2min for example would be fine.
I use meshtastic for hiking and similar scenario to you. The point is to not mess with any of our preferred uses, just dial it back automatically when in a city of 100 or more nodes where lots of people have a node in a stationary house.
The scaling algorithm already works really well in my city with nodes of 200-400. This would just be one level more to help reduce collisions and congestion. I think the main benefits of the scaling algorithm is that you won't need to change any settings when traveling from the woods, to a small town, to a large city.
Also, this isnt supposed to affect the primary roles. For example currently:
- nodes set as client do not ever get their text messages throttled
- nodes set as tracker do not ever get their position packets throttled
- nodes set as sensor do not ever get their telemetry data throttled
I do not agree on limiting position. We are using the nodesin rescue operations and are in need of positions of the team members every 5 minutes
Out of curiosity are your nodes in tracker role when used in rescue operations?
I do not agree on limiting position. We are using the nodesin rescue operations and are in need of positions of the team members every 5 minutes
Out of curiosity are your nodes in tracker role when used in rescue operations?
Yes, most of them tracker
Being able to turn off telemetry entirely (which doesn't seem to work currently) for nodes where the data is wrong or not meaningful would be great. In some cases, we need it so that nodes can discover each other, but that's really only relevant in the first tiny bits of a new mesh. Being able to send position and telemetry to different channels or even target nodes would also give us a lot of flexibility.
