Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BLE.setScanTimeout and BLE.setScanParameters fail #1855

Closed
mdgagne opened this issue Jul 14, 2019 · 11 comments

Comments

@mdgagne
Copy link

commented Jul 14, 2019

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 mdgagne changed the title BLE.setTimeout and BLE.setScanParameters fail BLE.setScanTimeout and BLE.setScanParameters fail Jul 14, 2019

@mdgagne

This comment has been minimized.

Copy link
Author

commented Jul 15, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jul 15, 2019

👍

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

Thanks for reporting the issue!

@XuGuohui

This comment has been minimized.

Copy link
Contributor

commented Jul 15, 2019

@dominicgermana

This comment has been minimized.

Copy link

commented Jul 29, 2019

@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

This comment has been minimized.

Copy link
Contributor

commented Jul 30, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Aug 1, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Aug 5, 2019

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

This comment has been minimized.

Copy link
Member

commented Aug 5, 2019

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 (particle-iot/openthread@e2d61d7), 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

This comment has been minimized.

Copy link

commented Aug 5, 2019

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

@avtolstoy

This comment has been minimized.

Copy link
Member

commented Aug 5, 2019

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

@technobly technobly added the bug label Aug 14, 2019

@XuGuohui

This comment has been minimized.

Copy link
Contributor

commented Sep 15, 2019

@XuGuohui XuGuohui closed this Sep 15, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.