[Feature Request]: New Scaling Algorithm for Telemetry

[b8b8]

Platform

NRF52, ESP32, Cross-Platform

Description

I think the scaling algorithm for telemetry needs to be adjusted to more easily deal with densely populated cities.

Right now after 40 nodes a scale factor is applied to stretch out the telemetry rate relative to the number of online nodes.

A suggestion is stop changing the default rate and instead have a hardcoded rate that is scaled both up and down more incrementally than before. This would also automatically benefit using nodes away from population dense areas by increasing the rate.

Possible layout <10 nodes, 5 min: This would automatically help small hiking, skiing groups without having to change settings before an outing 10-30 nodes, 30min: small town, minimal congestion 30-40 nodes, 1 hour + no SF: current default and the new number in which a scaling factor is applied later

40-50 nodes, 1 hour+SF: scaling factor starts being applied to 1hr timing 60-80 nodes, 1 hour+SF2: 80-120 nodes, 1 hour+SF3: 120+ nodes, every 8 hours unless manually requested using an updated "request user info" button

These scaling factors would not be applied to Sensor Role telemetry. These scaling factors would not be applied to Tracker Role positions Client position interval (not smart position) set to 2 hours, user sets smart position at what they deem as appropriate rate

At some point it makes sense to look at switching to MediumFast before the 3.0 roll-out. Switching to MediumFast does not force break the network as even remote nodes can be changed to a different preset over the admin channel at worst case.

[Technologyman00]

I'd love if it could also be separated out from MQTT as I have a static node that is hooked up to Home Assistant as a weather station and I'd prefer to not have the update rate limited by the number of nodes

[b8b8]

I'd love if it could also be separated out from MQTT as I have a static node that is hooked up to Home Assistant as a weather station and I'd prefer to not have the update rate limited by the number of nodes

Sensor role already has a much higher limit and now you can set "none" (like client_mute) to not mesh other packets. This is how i have my weather station hooked up now.

https://github.com/meshtastic/firmware/issues/5030#event-14616717633

[Technologyman00]

Sensor role already has a much higher limit and now you can set "none" (like client_mute) to not mesh other packets. This is how i have my weather station hooked up now.

Ideally I could have it mesh and update other users as well as much more rapidly update my MQTT server. As the weather station is not on solar and is in a high vantage point. This probably wont make a significant difference for a while in my location as there is not much traffic.

[b8b8]

Sensor role already has a much higher limit and now you can set "none" (like client_mute) to not mesh other packets. This is how i have my weather station hooked up now.

Ideally I could have it mesh and update other users as well as much more rapidly update my MQTT server. As the weather station is not on solar and is in a high vantage point. This probably wont make a significant difference for a while in my location as there is not much traffic.

i agree with you. I guess my note was more of a suggestion to you as a temporary fix with a higher rate. Being able to separate out telemetry rate for MQTT only use makes sense.

[b8b8]

@thebentern any comments? Specifically for moving to mediumfast as well.

[thebentern]

@thebentern any comments? Specifically for moving to mediumfast as well.

We may end up moving to medium fast as a default before 3.0, but it's a big maybe.