Thanks Luiz, that makes sense and would explain why it ignores the sensor's advertisements at pretty regular 11 second intervals. And again, I don't want to keep bugging you guys but my last question is, is there any issue using the MGMT api in conjunction with the normal DBus BLE api's? For that matter if I end up having to go to the hci level can that be mixed as well or will they step on each other somehow? I'm envisioning putting the normal, "connected" sensors using the DBus api calls (for scanning, connecting, receiving characteristic data) in one thread and the beacon devices in a completely separate thread, both running independently and using different api's (though possibly sharing some data). If that's just not going to work it'll help to know up front and I can look at alternatives. Thanks again, chris On Mon, Feb 24, 2020 at 5:52 PM Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> wrote: > > Hi Chris, > > On Mon, Feb 24, 2020 at 5:36 PM chris baker <chrisbkr2020@xxxxxxxxx> wrote: > > > > On Mon, Feb 24, 2020 at 4:33 PM Luiz Augusto von Dentz > > <luiz.dentz@xxxxxxxxx> wrote: > > > > > > Hi Chris, > > > > > > On Mon, Feb 24, 2020 at 1:56 PM chris baker <chrisbkr2020@xxxxxxxxx> wrote: > > > > > > > > On Mon, Feb 24, 2020 at 9:13 AM Barry Byford <31baz66@xxxxxxxxx> wrote: > > > > > > > > > > If the DBus API is not cutting it for you then using the MGMT API > > > > > https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/mgmt-api.txt > > > > > is what has been recommended in the past: > > > > > https://www.spinics.net/lists/linux-bluetooth/msg68959.html > > > > > > > > > > On Mon, 24 Feb 2020 at 16:37, chris baker <chrisbkr2020@xxxxxxxxx> wrote: > > > > > > > > > > > > On Mon, Feb 24, 2020 at 6:08 AM Barry Byford <31baz66@xxxxxxxxx> wrote: > > > > > > > > > > > > > > Hi Chris, > > > > > > > > > > > > > > On Mon, 24 Feb 2020 at 10:12, chris baker <chrisbkr2020@xxxxxxxxx> wrote: > > > > > > > > > > > > > > > > > > > > > > > So my question is, is there a way to get those missing advertisements > > > > > > > > through the dbus api, possibly some additional setting somewhere? > > > > > > > > > > > > > > Duplicates are disabled by default with the DBus API. This can be > > > > > > > controlled with the DuplicateData setting: > > > > > > > https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/adapter-api.txt#n107 > > > > > > > > > > > > > > Regards, > > > > > > > Barry > > > > > > > > > > > > > > > > > > My apologies, I guess I wasn't clear (long post) but, I turned > > > > > > duplicate data on when using the bluetoothctl command (via the "scan" > > > > > > submenu) and also used the flag, "hcitool lescan --duplicates", when > > > > > > running the hcitool command. So both scans should have included any > > > > > > duplicates (unless I've misunderstood something). Additionally, none > > > > > > of the missing packets were duplicates (again, unless I'm > > > > > > misunderstanding what "duplicates" means). each packet had a unique > > > > > > sequence numbers as well as the button data field toggling. > > > > > > > > Great, thank you. I'll look into the MGMT api in the coming days. That > > > > said, is it a problem to use both api's (MGMT/DBus) concurrently from > > > > the same app? My application supports both connected BLE sensors as > > > > well as BLE beacon type sensors. If possible I can handle them in two > > > > different threads, but the DBus thread for connected sensors would > > > > still occasionally need to scan for new sensors (using the DBus > > > > discovery call) and would still need to get characteristic changed > > > > callbacks as well. > > > > > > Have a look at the other thread subject: Adding support for > > > DuplicateData into the kernel > > > > > > We are discussing adding support to disable duplicate via MGMT since > > > DuplicateData does not currently remove it but we might want to change > > > that, or at least have some alternative API to do that. We could for > > > example have a socket that enables a more direct access to the > > > advertisments, that way protocol that work over advertisement would > > > have a way to do this, in fact this might be better for things like > > > mesh so it can coexist with bluetoothd. > > > > > > > Out of curiosity though, is the behavior I'm seeing normal? Or is the > > > > sensor doing something improper possibly? Seeing as the packets aren't > > > > duplicates why would they be filtered (or are they just not being > > > > received to begin with for some reason)? The 11 second interval seems > > > > kind of strange. Anyway, thanks again for the help! Chris > > > > > > > > > > > > -- > > > Luiz Augusto von Dentz > > > > > > Thanks Luiz, I don't want to sound dense, and I really appreciate you > > and Barry's help, but these aren't duplicate packets (unless, again, > > I'm misunderstanding the term). Each packet payload is completely > > unique. I'll have a look at the other thread for sure, but I'm really > > just trying to understand if the missing packets I identified in the > > trace should be there (in the DBus/bluetoothctl trace) or if there's a > > reason they were excluded. Again, they weren't duplicates and I'm > > reasonably sure I had the duplicate data flags set correctly each > > time. Also, whatever is going on is not transient, I can duplicate it > > with the senor I'm testing every time (both in my app or via > > bluetoothctl). More important for sure is to find a work-around > > (hopefully the MGMT api Barry pointed me to) but still just curious > > why these packets are getting dropped/filtered... Anyway, thanks again > > to you both! > > Afaik the HCI duplicate filter flag is not very granular, so the > controller may be dropping any reports found during a sort period > since it might not have enough memory to store everything, include > actual data in the advertisement, to compare with. > > -- > Luiz Augusto von Dentz
