nRF5340 radio ED, why getting zero for values?

[esmart-engineering]

Hi. I am looking into measuring radio channels' qualities by using Energy Detection (ED). But for the examples I've tried so far, I've been getting zero for all the readings across most if not all the channels.

I started with NCS v2.5.0 @ nrf\samples\peripheral\802154_phy_test\. I've been noticing that when checking ED by doing "custom changemode 1" and then repeatedly doing "custom lgeted", it keeps reporting 0x0000. Not sure what's happening. I also can't seem to change channels. 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.

I also had my own code that I made, adapted from NCS v2.5.0 at nrf/samples/esb/esb_ptx/. I did it based off what I saw here, but again it just seems to be reporting zeros (even when I've been able to check more channels/frequencies). I understand there's the TX_FAILED events from the ESB at the moment; I can resolve later but right now I'm most curious about getting the ED working.
esb_with_ed_checks.zip

What am I missing here to get non-zero readings?

Also note that I did open a somewhat similar ticket here, but it is not a repost of the same topic. This one is for another member of the team who will separately do investigation on ED.

[Kenneth]

Hi,

I think the secret is within the description of the api call "Energy level in units compliant to IEEE Std. 802.15.4-2015 chapter 10.2.5."

/**
 * @brief  Converts energy level received during the energy detection procedure to IEEE Std. 802.15.4-2015 compliant value.
 *
 * @param ed_dbm  Energy level in dBm
 *
 * @return uint8_t  Energy level in units compliant to IEEE Std. 802.15.4-2015 chapter 10.2.5.
 */
uint8_t nrf_802154_energy_level_from_dbm_calculate(int8_t ed_dbm);

And inside the api you can find that:

/** Minimum value of ED in dBm for conversion to units conforming IEEE Std. 802.15.4-2015 chapter 10.2.5. */
#define ED_DBM_MIN (PHY_MIN_RECEIVER_SENSITIVITY + 10)

/** Maximum value of ED in dBm for conversion to units conforming IEEE Std. 802.15.4-2015 chapter 10.2.5. */
#define ED_DBM_MAX (EDSAMPLE_MAX_REPORTED_VALUE + ED_RSSIOFFS)

So looks like the range is between -30dBm to -75dBm. Any value below the floor of -75dBm will return 0.

The spec's rationale: signals below -75 dBm are too weak to be reliably decoded anyway, so reporting them as "no energy" is a deliberate design choice, it avoids false congestion reports from noise.

Kenneth

[esmart-engineering]

Hi. If you are suggesting that there's no or little energy/noise on all the channels, that's quite the leap in speculation. I would imagine there were several more-likely reasons for this before we jumped to this extreme.

1. We adjusted the code to only scan channel 90 (2490MHz), and had a separate pair of nRF devices sending ESB packets to try "flooding" channel 90. The results were still showing zeros for the ED values.
2. Our test environment is not in some "clean lab"; there is plenty of traffic over the air. When using a typical WiFi analyzer app, we can confirm that there's plenty of energy between -30dBm and -75dBm across all the 2.4GHz WiFi channels (from our own routers, other offices' routers, etc).

For example, the snippet code from here is quite short. Perhaps there's some other code that's not explicitly shown that I'm missing from the example project I attached?

[Kenneth]

Hello,

You should only need to execute the following before you start measuring energy:
RE: About Sample Source, " IEEE 802.15.4 PHY test tool" , i do not understand any command. 

Whether "normal" short GFSK modulated packets are detected by the energy detection I am not sure of, simple running at my home I could find that there was some energy detected on some channels (likely related to the WiFi).

Kenneth

[esmart-engineering]

The link you provided is completely irrevelant to the questions we answered earlier on.  Your link is not even referring to the REGISTER method.  

Please do not just reply for the sake of keeping the ticket alive.  It is wasting everybody's time.  We need competent answer and not just non-sense useless respond.  If you do not know, please assign to someone who is familiar w/ the topics.  

I have esaclated this to our sales rep at Nordic.  Again, please do not waste our time for incompetent respond.

[Kenneth]

Hello,

A few things here just to clarify a bit.

When you are working on a higher level protocol api through either esb or the rf py test tool they are kind of mutually exclusive, meaning they rely on the radio being in default state when you start to use the api, an it rely on any (previous) configured configuration is not changed between api calls, it will very likely not handle well in any way that you switch between them without being very careful, see my initial reply here (From "Be aware"):
https://devzone.nordicsemi.com/f/nordic-q-a/127465/nrf5340-esb-scanning-rssi-across-channels/563421 

Secondly, you can't really mix low level register calls with higher level api calls no, that will very quickly break, but if you are only interested in just testing some specific functionality (e.g. energy detect) it is possible to do so by lower level register calls, however it still rely on the radio is setup correctly in for instance 802.15.4 mode in the first place and not mixed or dynamically switched with some ESB code before or in between. My input in this particular case have been to help you try out an evaluate the specific energy detect feature to see if it can meet your expectations, this before you start looking at a proper full implementation in your actual application. I guess that have led to some confusion.

In your current code you are for instance configuring the radio to ESB mode and then performing energy detect, this is not possible no. It needs to be in 802.15.4 mode to perform energy detect (ED). The only way to perform ED in an application that is planning to use ESB normally, would be to disable ESB, ensure radio registers (including shortcuts, radio buffer and ppi channels) have default settings, then configure to 802.15.4 mode with specific channel, then perform one one several ED measurements for the channels you are interested in, then disable 802.15.4 mode, ensure radio registers (including shortcuts, radio buffer and ppi channels) have default settings before you init ESB again. All should be done using the specific protocol api calls. Realistically this will take time and you need to be careful handling to get it right.

Going back to my initial reply I believe the best way is to monitor the packet loss over time on individual channels, you can also store away the rssi measurements for each packet received to give the user a indication of the signal strength. Reason doing it this way is that even if other sources may be present on a specific channel, they may not be problematic, either because the signal to noise radio is enough for the packet to be received anyways, or because the other sources are frequency hopping also, or only intermittently transmitting short packets on the channel in question.

Hope that helps to explain why my answers seems to contradict themselves.

Edit: Just to add some more comments:

- Performing RSSI is faster than ED. In both case the radio need to ramp up (130us for both) and then perform either energy detect (128us) or rssi measurements (pretty instant in comparison: 0.25us). 

- I can see you have used channel 90 for ESB, be aware that this is outside the ISM band (2.400 GHz to 2.4835 GHz). 

Kenneth