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

Typo in documentation

In SDK 15.2 in ble_gap.h

#define BLE_GAP_SCAN_WINDOW_MAX         0xFFFF /**< Maximum Scan window in 625 us units, i.e. 40,959.375 s. */

#define BLE_GAP_SCAN_INTERVAL_MAX       0xFFFF /**< Maximum Scan interval in 625 us units, i.e. 40,959.375 s. */

Shouldn't this be 40,959.375 ms and not s.

This would mean the max window for scan and scan interval would be limited to 40 secs and not 40k secs as the document suggests.

What would be a good way to increase the scan window to minutes ?

Parents
  • Yep, looks wrong to me. Should be 40.959375 seconds or 40,959.375 ms. I will report this internally. Thanks for the feedback!

    The scanning device will continuously scan based on the scanning interval & window. The scanning interval says how often the central scans for advertising packets & the scan window says how long the central should scan for. Also, the scanner will continuously loop between the three advertising channels after each scanning interval until the scan timeout is reached (see code below found in ble_gap.h).

    /**@defgroup BLE_GAP_SCAN_TIMEOUT GAP Scan timeout max and min
     * @{ */
    #define BLE_GAP_SCAN_TIMEOUT_MIN        0x0001 /**< Minimum Scan timeout in 10 ms units, i.e 10 ms. */
    #define BLE_GAP_SCAN_TIMEOUT_UNLIMITED  0x0000 /**< Continue to scan forever. */

    See this blog post for more info & some good diagrams. This devzone case could also be helpful.

    May I ask why you want to increase the scan window? As the devzone case link clearly states, long scanning windows can lead to problems if you have multiple connections to one central or delays in executing flash commands or timeslot api executions.

  • Hi Bjorn,

    In our application we are simply scanning for advertisements and not establishing connections. Since those advertisements are event based, we can work with longer scan times to make a response to it. Since our sensor is advertising and scanning at the same time, longer scan times will result in lesser average current draw.

    However, it's always a balancing act trying to find the right numbers for it. Thanks for the quick response.

Reply
  • Hi Bjorn,

    In our application we are simply scanning for advertisements and not establishing connections. Since those advertisements are event based, we can work with longer scan times to make a response to it. Since our sensor is advertising and scanning at the same time, longer scan times will result in lesser average current draw.

    However, it's always a balancing act trying to find the right numbers for it. Thanks for the quick response.

Children
No Data
Related