BLE под микроскопом. Часть 2
В первой части мы проанализировали для чего был придуман стандарт Bluetooth LE, а так же рассмотрели формат пакетов объявления «advertising». В данной части, мы продолжим изучать особенности формата и рассмотрим механизм присоединения устройства BLE к смартфону.
Режимы работы 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.
В этом приложении есть поле из 9 клеток, каждой из которых можно присвоить любую команду, а на на саму клетку повесить значок. Таким образом можно получить готовый пульт для управления BLE устройствами. Например для управления электронными игрушками.
Работа с nRFgoStudio
У фирмы Nordic есть универсальное средство для работы с различными китами — это программа nRFgoStudio. Её, как и другие, можно скачать на сайте производителя здесь. Присоедините свое устройство или кит при помощи программатора к компьютеру. Откройте nRFgoStudio и кликните на строчку nRF5x Programming. Если программатор увидит процессор, то откроется окно как на рисунке.
С правой стороны мы видим окно с тремя закладками: Program SoftDevise, Program Application, Program Bootloader. Первое окно (Program SoftDevise) позволяет загружать в процессор стек от Nordic-a, второе — пользовательское приложение, а третье — загрузчик по эфиру (DFU). На сайте есть статья, где это уже было вскользь освещено.
Заключение
Хотелось бы отметить, что мы подробно не разбирали саму рекламную посылку advertising и способ её формирования. Тем, кто заинтересуется как это сделать ручками, я отсылаю к статье. Там указано как можно попробовать работать на более простой микросхеме Nordic-а nRF24L01, не используя стек. Это позволит более глубоко понять структуру посылки.
Кроме того, можно научиться формировать эти же посылки, минуя стек, и на микросхемах nRF51822 b nRF52832. Это гораздо проще, чем работа со стеком. Однако без стека мы не сможем работать на рабочих каналах. Самостоятельно реализовать синхронный режим будет очень сложно. Тема BLE очень обширна и постоянно развивается. Поэтому мы конечно же не смогли описать все особенности этого протокола. Но для первоначального старта этой информации более чем достаточно. Дополнительную информацию можно почерпнуть здесь, здесь и здесь.
Печерских Владимир
Автор: pecherskih
