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 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