• State Verified Answer
  • Replies 1 reply
  • Subscribers 68 subscribers
  • Views 788 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 236079
Options
Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Can't extend Gazell timeslot beyond 65535 us

Pete W

Hi,

Our application requires a Gazell device to be put into a 'slow' mode whereby it transmits a very short packet periodically but at a slow rate, e.g. once a second, until it is acknowledged by the host, at which point we reconfigure and restart with a much shorter timeslots. Unfortunately I can't get beyond 65.535 ms, even though the parameter in the nrf_gzll_set_timeslot_period(xxx) is 32 bit. Is this a bug? (I know we could use BLE but Gazell is a better match for our application).

Regards

Pete

Parents
  • +1

    Hi Pete,

     

    This is an inherited restriction from the TIMER configuration, which is set in a 16 bit width. This is due to the nRF51-series devices only having 1 timer instance that could do > 16 bit width.

    However, when running on nRF52-devices, this restriction should not be a restriction, as it can do up to 32 bit on all timer instances. Thank you for reporting this to us, I'll report this internally.

     

    Kind regards,

    Håkon

Reply
  • +1

    Hi Pete,

     

    This is an inherited restriction from the TIMER configuration, which is set in a 16 bit width. This is due to the nRF51-series devices only having 1 timer instance that could do > 16 bit width.

    However, when running on nRF52-devices, this restriction should not be a restriction, as it can do up to 32 bit on all timer instances. Thank you for reporting this to us, I'll report this internally.

     

    Kind regards,

    Håkon

Children
No Data
Related