Hello Don, On 28 November 2016 at 20:55, Don Zickus <dzickus@xxxxxxxxxx> wrote: > On Thu, Nov 24, 2016 at 03:07:21PM +0200, Luiz Augusto von Dentz wrote: >> Hi Don, >> >> On Wed, Nov 23, 2016 at 11:40 PM, Don Zickus <dzickus@xxxxxxxxxx> wrote: >> > Hi, >> > >> > I was trying to write some code to continuously scan the bluetooth field >> > for bluetooth devices sending advertising packets (ie beacon-mode). >> >> That is tricky, if you have anyone else trying to use the adapter in >> this situation it will probably be blocked, we may add support for >> setting intervals but that will probably be a best effort in case >> there is no connection or other usage of the adapter by the system. >> >> > These devices would come and go so I wanted to avoid the cache. >> >> Beacon are not normally not connectable, connections and continuous >> advertisement don't go well together so we will probably have to >> reduce the intervals in order to maintain any traffic on the >> connections. > > > Hi Luiz, > > Thanks for the response. I am wondering if I explained it wrong. I wasn't > looking to do advertisements but instead scan for advertisements. I also > don't plan to connect to any of the advertising device, just read the > advertised data. > > >> >> > I noticed the D-Bus interface doesn't quite allow me to do this (as it >> > caches the devices and I can't monitor the RSSI field). But I think the >> > bluetooth management interface does. Is that the correct approach? >> >> Yep you could in theory use the MGMT interface and manually add you >> beacon management on top, but I guess you don't want applications to >> do that since it would require root permissions to connect to the >> management socket, so making bluetoothd, via kernel?, to adjust the >> intervals is probably a better idea in the long run. We would probably >> have to maintain the biggest advertising window possible, and the >> consider: >> >> 1. Is it connectable/there any advertising instance that is >> connectable? If yes, the it has to adjust the window to allow them >> (perhaps using the default connection parameters). >> 2. In case of a connection is made the controller may not be able to >> advertise anymore, and in case it can still advertise we need to make >> sure it doesn't interrupt the connection (this is not very clear if >> the controller is suppose to manage this somehow). >> 3. Similar to the connection situation we may have application >> scanning, again there might be problems if the controller cannot scan >> while advertising we would probably have to stop advertising. > > Hmm, as I said above, I am wondering if I explained it wrong. > > I was wondering how much was already done because in reality, I was just > going to mimic what android does on the phones with apple ibeacons except my > machines stay put and the ibeacons travel. > > Currently I was using 'hcitool lescan --duplicates' and 'hcidump' and trying > to script that. But wanted to be smarter. :-) I am planning on doing a similar application as you describe and understood that you should be able to do much of what you want with the dbus API. Have you taken a look at adapter/StartDiscovery? It is documented at git.kernel.org/cgit/bluetooth/bluez.git/tree/doc/adapter-api.txt#n12 You would then monitor the PropertiesChanged signal on the system dbus. SetDiscoveryFilter might also be necessary/helpful. Regards, Barry > > Cheers, > Don > -- > To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
