Calculate TX air time duty cycles

[mc-hamster]

Calculate air time duty cycles

Pls include 1hr / 24hr percentages.

maybe maintain the usage over a few days. It shouldn’t cost that much ram.

[geeksville]

This issue has been mentioned on Meshtastic. There might be relevant details there:

https://meshtastic.discourse.group/t/ip-over-meshtastic-kinda-implemented/1775/12

[geeksville]

I really like the "track over a long period of time idea (a day or two)" so that throttling (when eventually added) doesn't kick in with false positives.

[geeksville]

also just knowing what 'real world duty cycle' we are currently getting would be useful.

[mc-hamster]

I think a first pass would be to report the TX airtime. A next step may be to also report on RX airtime so we have an idea of cannel utilization.

[geeksville]

ooh really good point wrt rx airtime telling us % channel utilization also.

[geeksville]

Also nodes with "higher rx airtime than others" might be a really good heuristic for "nodes that should probably be preferentially considered for routing (someday when we are doing something smarter than naive flood routing)" (assuming rx sensitivity and tx reach are symmetric - which alas, might not be true)

[mc-hamster]

Note to self: 1839f8f

[mc-hamster]

@geeksville Thinking about channel utilization, I think there are two measures.

1. The utilization of the lora channel are we using for our current network
2. The utilization of the lora channel by the current device, the devices on our current meshtastic channel and other lora devices that may have similar channel configurations.

I'll assume that for #2, if our radio receives a packet that is not designated for the device, it's discarded. Where does that happen? I'd like to also include that.

[crossan007]

Seems like we need 4 counters?

Transmitted packets (originating on device)
Transmitted packets (forwarded for other devices)
Received packets (destined for device)
Received packets (for other devices)

[mc-hamster]

Seems like we need 4 counters?

Transmitted packets (originating on device)
Transmitted packets (forwarded for other devices)
Received packets (destined for device)
Received packets (for other devices)

Hmm ...

Other than for reporting, how would having a counter for packets originating from the device vs to be forwarded to other devices be used?

When maintaining a 48 hour history, each counter costs us about ~100 bytes of RAM. The amount of history to maintain is a config setting.

Regardless, adding more counters will be easy if it's needed. :)