RE: Typo in documentation

Siddhesh — Mon, 08 Oct 2018 13:47:05 GMT

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.

RE: Typo in documentation

Bjørn Kvaale — Mon, 08 Oct 2018 13:37:27 GMT

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.