Scanning on both 1M and Coded PHYs works terribly, skipping packets for a long time even when scan_window = scan_interval (100% scanning).
What I think is happening is that device first scans on 1M for the duration of scan_window, then switches to Coded and also scans for the duration of scan_window. I assume that switching back and forth between the PHYs occurs every scan_interval. Also scanner has to go through all of the advertisement channels, so it's probably also changes them every scan_interval.
So I assume it goes like this:
37_1M, 37_Coded, 38_1M, 38_Coded, 39_1M, 39_Coded (changes every scan_interval)
OR
37_1M, 38_1M, 39_1M, 37_Coded, 38_Coded, 39_Coded.
Also there's probably a certain dead time, when switching between channels and PHYs.
All this results in a very high latency of some advertisement packets. For example, a device that sends adv packets every second might sometimes not be detected by the scanner for 20-30 seconds! This is for the scanner that scans 100% of the time.
So is this an intended behaviour? Even if PHYs are indeed periodically switched, having 20-30 second timeouts is seems to be too much.
Something isn't right.
Also, is there a possibility to perforum a true simultaneous scanning on both PHYs? I worked with other BLE modules and that feature was very useful.
I'm using ESP32-C3, ESP-IDF v5.0.2, NimBLE Host.
The code for scaning:
Code: Select all
#define SCAN_INTERVAL (950)
#define SCAN_WINDOW (950)
struct ble_gap_ext_disc_params ext_disc_params = {
.itvl = scan_interval_ms(SCAN_INTERVAL),
.window = scan_window_ms(SCAN_WINDOW),
.passive = 1,
};
// duration = 0 (forever)
// period = 0 (continuous scan)
// filter_duplicates = 0
// filter_policy = 0
// limited = 0
rc = ble_gap_ext_disc(BLE_OWN_ADDR_PUBLIC, 0, 0, 0, 0, 0,
&ext_disc_params, &ext_disc_params,
nimble_gap_event, NULL);