Enabling Data Whitening for ESB Data Communication

[shchu]

I have one TX and another RX codes for data communication by ESB protocol. To verify whether data whitening can be enabled, I added below register setting on TX side only and let RX side use its default setting (data whitening disabled):

NRF_RADIO->PCNF1 = ((NRF_RADIO->PCNF1 & ~RADIO_PCNF1_WHITEEN_Msk) | (RADIO_PCNF1_WHITEEN_Enabled << RADIO_PCNF1_WHITEEN_Pos))

NRF_RADIO->DATAWHITEIV = 0x55

I expect the RX side should receive nothing from TX for this experiment but the RX could still receive all the packets (no CRC error) from TX without any packet drop. It looks like the data whitening was not working.

Does the ESB support data whitening? If yes, what is wrong with my setting? Thanks.

[Kenneth]

Have you checked the packet content? I would assume that CRC is calculated over the packet content, and thereby be valid depending on the content (with or without data whitening), the actual data however may be whitened.

Best regards,
Kenneth

[shchu]

Yes, I checked the packet content on RX. No data whitening on them after received.

You are right for the CRC check. I misunderstand it.

Any other reasons? Data whitening not worked on TX?

[Kenneth]

Hmm.. it may only work in BLE mode?

http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52832.ps.v1.1/radio.html?cp=2_1_0_22_13_10#register.MODE 

Can you give that a try also?

[shchu]

To test BLE from ESB mode, it should not simply change the MODE register's value from 1 (Nrf_2Mbit) to 4 (Ble_2Mbit), right?

As our TX & RX codes were already associated with some feature functions by us, it is not easy and fastly to change to BLE if not just a change in the MODE register's value.

But I guess the data whitening function can be both applied to BLE and ESB if according to the radio block disgram of figure 1 below

http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52832.ps.v1.1%2Fradio.html&anchor=concept_lhd_ygj_4r__fig

Any suggestion?

Thank you so much

[Kenneth]

This is just a test setup, so my suggestion is for test that you set MODE to BLE_1MBit on both PRX and PTX. No other change should be required for test. Then you can try to enable data whitening on the PTX, to check if PRX still receive the correct data.

Thanks,
Kenneth

[shchu]

I tested as you suggested. Both PRX and PTX were set to BLE_1Mbit and below are the 3 test cases.

(1) If no data whitening on both PRX and PTX, PRX could receive what PTX had sent. This proves the BLE_1Mbit could work.

(2) If data whitening on PTX, PRX could not receive anything from PTX no matter data whitening was set on PRX or not.

(3) If no data whitening on PTX and PRX with data whitening, PRX could still receive correct payload data from PTX. This looks like data whitening was still not working.

For another matter, I also tested BLE_2Mbit on both PRX and PTX without data whitening. The PRX could receive correct data from PTX, and this could improve the PRX sensitivity about 3dB (same as specification).

What is the difference in the protocal level by this setting (MODE set to BLE_2Mbit) as compared to using the "SoftDevice" stack? Maybe this setting uses non-standard BLE protocol, e.g. no GATT and no profile? If yes, this means it uses "shorter" packet data than the one by standard BLE protocol? This MODE setup is only for testing, but not suggest for our find products?

Sorry for so many questions as I would like to explore some "software" methods that can improve the PRX sensitivity while power consumption can be close to the our existing measurement level by ESB at 2Mbps. One of these is by data whitening even I guess this does not improve a lot.

Thank you so much.

[Kenneth]

Hello,

I am not sure why you are not able to make data whitening work. It doesn't seem as we have any example with it, and the reason is simply that it doesn't add any performance improvement. If it is a really important feature for you then I can try to look into modify the ESB examples to make it work.

You can find the receiver sensitivity values depending on the operation mode here:

http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52832.ps.v1.1/radio.html?cp=2_1_0_22_14_4#unique_919665808 

The reason for difference in sensitivity between legacy 2Mbps and ESB 2Mbps is due to the frequency deviation (increased deviation typically improve the sensitivity):

http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52832.ps.v1.1/radio.html?cp=2_1_0_22_14_0#unique_1056325669 

A new feature in BLE v5.0 was the introduction of 2Mbps on-air data rate, it is used by the softdevice if enabled and both peers support it. The time on-air is halved compared to 1Mbps yes.

You may use the BLE modes in a proprietary protocol also, but then it will not be backwards compatible with existing equipment you may have using legacy radio mode.

Best regards,
Kenneth

[shchu]

At this moment, I can use the BLE mode in a proprietary protocol to improve sensitivity instead. Using data whitening or not does not matter now. But I would like to know more about this BLE mode setting.

1. What did you mean by "legacy 2Mbps"? "Legacy 2Mbps" is exactly the MODE = BLE_2MBit, right?

2. This mode setting (MODE = BLE_2MBit) will use proprietary protocol (non-standard BLE), right?

3. If yes for question 2 above, does the structure of this proprietary protocol follow the packet layout in figure 2 (packet configuration) of this link:

http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52832.ps.v1.1%2Fradio.html&cp=2_1_0_22_1&anchor=concept_hz4_cjl_4r

4. This mode setting (MODE = BLE_2MBit) also supports auto packet retransmission upon packet loss, right?

Thank you so much.

[Kenneth]

"Legacy 2Mbps" mode I meant RADIO_MODE_MODE_Nrf_2Mbit
"BLE 2Mbps" mode I meant RADIO_MODE_MODE_Ble_2Mbit

The mode control the modulation of the on-air carrier, there is also some differences to radio ramp-up time depending on the mode, as long as both transmitter and receiver use the same mode they can communicate.

The packet format/layout will be the same for both, all other functionality is also the same.

[shchu]

I am clear now. Thanks for your help!