Re: bluez: using "service data" in BLE advertisement packets

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ah... Yes, this looks good (or at least much better :) )

In our specific case the service data changes relatively frequently,
on the order of once per minute. And we usually need the most
up-to-date data when an application actually inspects the device (as I
mentioned above, the devices aren't connectable, so the only way to
receive any data from them is through the advertisement packets).

In terms of filtering, we also see cases where we will need to filter
on the contents of the service data (i.e. when many devices of the
same type are in the same area, we will want to only receive
notifications on a subset of them). Think e.g. of iBeacons - an
application may want to only be notified on beacons that belong to the
app's developer (iPhones use this method to achieve low-power scanning
of BLE beacons).
-- Alon Ziv


On Thu, Mar 26, 2015 at 11:37 AM, Luiz Augusto von Dentz
<luiz.dentz@xxxxxxxxx> wrote:
> Hi Alon,
>
> On Wed, Mar 25, 2015 at 4:21 PM, Alon Ziv <nolaviz@xxxxxxxxxx> wrote:
>> Hi all,
>>
>> We are developing some applications with non-connectable BLE
>> advertisers that broadcast data in a "service data" element of the
>> advertisement packet. So far we have used these devices with Android
>> and with iOS, both of which can easily support these devices as the
>> entire advertisement packet payload is exposed to scanning
>> applications.
>>
>> Looking at the bluez DBus API, it appears that no equivalent
>> functionality exists: in particular, when the advertisement packets
>> are parsed (eir_parse() called from
>> src/adapter.c:update_found_devices()) any service-data elements are
>> simply discarded. Even worse (for us), if the devices' advertisements
>> are not marked "discoverable" they are simply dropped outright. And
>> even if the device is discoverable, it looks like we'd get only a
>> single notification when the device is first seen - but we won't be
>> able to verify it is still in range (i.e. continued reception of
>> advertisement packets).
>>
>> Is the above summarization correct?
>
> We working on adding advertising support right, perhaps you should
> take a look at my proposal:
> [RFC BlueZ] doc/device-api: Add ServiceData and ManufacturerData
>
> Do expect the service data to change frequently? I guess we are
> programming the controller to filter duplicates, but we are working
> (actually most of the work is coming from your colleague Jakub
> Pawlowski) SetDiscoveryFilter:
>
> https://git.kernel.org/cgit/bluetooth/bluez.git/tree/doc/adapter-api.txt
>
>> (The API documentation claims to support "observer" mode, but these
>> limitations actually put the lie to this statement - an observer is
>> supposed to see _all_ advertisement packets, including non-first ones
>> and those from non-discoverable devices...)
>>
>> Regards
>> -- Alon Ziv
>> --
>> 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
>
>
>
> --
> 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




[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux