• State Verified Answer
  • Replies 6 replies
  • Subscribers 68 subscribers
  • Views 2894 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 235871
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Sub oscillator usage when using Gazell protocol

astella

To the kind attention of Nordic support team,

We are going to use gazell protocol for some of our wireless products. Could you please point me out to the relevant documentation about how gazell protocol machine gets its time base? Do you recommend the usage of the XL1, XL2 sub oscillator for more precision? I have to say that our device is not going to have power problems, so will it suffice to have the main oscillator and trigger any sort of software correction? In this case is there some change that must be done to the code in order to inform the gazll stack about the timing source? 

Parents
  • 0

    I believe you should be able to find answers to your questions in the documentation:
    https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.sdk5.v15.3.0/gzll_02_user_guide.html?cp=5_1_5_3 

    There is no exact answer here, but the Gazell protocol will be able to maintain synchronization for 50-100ms.

  • 0 in reply to Kenneth

    Thank you very much for your advises. They are really helpful. The second one and the third are clear, we understand how to put them into practice. May you please explain a little bit further the first one, please? We are going to use multiple devices and a gazell host. So it should be nice to better comprehend your meaning. It is clear that we want to theoretically avoid congestion as much as it is possible. May you please argument with a little practical example what is the gazell parameter that is key in this aspect? Thanks in advance 

  • 0 in reply to astella

    The time a device will keep track of the synchronization with the host is configured through nrf_gzll_set_sync_lifetime(). If several devices are transmitting, and they keep synchronization and they call nrf_gzll_add_packet_to_tx_fifo() close to the same time, they will try to transmit at the same time based on the synchronization with the host timing. This will very likely cause collision on-air, where neither device are able to successfully transmit it's data, and the devices will keep trying at the same time due to the synchronization that is in place. It's only once one or both finally lose synchronization that they will be able to successfully transmit again. That is why I say that all device should in general use nrf_gzll_set_sync_lifetime() with a value of 0 to imply that the link is always out of sync. You may however choose one device that can use nrf_gzll_set_sync_lifetime() with a value different of 0.

Reply
  • 0 in reply to astella

    The time a device will keep track of the synchronization with the host is configured through nrf_gzll_set_sync_lifetime(). If several devices are transmitting, and they keep synchronization and they call nrf_gzll_add_packet_to_tx_fifo() close to the same time, they will try to transmit at the same time based on the synchronization with the host timing. This will very likely cause collision on-air, where neither device are able to successfully transmit it's data, and the devices will keep trying at the same time due to the synchronization that is in place. It's only once one or both finally lose synchronization that they will be able to successfully transmit again. That is why I say that all device should in general use nrf_gzll_set_sync_lifetime() with a value of 0 to imply that the link is always out of sync. You may however choose one device that can use nrf_gzll_set_sync_lifetime() with a value different of 0.

Children
No Data
Related