nRF5340 ESB, scanning RSSI across channels

[esmart-engineering]

I have worked a bit with ESB and see that there are functions to get/set a channel, as well as check the RSSI value in the "struct esb_payload" for a packet. Are there already some existing functions in the ESB library, or lower level libraries, that allow for scanning all the channels and reviewing all their RSSI values? Or would it have to be done in the application side with the existing ESB library functions?

We're trying to ultimately implement adaptive frequency hopping, but with ESB.

I'm working with the nRF5340, Windows 11, and NCS Connect SDK v2.5.0.

-------

EDIT 1 - I tried using some of the 'fw' code from the RSSI Viewer app (in a standalone application i.e., no ESB) and flashed it onto the nRF. It did report fluctuating values across all the channels I was interested in. But when I undo the commenting out of the ESB functionality, logs seem to report 1 TX_FAILED event followed by no other packets received.

• See the PTX project here, adapted from NCS v2.5.0 at nrf/samples/esb/esb_ptx/
  • 6320.radio_rssi_scan_with_esb.zip
• For PRX project, I used the one exactly from NCS v2.5.0 at nrf/samples/esb/esb_prx/

-------

EDIT 2 - From reviewing the RSSI code some more, it seems to switch the radio to RX mode, read the RSSI, then disable the radio. Perhaps that's causing ESB to be disabled somehow?

[Kenneth]

Hello,

All communication in the 2.4GHz band is packet based and changes continuously. RSSI might give some indication on the receive strength, e.g. whether the peer device is near or far away, but it's not very useful for any kind of assessment of the channel. If you want such functionality, then simply over time have an array where you for instance monitor the amount of retransmissions or packet lost on the channels used, and then based on that you can try to avoid specific channels that you see there is more loss on than others. 

If you want to manually sweep through channels to measure RSSI, then I expect you need to disable ESB, manually do as you already do in rssi_measurer_scan_channel_repeat(), then enable ESB again afterwards. Be aware that the rssi_measurer_scan_channel_repeat() seems to rely on a lot of radio registers have their default reset state, which might not be the case if ESB is initialized, hopefully disabling ESB will reset the radio, else you may need to attach a debugger and find which registers that ESB might have left configured after disable and write them back to default reset state before you do the rssi_measurer_scan_channel_repeat().

Kenneth

[esmart-engineering]

The manual sweep would suit our purposes better for AFH, but we don't want to keep enabling and disabling ESB, as we have tight timing constraints for how often ESB is sending and for how often we check RSSI.

Are there other measures of radio channel quality that we can utilize instead? I've seen some documentation about measuring LQI or using energy detection (ED), both of which seem to be for radio but are more related to 802.15.4 protocol. Could something like this be used alongside ESB, almost as if it's taking advantage of "multiprotocol support" (PHY arbiter)? The closest sample I've seen available is at NCS v2.5.0 @ nrf\samples\peripheral\802154_phy_test\, but it is more for RSSI; could it perhaps be repurposed for LQI or ED?

[Kenneth]

Hello,

I am not aware of other way than using RSSI no.

I would expect disable and enable ESB take approx the same time as executing rssi_measurer_scan_channel() for one channel.

Kenneth

[esmart-engineering]

Please have someone with LQI and ED (low level) knowledge to answer our question.

Thanks!

[esmart-engineering]

I reviewed the sample code at NCS v2.5.0 @ nrf\samples\peripheral\802154_phy_test\ some more, ensured my app core is the "Remote IPC shell" project, and focused mostly on ED rather than LQI (my understanding is that ED is a measure of how each channel's quality is, and LQI is a measure of overall quality independent of channel).

I've been noticing that when checking ED by doing "custom changemode 1" and then repeatedly doing "custom lgeted", it keeps reporting 0x0000. Could it be related to sampling time from ptt_rf_ed() function, or perhaps I'm not checking the right channel?

If it's an issue with which channel I'm checking, can I get some guidance on how to adjust the channel? I have a slight understanding from here, but I've tried various commands and haven't been able to change the result of "custom lgetchannel" being 11 (when I run it from the CMD mode device). I've tried "lsetchannel", "rsetchannel", and "setchannel" (on both CMD and DUT devices' terminals) but I'm not seeing a difference.

[Kenneth]

Hi,

Just looking at it from a hardware perspective the RSSI seems to be the way to go here.

RSSI is fast and actually measure the channel you are interested in, it can also be triggered several times if you need to average it:
https://docs.nordicsemi.com/bundle/ps_nrf5340/page/radio.html#ariaid-title167 

LQI is only available after receiving an 802.15.4 packet, so not relevant here.

ED is somewhat similar to an averaged RSSI value, however the channel is different than used by ESB, it's significant slower than RSSI, but you can find a low level code example in the documentation if you want to try it out:
https://docs.nordicsemi.com/bundle/ps_nrf5340/page/radio.html#ariaid-title24 

Kenneth