Evaluate nimBLE vs Bluedroid

[FlorianLudwig]

Experimenting results

Setup

• A esp32 is running GAP advertising with an advertising period of 1000-1100 ms.
• Two esp32 are running a BLE scanner. They only count advertising packages from the esp32 mentioned above. Other advertising packages from other devices will not be counted. The number of counted advertising packages are compared.

Results

esp32 scanner (NimBLE) vs. esp32 scanner (Bluedroid)

In a scanning period of 15 minutes, a bluedroid scanner registered 864 ble advertising packages while a nimble scanner only registered 128. Both scanners were configured with similar scan settings. However, nimble can be tewaked to scan faster. With these tweaked settings, simultaneously advertising seems to make a little difference.

-- @ju-mueller

[ju-mueller]

I did some tests comparing a nimble scanners with and without advertising as well as nimlbe scanners with bluedroid scanners. The code I used and my test results can be found here

[cyberman54]

How about the RF setup in this experiment? Were all 3 devices screened from outer RF, e.g. put in a microwave oven or metal box?

[FlorianLudwig]

Hi @cyberman54 ,

the tests without any special RF setup. The counting was just limited to a specific mac address, as the test did not test mac/device counting but package counting.

Most of the test did focus on the effect of having advertising on, while in listening mode, to get an estimate how much the multiplexing for the advertising does influence the listening.

[FlorianLudwig]

Another option would be to work without nimble or bluedroid:

https://github.com/espressif/esp-idf/tree/master/examples/bluetooth/hci/ble_adv_scan_combined

[cyberman54]

Probably the best option, since it avoids useless code overhead and can be tweaked exactly to the use case.

[FlorianLudwig]

@cyberman54 what is your opinion on making it a compile-time option?

This way libpax can be integrated into projects that use bluetooth already for something else than couting. But they must use the same bluetooth lib to be able to co-exist.

[cyberman54]

@FlorianLudwig compile-time option is probably the most straight forward way. Another option would be to have a separate branch.

[cyberman54]

@FlorianLudwig i created a quick & dirty version for testing. It compiles and runs, but not sure if it does what it should.

Note: If you test it with paxcounter, set #define BLESCANTIME 5 in paxcounter.conf !

[cyberman54]

@FlorianLudwig i cleaned up the code in hci branch, it now does what it should. Saving lots of ressources, compared with a full-fledged bluetooth stack.

We now have a bunch of fine tuning parameters, affecting both the scope (= total number of seen packets) and the focus (= filtered packets) of MACs to be counted as pax.

Probably affecting scope:

• priority of HCI event processor task
• scan parameters: scan window [ms], scan interval [ms] (probably in concurrence to scope of Wifi packets)
• advertising parameters: adv interval / adv type / adv channel map (see [Bluetooth Specification v5.0, Vol 2, Part E, sec 7.8.5] https://www.mouser.it/pdfdocs/bluetooth-Core-v50.pdf))

Probably affecting focus:

• advertising filter policy
• filtering advertising report event for event_type and addr_type (see [Bluetooth Specification v5.0, Vol 2, Part E, sec 7.7.65.2] https://www.mouser.it/pdfdocs/bluetooth-Core-v50.pdf))
• rssi

I think we need deeper investigation here, to find optimum settings for the use case.

/cc @spmrider

[oliverbrandmueller]

1.0.0 RC2 introduces stackless BLE and thus the stack decision is done and void.