Hi Tony, On Fri, May 15, 2015 at 2:57 PM, Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> wrote: > Hi Tony, > > On Wed, May 13, 2015 at 11:15 PM, Tony DiCola <tony@xxxxxxxxxxxxxx> wrote: >> On Wed, May 13, 2015 at 9:53 AM, Michael Janssen <jamuraa@xxxxxxxxxx> wrote: >>> Hi Tony, >>> >>> On Tue, May 12, 2015 at 6:16 PM, Tony DiCola <tony@xxxxxxxxxxxxxx> wrote: >>>> Hi all, I'm playing with the latest bluez 5.30 and bluetooth low >>>> energy devices and am noticing that the manufacturer data field from a >>>> device's advertisement data appears to be cached somewhere internally. >>>> I wanted to check if this was expected and see if there was any way to >>>> disable that caching or work around getting back stale manufacturer >>>> data. >>>> >>>> For some context I'm using bluez 5.30's dbus API and applied these >>>> patches to make the gatt support non-experimental (so I can run >>>> bluetoothd without the --experimental flag): >>>> https://chromium.googlesource.com/chromiumos/third_party/bluez/+/2b3a91a12c86a5708329edf58d0cea237f319f6f%5E%21/#F0 >>>> https://chromium.googlesource.com/chromiumos/third_party/bluez/+/5755965a9944f158dd8aba63655f2b0a414a1f49%5E%21/#F0 >>>> However I've also tried it with the stock 5.30 code and the >>>> --experimental flag and see the same results. >>>> >>>> For my device I'm using a Nordic nRF51822-based board that I have >>>> control over the firmware and am using it to send custom advertisement >>>> data for my device. In my advertisement data I'm sending manufacturer >>>> data that looks like this: 0x07FFFFFF00000001. This breaks down as >>>> the length of the advertisement section (0x07 bytes), the manufacturer >>>> data advertisement type (0xFF), the testing manufacturer ID (0xFFFF), >>>> and then 4 bytes with a value of 1 (0x00000001). >>>> >>>> I see when I enable scanning on an adapter that a device object is >>>> created for my device in bluez's dbus hiearchy. It has a >>>> ManufacturerData field that looks just like what my advertisement >>>> sends, for example here's the output of the device's dbus tree (using >>>> python): >>>> >>>> [ /org/bluez/hci0/dev_C5_25_55_09_6A_B1 ] >>>> org.bluez.Device1 >>>> Name = UART >>>> Paired = 0 >>>> Adapter = /org/bluez/hci0 >>>> LegacyPairing = 0 >>>> Alias = UART >>>> ManufacturerData = dbus.Dictionary({dbus.UInt16(65535): >>>> dbus.Array([dbus.Byte(0), dbus.Byte(0), dbus.Byte(0), dbus.Byte(1)], >>>> signature=dbus.Signature('y'), variant_level=1)}, >>>> signature=dbus.Signature('qv'), variant_level=1) >>>> Connected = 0 >>>> UUIDs = dbus.Array([], signature=dbus.Signature('s'), variant_level=1) >>>> Address = C5:25:55:09:6A:B1 >>>> Trusted = 0 >>>> Blocked = 0 >>>> >>>> Everything looks great and the manufacturer data is parsed out as I >>>> expect. However the problem is when I have the nRF51822 change the >>>> advertised manufacturer data. For example if I change to >>>> 0x07FFFFFF00000002 (so the last 4 bytes change to 0x00000002) I'm not >>>> seeing the updated value in bluez's dbus hierarchy. When I query the >>>> device object's ManufacturerData property I still see the old value >>>> that ends in 1. Even if I sit in a loop querying the value every >>>> second for over a minute I still don't see the updated value (for >>>> reference the nRF51822 is advertising this updated value every >>>> second). >>>> >>>> I do notice that if I remove the device from bluez's dbus hiearchy (by >>>> getting its parent adapter and calling RemoveDevice on it) then I do >>>> see the device added back with the current/updated ManufacturerData >>>> property. This makes me think there's something up with the >>>> manufacturer data field getting cached or never being updated. >>>> >>>> I wanted to check is this expected behavior, that the manufacturer >>>> data property won't be updated when it changes? If so is there any >>>> clean way to disable this caching or get access to the most recently >>>> seen/up to date manufacturer data field? >>>> >>>> Let me know if anything isn't clear or if perhaps I'm doing something >>>> completely wrong. Thanks! >>>> >>>> -Tony >>>> -- >>>> 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 >>> >>> BlueZ doesn't update the Advertising Data unless there is an active >>> discovery client or the device is already paired. Is the device >>> paired, or are you calling the StartDiscovery method on the device? >>> >>> Note that the link layer does not need to send duplicate reports (the >>> same device address) to the host even if the advertising data changes. >>> This is acceptable behavior per the spec, as outlined in Vol 6, Part >>> B, Section 4.4.3 "Scanning State": "The advertising data may change; >>> advertising data or scan response data is not considered significant >>> when determining duplicate advertising reports." >>> >>> -- >>> M Janssen >> >> Thanks for the reply! Yeah I've called StartDiscovery on an adapter >> so I should see advertisement data come in (and in practice I do see >> my deivce show up after StartDiscovery is called). >> >> However I'm not pairing or connecting to the device because I'd like >> to read advertisement data from multiple devices at the same time. >> I'm thinking of a scenario kind of like Apple's iBeacon or Google's >> UriBeacon but for reading sensors, where each device/sensor puts its >> data into an advertisement packet (just using some custom manufacturer >> data field for now) and broadcasts that reading to any device >> listening for advertisements. >> >> Here's pseudo code of what I'm doing: >> - Setup my device firmware to start advertising custom manufacturer >> data with value 1 (for example). >> - Get BLE adapter org.bluez.Adapter1 object. >> - Set adapter's Powered property to True/1 to make sure it's powered up. >> - Call adapter's StartDiscovery function to start listening for advertisements. >> - See that my device is added to the bluez dbus tree with the >> org.bluez.Device1 interface. >> - Verify the device's ManufacturerData property has the expected value of 1. >> - Change my device's firmware to advertise custom manufacturer data >> with value 2. >> - Sit in a loop reading the bluez device's ManufacturerData property >> every second. > > Are you still discovering at this point? If yes then we might have a > bug as it should be updating the data if provided it is not the same. > >> - See that the ManufacturerData from bluez still shows the old value of 1. >> >> Here's the pseudo code of something that works, but feels pretty hacky >> to have to remove the device to get an updated value: >> - Setup my device firmware to start advertising custom manufacturer >> data with value 1 (for example). >> - Get BLE adapter org.bluez.Adapter1 object. >> - Set adapter's Powered property to True/1 to make sure it's powered up. >> - Call adapter's StartDiscovery function to start listening for advertisements. >> - See that my device is added to the bluez dbus tree with the >> org.bluez.Device1 interface. >> - Verify the device's ManufacturerData property has the expected value of 1. >> - Change my device's firmware to advertise custom manufacturer data >> with value 2. >> - Call the adapter's RemoveDevice function to remove the device from >> bluez's dbus hierararchy. >> - See that my device is added back to the bluez dbus tree again (after >> it send another advertisement). >> - Verify the device's ManufacturerData property has the new value of 2. > > Something is not right then. So I found the problem, please check the last 2 patches I send to the mailing list. The second is not exactly by the spec since it might be possible to have duplicated entries, even if they have the data, in the same report but I doubt anyone would try to do that since the space in the AD is very limited, anyway so what it does is detect if there already an entry and replace the data which should trigger PropertiesChanged(ManufacturerData) signal. -- Luiz Augusto von Dentz -- 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
