nRF52805 Radio and EVENTS_DEVMATCH

[Rob Garner]

Hi there

When the EVENTS_DEVMATCH is raised, this signals that the device address received in the radio data packet matches one of all enabled addresses in the BASE0/BASE1 and PREFIX0/PREFIX1 registers, depending on the setting in DACNF.

As per the data sheet:

6.11.10 Device address match
The device address match feature is tailored for address whitelisting in Bluetooth low energy and similar
implementations.
This feature enables on-the-fly device address matching while receiving a packet on air. This feature only
works in receive mode and when the RADIO is configured for little endian, see PCNF1.ENDIAN.
The device address match unit assumes that the first 48 bits of the payload are the device address and
that bit number 6 in S0 is the TxAdd bit. See the Bluetooth Core Specification for more information about
device addresses, TxAdd, and whitelisting.
The RADIO is able to listen for eight different device addresses at the same time. These addresses are
specified in a DAB/DAP register pair, one pair per address, in addition to a TxAdd bit configured in the
DACNF register. The DAB register specifies the 32 least significant bits of the device address, while the DAP
register specifies the 16 most significant bits of the device address.
Each of the device addresses can be individually included or excluded from the matching mechanism. This
is configured in the DACNF register.

Can you please clarify which address that is received in the radio packet is used for this comparison? Is it the BASE/PREFIX fields after the PREAMBLE field in the radio packet, or is it the first 48 bits (6 bytes) of the PAYLOAD packet?

Thanks

Gunter  

[Håkon Alseth]

Hi,

 

A very simple proprietary RF communication will look approx. like this:

Preamble | BASE + PREFIX | payload | CRC

  

When adding the device address, the PS states:

The device address match unit assumes that the first 48 bits of the payload are the device address and that bit number 6 in S0 is the TxAdd bit. See the Bluetooth® Core Specification for more information about device addresses, TxAdd, and whitelisting.

This means that the first 6 bytes of the above shown payload field will now be the "device address" for BLE.

This is approx. how it looks:

Preamble | access address | device address | payload | CRC

 

Access address is the .BASE + PREFIX, and Device address is the 48 bit BT address.

Can you please clarify which address that is received in the radio packet is used for this comparison? Is it the BASE/PREFIX fields after the PREAMBLE field in the radio packet, or is it the first 48 bits (6 bytes) of the PAYLOAD packet?

Technically both are.

Your access address is clocked in first, and compared. If matching the expected address (ie. what is set in RADIO .BASE/.PREFIX), it will start demodulating the device address and compared this against the content of the DAB/DAP registers, and finally checking if the CRC matches.

 

Let me know if anything is unclear!

 

Kind regards,

Håkon

[Rob Garner]

Hi Håkon

Thank you very much for the quick response. I'd like to summarize it, and also ask one additional question.

So, from my understanding, if there is a mismatch in one or both of the two address fields (access address or device address), then the EVENTS_DEVMATCH flag will NOT be set. Instead, the EVENTS_DEVMISS flag will be set.

According to nRF52805 errata 245 [RADIO: CRC is wrong when data whitening is enabled and address field is included in CRC calculation], the CRC calculation can be incorrect, even if all the data is correct. Let's assume we received a radio packet where all the data (including all addresses) is correct, but a CRC error is flagged due to the above stated errata. Will the EVENTS_DEVMISS also be set, or are the EVENTS_DEVMATCH and EVENTS_DEVMISS independent of the CRC result?

[EDIT]

I just thought of another question, so I will edit my response. Regarding the above errata, does the error in the CRC calculation only happen if the address field is included when data whitening is enabled? Let's assume data whitening is enabled, but the address field is NOT included in the CRC calculation. Does the errata still apply?

If the errata only applies when both data whitening are enabled AND the address field is included in the CRC calculation, what are the possible effects on the Bit Error Rate if data whitening is NOT active? 

[End EDIT]

Thank you very much for your help.

Cheers

Gunter

[Håkon Alseth]

Hi Gunter,

 

Rob Garner said:

Thank you very much for the quick response. I'd like to summarize it, and also ask one additional question.

Always happy to help.

 

Rob Garner said:

According to nRF52805 errata 245 [RADIO: CRC is wrong when data whitening is enabled and address field is included in CRC calculation], the CRC calculation can be incorrect, even if all the data is correct. Let's assume we received a radio packet where all the data (including all addresses) is correct, but a CRC error is flagged due to the above stated errata. Will the EVENTS_DEVMISS also be set, or are the EVENTS_DEVMATCH and EVENTS_DEVMISS independent of the CRC result?

The events you mention will occur independent of the CRC result.

What errata #245 describes is a scenario where you include the address withing the CRC calculation, with the whitening enabled.

Rob Garner said:

I just thought of another question, so I will edit my response. Regarding the above errata, does the error in the CRC calculation only happen if the address field is included when data whitening is enabled? Let's assume data whitening is enabled, but the address field is NOT included in the CRC calculation. Does the errata still apply?

The error in the CRC event only occurs if the address field is also included in the CRC calculation, with whitening enabled.

The fix is then to not include the address within the CRCCNF register:

https://infocenter.nordicsemi.com/topic/ps_nrf52805/radio.html?cp=4_6_0_5_10_12_43#register.CRCCNF

 

Rob Garner said:

If the errata only applies when both data whitening are enabled AND the address field is included in the CRC calculation, what are the possible effects on the Bit Error Rate if data whitening is NOT active? 

The reason for using whitening is to allow for a evenly distributed amount of bitwise '0' and '1' within the RF payload, to ensure a proper DC-bias within the radio receiver itself.

This is more of a generic radio question, meaning not just the nRF radios. Sending packets with payloads that include long bitwise '0' or '1' sequences can be a problem from some types of receivers, especially if the RF packet length is high.

The requirement of using whitening of the on-air payload is coming from the bluetooth specification itself, and there's several vendors out there that make bluetooth compatible radios, and to ensure interoperability between all types of receivers; they added this as a requirement for the on-air communication.

 

Kind regards,

Håkon

[Rob Garner]

Hi Håkon

Your explanations have clarified the issues for me. Thank you again for the fantastic support!

Cheers

Gunter