GZLL Channel switching mechanism

[E-hao]

Hi, we're having some problems and need help.
We have a usage scenario: in HOST mode, the switching rate is 250k/2M every 10ms, the time slots of the two rates are different, and the channel is shared. Whenever the program wants to switch rates, it reconfigures the datarate/timeslot_period/tx_attempts parameter nrf_gzll_enable() after nrf_gzll_disable() is done. Sending and receiving share a set of channel tables, with a total of 5 channels, but the number of retransmissions sent can only be sent to the second channel, and the receiving 10ms window at 250k rate can only run 5 slots.
Under such a mechanism, there is a probability that we will not receive the data and cannot recover it without calling reinitialization. What I'm wondering is whether this problem is related to the misalignment of the channel on the sending and receiving side, and whether the initial receiving channel at each switching rate is from channel 0 or from the channel at disable.

[Sigurd]

Hi!

What SDK and SDK version are you using?

[E-hao]

nRF5_SDK_12.3.0_d7731ad

[Sigurd]

Thanks. I would need to check this with our GZLL experts. Expected answer within a few weeks.

[E-hao]

Hello, it has been three weeks since the last reply. Is there any definitive news from the GZLL expert?

[Håkon Alseth]

Hi,

 

If I understand the scenario correctly, you are continuously disable/re-config/enable gazell, and after a while the devices cannot communicate with the host.

A re-init of gazell fixes this issue.

 

Please correct me if my understanding is incorrect.

 

Could you share the gazell settings of both host and device?

 

Kind regards,

Håkon

[E-hao]

Hi,

Your understanding is correct; there are some translation errors in the question.

The settings are as follows.

Number of channels: 5

Channel selection strategy: USE_CURRENT

Master device rate: Fixed at 2M or 250k, with the issue occurring in the 250k configuration.

At 250k rate, the time slot is 2596, and the number of retries is 16;

at 2M rate, the time slot is 600, and the number of retries is 70.

Slave device rate: Switches between 250k and 2M every 10ms upon power-up, and will fixate on the current rate configuration after receiving valid data; the time slot and retry count configurations are consistent with the master device.

Single-channel transmission time slot: 10

Single-channel reception time slot: 2

[Håkon Alseth]

Hi,

 

E-hao said:

Channel selection strategy: USE_CURRENT

This is a synchronous mode, meaning that the gazell device (transmitter) will try to sync towards the gazell host channel table rotation.

If your "out of sync" settings here are configured similar to the "in sync" settings, you can potentially always be transmitting on the incorrect RF channel.

When out of sync, you should setup "nrf_gzll_set_timeslots_per_channel_when_device_out_of_sync" equal to "channel-tab size * timeslots_pr_chan"

This will ensure that the device will transmit a whole "host channel table cycle" on the same channel.

E-hao said:

At 250k rate, the time slot is 2596,

We recommend that the timeslot is 2700 us or greater for 250 kbit:

/**
 * @brief Set the timeslot period.
 *
 * The length in microseconds of a Gazell link layer timeslot.
 *
 * The minimum value of the timeslot period is dependent of the
 * radio data rate (@sa nrf_gzll_set_datarate()).
 *
 * - For NRF_GZLL_DATARATE_2MBIT the timeslot period must be >= 600 us.
 * - For NRF_GZLL_DATARATE_1MBIT the timeslot period must be >= 900 us.
 * - For NRF_GZLL_DATARATE_250KBIT the timeslot period must be >= 2700 us.
 *
 * @param period_us The timeslot period in microseconds.
 *
 * @retval true  If the parameter was set.
 * @retval false If Gazell was enabled.
 */
bool nrf_gzll_set_timeslot_period(uint32_t period_us);

 

E-hao said:

Single-channel transmission time slot: 10

Single-channel reception time slot: 2

Q1: Can you share your gazell init C code configurations for both gazell host and gazell device?

Q2: Do you use the same address with each gazell device?

Q3: When disable/re-configure/enable, do you wait until gazell is fully disabled?

 

Kind regards,

Håkon

[E-hao]

Hi, thank you for your response.

We had already tried the suggestions you mentioned before the issue was reported. After modifying the configuration, we did not encounter the freezing issue again. We raised this question to understand the root cause of the problem, so we can avoid making the same mistakes in the future. Thank you!

Here are the answers to your inquiries:

1. The initialization code is as follows

   void User_Gzll_Init(void)
   {
   	uint32_t device_address0;
   	
   	bool result_value = nrf_gzll_init( NRF_GZLL_MODE_HOST );
   	
   	nrf_gzll_set_base_address_0(device_address0);
   	nrf_gzll_set_base_address_1(device_address1);
   	
   	nrf_gzll_set_timeslots_per_channel(NRF_GZLL_DEFAULT_TIMESLOTS_PER_CHANNEL); //2
   	nrf_gzll_set_device_channel_selection_policy(NRF_GZLL_DEVICE_CHANNEL_SELECTION_POLICY_USE_CURRENT);
   //	nrf_gzll_set_timeslots_per_channel_when_device_out_of_sync(NRF_GZLL_DEFAULT_CHANNEL_TABLE_SIZE*NRF_GZLL_DEFAULT_TIMESLOTS_PER_CHANNEL); //2*5 config before Sending
   	
   	nrf_gzll_set_channel_table(NRF_GZLL_USER_CHANNEL_TABLE, NRF_GZLL_DEFAULT_CHANNEL_TABLE_SIZE); //5 channels
   	
   	nrf_gzll_set_tx_power(NRF_GZLL_TX_POWER_0_DBM);
   	
   	nrf_gzll_set_datarate(current_baud ); 
   	
   	if(current_baud == NRF_GZLL_DATARATE_2MBIT)
   	{
   		rf_period_time = RF_2M_PERIOD_TIME; //600
   		rf_retry_count = RF_2M_RETRY_COUNT; //70
   	}
   	else
   	{
   		rf_period_time = RF_250K_PERIOD_TIME; //2596
   		rf_retry_count = RF_250K_RETRY_COUNT; //16
   	}
   
   	nrf_gzll_set_timeslot_period(rf_period_time);
   	nrf_gzll_set_max_tx_attempts(rf_retry_count);  
   	
   	nrf_gzll_flush_tx_fifo(0);
   	nrf_gzll_flush_rx_fifo(0);
   	
   	result_value = nrf_gzll_enable();
       GAZELLE_ERROR_CODE_CHECK(result_value);
   
   }

2. The host and device addresses are different. We switch to the target device's address before sending and switch back to our device's address after transmission;
3. We can confirm that all configurations are modified after the disable callback has been triggered.