2017-01-03 11 views
2

Я пытаюсь реализовать код C++ (используя bluez 5.43 и dbus) для чтения рекламных пакетов с датчика BLE. В соответствии с документами bluez DBus существует StartDiscovery API, который можно использовать для сканирования ближайших устройств. Тем не менее, я не могу найти какие-либо API-интерфейсы для хранения/анализа рекламных пакетов из соседних устройств BLE. advertising-api.txt перечисляет registeradvertisement API, но, по моему мнению, его можно использовать только для создания рекламных пакетов и не чтения с внешнего устройства (или я не прав?) Может ли кто-нибудь, пожалуйста, направить меня на правильный способ получить рекламные пакеты из соседнего BLE устройства с использованием bluez и DBus?Каков правильный способ чтения рекламных пакетов с датчика BLE с использованием bluez 5.43 и DBus

+0

Как я понимаю, вы запускаете «StartDiscovery», затем появляются объекты «Устройство», поскольку они обнаруживаются. Свойства этих объектов, вероятно, заполнены данными из рекламных пакетов. – Velkan

+0

@Velkan: спасибо, что ответили. Честно говоря, я немного смущен. У меня есть датчик BLE, который регулярно передает показания датчиков в виде рекламных пакетов. Эта информация содержится в ответе на сканирование с низкой энергией. Поэтому мне нужен полный ответ для анализа необходимых данных. Я пытаюсь реализовать это с помощью dbus и bluez-5.43. Я не думаю, что какие-либо свойства дают низкий ответ сканирования энергии. Пожалуйста, поправьте меня, если я ошибаюсь. – darkknight

+0

org.bluez.Device1 имеет ServiceData и ManufacturerData. Разве они не являются такими же, как ServiceData и ManufacturerData из рекламного-api.txt? Может быть, они содержат AdvData, который содержит показания? – Velkan

ответ

0

Поведение, которое вы описали в одном из своих последних комментариев, является правильным (рекламные данные не обновляются): если я прав, устройство BLE не должно постоянно находиться, он может спать или поворачиваться малой мощности и т. д.

В этом контексте не странно, что данные каким-то образом «кэшированы». По моему опыту, когда вы выполняете сканирование и обнаруживаете устройство (даже если вы не подключаетесь к нему), информация об устройстве будет храниться в течение некоторого времени.

В вашем случае это проблематично, потому что вы передаете данные через рекламу. Однако есть способ заставить bluez удалить все его кэшированные данные об устройстве: адаптер-api предоставляет RemoveDevice (объектное устройство). Он принимает путь объекта (например, «/ org/bluez/hci0/dev_AA_BB_AA_BB_AA») в качестве аргумента.

Если вы ищете привязки DBus на C, я предлагаю GLib GDBus (вы найдете ссылки внизу этого руководства на веб-сайте freedesktop: https://dbus.freedesktop.org/doc/dbus-tutorial.html).

Если вы знакомы с bluetoothctl (инструмент для взаимодействия с Bluez с помощью команд), она была разработана с помощью Bluez ребят с помощью Glib GDbus и вы можете найти исходный код здесь (смотрите внизу, чтобы найти команду список): https://git.kernel.org/cgit/bluetooth/bluez.git/tree/client/main.c

есть более straigthforward способы использования GDBus с Bluez но bluetoothctl исходный код является стартовым и вы найдете примеры почти ничего, что можно сделать с Bluez =)

0

Спасибо за предложения все. Наконец, я смог получить данные производителя, используя библиотеку Intel tinyb. Он имеет API-интерфейс enable_manufacturer_data_notifications, который позволяет вам получать уведомления о каждом изменении данных производителя.