I took three devices loaded with something newer than 1.1.30, the new air time calculator and let it run for a few hours.
In those few hours, I did not send or receive any text messages during this time and did not turn on any new devices or any devices. I wanted to see just how much ambient traffic the devices were sending. This data was then imported into Google Sheets. This is all just default settings. I didn’t even set my username on the devices, that would have been more bytes.
The summary is that, over a 12 hour measurement period, with three devices on the default channel of #LongSlow-1 (this is the longest range and slowest setting), the transmitter utilized 1.36% of the total airtime. The channel was utilized by the mesh network 3.86% of its total capacity.
Want to see the spreadsheet?
I think the take away is that the highest range / lowest bit rate option should really only be used as a last resort where extreme range is necessary.
I’ll take measurements of the other channel settings over the next few days and the next measurement will be of the fastest bitrate / lowest range setting.
@geeksville I’ve had my head thinking about air time usage and packet collisions for a few days and realized something about our default modem configs. Specifically these two:
The lora docs say that multiple different spreading factors can co-exist on a single frequency without creating interference or packet collisions. Since Medium and ShortFast exist within the same SF, transmissions on one will be seen as noise on the other. I think it would benefit us to move ShortFast to a different spreading factor and channel configuration. This will, in effect, give us more total capacity.
PS. Please don’t merge this into the protobufs just yet. I released I may have to redefine the data structure to support fast configuration. 1 second granularity may end up being rounded down to 0 with small packets.