duplicates repeated after 60s #84
Comments
|
There is a buffer in the controller that once filled will clear itself and duplicate devices will be reported again. You can adjust the size of the buffer by calling |
|
I think something is not working here, but it might be something down inside ESP-IDF. First of all, the default value for the duplicates cache is 200, which is way more than I am seeing. Second, even changing it to 1000, both in the config and in the esp-nimble-cpp API, does not eliminate the duplicates. I initialize this way: I wonder if maybe this is a bug in ESP-IDF that worked with Bluedroid but doesn't work with NimBLE. The code for this in esp-nimble-cpp looks correct to my eyeballs (for passing the right thing down into ESP calls). Incidentally, when I use passive scanning instead of active scanning, I see tons and tons of duplicates in my callback. |
|
What IDF/NimBLE version are you using? Do you have a lot of BLE advertisers around you? |
|
I am using ESP-IDF 4.4.1. I have 10-20 BLE advertisers typically visible if I scan for a while. I think I have figured out what's going on, but I'm not sure if it's a bug or just something I didn't understand correctly. I modified my code to print the current result count in the callback, and I also print the results list when I stop the scan. These things happen:
Here's the current code: And here is the output from a run of that code:
|
|
BTW, I am using v1.3.3 of esp-nimble-cpp |
|
Thank you for the info. I can reproduce and explain this. In here you can see the gaps are due to awaiting scan response data. The device when first detected is added to the vector and either calls the callback or waits for the scan response data before calling it, which can be seen here. The duplicates you are seeing and as I see them in the log are due to the scan response data being updated. So it would seem there may be room for improvement on the filtering side, what you could try for the time being is changing the scan filter mode to I will look to improve this shortly. |
|
I made a quick patch for v1.3.3 for you to try: |
|
Thanks for the quick turnaround. With the patch, the duplicates in the callback are gone. With active scanning, there are still some devices that don't show up in the callback, but with passive scanning they all show up. That resolves things for my use case, so I'll leave it to you whether you want to pursue the active scan case. (FWIW, in my scenario I'll be updating a UI with scanned devices as they are found. That's in a different FreeRTOS task, so I'm probably going to just check for a change in the results count every few seconds and act on that.) Thanks again (and thanks for your work in porting this library in the first place). |
|
Re; active scan, The devices don't show due to not receiving the scan response. This is an issue that I've been struggling with for a while as to how it should be resolved. If the scan is short and restarted often this is a non-issue mostly, however, it's not ideal. |
|
Yeah, I don't even know what most of the devices are that I'm picking up in my scans. I checked the MACs and they are either unregistered or have confidential vendors in the IEEE database. Some of them could be quite old or could be sketchy manufacturers who don't follow the protocols reliably. I guess there is no way to tell from the initial advertising packet if the device would respond to the request for additional scan data. If there were, and the indication was "no", you could skip them for the active scan follow-up. |
Actually, this is already being done, it's just a matter of the device responding to the request. After advertising it will go into receive mode to listen for scan requests but if the timing is off or it goes out of range etc. then the response won't come until the next time we request from it (assuming it works that time). What I have in place now is, when the scan ends the callback for any device that it hasn't been called for yet will be called at that time. It's not ideal but you'll at least get it eventually. |
|
Even with the patch, I'm not getting those "eventual" callbacks. Should that be working with a "scan forever" call that is stopped by a stop() call instead of the timeout? |
Unfortunately no, manually stopping does not call the callbacks as it would cause problems for the client connect function. |
|
I'm all ears for potential solutions to this problem. So far the options considered have been to use a timeout on waiting for the scan response, this is not ideal though because the response could come at any moment so coming up with an appropriate time would be a challenge. The second option is to provide a callback for the initial advertisement and again when the scan response is received, this may result in breaking the API. |
|
I'm not any kind of BT expert, so I don't have any great ideas. I was only using active scanning in the hope of getting something human-consumable for the devices that don't provide names in the initial packet. But so far I haven't seen them provide names in those cases. (Funny story, though. The remote for a TiVo Stream 4k gives its name as "TiVo Remot" in the initial packet but completes it to "TiVo Remote" in the additional scan data. So, I guess that's something. :-).) |
|
Lol, yeah there isn't much advertising data space so most devices don't advertise a name or if they do it's a short version. |
I find that if I scan for advertised devices requesting no duplicates my callback sees duplicates repeated at almost exactly 60 second intervals. I wonder if I'm doing something wrong or if there is some config I don't know about for this mystery. Or maybe there is just something I'm misunderstanding about how duplicate suppression is intended to work.
My code is pretty simple (it will eventually scan forever and be stopped by a user action or a timeout outside of the BLE code).
The text was updated successfully, but these errors were encountered: