RE: Measuring RTT & RSSI through Radio States

MartinBL — Tue, 13 Nov 2018 12:21:23 GMT

Hi,

Sorry for the late response. Your case fell through the cracks.

I agree with all your reasoning and conclusions. The nRF5 series simply isn't built for these kinds of things.

I have one last suggestion though. You can look into using the Timeslot API and some sort of custom radio protocol and PPI/software hybrid. Using the timeslot API you can schedule "sessions" where you are allowed to use the radio at your own discretion between the BLE events. With a custom radio protocol you can work directly with the radio peripheral and have complete control what, when, and where things are being transmitted and received. You are also free to use a combination of software and PPI to time the events. You might find some inspiration in this blog post: https://devzone.nordicsemi.com/b/blog/posts/wireless-timer-synchronization-among-nrf5-devices

RE: Measuring RTT & RSSI through Radio States

M. Corrente — Fri, 02 Nov 2018 18:36:08 GMT

Bump

RE: Measuring RTT & RSSI through Radio States

M. Corrente — Tue, 25 Sep 2018 23:04:00 GMT

Hi, thank you for the guidance.

So, with PPI I am able to Start / Stop / Clear timers, however, I need to be able to save their value inbetween connection events and mostly, between links, ideally, it should be done when the radio is in the "t_prep" interval, but I'm guessing that access to radio (and CPU) will still be locked.

If the t_prep takes from 167us to 1542us I could be possible get a interrupt done through SWI solely to run a fast routine that saves the timers value to some data vector.

So, in order to capture the processing delay on the peer, the radio events that PPI will listen to are:

READY - Clear Timer - Radio is ready
DEVMATCH - Start Timer - Peer acked packet
CRCERROR - Stop Timer (and maybe clear) - Dispose
ADDRESS - Stop Timer - Peer is now Tx

After the ADDRESS event, the timer holds the delay value, however, for a multi link situation (the peer will be connected to 3 centrals simultaneously), the next link will just re-start the timer.

I am not seeing a good solution for this problem. Radio notifications only occur at the beginning and end of the radio event containing multiple links, not usable.

Another problem is that for each link, multiple packets are exchanged, but it wouldn't be too bad if I would only be able to get a read on the last one.

The only solution I can imagine right now is some sort of external peripheral with some sort of state machine and access to the timers registers, controlled through GPIOTE. That or a completely different approach, using unconnected devices, where the Centrals send SCAN_REQ packets and the peers responds, but still, if the SCAN_REQ arrive in the same connection event, the same issue arises (and collisions would be more frequent).

Using the given API for PPI I generated the following init for the peer (not tested):

void init_ppi(void)
{
    nrf_ppi_channel_t ppi_ch0, ppi_ch1, ppi_ch2;

    nrfx_ppi_channel_alloc(&ppi_ch0);
    nrfx_ppi_channel_alloc(&ppi_ch1);
    

    // DEV MATCH - Start Timer
    nrfx_ppi_channel_assign(ppi_ch0,
	            &NRF_RADIO->EVENTS_DEVMATCH,
	            nrf_drv_timer_task_address_get(&delay_counter,
			           NRF_TIMER_TASK_START) );
		
    // CRC ERROR - Stop Timer
    nrfx_ppi_channel_assign(ppi_ch1,
	            &NRF_RADIO->EVENTS_CRCERROR,
	            nrf_drv_timer_task_address_get(&delay_counter,
			           NRF_TIMER_TASK_STOP) );
	
    // READY - Clear Timer
    nrfx_ppi_channel_fork_assign(NRF_PPI_CHANNEL24,
		 nrf_drv_timer_task_address_get(&delay_counter,
			           NRF_TIMER_TASK_CLEAR));
	
    // ADDRESS - Stop Timer
    nrfx_ppi_channel_fork_assign(NRF_PPI_CHANNEL25,
		 nrf_drv_timer_task_address_get(&delay_counter,
			           NRF_TIMER_TASK_STOP));
    
    uint32_t ppi_mask = (1 << 0) |
	        (1 << 1) |
	        (1 << 2);
	        //(1 << 25);
    nrfx_ppi_channels_include_in_group(ppi_mask, NRF_PPI_CHANNEL_GROUP0);
    
    nrfx_ppi_group_enable(NRF_PPI_CHANNEL_GROUP0);
}

For central devices, they would one be connected to one peer at a time, so measuring the RTT should still be possible using PPI and radio notifications:

READY - Clear Timer - Radio is ready
ADDRESS- Start Timer - Packet address sent
CRCERROR - Stop Timer (and maybe clear) - Dispose
DEVMATCH- Stop Timer - Receiving Peer Response

And through the radio notification (nActive) get the timer values.

--- UPDATE ---

So, upon closer inspection of the radio states diagram.

I came to the conclusion that using PPI to Start/Stop the timers alone will not work aswell,

For Central Devices (measuring RTT):

[DISABLED]

	-->TXEN
	[TXRU]
	READY					PPI: Clear Timer
	[TXIDLE]
	-->START
		[TX]
			ADDRESS			PPI: Start Timer
			PAYLOAD
			END
	[TXIDLE]
		
	-->RXEN
	[RXRU]
	READY					PPI: Clear Timer
	[RXIDLE]
	-->START
		[RX]
			ADDRESS			PPI: Start Timer
			DEVMATCH		PPI: Stop Timer
			PAYLOAD
			END
	[RXIDLE]
	
	-->DISABLE
[DISABLED]



For the Peer Device (measuring Processing Delay):

[DISABLED]

	-->RXEN
	[RXRU]
	READY					PPI: Clear Timer
	[RXIDLE]
	-->START
		[RX]
			ADDRESS			PPI: Stop Timer
			DEVMATCH		PPI: Start Timer
			PAYLOAD
			END
	[RXIDLE]

	-->TXEN
	[TXRU]
	READY					PPI: Clear Timer
	[TXIDLE]
	-->START
		[TX]
			ADDRESS			PPI: Stop Timer
			PAYLOAD
			END
	[TXIDLE]
	
	-->DISABLE
[DISABLED]

Legend:

[ ] - Radio States;
--> - Tasks;
Simple words - Events that PPI can use.

Without knowing if the radio is currently in Tx or Rx mode and use Start/Stop accordingly, it just seems impossible.

Thank you for the assistance,

Marco.

RE: Measuring RTT & RSSI through Radio States

MartinBL — Thu, 13 Sep 2018 13:07:59 GMT

When the Softdevice is enabled your access to the Radio peripheral is blocked. Here is a list of blocked and restricted peripherals.

You can look into using Radio Notifications instead. It allows you to get notified whenever the radio ramps up or down. Here is a (somewhat outdated) tutorial.

You might also look into using PPI to start and stop your timers directly on specific radio events. To get you started you can use this simple code to make LED 4 toggle each time a packet is sent or received:

void toggle_gpio_on_radio_end_event()
{
    NRF_GPIOTE->CONFIG[0] = (GPIOTE_CONFIG_MODE_Task << GPIOTE_CONFIG_MODE_Pos) |
                            (LED_4 << GPIOTE_CONFIG_PSEL_Pos) |
                            (GPIOTE_CONFIG_POLARITY_Toggle << GPIOTE_CONFIG_POLARITY_Pos) |
                            (GPIOTE_CONFIG_OUTINIT_Low << GPIOTE_CONFIG_OUTINIT_Pos);
    NRF_PPI->CH[0].EEP = (uint32_t)&NRF_RADIO->EVENTS_END;
    NRF_PPI->CH[0].TEP = (uint32_t)&NRF_GPIOTE->TASKS_OUT[0];
    NRF_PPI->CHENSET |= 1;
}