Easyway ble в машине находит что за устройство
Android Bluetooth Low Energy (BLE) — готовим правильно, часть #2 (connecting/disconnecting)
Содержание
Часть #2 (connecting/disconnecting), вы здесь.
Подключение к устройству
Autoconnect = true
Autoconnect работает только с закешированными и сопряженными (bonded) устройствами!
Android-6 и ниже имеет известный баг, в котором возникает гонка состояний и автоматическое подключение становится обычным ( autoconnect = false ). К счастью, умные ребята из Polidea нашли решение для этого. Настоятельно рекомендуется использовать его, если думаете использовать автоподключение.
возможность подключаться к нескольким устройствам одновременно;
Изменения статуса подключения
Работа с этим колбеком – достаточно нетривиальная вещь. Большинство простых примеров из сети выглядит так (не обольщайтесь):
Возможно вы заметили такие логи в LogCat:
Важно всегда вызывать close() после отключения! А сейчас обсудим основные случаи дисконнекта устройств.
Состояние подключения (newState)
Переменная newState содержит новое состояние подключения и может иметь 4 значения:
Статус подключения (status)
Это не последний вариант, мы еще улучшим колбек в этой статье. В любом случае, теперь у нас есть обработка ошибок и успешных операций.
Состояние bonding (bondState)
Теперь мы можем учитывать состояние bondState вместе с status и newState :
Обработка ошибок
После того как мы разобрались с успешными операциями, давайте взглянем на ошибки. Есть ряд ситуаций, которые на самом деле «нормальные», но выдают себя за ошибки.
Статус 133 при подключении (connecting)
Убедитесь, что вы всегда вызываете close() при отключении. Если этого не сделать, в следующий раз при подключении вы точно получите status=133 ;
Всегда используйте TRANSPORT_LE в вызове connectGatt() ;
Проверьте что устройство посылает advertising пакеты. Вызов connectGatt() с autoconnect = false имеет таймаут 30 секунд, после чего присылает ошибку status=133 ;
Замените/зарядите батарею на устройстве. Обычно устройства работают нестабильно при низком заряде;
Если вы попробовали все способы выше и все еще получаете статус 133, необходимо просто повторить подключение! Это одна из Android ошибок, которую мне так и не удалось понять или решить. Иногда вы получаете 133 при подключении к устройству, но если вызывать close() и переподключиться, то все работает без проблем! Есть подозрение, что проблема в кеше Android и вызов close() сбрасывает его состояние для конкретного устройства. Если кто-нибудь поймет, как решить эту проблему – дайте мне знать!
Отключение по запросу (disconnect)
Для отключения устройства вам необходимо сделать шаги:
подождать обновления статуса в onConnectionStateChange ;
освободить связанные с объектом gatt ресурсы;
Команда disconnect() фактически разрывает соединение с устройством и обновляет внутреннее состояние Bluetooth стека. Затем вызывается колбек onConnectionStateChange с новым состоянием «disconnected».
Вызов close() удаляет ваш BluetoothGattCallback и освобождает клиента в Bluetooth стеке.
Наконец, удаление BluetoothGatt освободит все связанные с подключением ресурсы.
Отключение «неправильно»
В примерах из сети можно увидеть, разные примеры отключения, например:
сразу вызвать close()
Это будет работать более-менее. Да устройство отключится, но вы никогда не получите вызов колбека с состоянием «disconnected». Дело в том, что disconnect() операция асинхронная (не блокирует поток и имеет свое время выполнения), а close() немедленно удаляет коллбек! Получается, когда Android будет готов вызвать колбек, его уже не будет.
Отмена попытки подключения
При удачной отмене вы увидите примерно такое в логах:
Прим. переводчика: но это не значит что для autoconnect = false не надо проводить такую отмену!
Обнаружение сервисов (discovering services)
Первым делом проверим, есть ли какие ошибки после обнаружения сервисов:
Если есть ошибки (обычно это GATT_INTERNAL_ERROR со значением 129), делаем отключение устройства, что-то исправить здесь невозможно (нет специальных технических способов для этого). Вы просто отключаете устройство и повторно пробуете подключиться.
Если все прошло удачно, вы получите список сервисов:
Кеширование сервисов.
Bluetooth стек кеширует найденные на устройстве сервисы, характеристики и дескрипторы. Первое подключение вызывает реальное обнаружение сервисов, все последующие – возвращаются кешированные версии. Это соответствует стандарту Bluetooth. Обычно это нормально и сокращает время соединения с устройством. Однако в некоторых случаях, может потребоваться очистить кеш, чтобы снова обнаружить их с устройства при следующем соединении. Типичный сценарий: обновление прошивки, в которой изменяется набор сервисов, характеристик, дескрипторов. Есть скрытый метод очистки кеша и добраться до него нам поможет механизм рефлексии Java:
Этот метод асинхронный, дайте ему некоторое время для завершения!
Странные штуки в подключении/отключении
Хотя операции подключения и отключения выглядят просто, есть некоторые особенности, которые нужно знать.
Случайная ошибка 133 при подключении, выше мы разобрались как с ней работать;
Некоторые смартфоны имеют проблему с подключением во время сканирования. Например, Huawei P8 Lite один из таких. Останавливаем сканнер перед любым подключением (Прим. переводчика: это правило соблюдаем строго!);
Все вызовы подключения/отключения асинхронные. То есть неблокирующие, но при этом им нужно время, чтобы выполнится до конца. Избегайте быстрый запуск их друг за другом (Прим. переводчика: я обычно использую задержку 50-100мс между вызовами).
Следующая статья: чтение и запись характеристик.
Теперь мы разобрались с подключением/отключением и обнаружением сервисов, следующая статья – о том, как работать с характеристиками.
Не терпится поработать с BLE? Попробуйте мою библиотеку Blessed for Android. Она использует все подходы из этой серии статей и упрощает работу с BLE в вашем приложении.
BLE под микроскопом 2
BLE под микроскопом. Часть 2
Режимы работы BLE
Сначала мы поговорим о различных режимах работы устройств BLE. Начнем с самого простого. Для однонаправленной передачи данных, например с уличного термометра на телефон, существует формат маяка. Устройство передает статические или медленно меняющиеся динамические данные в эфир. Здесь пользователей предостерегает подводный камень. Если просканировать эфир, используя пункт меню андроида (Настройки=>BlueTooth), мы не увидим маяков. Всё дело в типе сканирования. Существует активное и пассивное сканирование. Пассивное сканирование просто слушает эфир, а при активном сканировании делается дополнительный запрос на устройство BLE. Здесь есть принципиальное отличие в режиме работы объявителей.
Маяки имеют заголовок ADV_NONCONN_IND. Это означает, что они не присоединяемые и не несут дополнительной информации, кроме той, что уже содержится в пакете. За счет того, что у них нет дополнительных функций и режима приема, вся энергия идет только на передачу рекламных пакетов. Это наиболее экономичный тип работы устройств BLE. Однако, для того чтобы их увидеть, необходимо использовать на смартфоне специальную программу с пассивным режимом сканирования. В принципе, информация в пакете маяка может меняться. Например, нужно передать больше информации, чем вмещает один пакет. Тогда возможна циклическая смена информации, которую передает маяк.
Особенности пассивного сканирования в том, что все данные, которые андроид получает из посылки маяка, он немедленно передает в пользовательское приложение. При активном же сканировании, приложение не увидит устройства BLE до тех пор, пока гаджет не ответит на запрос сканирования со стороны смартфона. Это наиболее распространенный режим работы устройств. Рассмотрим его особенности. При сканировании, когда смартфон получает на одном из каналов объявления посылку от устройства (типа ADV_IND или ADV_SCAN_IND), он посылает запрос на этом же канале. Это пустая команда SCAN_REQ.
Она должна быть передана не позднее, чем за время T_IFS(Time Inter Frame Space), которое составляет 150 мкс. Для того, что бы устройство объявления услышало этот запрос, после каждой рекламной посылки оно задерживается на канале на время T_IFS. При этом, естественно, потребляется дополнительная энергия. Если запрос получен, устройство отвечает ответной посылкой SCAN_RSP. На рисунке видно, что максимальное время задержки на ответ так же составляет T_IFS.
И здесь пользователей подстерегает ещё один подводный камень. Дело в том, что операционная система смартфона, после того как получила ответную команду SCAN_RSP, запоминает параметры устройства. Она продолжает время от времени повторять свои запросы SCAN_REQ на гаджет, однако они не регулярны. А на запрос пользовательского приложения, система будет выдавать последние полученные данные, вне зависимости от потребностей приложения. Поэтому, что бы обновить данные, например, с датчика положения, необходимо будет перезапустить процесс сканирования на телефоне. Поэтому устройства с заголовком ADV_IND и ADV_SCAN_IND плохо подходят для передачи быстро меняющихся данных в режиме маяка. Лучше пройти процедуру присоединения и переходить на рабочие каналы. Это мы рассмотрим ниже, но сразу укажем, что это умеют делать только устройства ADV_IND.
В конце главы хочу разобрать интересную особенность команд SCAN_REQ и SCAN_RSP. Дело в том, что ответная команда SCAN_RSP может быть как пустая, так и содержать любую полезную информацию. Этим пользуются в двух случаях. Во-первых, когда вся необходимая информация не влезает в одну посылку. Во-вторых, когда хотят сберечь энергию батареи. Это делается так. Сама рекламная посылка максимально коротка. В неё входит только заголовок, флаги и МАС-адрес устройства. А при запросе SCAN_REQ устройство передает всю дополнительную информацию о себе (например имя, уровень батареи и т.д.) уже во фрейме SCAN_RSP. Операционная система на телефоне сшивает всю информацию в один блок.
Работа в режиме присоединения
Для полноценного использования всех ресурсов протокола BLE необходимо работать на рабочих частотах. Это синхронный режим работы. Рассмотрим, как его создать. После того как смартфон, в ответ на запрос при активном сканировании, получит фрейм SCAN_RSP, появляется возможность присоединения гаджета к телефону. Процесс присоединения обычно запускается пользователем, но может быть запущен и приложением, в случае разрыва соединения. Именно ради синхронного режима и создавался BLE. После присоединения и гаджет и телефон переходят в экономичный режим работы. Устройства перестают передавать на рекламных частотах, и начинают работу на других 37 каналах. Рассмотрим, как это происходит. Взглянем на рисунок.
В ответ на требование пользователя присоединить гаджет, андроид посылает пакет CONNECT_REQ. Он должен быть отправлен не позднее времени ожидания T_IFS. В этом пакете содержится полная информация о том, на каких частотах, с каким интервалом и с каким Access Address-ом смартфон предлагает обмениваться данными. Вот формат данных этого пакета.
Как он выглядит в «Wireshark» мы видим на следующем рисунке. В разделе Link Layer Data мы видим, что новый Access Address равен 0x21431df6. Далее идут три байта контрольной суммы 0x277d0f. Чтобы получить четыре следующие временные параметра, их надо умножить на соответствующий коэффициент.
transmitWindowSize = Win-Size * 1.25 ms
transmitWindowOffset =WinOffset * 1.25 ms
connInterval = Interval * 1.25 ms
connSupervisionTimeout = Timeout * 10 ms
В части ChM описываются те рабочие каналы, на которых предполагается дальнейшая работа. А в части Hop – с каким интервалом будут перебираться разрешенные каналы. По спецификации, Hop находится в интервале от 5 до 16.
На следующем рисунке схематически показан механизм перехода на рабочие частоты.
Далее смартфон и устройство начинают работать в синхронном режиме на рабочих частотах. Однако смартфон (Master) может изменить параметры работы гаждета (Slave) на рабочих частотах. Это чаще всего происходит тогда, когда к телефону присоединяется ещё одно устройство. Для экономии энергии, смартфону проще так выстроить работу с присоединенными устройствами, чтобы обслуживать их последовательно за один сеанс просыпания. В этом случае, используется процедура Feature Exchange Procedure. Она во многом похожа на процедуру присоединения и происходит в автоматическом режиме, поэтому мы не будем её рассматривать.
В заключении главы, немного затронем тему профилей. Для того, что бы систематизировать передачу и прием данных, в формат BLE были введены сервисы. Это различные задачи, которые может исполнять устройство. Сервисом, например, является возможность сообщать уровень напряжения батарейки, или перепрограммировать устройство по эфиру. Профиль, как правило, объединяет несколько сервисов. Полный список профилей устройств BLE можно посмотреть здесь.
Для разработки собственных устройств, проще всего пользоваться профилем NUS (Nordic UART Service). Для работы с ним, у nordic-a есть два приложения. Одно — nRF UART 2.0. Другое, и на мой взгляд более удобное, входит в состав nRF Toolbox.
Работа с nRFgoStudio
У фирмы Nordic есть универсальное средство для работы с различными китами — это программа nRFgoStudio. Её, как и другие, можно скачать на сайте производителя здесь. Присоедините свое устройство или кит при помощи программатора к компьютеру. Откройте nRFgoStudio и кликните на строчку nRF5x Programming. Если программатор увидит процессор, то откроется окно как на рисунке.
С правой стороны мы видим окно с тремя закладками: Program SoftDevise, Program Application, Program Bootloader. Первое окно (Program SoftDevise) позволяет загружать в процессор стек от Nordic-a, второе — пользовательское приложение, а третье — загрузчик по эфиру (DFU). На сайте есть статья, где это уже было вскользь освещено.
Заключение
Хотелось бы отметить, что мы подробно не разбирали саму рекламную посылку advertising и способ её формирования. Тем, кто заинтересуется как это сделать ручками, я отсылаю к статье. Там указано как можно попробовать работать на более простой микросхеме Nordic-а nRF24L01, не используя стек. Это позволит более глубоко понять структуру посылки.
Кроме того, можно научиться формировать эти же посылки, минуя стек, и на микросхемах nRF51822 b nRF52832. Это гораздо проще, чем работа со стеком. Однако без стека мы не сможем работать на рабочих каналах. Самостоятельно реализовать синхронный режим будет очень сложно. Тема BLE очень обширна и постоянно развивается. Поэтому мы конечно же не смогли описать все особенности этого протокола. Но для первоначального старта этой информации более чем достаточно. Дополнительную информацию можно почерпнуть здесь, здесь и здесь.
Easyway ble в машине находит что за устройство
У нашего сервиса есть ряд полезных функций, которыми мы, создатели сервиса, пользуемся каждый день. Но по какой-то причине Вы, наши пользователи, их почти не используете. Возможно потому, что просто не знаете об их существовании 🙂
В этой статье мы постараемся исправить эту досадную ошибку и подробно расскажем о каждой из таких функций.
Актуализация точек ОТ (ДО)
Логика сервиса устроена таким образом, что для задания координат точек ОТ(ДО) используется левый клик мыши. После того, как точки заданы, актуализировать расположение ОТ(ДО) можно, лишь перетянув соответствующий маркер. Либо использовать контекстное меню карты, которое отображается при правом клике.
При выборе ОТ(ДО) из контекстного меню соответствующая точка гарантировано установится в место клика, независимо от любых других условий. Что довольно удобно.
Ссылка на адрес
Например:
Ссылка на маршрут
Эта функция устанавливает точки ОТ и ДО в нужных местах, запускает поиск маршрута и затем активирует требуемый вариант.
Хотите поделиться с кем-то, как:
Никаких проблем, все эти маршруты можно закодировать в виде обычной ссылки!
Печать маршрута
Эта гениальная по своей информативности функция предоставит Вам всю полноту информации о схеме проезда в оптимизированном для печати формате. На альбомном листе А4 будет отражено:
Если Вы в первый раз собираетесь на отдых в Севастополь и решили расположиться в районе Любимовки (отличное место, хорошие волны!), то Вам пригодится печатная копия маршрута от ЖД вокзала
BLE под микроскопом
BLE под микроскопом. Часть 1
Зачем придумали BLE
Как только люди научились передавать информацию без помощи проводов, встала задача передачи данных, используя устройство с батарейным питанием. Проблема в том, что ему должно помогать другое устройство, которое будет постоянно либо прослушивать эфир, либо передавать данные. Проблема возникает в том случае, если и приемник и передатчик имеют батарейное питание. В этом случае приходит на помощь BlueTooth Low Energy (BLE). Он впервые вошел в протокол BlueTooth 4.0. На данный момент уже вышла спецификация BlueTooth 5.0, однако мы будем рассматривать в основном формат BlueTooth 4.0, иногда указывая нововведения для формата 5.0. В качестве одного из устройств обычно выступает смартфон, а второго — батарейный гаджет. Андроид поддерживает BLE с версии 4.3.
Для передачи и приема данных необходима энергия, поэтому поднимают скорость передачи данных, что бы в единицу времени успеть передать больше информации. Для этого в BLE принята скорость передачи информации в 1 Mbit/c. Однако не только скорость передачи данных важна. Самым важным в BLE является то, что устройства связи умеют переходить в синхронный режим работы. Другими словами, устройства спят 99% времени, потом просыпаются на очень короткое время, обмениваются информацией и опять засыпают. Однако перед тем как войти в этот режим, необходимо пройти процедуру синхронизации. Для этого существует режим «advertising». Его мы рассмотрим позднее. А перед тем как погрузится в описание протокола BLE, хотелось бы затронуть тему инструментальных средств, для работы с протоколом BLE.
Инструменты
Для того чтобы разобраться во всем многообразии посылок и запросов нам необходимы инструментальные средства. С их помощью мы смогли бы увидеть содержимое посылок и проконтролировать механизм взаимодействия между устройствами. Для этих целей мы будем использовать nRF51822 Development Dongle (PCA10000), программу сниффера и, для отображения результатов, хорошо известную всем сисадминам программу «Wireshark».
Программы бесплатные, но достать сам донгл может оказаться проблемой. Однако без инструментария, заниматься разработкой таких сложных устройств будет весьма проблематично. На первом этапе может помочь программа на андроиде «nRF Connect».
Она позволяет сканировать эфир, находить и разбирать посылки как присоединяемых, так и не присоединяемых устройств. У Nordic-a есть и ещё инструменты для разработки BLE устройств, но нам будет достаточно этих. На российском рынке присутствует представитель компании Nordic – фирма «Rutronik» (rutronik24.com, rutronik.com). Через её представителей можно приобрести необходимые микросхемы, отладочные платы и т.д. Кроме того, в интернете имеется форум, на котором представители фирмы отвечают на вопросы разработчиков.
Сначала вкратце поговорим о том, как пользоваться нашими инструментами. Вставим в разъем USB наш донгл и запустим программу ble_sniffer_win. Мы увидим следующее окно.
Если донгл увидит BLE устройства, то внизу появится информация о них. В данном случае, в эфире присутствует одно устройство с именем «TestBLE». Так же отображается его уровень сигнала, MAC адрес и то, что этот адрес является случайным (random). Забегая вперед, хочется заметить, что здесь кроется один из подводных камней для разработчиков. Некоторые телефоны (LG G3S, Samsung S6) работают только с устройствами, MAC адреса которых зарегистрированы (public).
У сниффера есть два режима работы. Если мы нажмем кнопку «w» на клавиатуре, то запустится программа «Wireshark». Сниффер будет сканировать три рекламных канала и выдавать информацию обо всех устройствах объявления. Если мы сначала нажмем цифру на клавиатуре, такую же, как напротив интересующего нас устройства, то включится другой режим работы. В нем сниффер будет отслеживать трафик только одного выбранного устройства, причем как на каналах объявления, так и на рабочих каналах
Используя «Wireshark», легко получить всю информацию о посылке. Программа состоит из трех окон. Сверху отображаются все принятые посылки, во втором окне – детальная информация о выбранном пакете, а в третьем окне отображается сам фрейм. В свою очередь, во втором окне имеется три блока информации. В самом верхнем – временные значения выбранного фрейма, во втором (Nordic BLE sniffer meta) – общая информация о фрейме, такие как уровень сигнала, частотный канал и некоторые другие. Самым интересным для нас является третий блок информации (Bluetooth Low Energy Link Layer). В нем можно посмотреть разбор самого фрейма. В дальнейшем мы будем говорить именно об этом блоке информации. Сначала мы разберем формирование рекламных пакетов.
Advertising
Посмотрим на рисунок ниже. На нем показаны распределения каналов по частотам для BLE. Рекламные каналы — это 37 (2402Мгц), 38 (2426Мгц) и 39 (2480Мгц) каналы. Такое распределение рекламных каналов выбрано не случайно. Во-первых, рекламные каналы попадают между каналами Wi-Fi (1, 6, 11 каналы), что позволяет даже при малом уровне мощности, быть услышанными другими устройствами. Во-вторых, когда мы разносим рекламные каналы далеко друг от друга, мы получаем гарантированную доставку сообщения. Это связано с интерференцией сигнала в помещениях. Известно, что в результате отражения радиосигналов от стен, может получиться ситуация, когда приемник и передатчик не слышат друг друга. Однако в нашем случае, когда передача рекламных пакетов идет последовательно на трех разных каналах, максимально удаленных друг от друга по частоте, этот эффект отсутствует.
Рассмотрим теперь формат самого пакета advertising. В спецификации длина данных измеряется в октетах. Для нас это байты. Самым первым байтом идет преамбула. Она состоит из чередующихся нулей и единиц. Это нужно для синхронизации передатчика и приемника. Следом за преамбулой передаются четыре байта адреса доступа(Access Address). После него идет пакет данных (PDU). В спецификции 4.0 максимальная длина PDU составляет 39 байт, а в версии 5.0 длина пакета данных увеличена до 257 байт. В конце каждого рекламного пакета идут три байта контрольной суммы (CRC).
Здесь надо заметить, что Access Address служит для того, что бы устройства понимали, для кого предназначен BLE пакет. Это своеобразный код доступа. Если этот код доступа не знаком устройству, то пакет игнорируется. На всех рекламных каналах, в отличии от рабочих, он одинаков (0x8E89BED6), поэтому все устройства на каналах объявления видят друг друга.
Рассмотрим теперь формат блока данных PDU. В самом начале пакета PDU идет заголовок длинной 16 бит. В нем содержится тип пакета, флаги TxAdd, RxAdd, а так же длина всего поля PDU в байтах. RFU – это зарезервированные поля. Для спецификации 4.0 это выглядит так:
Для спецификации 5.0 увеличена длина поля Payload до 255 байт, а так же добавлены новые поля в заголовок:
Поле TxAdd как раз и отвечает за то, как будет видеться MAC адрес устройства. Если это поле равно единице, то МАС устройства будет виден как random. Рассмотрим теперь какие бывают типы advertising пакетов. На рисунке приведен их список для спецификации 4.0. В формате 5.0 их число увеличено, но мы будем рассматривать то, что есть в обоих форматах.
ADV_IND – это ненаправленные пакеты, которые рассылают устройства, готовые к присоединению. Большинство гаджетов при рассылке рекламных пакетов используют именно их.
ADV_DIRECT_IND — направленные рекламные пакеты присоединяемых устройств. Присоединять и обмениваться данными с ними может только конкретное устройство с заранее известным МАС адресом.
ADV_NONCONN_IND – рекламные пакеты, которые рассылают не присоединяемые устройства. Это маяки (beacon). Обычно они служат для получения какой-либо справочной информации. Например, при входе в магазин могут информировать об акциях. Кроме того, измеряя уровень сигналов от маяков и зная карту их расположения, можно осуществить автоматическое позиционирование внутри помещений. Это актуально для автоматизированных складов.
SCAN_REQ, SCAN_RSP, CONNECT_REQ – пакеты, которыми обмениваются присоединяемое устройство и телефон в процессе установления синхронного соединения. Эти пакеты и сам процесс присоединения мы рассмотрим во второй части статьи.
ADV_SCAN_IND – эти пакеты рассылает не присоединяемое устройство, которое может предоставить дополнительную информацию в ответ на запрос при сканировании.
Во второй части статьи мы рассмотрим различные режимы работы BLE устройств, а так же механизм «присоединения» устройства к телефону и переход на рабочие частоты.