Intereting Posts

Надежная связь с несколькими устройствами BLE одновременно на Android

Хотя недокументированная традиционная мудрость с использованием Android BLE apis заключается в том, что определенные операции, такие как чтение / запись характеристик и дескрипторов, должны выполняться по одному (хотя некоторые устройства более мягкие, чем другие). Однако я не знаю, следует ли применять эту политику только к одному соединению или по всем активным соединениям.

Я слышал, что лучше всего начать подключение к устройствам по одному за раз. Это может быть пример операций (connect / connectGatt), который должен выполняться последовательно среди всех устройств.

Но для других операций, таких как чтение и запись характеристик, достаточно ли это, если каждое соединение выполняет операции поочередно или мне нужна какая-то глобальная рабочая очередь, распределенная между всеми устройствами, чтобы между всеми устройствами выполнялась только одна операция?

Solutions Collecting From Web of "Надежная связь с несколькими устройствами BLE одновременно на Android"

В Android для каждого объекта BluetoothGatt вы должны выполнять только одну операцию за один раз (запрос mtu, обнаружение сервисов, характеристика / дескриптор чтения / записи), иначе все пойдет не так. Вам нужно подождать, пока соответствующий вызов будет вызван, пока вы не сможете выполнить следующую операцию.

Что касается одновременного подключения к нескольким устройствам, если вы используете autoConnect = true, тогда нет проблем, но если вы используете autoConnect = false, то стек bluetooth для Android будет пытаться только подключиться к одному устройству за раз, то есть он будет в очереди Соединение запрашивает, если имеется более одного непогашенного. Существует одна конкретная ошибка, в которой он не может отменить ожидающее соединение, которое все еще находится в очереди (когда вы вызываете .disconnect () или .close ()), однако это недавно было исправлено в Android.

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

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

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

BLE работает более 40 каналов, в которых 3 используются для широковещательной и другой передачи данных. Это делается для того, чтобы иметь множество устройств, сообщающихся вместе, ограничивая столкновение, находясь на других частотных диапазонах.

Эти группы выбираются на основе одного с самым низким уровнем шума (или трафика).

Сам приемопередатчик способен общаться (говорить и слушать) в одной полосе одновременно, и он должен переключаться между диапазонами для доступа к другим устройствам. Это достигается очень плотным сроком связи.

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

Если вы реализуете какую-то операционную очередь или поточную реализацию, в конце все придется обрабатывать последовательно / последовательно приемопередатчиком.

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

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

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

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

При этом я не знаю, как структурирована библиотека Android.