Device-os: BLE.setScanTimeout and BLE.setScanParameters fail

[mdgagne]

Bug Report

Calls to BLE.setScanTimeout or BLE.setScanParameters fail for all values of timeout stating the interval is out of range.

Expected Behavior

Firmware writers should be able to adjust ble scan parameters such as window, interval, or timeout.

Observed Behavior

Calls fail with -1, log displays: 000022690 [hal.ble] ERROR: params->interval < 0x0004

Steps to Reproduce

Call BLE.setScanTimeout or BLE.setScanParameters. The bounds checking in BleObject::Observer::setScanParams looks reversed and always causes the interval check to fail.

firmware: 1.3.0-rc

Test App

SerialLogHandler handler (LOG_LEVEL_ALL);

void setup() {
  // A minimal test case to reproduce the issue is super helpful!
BleScanParams scanParams;
scanParams.version = BLE_API_VERSION;
scanParams.size = sizeof(BleScanParams);;
BLE.getScanParameters (&scanParams);
scanParams.interval = 10;
scanParams.timeout = 10;
auto result = BLE.setScanParameters (&scanParams);
Serial.printf("setScanParameters result: %u\n", result);

result = BLE.setScanTimeout (100);
Serial.printf("setScanTimeout result: %u\n", result);
}

void loop() {
auto startTime = millis ();
auto results = BLE.scan ();
auto stopTime = millis ();
Serial.printf ("Spent %u millis scanning BLE devices\n", stopTime - startTime);
}

Output

0000021739 [hal.ble] ERROR: params->interval < 0x0004 failed: -270
setScanParameters result: 4294967026
0000021743 [hal.ble] ERROR: params->interval < 0x0004 failed: -270
setScanTimeout result: 4294967026
Spent 5001 millis scanning BLE devices

[mdgagne]

I got by this problem with a local update to ble_hal.cpp but still cannot get the scan timeout to work appropriately. As far as I can tell, the lower timeout limit seems to be 1000ms. The NRF docs indicate that this timeout should be configurable down to 10 ms (scanParams.timeout = 1)

[XuGuohui]

👍

I have confirmed this issue after looking into the source code. It will be fixed with next release.

Thanks for reporting the issue!

[XuGuohui]

https://github.com/particle-iot/device-os/commit/ce6e198f12c9676d2766b6cd5aeef4d894b6993d

[dominicgermana]

@mdgagne wrote:

I got by this problem with a local update to ble_hal.cpp but still cannot get the scan timeout to work appropriately. As far as I can tell, the lower timeout limit seems to be 1000ms. The NRF docs indicate that this timeout should be configurable down to 10 ms (scanParams.timeout = 1)

Testing with the fix/BLE/v1.3.1-rc.1 branch, I can confirm that the timeout parameter is now adjustable, however it appears to be limited to integer value seconds, instead of the 10 ms increments described in the documentation.

Timeout value => Actual scan duration:
1 => 1000 ms
100 => 1000 ms
190 => 1000 ms
200 => 2000 ms
290 => 2000 ms

In my usage case, I'm trying to get refreshed scan data from peripherals faster than 1 Hz, but with a minimum timeout value of 1 second, 1 Hz is the fastest I can get new data. Even when I use the callback method of BLE.scan(), it will only return 1 result per BLE device per scan(). Apparently, scan() must filter by MAC address to avoid returning more than 1 result per scan from each MAC address.

[XuGuohui]

Apparently, scan() must filter by MAC address to avoid returning more than 1 result per scan from each MAC address.

That's true. And I can also observe this issue. I'm looking into this.

[XuGuohui]

Just a FYI, there is a ticket on Nordic dev zone related to this issue: https://devzone.nordicsemi.com/f/nordic-q-a/50386/ble-scan-timeout-always-in-multiple-of-second

[XuGuohui]

The scanning timeout issue has been confirmed that it is a known issue related to the SoftDevice 6.0.0 which has been pre-programmed to the shipped nRF52840 dev kits. Currently, Particle Device OS doesn't support upgrading the SoftDevice, but hopefully it should be capable of doing that since v1.3.1. Alternatively, you can manually flashing the SoftDevice 6.1.1 (upper version is not supported by Device OS) to fix this issue temporarily.

[avtolstoy]

Just to clarify, starting with the next release (1.3.1-rc.1) you should be able to manually update the SoftDevice using the CLI, provided the SoftDevice binaries are wrapped with our standard module header and footer (we will release such binaries). SoftDevice 7.0.0 should also be supported starting with 1.3.1-rc.1 (https://github.com/particle-iot/openthread/commit/e2d61d7adc142cf5fba096f9831d3801d1d93ef6), however we haven't yet done much testing with it.

In the next minor release (1.4.0) we'll add a dependency on the newer version of SoftDevice and it should get updated automatically for all the devices running DeviceOS 1.4.0.

As of right now, the only way of updating the SoftDevice is taking 6.1.1 hex file and manually flashing it using the debugger in its location.

[JeffreyKidwell]

@avtolstoy any idea when that next release is scheduled to come out?

[avtolstoy]

@JeffreyKidwell We are targeting somewhere next week, depending on how the testing goes.

[XuGuohui]

https://github.com/particle-iot/device-os/pull/1816