IQ sampling in BLE payload

[Jasperbrg]

Hello,

For my project I am interested in performing IQ sampling in the payload of a BLE packet, using nRF52833 at both receiver and transmitter.

I am manually configuring the RADIO peripheral at the receiver. As far as I understand, the bit DFECTRL1.DFEINEXTENSION should do the trick for me, by setting it to 0. However, modifying that bit by writing 0 to that bitfield does not change anything. It stays set to 1.

When I start the debugger and manually flip the bit at a breakpoint using the register editor, it seems to do the trick and the device behaves as expected. How can I achieve this without using the debugger?

This is the function I use to configure the sampling procedure.

void aoa_radio_rx_init(){
    NRF_RADIO->DFEMODE |= (RADIO_DFEMODE_DFEOPMODE_AoA << RADIO_DFEMODE_DFEOPMODE_Pos);
    NRF_RADIO->CTEINLINECONF |= (RADIO_CTEINLINECONF_CTEINLINECTRLEN_Disabled << RADIO_CTEINLINECONF_CTEINLINECTRLEN_Pos);
    NRF_RADIO->DFECTRL1 |= (RADIO_DFECTRL1_DFEINEXTENSION_Payload << RADIO_DFECTRL1_DFEINEXTENSION_Pos);
    NRF_RADIO->DFECTRL1 |= (RADIO_DFECTRL1_SAMPLETYPE_IQ << RADIO_DFECTRL1_SAMPLETYPE_Pos);
    NRF_RADIO->DFECTRL1 |= (RADIO_DFECTRL1_TSWITCHSPACING_2us<<RADIO_DFECTRL1_TSWITCHSPACING_Pos);
}

 

[Simonr]

Hi

Setting the DFEINEXTENSION bit to 0 and doing I/Q sampling in the payload will not be supported by Bluetooth and is for proprietary modes only, which is why it isn't mentioned in our Direction Finding Whitepaper (which focuses on BLE). How to use it is described in the PS (the output from the radio will be the same as for normal CTE, you just need to determine what to trig from and how much delay from the trigger point to the first sample to be taken), but as it will only be used for proprietary solutions it's difficult to describe in the likes of a white paper.

Best regards,

Simon

[Jasperbrg]

Hi Simon, thanks for the fast reply.

My issue right now is just that I cannot modify the DFEINEXTENSION bit for some reason, except when I use the register editor of the debugger as shown in the picture. But when I try to clear the bit in the code, it has no effect. Could there be some kind of write protection on that bit?

[Jasperbrg]

Edit: I see now that I had a logical mistake on my side. My bad. Thanks for your help!

[brook]

do you succeed in this task? 

[Jasperbrg]

Yes, I got it to work with this DFECTRL1 and DFECTRL2 configuration:

uint32_t conf;
conf = ((((uint32_t)20 << RADIO_DFECTRL1_NUMBEROF8US_Pos) & RADIO_DFECTRL1_NUMBEROF8US_Msk) |
    ((uint32_t)RADIO_DFECTRL1_DFEINEXTENSION_Payload << RADIO_DFECTRL1_DFEINEXTENSION_Pos) |
    ((uint32_t)RADIO_DFECTRL1_TSWITCHSPACING_4us << RADIO_DFECTRL1_TSWITCHSPACING_Pos) |
    ((uint32_t)RADIO_DFECTRL1_TSAMPLESPACINGREF_1us << RADIO_DFECTRL1_TSAMPLESPACINGREF_Pos) |
    ((uint32_t)RADIO_DFECTRL1_SAMPLETYPE_IQ << RADIO_DFECTRL1_SAMPLETYPE_Pos) |
    ((uint32_t)RADIO_DFECTRL1_TSAMPLESPACING_4us << RADIO_DFECTRL1_TSAMPLESPACING_Pos) |
    (((uint32_t)0 << RADIO_DFECTRL1_AGCBACKOFFGAIN_Pos) & RADIO_DFECTRL1_AGCBACKOFFGAIN_Msk));

NRF_RADIO->DFECTRL1 = conf;

conf = ((((int16_t)15 << RADIO_DFECTRL2_TSAMPLEOFFSET_Pos) & RADIO_DFECTRL2_TSAMPLEOFFSET_Msk) |
	    (((int16_t)2000 << RADIO_DFECTRL2_TSWITCHOFFSET_Pos) & RADIO_DFECTRL2_TSWITCHOFFSET_Msk));

NRF_RADIO->DFECTRL2 = conf;