Bitrates of the different channel settings

Development
1

I pulled out a calculator and crunched some math …

These are the channel settings that have been predefined into Meshtastic.

Short range (but fast) - 21.875 kbps
Medium range (but fast) - 5.469 kbps <-- This is the default
Long range (but slower) - 0.275 kbps
Very long range (but slow) 0.183 kbps

I use “Long range (but slower)” on my devices. What data rate do you use?

2

I am interested in the time for the mesh connected devices to maintain a synch.
Possibly four scenarios for the number in mesh: 2 devices, 5 devices, 10 devices, 20 devices

The question is at the various bitrates, How long does it take to perform
the following operations:

  1. Time for Initial mesh connect and transmit initial position and health status.
  2. Time to add and synch an additional device.
  3. Time to transmit and receive by all devices acknowledgement of a message initiated by one device.
3

Those are hard questions to be answered. We should take into account at least

  • physical network layout (which nodes can TX and/or RX to each other)
  • all network parameters
  • overall load on the network
  • duty cycle restrictions

  1. In theory, if I’m not mistaken, the first step could be counted by: [GPS fix time ms] + [random TX delay ms] + [packet TX length ms] + ( ( [random TX delay ms] + [duty cycle wait timer ms] + [packet TX length ms] ) * [number of nodes/hops and needed retransmissions] )

  2. The same as the first one.

  3. a) Initial message: [random TX delay ms] + [packet TX length ms] + ( ( [random TX delay ms] + [duty cycle wait timer ms] + [packet TX length ms] ) * [number of nodes/hops and needed retransmissions] )

  4. b) Acknowledgements: [random TX delay ms] + [packet TX length ms] + ( ( [random TX delay ms] + [duty cycle wait timer ms] + [packet TX length ms] ) * [number of nodes/hops and needed retransmissions] )

All message types are treated the same way. In addition, all messages are, more or less, flooded at the moment. Therefore, currently most important factors are network parameters (SP, Spreading Factor), and the amount of hops/retransmissions needed. Duty cycle limits are not enforced yet.

There might be flaws in those formulas, and hopefully someone corrects me if needed. :slight_smile:

More about airtimes can be found here: Antenna improved range

1 Like
4

yep and btw - there is a bug in how we are setting the delays to avoid collisions. The current delay calculation is not considering the expected airtime of the packet. Which is fine for the default long range/slow settings - because that’s what I used when I was developing. But now that more people are wanting to use the fast/shorter range settings, we should fix that. Fixing this will dramatically speed up the the ‘faster’ settings.

The fix is easy, would someone mind putting a bug in for meshtastic-device and I’ll do it soon.

1 Like
5

Done.

1 Like
6

thanks - btw - working on this now because it has really been bugging me for a long time. Should be checked in today or tomorrow.

1 Like
7

Does your fix only work for the four predefined or does it also work if custom channel settings are set?

8

It will work for any - I implemented the function described in section 4 of https://www.rs-online.com/designspark/rel-assets/ds-assets/uploads/knowledge-items/application-notes-for-the-internet-of-things/LoRa%20Design%20Guide.pdf

2 Likes
9

Are these data-rates confirmed? Shall we put them somewhere in the docs? Perhaps here?

2 Likes