CTEInfo receive with antenna switch

I am developing AoA for nRF52833.

Please tell me about antenna switching.

Setting:

PSEL.DFEGPIO[0]=28
PSEL.DFEGPIO[1]=29
PSEL.DFEGPIO[2]=30
PSEL.DFEGPIO[3]=31

SWITCHPATTERN=0x0
SWITCHPATTERN=0x0
SWITCHPATTERN=0x1
SWITCHPATTERN=0x2
SWITCHPATTERN=0x4
SWITCHPATTERN=0x8

GPIO.DIRSET=0xF0000000
GPIO.OUT=0x00000000

Use CTE inline mode.

If Advertising with CTEInfo is received, the antenna switch will work as expected.

If Advertising without CTEInfo is received, PORT28/29 will change immediately after receiving the Advertising. (It outputs a pulse)

(There will be no change if no Advertising is received at all)

Is this normal operation?

  • loquat said:
    'reference period' and 'sample period' will be output, but this is unnecessary processing.

    If you are referring to this "part of the protocol" then it definitely isn't unnecessary - it's important in order to find the bias etc.

    loquat said:
    Additionally there is an unnecessary delay between END_EVENT and PHYEND_EVENT.

    If you are seeing delays etc. that is interesting, but you will have to give us more details than that. You should measure this with a logic analyzer or PPK and give us what values for sample slot etc. you are using, or if you're simply using the default values. And whether you are using zephyr controller, and what ncs version. And you should definitely try this with NCS 2.2, as that is the only version we've tested and know that we have a QDID. Most likely you would just need to look at the WP.

    -Priyanka

  • Thanks.

    >isn't unnecessary

    The advertising does not include a CTE, so there is no need to switch antennas.

    Below are the AoA related configuration parameters.
    (Sorry, my environment is optimized for NCS2.9 and can no longer run on NCS2.2.)

    	RADIO_DEV->DFEMODE = (RADIO_DFEMODE_DFEOPMODE_AoA << RADIO_DFEMODE_DFEOPMODE_Pos);
    
    	const nrf_radio_cteinline_conf_t cteconf = {
    		.enable				= true,
    		.info_in_s1			= false,
    		.err_handling		= true,
    		.time_range			= NRF_RADIO_CTEINLINE_TIME_RANGE_20,
    		.rx1us				= NRF_RADIO_CTEINLINE_RX_MODE_2US,
    		.rx2us				= NRF_RADIO_CTEINLINE_RX_MODE_4US,
    		.s0_pattern			=  0b0000'0111,
    		.s0_mask			=  0b0000'1111,
    	};
    	nrf_radio_cteinline_configure(RADIO_DEV, &cteconf);
    
    	const nrf_radio_dfectrl_conf_t dfeconf = {
    		.dfe_len			= 20, /* 受信時はINLINE=disable時のみ有効 */
    		.extension			= NRF_RADIO_DFECTRL_EXTENSION_CRC,
    		.switch_spacing		= NRF_RADIO_DFECTRL_SWITCH_SPACING_2US,
    		.spacing_ref		= NRF_RADIO_DFECTRL_SAMPLE_SPACING_1US,
    		.sample_type		= NRF_RADIO_DFECTRL_SAMPLE_TYPE_IQ,
    		.sample_spacing		= NRF_RADIO_DFECTRL_SAMPLE_SPACING_2US,
    		.repeat_pattern		= 0,
    		.gain_steps			= 0,
    		.switch_offset		= 0,
    		.sample_offset		= 0,
    	};
    	nrf_radio_dfectrl_configure(RADIO_DEV, &dfeconf);
    
    	nrf_radio_dfe_buffer_set(RADIO_DEV, m_iq_sample, sizeof(m_iq_sample));
    
    

  • Hi

    Sorry about the late reply, but I've been tasked with taking over this case. Let me take a step back here before we move on. First off, what sample project have you used as the starting point here? The connectionless sample or peripheral + central samples? Is the image you uploaded of the no-CTEInfo diagram something you made yourself or have you found it in documentation somewhere?

    Since the CTEInfo is appended at the end of advertising packets (after the CRC), since the advertisement has told the application that there is CTEInfo appended, it might be that the guard/ref period is alreadty scheduled no matter what the CTEInfo is, and that's why you see these pulses. I will need to confirm with the devs whether or not this is the case though. How long is the delay between END_EVENT and PHYEND_EVENT exactly?

    Best regards,

    Simon

  • Thanks for the answer.

    The test code uses the Timeslot API and there is no base sample.

    I created the diagram.

    The interval between ND_EVENT and PHYEND_EVENT is about 12us.

  • Hi

    I don't think there is much to do with this interval I'm afraid. The PHYEND_EVENT is sent as soon as the last bit is sent/received on air while the EVENTS_END is triggered when a packet is sent/received.

    Best regards,

    Simon

Related