Sort poll responses by RPD signal

[TMRh20]

I've been playing around more with the mesh layer, and figured it was about time to play around with the RPD results since we are now caching and utilizing poll requests.

Basically it will order Address Requests by signal strength, requesting an address from nodes that have responded with a strong signal first, leaving the weaker nodes for last.

• Gather RPD results when receiving POLL responses
• When requesting an address, request from nodes that have responded with signal > 65dB first, then the weaker nodes if that fails

I'm still playing around with this one, but initial testing looks good!

Not sure if we want to incorporate this into the library, but figured I'd post my code for discussion.

[2bndy5]

Just posting an excerpt from datasheet (v2) as a reference:

The RPD can be read out at any time while nRF24L01+ is in receive mode. This offers a snapshot of the current received power level in the channel. The RPD status is latched when a valid packet is received which then indicates signal strength from your own transmitter. If no packets are received the RPD is latched at the end of a receive period as a result of host MCU setting CE low or RX time out controlled by Enhanced ShockBurst.

I can think of 2 flaws here:

1. the code does not ensure we wait 130 us
2. we could be getting duplicate snapshots if network.update() doesn't cycle the radio's role (RX -> TX -> RX)

Since the RPD is really only meant for hardware testing (& the obvious increase in compile size), I really don't think this is a good idea for production.

[TMRh20]

Hmm, I'm not sure we need to wait, it says it can be read anytime during the receive period AND is latched upon reception. The code ensures a valid packet has been received, so it should be latched. I think that takes care of most concerns. It seems to work when looking at the results too.

I think you are right though that this is not meant for production on NRF24. I might still keep playing with this and leave the PR open for a while, because the NRF52x I believe can actually get the actual dBm and of course sort the requests by dBm. It could also handle more poll responses.

I've been extensively testing connectivity and packet loss on two busy mesh networks, so looking for more ways to improve things.

[2bndy5]

It would make more sense on nRF5x radios. Maybe we could ifdef this approach to only get used on those radios?

[TMRh20]

Yeah, that's what I've done for testing, now to see if it makes much of a difference...