More Frequent BLE Scan (Specifically, RSSI change) Results

[swanav]

I am working on a BLE Product which connects to a remote device when detected within a certain proximity (based on the RSSI values).
After switching on the scanning, I receive Scan Results almost every 2 seconds. The thing is I want the RSSI tracking to be smoother, 300 ms at max, so that connection is almost instantaneous when the device is found in the range. I have tried fiddling with the Scan Interval and Durations, but the frequency at which the application receives the scan results is unaffected. Can someone please give me some pointers on how that parameter can be changed?

[tesc]

Hi,

I see that the ticket is tagged with nRF5 SDK for Mesh. Is this a Bluetooth mesh application?

In that case, please note that if you use the SoftDevice API (or nRF5 SDK libraries) for scanning, it will compete for radio time with the mesh stack.

If you have a clean BLE application (no Bluetooth mesh) you can have a look at the Scheduling chapter of the SoftDevice Specification, in particular Suggested intervals and windows.

If you use Bluetooth mesh, through nRF5 SDK for Mesh, then you can have a look at the scanner role implementation there, which has a callback that is showcased in the Beaconing example. With that, all advertisements received by the mesh stack can be forwarded to the application through the registered callback function. Note however that this does not hook into the SoftDevice scanner / nRF5 SDK libraries, and so you cannot use that for establishing a connection directly.

Regards,
Terje

[swanav]

Hi Terje!

Thanks for your response! You are right, the application does use the BLE mesh stack.

Registering the callback with nrf_mesh_rx_cb_set(rx_cb); helps me get the payload information from raw packets, but the callback is still called after that 2s interval.

For your reference, I am referring to then difference in these timestamps. 14564523 and 14857948.

I need a way to minimise this difference. This might be battery intensive, but I do not expect my application to run in this state for long. I just need to discover that my device is in this vicinity and provision it afterwards.

<t: 14546745>, main.c, 642, RX [@443930985]: RSSI: -26 ADV TYPE: 2 ADDR: [06:5f:71:b2:67:ac]: 172A57340D18AD7B06BAFAEAD6CE83B53A00E312D9E33382
<t: 14547851>, main.c, 642, RX [@443964735]: RSSI: -26 ADV TYPE: 2 ADDR: [06:5f:71:b2:67:ac]: 172A57340D18AD7B06BAFAEAD6CE83B53A00E312D9E33382
<t: 14548998>, main.c, 642, RX [@443999735]: RSSI: -27 ADV TYPE: 2 ADDR: [06:5f:71:b2:67:ac]: 172A57340D18AD7B06BAFAEAD6CE83B53A00E312D9E33382
<t: 14550227>, main.c, 642, RX [@444037235]: RSSI: -27 ADV TYPE: 2 ADDR: [06:5f:71:b2:67:ac]: 172A57340D18AD7B06BAFAEAD6CE83B53A00E312D9E33382
<t: 14551537>, main.c, 642, RX [@444077236]: RSSI: -26 ADV TYPE: 2 ADDR: [06:5f:71:b2:67:ac]: 172A57340D18AD7B06BAFAEAD6CE83B53A00E312D9E33382
<t: 14563868>, main.c, 642, RX [@444453486]: RSSI: -26 ADV TYPE: 2 ADDR: [06:5f:71:b2:67:ac]: 172B0100766999C335A8AF62000000003E6BC8C7134C1018
<t: 14564523>, main.c, 642, RX [@444473486]: RSSI: -26 ADV TYPE: 2 ADDR: [06:5f:71:b2:67:ac]: 172B0100766999C335A8AF62000000003E6BC8C7134C1018
<t: 14857948>, main.c, 558, Node 0x0108 alive with 0 active fault(s), RSSI: -24
<t: 14857955>, main.c, 642, RX [@453427890]: RSSI: -24 ADV TYPE: 2 ADDR: [06:5f:71:b2:67:ac]: 172A57203D1D01FF5BAECBD8742E4B9B9082BC81E74D9DBE
<t: 14859250>, main.c, 642, RX [@453467890]: RSSI: -24 ADV TYPE: 2 ADDR: [06:5f:71:b2:67:ac]: 172A57203D1D01FF5BAECBD8742E4B9B9082BC81E74D9DBE
<t: 14860438>, main.c, 642, RX [@453504140]: RSSI: -24 ADV TYPE: 2 ADDR: [06:5f:71:b2:67:ac]: 172A57203D1D01FF5BAECBD8742E4B9B9082BC81E74D9DBE
<t: 14861667>, main.c, 642, RX [@453541640]: RSSI: -24 ADV TYPE: 2 ADDR: [06:5f:71:b2:67:ac]: 172A57203D1D01FF5BAECBD8742E4B9B9082BC81E74D9DBE
<t: 14862937>, main.c, 642, RX [@453580390]: RSSI: -24 ADV TYPE: 2 ADDR: [06:5f:71:b2:67:ac]: 172A57203D1D01FF5BAECBD8742E4B9B9082BC81E74D9DBE
<t: 14864043>, main.c, 642, RX [@453614140]: RSSI: -24 ADV TYPE: 2 ADDR: [06:5f:71:b2:67:ac]: 172A57203D1D01FF5BAECBD8742E4B9B9082BC81E74D9DBE
<t: 14865108>, main.c, 642, RX [@453646640]: RSSI: -24 ADV TYPE: 2 ADDR: [06:5f:71:b2:67:ac]: 172A57203D1D01FF5BAECBD8742E4B9B9082BC81E74D9DBE
<t: 14866296>, main.c, 642, RX [@453682890]: RSSI: -24 ADV TYPE: 2 ADDR: [06:5f:71:b2:67:ac]: 172A57203D1D01FF5BAECBD8742E4B9B9082BC81E74D9DBE 

[swanav]

Hi Terje!

Yep. The example that I am using right now is the provisioner example from the nRF Mesh SDK. Where I have added a condition on the RSSI during scan before proceeding to provision it.

So, I don't think there should be any major activity going on with the flash.

I have verified that the advertising device does not pause in between.

Regards,

Swanav

[tesc]

Hi,

I am sorry for the delays. We are in contact with the mesh SDK developers in order to figure out what might be the issue.

You should expect a response within 1-2 days.

Regards,
Terje

[tesc]

Hi,

We provided a follow-up in the thread BLE Mesh intermittent behavior last week, have you tried changing the scan time as suggested there?

Regards,
Terje

[swanav]

Hi Terje,

Sorry for the delayed response.

The issue with the Scan Time has been resolved with the scanner_config_scan_time_set API on the provisioner and the configuring the NRF_MESH_PROV_BEARER_ADV_UNPROV_BEACON_INTERVAL_MS macro on the node.

[tesc]

Hi,

Thank you for the update. I am happy to hear that the issue is resolved.

Regards,
Terje