51822 RF setting Problem

[Chester]

For our application, As I used 24LU1(host) with 51822(device) be the platform. I hope to transmit Audio data with 8 kHz, 10 bits data format. To commit the requirements , I send a packet with 32 bytes payload every 2 ms, the details settings as follow:

using semi- synchronization nrf_gzll_set_timeslots_per_channel_when_device_out_of_sync (NRF_GZLL_DEFAULT_TIMESLOTS_PER_CHANNEL*NRF_GZLL_DEFAULT_CHANNEL_TABLE_SIZE) nrf_gzll_set_device_channel_selection_policy (NRF_GZLL_DEVICE_CHANNEL_SELECTION_POLICY_USE_CURRENT)

On host

On Device

Q1 The transmission will loss packet continually sometimes, I guess the reason why is about out of synchronization. Is there exist other possible problem?

Q2 nrf_gzll_set_sync_lifetime() How it works? I guess the function is to set the time of maintaining in sync state.

Q3 Does nrf_gzll_set_xosc_ctl(NRF_GZLL_XOSC_CTL_AUTO)，gzll clock affect the packets transmission ? Could it be auto?

[Håkon Alseth]

I will recommend that you try my comments for Q3 first before altering any other gazell configurations.

Q1. Most likely it's because you're losing sync. I would recommend that you scope the VDD_PA pin on your device, and post the results here. This pin will go high for each TX on-air operation, and will give you a good overview if the sync is off.

Q2. This function sets the number of timeslots that the device considers itself to be in sync with the host after a successful transfer. In your case, if you set this to 10, it will consider itself in sync for 10 x timeslot (with no successful communication) before the link is not-in-sync. If after 9 timeslots you receive an ACK from the host, the link will be considered in-sync for the whole process.

This means that you can get one packet through every 9 timeslots (9 ms in your case), giving a throughput of 3.5 kBps, and your link is considered in sync for the whole period.

Try these settings. Host:

#define GZLL_DEFAULT_PARAM_RX_CHANNEL_HOLD_PERIODS 5

Device:

nrf_gzll_set_device_channel_selection_policy(NRF_GZLL_DEVICE_CHANNEL_SELECTION_POLICY_USE_SUCCESSFUL);

This will cause your link to be asynchronous, but it will force the host to not switch RF channel for 10 ms if it receives a packet. The device will then start communication on the last successful RF channel. This will be a "frequency agility" approach, where the host and device only changes RF channel when the re-transmission count is high.

This approach is not very good if you have other devices that needs consistent data transfer, as it disrupts the host listening pattern.

Q3: This will cause the external 16M to be stopped/started by the gazell library. Note that it takes up to 1.5 ms for a 16M xtal to start up (nom. 800 - 1000 us on most xtals). I would recommend that you set this to NRF_GZLL_XOSC_CTL_MANUAL, and start the xtal manually before enabling the gazell library:

// Start 16 MHz crystal oscillator.
NRF_CLOCK->EVENTS_HFCLKSTARTED = 0;
NRF_CLOCK->TASKS_HFCLKSTART    = 1;

// Wait for the external oscillator to start up.
while (NRF_CLOCK->EVENTS_HFCLKSTARTED == 0) 
{
    // Do nothing.
}