Multiple frequencies and modulation types for RX and TX

[victorpasse]

Hi, We pulled the mesh stack way back V0.7.8 I belive and we have made many modifications since then.
Now we are revising the firmware of our product and want to incorperate our modifications with your fixes so I would much like if some of our modifications would become "standard" in the package.

I propose implementing a simple "frequency hopping" technique that could be implemented by always sending mesh packages on multiple frequencies and using multiple modulations types (125kb/s, 250kb/s, 500kb/s, 1mb/s and 2mb/s) to maximise probability of delivery.

Every tx package should be sent on X channels using X modulation types
When in Rx, set an timeout for max Yms and when timed out switch Rx frequency and modulation to next entry in X.

So no synchronised hopping, just random hopps at random times.

The use of multiple frequenies is to minimize risk of WLAN jaming and multiple modulation types to give some extra range.

A default set could be something like [ch 37, ch 38, ch39] using [1mBit, 2mBit, 0.125mBit]

I can not share any code as my code is confidensial but this can be quite easily added to your code

[trond-snekvik]

This is interesting.

Would this mean transmitting 9 times for every tx packet, with every permutation of the channel and datarate? Does your throughput improve? Normal advertising works like this, but keeps it to a single modulation scheme. Have you seen any benefits of the other modulation schemes?

[victorpasse]

No, just 3 times, once at ch37 1mBit, once at ch38 2mBit and once at ch39 0.125mBit.

125kBit gets higher SNR so when you are on the edge of reception your packetloss will go 0%, 33%, 66% and then 100% instead of 0 to 100% directly. So you get a larger region where it works but slowly.

We have seen that 125kBit gets longer range than 2mBit.
We have also seen ch39 nearly totaly dead when using wlan at high datarate

[trond-snekvik]

I see. We'll look into adding an option for this in the radio controller, but I think the default should remain compatible with BLE to avoid confusion. These are some pretty advanced optimizations