Различие между производственными данными, сервисными данными и рекламными данными в Bluetooth LE - PullRequest
0 голосов
/ 03 августа 2020

Что касается BLE, я немного запутался между терминами и их использованием в BlueZ:

  • Данные производителя
  • Сервисные данные
  • Реклама Данные

Я собираюсь подытожить то, что я понимаю, и где это разваливается.

Из здесь в рекламном пакете есть полезная нагрузка длиной 31 байт, которая может может использоваться для данных, определяемых пользователем.

Однако BlueZ в своем рекламном API имеет другое понятие данных. Требуется dict, который имеет <type> <byte array> из документации.

Если присмотреться, вы можете натолкнуться на эту таблицу, которая, похоже, имеет тот же двухбайтовый тип и структуру данных.

Он имеет определенную пользователем полезную нагрузку в терминах:

0xFF    «Manufacturer Specific Data»    Bluetooth Core Specification:Vol. 3, Part C, section 8.1.4 (v2.1 + EDR, 3.0 + HS and 4.0)Vol. 3, Part C, sections 11.1.4 and 18.11 (v4.0)Core Specification Supplement, Part A, section 1.4

Итак, я загрузил spe c, чтобы попытаться прочитать различие, которое приводит меня к предложению, которое я не Не совсем следую:

Данные отправляются в рекламных или периодических c рекламных акциях. Данные Host Advertising помещаются в поле AdvData PDU ADV_IND, ADV_NONCONN_IND, ADV_SCAN_IND, AUX_ADV_IND и AUX_CHAIN_IND. Дополнительные рекламные данные контроллера помещаются в поле ACAD PDU AUX_ADV_IND, AUX_SYNC_IND и AUX_SCAN_RSP. Periodi c Рекламные данные помещаются в поле AdvData PDU AUX_SYNC_IND и AUX_CHAIN_IND. Данные ответа сканирования отправляются в поле ScanRspData PDU SCAN_RSP или поле AdvData PDU AUX_SCAN_RSP. Если полные данные не могут поместиться в поле AdvData PDU AUX_ADV_IND, AUX_SYNC_IND или AUX_SCAN_RSP, для отправки оставшихся фрагментов данных используются блоки PDU AUX_CHAIN_IND. Структура AD может быть фрагментирована по двум или более PDU

Также, когда я смотрю на реализацию BlueZ их собственного API DBUS, я вижу, что они предоставляют способ заполнения производственных данных, но не способ изменить тип рекламы (ADV_NONCONN vs ADV_CONN).

У них тоже есть тип adv_data, но это всего 25 байт? Почему я не могу получить полный 31 байт?

https://github.com/bluez/bluez/blob/cbbb0c2ead89ed19280ecd94e8a2fb0d22216bb6/client/advertising.c#L55

Актуальные вопросы:

  1. При реализации периферийного устройства BT с использованием BlueZ у меня есть 31 или 25 байт. Могу ли я заполнить как служебные данные, так и данные производителя общим размером 50 байт ??
  2. Являются ли данные производителя абстракцией по сравнению с данными рекламы? Если да, то как я могу получить доступ к базовым Рекламным данным? Если нет, могу ли я теоретически заполнить данные о рекламе и производителе?

1 Ответ

2 голосов
/ 04 августа 2020

Изображение ниже, созданное Джосом Райком, может быть полезно для визуализации происходящего.

Как показано на рисунке, рекламные данные ADV FLAGS и рекламные данные составляют 31 байт рекламной полезной нагрузки, но их всего 26 байтов. по имеющимся данным. Изображение содержит примеры данных производителя (тип = FF) и служебных данных (тип = 16)

Beacon Cheat Sheet

In the D-Bus API, to change the type of advertising (ADV_NONCONN vs ADV_CONN) use the type property: https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/advertising-api.txt#n37

broadcast = ADV_NONCONN

В одном рекламном объявлении могут быть данные как об услуге, так и о производителе (см. Пример https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/test/example-advertisement#n141), но он не может быть длиннее 31 байта. С помощью BlueZ вы можете зарегистрировать (если я правильно помню) до четырех рекламных объявлений, которые будут отправляться в виде разных пакетов.

Таким образом, данные об услугах и данные производителя являются типами подэлементов в полезной нагрузке рекламы. BlueZ позволяет вам создавать различные типы данных , которые вы хотите использовать в своей рекламе, а затем регистрировать их для трансляции.

...