Передача данных с датчиков по BLE

[spectra]

Доброго времени суток!

Требуется снимать данные с нескольких (2-5 шт.) сенсоров.
Данные будут передаваться пакетами по 12 байт с частотой передачи 10 Гц.
Вычитал что можно передавать небольшие пакеты с данными по рекламному BLE каналу.
Вопрос - при асинхронной передаче данных по рекламному каналу не будут ли пакеты создавать коллизии и мешать друг другу?

 

[pvvx]

Вопрос - при асинхронной передаче данных по рекламному каналу не будут ли пакеты создавать коллизии и мешать друг другу?

Будут.
Кроме того в эфире есть помехи, а так-же чипы BT/BLE с кривописанным кодом и кривые BT/BLE чипы.

5 шт сенсоров с 10-ю рекламами в сек - это 50 шт реклам в сек (* 3 канала = 150 передач). И не все USB BT адаптеры такое вытянут. Только некоторые, работающие на USB2.0 High-Speed (большинство работает на Full-Speed и имеют тормозной код).

 

[pvvx]

И работе BLE мешает WiFi - от этого у ESP32 с BLE полный ужас - сплошные потери приема рекламных пакетов BLE...

 

[spectra]

Значит мое опасение оправдалось(
В общем-то потеря до 30% пакетов допускается.
Кроме BLE других вариантов нет, т.к. в качестве приемника будет смартфон.
Для передачи по рекламным каналам используется всего 3 фиксированные частоты, что существенно увеличивает вероятность патери.
Будет ли лучше если не использовать рекламные каналы, а передавать через BLE соединение в котором больше частот и есть подтверждение доставки?

 

[pvvx]

Будет ли лучше если не использовать рекламные каналы, а передавать через BLE соединение в котором больше частот и есть подтверждение доставки?

По соединению - имеется ограничение кол-ва одновременно подключенных устройств. По Win-де это где-то было описано - что-то около 5 соединений. Но возможна зависимость от драйверов и адаптера BT.
По Android и iOS подробной информации не нашел. Поиск дает типа такого
https://stackoverflow.com/questions...concurrent-ble-connections-android-m-can-have

Maximum Concurrent Bluetooth LE Devices on iOS and Android?

I am looking for definitive values for the maximum number of concurrent BLE devices you can connect to on both iOS and Android. I have done my own research and testing and it is not consistent. The

stackoverflow.com

А в реалии надо глядеть ограничения в константах исходников конкретной версии Android...

 

[pvvx]

Есть другие варианты как принимать множество рекламных BLE устройств.
Лучшее решение лежит в области специального адаптера, построенного на чипе BLE и передающего данные по Ethernet проводу. Но это слишком специфичное решение.
Упрошенное решение, которое пропускает какую-то не очень большую часть реклам можно строиться на дешевом BLE чипе. Он постоянно принимает рекламу, но в этот момент иcпользует BLE соединение с смартфоном или другим BT адаптером.
Проверенный пример такого решения - AdScanerTrg и подобные, описанные где-то на данном форуме...
Такое устройство у меня успешно принимает 25 внешних BLE датчиков. Потери не большие - до 10%, зависит от интенсивности поступления реклам в единицу времени, т.к. принятое ему надо успеть передать и на время этих транзакций канал приема занят...
Гораздо хуже, т.е. очень большое кол-во потерь, дают решения на одиночном SoC с одновременным WiFi соединением и BLE приемом реклам. Типа ESPHome - просто ужас (полные выпадения по несколько секунд и т.д.). Я не смог это использовать, хотя постоянно слежу за новыми версиями...

 

[spectra]

Такое устройство у меня успешно принимает 25 внешних BLE датчиков. Потери не большие - до 10%, зависит от интенсивности поступления реклам в единицу времени, т.к. принятое ему надо успеть передать и на время этих транзакций канал приема занят...

25 это много, а с какой интенсивностью передаются данные?

Почитал про организацию рекламной передачи, она делится на два базовых вида - с соединением и без соединения с централью.
Рекламная передача с соединением используется для передачи информации бОльшего размера чем может уместиться в одном рекламном пакете. В этом случае определенно возникнет конкурентная проблема с несинхронной приемом/передачей.
В моем же случае может и прокатить, т.к. передаваемый объем информации умещается в одном рекламном пакете который можно передавать без соединения с централью.

Гораздо хуже, т.е. очень большое кол-во потерь, дают решения на одиночном SoC с одновременным WiFi соединением и BLE приемом реклам.

Совмещенные WiFi/BLE трансмиттеры является проблемой на стороне приема или передачи?
В качестве BLE передатчиков предполагаю использовать какие-нить недорогие модули например на базе чипов NRF52 или других...

 

[pvvx]

25 это много, а с какой интенсивностью передаются данные?

Пара LYWSD02MMC - 0.1 сек
USB-BT адаптер в компе (всегда годит BLE и MESH рекламу и при включении) - менее 0.1 сек
Разнообразные термометры с неоф. прошивкой - 2.5 сек
Разнообразные термометры с оф. прошивкой - 1..1.6 сек
При тесте в городе ещё захватывало какие-то Apple телевизор и другие устройства, вечно транслирующие рекламу с периодом в 50 мс.
И т.д.

В среднем данные в нужных рекламках меняются каждые 10 сек. AdScanerTrg по соединению передает только изменяющиеся данные из рекламы. Не полные кадры рекламы, а только блок с нужными данными. Но можно включить всё.

 

[pvvx]

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

Что-то не то вычитали.

Рекламная передача с соединением используется для передачи информации бОльшего размера чем может уместиться в одном рекламном пакете. В этом случае определенно возникнет конкурентная проблема с несинхронной приемом/передачей.
В моем же случае может и прокатить, т.к. передаваемый объем информации умещается в одном рекламном пакете который можно передавать без соединения с централью.

C версии 5.0 есть расширенный формат рекламы. Там длина и модуляция (2М/LongRange:125K/250К/...) ничем не ограничена.
Но есть проблемс в реализации на смартфонах. Нет поддержки в старых и т.д. ....

Совмещенные WiFi/BLE трансмиттеры является проблемой на стороне приема или передачи?

На стороне приема. WiFi сигнал громкий и творит коллизии всем BLE/BT. Тупо затыкает АРУ.
И у SoC c WiFi долгое переключение RF части, да длительное время срабатывания АРУ у приемника.
По этому их антенны всегда разносят на как можно дальнее расстояние. А в одном Чипе - это бред.

 

[pvvx]

В качестве BLE передатчиков предполагаю использовать какие-нить недорогие модули например на базе чипов NRF52 или других...

У NRF52 бинарный ,блок-библиотека SoftDevice, подключаемая к вашей прошивке. И там подобие RTOS, да реализация постоянного приема реклам с одновременной работой устройства BLE будет иметь сложности из-за общих тормозов такого типа построения программной модели системы.

 

[pvvx]

Требуется снимать данные с нескольких (2-5 шт.) сенсоров.

Типичное время передачи устройством BLE рекламы по 3-м каналам - около 2..3 мс.
В итоге шустрый BLE сканер на одном канале может принимает максимум к 300 рекламных пакетов в сек.
При длине информационного тела рекламы в 31 байт - это 9300 байт в сек, плюс MAK и тип пакета.
Для типового HCI (интерфейса у адаптера и ОС) это дело сильно увеличивается на всякие доп. команды и заголовки. USB2.0 12Мбит/c не хватает
В итоге смартфон или BT-USB и прочие BT адаптеры принимают гораздо меньшее кол-во реклам в сек, чем нормальный BLE сканер (бывают и тупые BLE сканеры).

Данные будут передаваться пакетами по 12 байт с частотой передачи 10 Гц.

В рекламе должны быть заголовки блоков в спец формате. Плюс другие блоки, чтобы смартфон или другое типовое устройство поняло, что это BLE реклама, а не MESH и т.д.

 

[pvvx]

При правильном построении (учете описанного) ваша задача не является сложной.
Современный смартфон с Android спокойно примет данные в рекламах от ваших 5 датчиков. Тут важнее расстояние до них и уровень мощности их передатчика.
По поводу формата пакета рекламы - желательно изначально совместить с уже известными форматами для DIY устройств - https://bthome.io/
Такое сразу будет работать в разных "умных домах" и проще отладить-контролировать к примру в ble_monitor для HomeAssistant.
Можно попробовать и https://esphome.io/components/bluetooth_proxy.html

 

[spectra]

Огромное спасибо за поддержку!
Если будет интересно, то поделюсь результатами экспериментов.

Что-то не то вычитали.

Читал тут

При длине информационного тела рекламы в 31 байт - это 9300 байт в сек, плюс MAK и тип пакета.

Максимальная длина рекламного пакета составляет - 31 байт.
Т.е. нам нужно отправить 5 пактов * 10 раз/сек * 31 байт = 1550 байт/сек т.е. 12400 бит/сек.
12.4 килобит/сек. в сущности мелочь.
Главная проблема похоже будет заключаться в том, что пакеты будут отправляться асинхронно с пяти передатчиков по фиксированным частотам + всевозможные внешние коллизии как Вы и говорили от BT и WiFi.
Но при такой объеме передаваемой информации все должно получиться.
Если я все правильно понял с форматом пакета, то мы идеально в него укладываемся.
Формат рекламного пакета:

• Flags (0x01)
• UUID16 (0x16)
• MYDATA (0x12)
• CRC (0X2)