Как подключить телефон по Bluetooth к автомобилю
Система Bluetooth является беспроводной технологией, которая позволяет создавать беспроводные защищенные локальные сети, что делает данную технологию идеальной для соединений малого радиуса действия между такими устройствами, например, как телефон и информационно-развлекательная система, или между телефоном и громкой связбю системы Bluetooth, которой сегодня оснащаются автомобили.
Смотрите также: Пять лучших автомобильных навигационных систем
Процесс создания таковой сети соединения телефона с автомобилем называется «сопряжением» или «спариванием», так как сама сеть состоит только из одной пары устройств. Несмотря на все то, что одно устройство по Bluetooth можно соединить практически с несколькими (другими) системами и гаджетами, то все-же каждое такое соединение будет надежно и уникально только для одной конкретной пары устройств.
Чтобы успешно создать между сотовым телефоном и информационно-развлекательной системой автомобиля «пару», оба этих устройства должны быть совместимы с Bluetooth.
Большинство автомобильных развлекательных систем оснащены сегодня беспроводной технологией Bluetooth, которая совместима с большинством мобильных телефонов представленных на мировом рынке.
Это позволяет водителю создавать в машине беспроводной канал связи, который будет обеспечивать работу громкой связи с помощью мобильного телефона с которого можно принимать и отправлять звонки не отрывая рук с рулевого колеса. Также такое подключение телефона к автомобилю позволяет водителю принимать и отправлять СМС сообщения, а также прослушивать на аудио-системе автомобиля любимую музыку с телефона и даже выходить в интернет сеть с помощью мобильного интернета прямо с экрана автомобиля.
1). Проверьте ваше оборудование на Bluetooth совместимость
Чтобы использовать свой мобильный телефон в автомобиле с помощью системы громкой связи вам необходимо иметь следующее:
- — Сотовый телефон с поддержкой Bluetooth.
- — Информационно-развлекательную систему или аудиосистему автомобиля с поддержкой Bluetooth.
- — Номер «PIN»-кода для информационно-развлекательной или аудиосистемы.
Кроме всего, подключая телефон к автомобилю полезно иметь следующие аксессуары:
- — Автомобильное крепление для телефона.
- — Зарядное устройство в 12 вольт для сотового телефона.
2). Убедитесь в том, что в телефоне включена система Bluetooth
В большинстве мобильных телефонов и смартфонов обычно уже есть система Bluetooth. Но, тем не менее, перед соединением мобильного телефона с автомобилем вы должны убедиться и проверить наличие данной беспроводной технологии.
Точный процесс сопряжения (подсоединения) телефона к аудиосистеме автомобиля зависит от марки и модели самого телефона и от информационно-развлекательной системы установленной в автомобиле. Поэтому дорогие друзья в этом руководстве по подключению мы будем использовать универсальные советы, которые помогают подключить телефон к машине независимо от его типа, марки и модели. Тем не менее, соединяя телефон с автомобилем предварительно убедитесь, что вы используете правильные функции настройки Bluetooth, ознакомившись для этого с руководством к машине.
И так, чтобы подключить телефон по Bluetooth к автомобилю для начала нужно убедиться, что данная система активирована в самом телефоне. Для этого Вы должны найти в настройках мобильного телефона определенное меню, которое отвечает за включение/отключение беспроводной системы передачи данных по Bluetooth.
Если вы не знаете где в телефоне включается Bluetooth, то обратитесь к руководству данного устройства, где подробно должно быть рассказано, как включить эту беспроводную систему.
Когда Вы нашли в меню телефона ту нужную функцию, которая активирует или дезактивирует систему Bluetooth, то должны все-равно убедиться для себя, что в вашем телефоне стоит и включена опция- «обнаружение телефона другими устройствами». В зависимости от марки и модели телефона можете также установить время видимости (доступности) вашего устройства для других устройств. Например, вы можете настроить ваш телефон таким образом, что он будет виден другими устройствами всего лишь несколько минут.
В некоторых телефонах возможна настройка, чтобы устройство (телефон) был видим постоянно.
Также, в некоторых определенных моделях телефонов система Bluetooth отключается автоматически по прошествию нескольких минут поиска других устройств, если за эти самые минуты не было сделано ни одного внешнего подключения.
3). Убедитесь для себя, что информационно-развлекательная система автомобиля готова к соединению с телефоном
Многие автомобили имеют у себя кнопку- «TEL», «Phone», «Bluetooth» и подобные, при нажатии на которую начнется процесс подключения автомобиля с телефоном. В некоторых автотранспортных средствах данный процесс «спаривания» телефона с машиной можно запустить при помощи голосовой команды. Также есть не мало автомобилей в которых сам процесс соединения мобильного телефона с информационно-развлекательной системой запускается при помощи активации специальной функции прямо с меню экрана.
В нашем примере мы с вами рассмотрим друзья самый сложный из вариантов, когда, чтобы подключить телефон к автомобилю, вам придется воспользоваться меню на самом экране автомобильной информационно-развлекательной системы.
Хотелось бы здесь сразу отметить следующее, что если вам не удалось найти в машине кнопку Bluetooth или же ваш автомобиль просто не поддерживает голосовые команды, то вам придется найти в руководстве к автомобилю определенный раздел, где рассказывается о подключении телефона к информационно-развлекательной системе и о настройках передачи звука с телефона на аудио-систему машины.
4). Поиск телефона информационно-развлекательной системой автомобиля
К этому шагу подключения вы должны приступить только в том случае, если на вашем телефоне включена опция «телефон видим другим устройствам» и система Bluetooth активирована (если вы хотите, чтобы именно информационно-развлекательная система обнаружила ваш мобильный телефон), а также если на вашем телефоне работает функция «поиск устройств» (если вы хотите чтобы именно сам телефон нашел информационно-развлекательную систему).
Тем не менее, независимо каким устройством Вы хотите включить поиск подключаемого оборудования обе эти системы должны быть готовы к поиску подключения в течение 2 минут.
В нашем примере друзья для поиска телефона мы использовали информационно-развлекательную систему автомобиля. Для этого мы нашли в меню развлекательной системы иконку Bluetooth и нажали на нее, чтоб запустить поиск сотового телефона по беспроводному каналу связи.
5). Поиск информационно-развлекательной системы автомобиля на вашем телефоне
Если Вы хотите произвести подключение прямо с телефона, то вы должны сначала активировать Bluetooth и запустить функцию «поиск устройств». После этого ваш телефон начнет сканировать сеть на предмет обнаружения вокруг всех видимых устройств Bluetooth.
Так что не удивляйтесь, если после поиска на экране телефона Вы увидите различные беспроводные гаджеты (ноутбук, чужой компьютер или чужие телефоны).
Ваша главная задача состоит в том, чтобы после поиска устройств выбрать на экране телефона именно вашу информационно-развлекательную систему или систему вашей громкой связи.
6). Выберите из списка обнаруженных устройств Bluetooth громкую связь вашего автомобиля
После того как телефон обнаружил систему громкой связи вашей машины, на экране своего устройства вы должны найти в списке обнаруженного оборудования доступного для подключения, систему «Hands Free» или т.п. систему.
В нашем примере телефон обнаружил систему «Hands Free» («громкая связь») автомобиля Тойоты Камри. После этого в нашем примере нужно было нажать на надпись- «Hands Free», чтобы начать процесс соединения телефона с автомобилем.
После того, как Вы выберете на экране телефона нужное вам устройство для подключения (или после того как информационно-развлекательная система обнаружит ваш телефон), то вы должны будете ввести на телефоне пароль (ПИН-код) для сопряжения двух устройств.
Как правило, все автомобили, оснащенные громкой связью или системой для прослушивания музыки с беспроводных устройств поставляются уже непосредственно с системой генерации паролей для сопряжения автомобиля с телефоном.
Если ваша автомобиль оснащен экраном информационно-развлекательной системы, то. после того как эти устройства найдут друг друга на экране вашего автомобиля должен высветиться слово «пароль», который вы должны набрать на мобильном телефоне для окончательного сопряжения (соединения) устройств.
Если же ваша машина не оснащена экраном, но имеет опцию громкой связи, то обратитесь к руководству транспортного средства, в котором должно быть указано, какой пароль необходимо ввести для подключения телефона к машине.
Например, во многих моделях автомобилей часто используются простые пароли, которые установлены уже на заводе, например: «1234», «1111» и т.п.
Также Вы можете задать (создать) такой пароль вручную, если будете осуществлять поиск устройств непосредственно с телефона.
7). Успешное подключение
Если Вы ввели правильный пароль для сопряжения телефона и автомобиля, то вам удастся успешно подключить телефон к громкой связи автомашины. Если же этого не произошло, то вам нужно повторить все ранее совершонные шаги (действия) сначала. Возможно во время сопряжения Вы ввели неправильный пароль.
Обратите свое внимание на следующее, что в некоторых подержанных автомобилях можно столкнуться с такой проблемой, как подключение телефона к машине, и все это из-за несовместимости или сбоев в работе оборудования. Поэтому запомните друзья, возможно данный процесс подключения нужно будет повторить несколько раз.
8). Исходящие и входящие звонки с помощью системы громкой связи в машине
После того, как вы успешно подключили телефон к автомобилю с помощью Bluetooth, Вы должны проверить для себя, все ли работает должным образом. В зависимости от спецификации вашего автомобиля сам прием и отправка звонков осуществляется у всех по-разному.
В нашем примере мы использовали как уже сказали, автомобиль Тойоту Камри, в которой есть кнопки на рулевом колесе, с помощью которых можно управлять своим сотовым телефоном, принимая входящие звонки не отвлекаясь от дороги.
Обратите свое внимание на то, что на многих современных автомобилях функция отвечающая за звонки при помощи громкой связи находится непосредственно в меню информационно-развлекательной системы или же прямо на центральной консоли.
Некоторые автотранспортные средства имеют у себя всего одну кнопку, которая помимо активации всех функций голосового управления также отвечает и за установку навигационных точек маршрута спутниковой навигации, а еще за управление радио и за входящие и исходящие вызовы.
Кроме того, на рынке есть такие автомобили, которые оснащены системой голосового управления при помощи которого вы можете управлять непосредственно многими функциями автомобиля, произнося таким образом определенные голосовые команды. Например, в некоторых моделях автомобилей есть функция голосового управления непосредственно системой громкой связи.
Беспроводные стереонаушники с функцией шумоподавления WH-XB910N
Операция по регистрации устройства, которое вы хотите подключить, называется “согласованием”. Перед тем как использовать какое-либо устройство с гарнитурой впервые, выполните согласование.
Перед выполнением этого действия проверьте следующее:
- Устройство Bluetooth располагается в пределах 1 м от гарнитуры.
- Батарея гарнитуры имеет достаточный заряд.
- Инструкция по эксплуатации устройства Bluetooth находится под рукой.
Войдите в режим согласования гарнитуры.
Включите гарнитуру при согласовании гарнитуры с устройством в первый раз после покупки или после инициализации гарнитуры (гарнитура не содержит информации согласования). Гарнитура автоматически перейдет в режим согласования. В этом случае перейдите к шагу 2. При согласовании второго и последующих устройств (гарнитура содержит информацию о согласовании с другими устройствами) нажмите и удерживайте кнопку 
(питание) приблизительно в течение 5 секунд. 
Убедитесь, что индикатор (синий) мигает сериями по два раза. Вы услышите голосовое уведомление “Bluetooth pairing” (согласование Bluetooth) .
Выполните процедуру согласования на устройстве Bluetooth для поиска гарнитуры.
[ WH-XB910N ] будет отображаться в списке обнаруженных устройств на экране устройства Bluetooth .
Выберите [ WH-XB910N ] на экране устройства Bluetooth для согласования.
Если требуется введение кода доступа (*), введите “0000”. * Код связи может называться “Код доступа”, “PIN-код”, “PIN-номер” или “Пароль”.
Выполните подключение Bluetooth с устройства Bluetooth .
Некоторые устройства подключают гарнитуру по завершении согласования. Вы услышите голосовое уведомление “Bluetooth connected” (Bluetooth подключено) . Если подключение отсутствует, см. раздел “Подключение к согласованному устройству Bluetooth ”.
Совет
- Указанная выше процедура приводится в качестве примера. Дополнительные сведения см. в инструкции по эксплуатации, прилагаемой к устройству Bluetooth .
- Для удаления всей информации о согласовании Bluetooth см. раздел “Инициализация гарнитуры для восстановления заводских настроек”.
Примечание
- Если согласование не было установлено в течение 5 минут, режим согласования отменяется. В этом случае выключите питание и выполните операцию снова с шага 1.
- Если устройства Bluetooth согласованы, выполнять согласование повторно не требуется, кроме следующих случаев.
- Информация о согласовании была удалена после ремонта и т. д.
- Если согласуется 9-е устройство.
Согласование гарнитуры можно выполнить максимум с 8 устройствами. Если новое устройство согласуется после выполнения согласования с 8 устройствами, информация о регистрации устройства, которое согласовывалось давнее всего, будет заменена информацией нового устройства. - Если информация о согласовании гарнитуры удалена с устройства Bluetooth .
- Если гарнитура инициализирована.
Вся информация о согласовании будет удалена. В этом случае удалите информацию о согласовании с гарнитурой с подключенного устройства и выполните согласование снова.
См. также
- Установка беспроводного соединения с устройствами Bluetooth
- Подключение к согласованному устройству Bluetooth
- Прослушивание музыки с устройства через подключение Bluetooth
- Отключение соединения Bluetooth (после использования)
- Инициализация гарнитуры для восстановления заводских настроек
Bluetooth Low Energy: подробный гайд для начинающих
Создание кастомного сервиса и тем более клиента Bluetooth Low Energy – прогулка по граблям с завязанными глазами. По крайне мере так было для меня 4 года назад, когда я только начинал работать с BLE-устройствами. Сейчас почти каждый мой проект предусматривает использование этого протокола, поэтому в свое время пришлось в нем долго и мучительно разбираться.
Разложить все по полкам помогла книга Мохаммада Афане «Intro to Bluetooth Low Energy» и серия постов на Novel Bits. Лично для меня эта книга стала настоящим открытием. Изначально я делал ее перевод на русский для своих коллег, не имеющим опыт работы с BLE. С согласия автора (огромное ему спасибо) решил опубликовать свою работу здесь. Надеюсь, перевод окажется полезным.
Это первая часть перевода (всего их будет 5), которая рассказывает, что такое BLE, его возможности и отличия от Bluetooth Classic, а также описывает архитектуру протокола.
Об авторе
Мохаммад Афане занимается разработкой встроенного программного обеспечения и прошивок с 2006 года. Он работал и консультировал множество крупных компаний, включая такие как Allegion (Schlage locks), Motorola, Technicolor, Audiovox, и Denon & Marantz Group. На протяжении всей своей карьеры он работал над множеством проектов Интернета Вещей, включая: беспроводные электронные дверные замки, спутниковые приемники, беспроводные дверные замки и т.д.
В июле 2015 года он принял решение прекратить работу на полную ставку для того, чтобы основать собственную компанию Novel Bits, LLC, где он делится своими знаниями и опытом на своем web-сайте, локальных тренингах и в электронных книгах, посвященных разработке приложений с поддержкой Bluetooth Low Energy.
Вы можете связаться с Мохаммадом по его электронной почте: mohammad@novelbits.io или через профиль на LinkedIn.
Базовые понятия Bluetooth Low Energy
1. Что такое Bluetooth Low Energy?
Bluetooth был задуман как технология связи ближнего диапазона, призванная заменить провода в таких устройствах, как компьютерные мыши, клавиатуры или персональные компьютеры. Если у вас есть современный автомобиль или смартфон, то скорее всего вы использовали Bluetooth хотя бы раз в своей жизни. Он повсюду: в громкоговорителях и колонках, беспроводных наушниках, автомобилях, носимых устройствах и даже в шлёпанцах!
Первая официальная версия стандарта была выпущена компанией Ericsson в 1994 году. Разработчики назвали свое изобретение в честь короля Дании Харальда Гормссона по прозвищу «Синезубый», объединившего в 10 веке враждовавшие датские племена в единое королевство.
В настоящее время существует два типа устройств с поддержкой Bluetooth:
- Bluetooth Classic (BR/EDR), используется в беспроводных громкоговорителях, автомобильных информационно-развлекательных системах и наушниках;
- Bluetooth Low Energy (BLE), т.е. Bluetooth с низким энергопотреблением, который появился в версии стандарта Bluetooth 4.0. Он чаще всего применяется в приложениях, чувствительных к энергопотреблению (например в устройствах с батарейным питанием) или в устройствах, передающих небольшие объемы данных с большими перерывами между передачами (например, разнообразные сенсоры параметров окружающей среды или управляющие устройства, такие как беспроводные выключатели).
Эти два типа устройств несовместимы друг с другом, даже если они выпущены под одним брендом или спецификацией. Устройства с поддержкой Bluetooth Classic не могут напрямую связываться с устройствами, использующими BLE. Это причина, по которой некоторые устройства, такие как смартфоны, выполняются с поддержкой обоих типов соединения (так называемые Dual mode Bluetooth devices), что позволяет им обмениваться информацией с обоими типами устройств.
Несколько важных замечаний о BLE:
- Официальная спецификация Bluetooth сочетает оба типа Bluetooth (Classic и BLE), что иногда затрудняет поиск документации, специфичной для BLE;
- BLE был введен в версии 4.0 спецификации стандарта Bluetooth, выпущенной в 2010 году;
- BLE иногда называют Bluetooth Smart, BTLE или Bluetooth 4.0, что является ошибкой, так как эта версия в действительности включает оба типа Bluetooth;
- Bluetooth Classic и BLE работают в одном и том же частотном диапазоне – 2.4 ГГц, ISM-диапазон.
Поскольку во многих устройствах Интернета Вещей (IoT) используются небольшие устройства и датчики, BLE стал наиболее часто используемым протоколом связи (в сравнении с Bluetooth Classic) в приложениях Интернета Вещей. В декабре 2016 года группа компаний Bluetooth Special Interest Group (SIG), регулирующая развитие стандарта, выпустила Bluetooth версии 5.0 (для простоты маркетинга была убрана точка из названия, так что официально он называется Bluetooth 5). Большинство улучшений и новых функций, представленных в этой версии, были ориентированы на BLE, а не на Bluetooth Classic.
Вы также могли слышать о другом термине, связанном с Bluetooth − Bluetooth Mesh. Bluetooth Mesh был выпущен в июле 2017 года и основан на BLE. Для работы ему требуется полный стек BLE (ПО, которое действует как интерфейс для другого программного или аппаратного обеспечения), но он не является частью основной спецификации Bluetooth. Мы рассмотрим более подробно эту технологию в отдельной главе.
Подводя итог, посмотрим на диаграмму, показывающую прогресс BLE за прошедшие годы с начала его появления:
Технические факты о BLE
Некоторые из наиболее важных технических фактов о BLE включают в себя:
- Используемый частотный диапазон 2.400 — 2.4835 ГГц.
- Весь частотный диапазон поделен на 40каналов по 2 МГц каждый.
- Максимальная скорость передачи данных по радиоканалу (начиная с Bluetooth версии 5) 2Мбит/с.
- Дальность передачи сильно зависит от физического окружения, а также используемого режима передачи. Например, в режиме большой дальности передачи дальность связи будет выше, а скорость передачи ниже, чем в высокоскоростном режиме. Типичная дальность передачи: 10-30 метров.
- Потребление электроэнергии также может изменяться в широких пределах. Оно зависит от реализации устройства, различных параметров протокола и используемого чипсета. Типичное потребление BLE-трансивера во время передачи данных как правило не превышает 15 мА.
- Обеспечение безопасности не обязательно при обмене данными через BLE и зависит от устройства и реализации приложения разработчиком. Другими словами, существует несколько возможных для реализации уровней обеспечения безопасности.
- Для всех операций, связанных с шифрованием, BLE использует алгоритм AES-CCM с длиной ключа 128 бит.
- BLE предназначен для передачи данных по каналу с низкой пропускной способностью. Использование BLE для приложений с большим объемом часто передаваемых данных существенно увеличивает потребление электроэнергии и сводит на нет основное преимущество BLE. То есть минимизация использования радиосвязи, насколько это возможно, позволяет достичь минимального уровня потребления энергии.
- Версии Bluetooth (в части BLE) являются обратно совместимыми. Тем не менее возможности связи будут ограничены функциями более старой версии. Например, устройство с поддержкой Bluetooth 5 LE может установить связь с устройством с поддержкой Bluetooth 4.1 LE, но возможности, появившиеся в версии 4.2 и более новых, будут недоступны. В то же время они смогут использовать возможности подключения, рассылки и приема широковещательных пакетов, обнаруживать сервисы и характеристики, а также читать и записывать их независимо от поддерживаемой ими версии стандарта, так как эти возможности доступны во всех версиях Bluetooth.
Сравнение Bluetooth Classic и BLE
Важно помнить, что существует большая разница между классическим Bluetooth и Bluetooth с низким энергопотреблением с точки зрения технических спецификаций, реализации и типов приложений, для которых они предназначены. Это в дополнение к тому факту, что они несовместимы друг с другом.
Некоторые из упомянутых различий представлены в этой таблице:
Таблица 1. Сравнение Bluetooth Classic и BLE
Bluetooth Classic
BLE
Используется для потоковых приложений, таких как трансляция аудио и передача файлов
Используется в сенсорах, управлении устройствами и приложениях, не требующих передачи больших объемов данных
Не оптимизирован для низкого энергопотребления, но поддерживает большую скорость передачи (максимум 3 МБит/с, в то время как BLE 5 имеет максимум 2 МБит/с)
Предназначен для применения в малопотребляющих устройствах с большими интервалами между передачей данных
Использует 79 радиоканалов
Использует 40 радиоканалов
Обнаружение происходит на 32 каналах
Обнаружение происходит на 3 каналах, что приводит к более быстрому обнаружению и установке соединения по сравнению с Bluetooth Classic
С момента официального выпуска в 2010 году BLE прошел череду ревизий и изменений. Наиболее важное изменение произошло в декабре 2016 года с внедрением Bluetooth 5, который привнес множество важных улучшений в спецификацию стандарта, большинство из которых касалось BLE. Эти улучшения позволили удвоить скорость передачи, в 4 раза увеличить дальность передачи и в 8 раз увеличить размер широковещательного пакета.
Возможности и ограничения BLE
Каждая технология имеет свои ограничения, и BLE не является исключением. Как мы упомянули ранее, BLE наилучшим образом подходит для приложений с небольшим радиусом передачи и редко передаваемыми небольшими объемами данных.
4.1. Ограничения BLE
Пропускная способность
Пропускная способность BLE ограничена физической пропускной способностью радиоканала, т.е. скоростью, с которой данные передаются по радиоканалу. Пропускная способность зависит от используемой версии Bluetooth. Для Bluetooth 4.2 и более ранних, доступна только пропускная способность в 1 Мбит/с. В Bluetooth 5 и более поздних версиях пропускная способность зависит от выбранного режима PHY (Physical Layer, рассматривается в разделе физического уровня). Она может составлять 1 Мбит/с как в более ранних версиях или 2 Мбит/с при использовании высокоскоростной передачи. При использовании функции дальней связи пропускная способность ограничена значениями 500 или 125 кбит/с. Мы обсудим это более подробно в главе, посвященной Bluetooth 5.
Скорость передачи с точки зрения конечного пользователя всегда будет ниже скорости передачи по радиоканалу в силу следующих факторов:
- Промежутки между пакетами данных: спецификация Bluetooth определяет зазор в 150 микросекунд между передаваемыми пакетами как требование для соблюдения спецификации. В этот промежуток времени невозможна передача данных между устройствами.
- Служебная информация внутри пакета: каждый пакет содержит помимо полезной нагрузки заголовок и служебные данные, обрабатываемые на уровнях ниже уровня приложения. Они учитываются при передаче данных, но не используются вашим приложением.
- Требование на передачу служебной информации периферийным устройством: спецификация требует обязательного ответа ведомого устройства на каждый пакет, переданный ведущим. В случае, когда необходимая для передачи информация отсутствует, передается пустой пакет.
- Переотправка пакетов данных: в случае потери пакета или перекрестных помех от находящихся поблизости устройств, потерянные или поврежденные данные отправляются заново.
Дальность передачи
BLE был разработан для применения на коротких расстояниях, и, следовательно, его диапазон действия ограничен. Вот некоторые факторы, ограничивающие дальность передачи при помощи BLE:
- На передачу в ISM-диапазоне 2.4 ГГц сильно влияют окружающие нас препятствия, такие как металлические предметы, бетонные стены, вода и человеческие тела.
- Диаграмма направленности и коэффициент усиления антенны.
- Корпус устройства, в котором находится антенна, также ухудшает характеристики антенны.
- Ориентация устройства в пространстве, от которого зависит ориентация антенны, например в смартфонах.
Потребность в шлюзе для интернет-соединения
Для передачи данных с устройства, поддерживающего только BLE-соединение, необходимо другое устройство с поддержкой как BLE, так и IP-соединения. Именно оно будет получать данные и отправлять их в интернет.
4.2 Преимущества BLE
Даже с учетом представленных выше ограничений BLE имеет некоторые существенные преимущества перед другими аналогичными технологиями передачи данных для IoT.
Вот некоторые из них:
По сравнению с другими низкопотребляющими технологиями передачи данных, BLE потребляет гораздо меньше электроэнергии. Это достигается благодаря глубокой оптимизации протокола, выключению передатчика при первой возможности и пересылке малых объемов данных на низкой скорости.
- Бесплатный доступ к официальным спецификациям;
Чтобы получить доступ к спецификациям большинства других протоколов вы должны стать членом официальной группы или консорциума по этому стандарту. Стать членом можно за внушительную сумму (от 7500 до 35000 долларов в год). В случае с BLE, спецификации для основных версий (4.0, 4.1, 4.2, 5) доступны для загрузки с сайта Bluetooth абсолютно бесплатно.
- Низкая цена модулей и чипсетов по сравнению с другими технологиями;
- Наконец, не менее важный фактор – наличие в большинстве смартфонов на рынке. Возможно, это наибольшее преимущество BLE перед такими технологиями как ZigBee, Z-Wave и Thread.
4.3 Наиболее подходящие области применения BLE
Исходя из ограничений и преимуществ, указанных выше, существуют варианты использования, где BLE раскрывается наиболее полно:
BLE подходит для случаев, когда устройство передает небольшие объемы данных, например, данные датчиков или команды исполнительных устройств.
В случаях, когда BLE не удовлетворяет основным требованиям системы, он может использоваться для настройки устройства до того, как оно окажется подключенным к основной сети передачи данных.
Например, некоторые устройства с поддержкой WiFi добавляют BLE как вспомогательный протокол вместо использования таких технологий как WiFi Direct. Это технология, которая позволяет двум устройствам с поддержкой WiFi соединяться напрямую, минуя роутер. Вы можете узнать подробнее о ней на Википедии или здесь.
- Использование смартфона в качестве интерфейса;
Компактные малопотребляющие устройства обычно не имеют больших экранов и зачастую отображают ограниченное количество данных конечному пользователю,например, путем светодиодной индикации. В настоящее время, благодаря широкому распространению смартфонов, BLE может предложить альтернативный, гораздо более информативный и удобный интерфейс для этих устройств. Еще одним преимуществом смартфона является возможность загрузки данных в облако.
- Персональные и носимые устройства;
Для случаев, когда устройство является носимым и находится вне зоны покрытия беспроводных сетей (таких как WiFi или сотовая связь), BLE может оказаться единственным доступным способом подключения.
- Устройства без возможности установления соединения.
Вероятно вы слышали или видели ранее такие устройства как маячки. У этих устройств одна простая задача – выдавать через определенные промежутки времени в эфир данные так, чтобы другие устройства могли их обнаружить и принять передаваемые данные. Существуют и другие технологии, которые могут быть использованы для этих целей. Тем не менее BLE становится все более популярным, так как большинство людей имеют смартфоны, которые поддерживают BLE «из коробки».
Все вышеперечисленные сценарии только выигрывают от использования BLE. С другой стороны, есть условия, при которых, как правило, использование BLE невозможно или не дает ощутимых преимуществ, такие как:
- Потоковая передача видео;
- Трансляция высококачественного звука (прим.: стала возможна в BLE 5.2);
- Передача больших объемов данных в течении длительного времени в тех случаях, когда важно сокращение энергопотребления.
Архитектура BLE
Рисунок ниже иллюстрирует различные уровни, присущие архитектуре BLE. Три главных блока в этой архитектуре – приложение, хост и контроллер.
В этой книге мы сфокусируемся на верхних уровнях архитектуры, кратко ознакомившись с нижними уровнями в этой главе. Подробное описание верхних уровней – GAP (Generic Access Profile), GATT (Generic Attribute Profile) и Security Manager – вынесем в отдельные главы.
Прикладной уровень
Прикладной уровень зависит от варианта использования девайса/приложения и относится к реализации на основе общего профиля доступа (GAP) и общего профиля атрибутов (GATT) – он отвечает за то, как ваше приложение обрабатывает данные, полученные от других устройств и отправленные на них, а также управляющую логику.
Эта часть является кодом, который вы написали для своего приложения и, как правило, не является частью BLE-стека для платформы, под которую вы разрабатываете. Эта часть не рассматривается в книге, поскольку она зависит от специфики вашего приложения и способа использования.
Хост-уровень
Хост включает следующие уровни:
- Общий профиль доступа (GAP, Generic Access Profile);
- Общий профиль атрибутов (GATT, Generic Attribute Profile);
- Протокол атрибутов (ATT, Attribute Protocol);
- Менеджер безопасности (SM, Security Manager);
- Протокол управления и адаптации логических связей (L2CAP, Logical Link Control and Adaptation Protocol);
- Интерфейс хост-контроллера (HCI, Host Controller Interface), зона ответственности хоста.
Контроллер
Контроллер включает следующие уровни:
- Физический уровень (PHY, Physical Layer);
- Слой связи (Link Layer);
- Режим прямого тестирования (DTM, Direct Test Mode);
- Интерфейс хост-контроллера (HCI, Host Controller Interface), зона ответственности контроллера.
Уровни архитектуры BLE
Физический уровень (PHY)
PHY относится к части оборудования, ответственного за прием, передачу, модуляцию и демодуляцию сигнала. BLE работает в ISM-диапазоне (2.4 ГГЦ), который разделен на 40 каналов по 2 Мгц, как показано на рисунке ниже:
Три выделенных канала носят название Первичных Широковещательных Каналов, в то время, как оставшиеся 37 используются в роли Вторичных Широковещательных и для передачи данных во время соединения. Мы подробно рассмотрим принципы их использования в разделе “Адвертайзинг и сканирование”, но для начала кратко ознакомимся с ними в этой главе.
Адвертайзинг заключается в рассылке широковещательных пакетов по трем Первичным Каналам Адвертайзинга (или части из них). Это дает возможность обнаружить широковещающее устройство и прочитать его данные сканирующим устройствам. После этого сканирующее устройство может инициировать соединение, если широковещающее разрешает подключение. Также сканирующее устройство может послать запрос на сканирование, и, если широковещающее устройство поддерживает эту функцию, то оно пошлет ответ на сканирование. Запросы на сканирование и ответы на него позволяют передавать дополнительные данные без подключения к устройству.
Вот некоторые другие важные технические детали, касающиеся физического уровня передачи BLE:
- Он использует скачкообразную перестройку несущей частоты (FHSS, Frequency Hopping Spread Spectrum), что позволяет двум взаимодействующим устройствам переключаться на случайные предварительно согласованные частоты для обмена данными. Это значительно повышает надежность и позволяет устройствам избегать перегруженных каналов.
- Мощность передачи может быть:
Не более: 100 мВт (+20 дБм) для версии 5 и более новых, 10 мВт (+10 дБм) для версии 4.2 и более старых;
Не менее: 0.01 мВт (-20 дБм).
- В старых версиях Bluetooth (4.0, 4.1 и 4.2) была доступна только одна скорость передачи – 1 Мбит/с. Физический уровень радио (PHY) в этом случае называется 1M PHY и является обязательным во всех версиях, включая Bluetooth 5. В Bluetooth 5 были также введены два новых дополнительных PHY:
- 2 Мбит/с PHY, используемый для удвоения скорости передачи по сравнению с более ранними версиями Bluetooth.
- Кодированный PHY, используемый для связи на дальних расстояниях.
Мы рассмотрим эти два новых PHY и концепцию кодирования в главе, посвященной Bluetooth 5.
Канальный уровень
Канальный уровень отвечает за взаимодействие с физическим уровнем радио и предоставление другим уровням абстракции для взаимодействия с радио (через промежуточный уровень интерфейса хост-контроллера, который мы вскоре обсудим). Он отвечает за управление состоянием радио и соблюдение требований к временным задержкам, необходимых для удовлетворения спецификации BLE. Также он отвечает за управление аппаратно-ускоренными операциями, такими как вычисление контрольных сумм, генерацию случайных чисел и шифрование.
Существует три основных состояния, в которых может находиться устройство с BLE:
- Широковещательное состояние (Advertising);
- Состояние сканирования (Scanning);
- Подключенное состояние.
Когда устройство посылает широковещательные пакеты, оно позволяет сканирующим устройствам обнаружить себя и подключиться. Если широковещающее устройство допускает подключения, сканирующее устройство нашло его и послало запрос на подключение, оба они переходят в подключенное состояние.
Канальный уровень управляет различными состояниями радио, показанными на рисунке:
- Standby: состояние по умолчанию, когда радио не передает и не принимает никаких данных.
- Advertising: состояние, в котором устройство посылает широковещательные пакеты для обнаружения и чтения другими устройствами.
- Scanning: состояние, в котором устройство ищет устройства, посылающие широковещательные пакеты.
- Initiating: состояние, в котором начинается процесс установки соединения с устройством, находящимся в состоянии advertising.
- Connected: Состояние, в котором одно устройство установило соединение с другим и регулярно обменивается с ним информацией. В подключенном состоянии устройство, которое находилось в состоянии scanning и инициировало соединение, называется ведущим. Устройство, которое рассылало широковещательные пакеты, называется ведомым.
Мы рассмотрим эти состояния более подробно в последующих главах.
Bluetooth-устройства идентифицируются посредством 48-битного адреса, похожего на MAC-адрес. Существуют два основных типа адресов: публичный и случайный.
Это фиксированный адрес, запрограммированный на фабрике. Он не может быть изменен и должен быть зарегистрирован в IEEE (также, как и MAC-адреса устройств с поддержкой WiFi или Ethernet).
Так как у производителей есть возможность выбирать, какой тип адреса использовать (публичный или случайный), случайные адреса встречаются более часто, так как они не требуют регистрации в Институте инженеров электротехники и электроники. Случайный адрес программируется на устройстве или генерируется в ходе выполнения программы. Он может относиться к одному из следующих подтипов:
- Статический адрес
- Используется в качестве замены публичного адреса;
- Может быть заново сгенерирован при загрузке кода или оставаться постоянным в течение всего срока службы;
- Не может изменяться при включении или выключении.
- Случайный, генерируется на определенный промежуток времени;
- Широко не используется.
– Разрешимый частный адрес:
- Используется для обеспечения безопасности;
- Генерируется с использованием ключа (IRK, Identity Resolving Key) и случайного числа;
- Периодически меняется (даже во время соединения);
- Используется для защиты от отслеживания злоумышленниками;
- Доверенные устройства (связанные, описанные в главе, посвященной безопасности) могут расшифровать адрес, используя предварительно сохраненный ключ.
Режим прямого тестирования
Режим прямого тестирования (DTM, Direct Test Mode) используется исключительно для проведения испытаний радиочасти во время производства или сертификационных испытаний. Он не относится напрямую к теме нашей книги, поэтому мы оставим его без подробного рассмотрения.
Уровень интерфейса хост-контроллера (HCI)
Интерфейс хост-контроллера – это стандартный протокол, определенный спецификацией Bluetooth, который позволяет уровню хоста коммуницировать с уровнем контроллера. Эти уровни могут быть реализованы на двух раздельных микросхемах или существовать на одной. В этом смысле он также обеспечивает взаимодействие между микросхемами, поэтому разработчик устройства может выбрать два сертифицированных Bluetooth-устройства, контроллер и хост, и быть на 100% уверенным в том, что они совместимы друг с другом в плане связи между уровнями хоста и контроллера.
В случае, когда хост и контроллер находятся на разных микросхемах, связь между ними может быть реализована посредством трех официально поддерживаемых физических интерфейсов: UART, USB или SDIO (Secure Digital Input Output). В случае, когда хост и контроллер находятся на одной и той же микросхеме, интерфейс хост-контроллера будет логическим интерфейсом.
Задача интерфейса хост-контроллера состоит в передаче команд от хоста контроллеру и передаче информации и событий от контроллера к хосту. На рисунке ниже приведен пример обмена командами и событиями между уровнями хоста и контроллера.
Примеры сообщений включают в себя: пакеты команд, настройку контроллера, запрос действий, управление параметрами соединения, пакеты событий, завершение команд и события состояния.
Уровень протокола управления и адаптации логического канала (L2CAP)
Протокол L2CAP предоставляет услуги по работе с данными, как ориентированные на соединения, так и без ориентации на них, протоколам более высокого уровня с возможностями мультиплексирования и обеспечения операций по сегментации и обратной сборке. Он заимствован из стандарта Bluetooth Classic и в случае BLE выполняет следующие задачи:
- Принимает несколько протоколов с верхних уровней и помещает их в стандартные пакеты BLE, которые передаются на нижние уровни под ним.
- Управляет фрагментацией и рекомбинацией пакетов. Он берет большие пакеты с верхних уровней и разбивает их на порции, которые соответствуют максимальному размеру полезной нагрузки BLE, поддерживаемому для передачи. На стороне получателя он принимает несколько пакетов и объединяет их в один пакет, который может быть обработан верхними уровнями.
В случае BLE уровень L2CAP управляет двумя основными протоколами: протоколом атрибутов (ATT, рассмотрен в главе, посвященной GATT) и протоколу управления безопасностью (SMP, рассмотрен в главе, посвященной безопасности).
Слои верхнего уровня
Протокол атрибутов (АТТ), общий профиль атрибутов (GATT), менеджер безопасности (SM) и общий профиль доступа (GAP) будут подробно рассмотрены в следующих главах.
На этом заканчивается первая глава книги. Большое спасибо дочитавшим. Следующая часть будет посвящена классам устройств и адвертайзингу – методу, с помощью которого устройства сообщают о своем присутствии окружающему миру.
Работаем с Bluetooth в iOS
Одно из моих любимых направлений в мобильной разработке — это разработка мобильных приложений, которые работают с объектами вне их инфраструктуры, с различными интересными гаджетами, датчиками и объектами из мира интернета вещей. Сегодня поговорим как раз про это направление, а точнее, про Bluetooth.
Эта статья — конспект к моему докладу на неделе «Нестандартной разработки iOS» прошедшей в рамках пятого сезона Podlodka iOS Crew. На этой неделе, помимо работы с Bluetooth, были рассмотрены и другие интересные моменты: Metal, Core Audio и многое другое! Вы еще можете приобрести доступ к докладам или залететь на следующий сезон!
Наверное, никому из вас не нужно объяснять что такое блютус и зачем он применяется. Сейчас эта технология беспроводной передачи данных имеет индекс версии 5.1 и очень сильно скакнула в своём развитии. Свой первый айфон я купил в 2009 году, и даже тогда мне приходилось выслушивать тонны хейта по поводу несовершенства этого девайса. Одним из саааамых частых и бесящих меня поинтов было постоянные упреки в отсутствии передачи файлов по блютусу. И вообще в неполноценности Bluetooth на iOS и невозможности им пользоваться кроме как подключить беспроводные наушники. Курьезный факт: уже через 3 года, iOS имела самый мощный среди мобильных платформ фреймворк, который конкуренты еще долго не смогут догнать (ИМХО и не догнали). Действительно, большинство вещей, о которых я сегодня расскажу были представлены в 2012 году (а часть и вовсе в 2011) и мало менялись с тех пор.
Итак, Блютус. Я не буду давать каких-то формальных объяснений или уходить глубоко в обзорную историю. Пройдусь максимально поверхностно. Для нас, как для разработчиков, это интерфейс взаимодействия с внешними устройствами. История его развития начинается в далёком 1998 году, но более менее массовое распространение он получил в середине 2000х с широким развитием рынка смартфонов и коммуникаторов. На заре iOS, вплоть до 4й версии, разработчики не имели возможности взаимодействовать с устройствами посредством блютус вообще, но всё изменилось в 2011 году, с выходом iOS 5. Ключом к такому стремительному росту стало принятие стандарта Bluetooth 4.0, который в 2010 году, который стал отвечать требованием рынка по параметрам скорости и энергопотребления. Последнее играло ключевую роль. Именно тогда появился стандарт, а точнее спецификация, BLE – Bluetooth Low Energy, который позволил сильно расширить сферу применения этой беспроводной технологии.
В чем же особенности BLE? Ну, как не сложно догадаться из названия, главная фишка в экстремально (на 2010 год уж точно) низком энергопотреблении. Спецификация позволяет разрабатывать устройства, которые будут минимально расходовать свою батарею и работать до одного года на одном заряде небольшого элемента питания. Спецификацию разработала компания Bluetooth Special Interest Group (SIG) и эти ребята настолько заморочились, насколько, как мне кажется, это было вообще возможно. Чтобы не давать волю полёта фантазии разработчикам и не плодить кучу конкурирующих страндартов, SIG разработала спецификацию под все возможные типы устройств, начиная с носимых датчиков пульса, заканчивая стационарными дверными замками. Именно взаимодействие через Bluetooth LE нам доступно через встроенный фреймворк CoreBluetooth. Apple тоже проделали гигантскую работу, скрыв от нас все детали работы с низкоуровневыми штучками и предоставили очень простой API с которым разберется и любой начинающий iOS разработчик!
Bluetooth Low Energy в деталях
Основой BLE является профиль GATT – General Attribute Profile, который предоставляет нам абстракции сервиса и характеристик. Характеристика — это, грубо говоря, ячейка данных, а сервис — это некоторое логическое их объединение. Может звучать непонятно, но сейчас я приведу пример и всё сразу встанет на свои места. Самый классический и на самом деле распространенный пример — термометр. Он может иметь сервис измерения температуры и иметь две характеристики: единицу измерения (℃, ℉) и собственно саму температуру. А еще он может определять влажность и для неё будет отдельный сервис с одной лишь характеристикой — влажности в процентах.
Всё взаимодействие в BLE строиться на классической клиент-серверной модели: тут тоже есть клиент и сервер, есть запросы. С этого момента я буду плавно переходить к самому фреймворку CoreBluetooth и уже новые термины объяснять ближе к предметной области, т.к. большинство терминов совпадают с теримнами BLE, только имеют префикс CB — CoreBluetooth.
CoreBluetooth
Итак, CoreBluetooth. Как уже было сказано, появился в iOS 5, был серьезно доработан в iOS 6 и существует до сих пор, не претерпев каких-либо серьезных изменений с тех пор. Как я уже сказал, всё взаимодействие строиться на классической клиент-серверной модели и в CB у нас есть сервер – Peripheral и клиент Сentral. Такой нейминг может слегка путать некоторое время, т.к. мы привыкли что именно сервер является неким центром, а CB переворачивает все с ног на голову. Но с другой стороны всё логично: Peripheral device — периферийное устройство, внешнее по отношению к нашему, центральному. Peripheral device’ом может быть фитнес трекер, умная лампочка, замок или целая система умного дома, а может быть и другое мобильное устройство или компьютер.
Поиск
Хотя и процесс является клиент-серверным, в отличии от HTTP, точный адрес или алиас устройства нам не известен, поэтому чтобы начать с ним взаимодействие необходимо его найти в эфире. Процесс обнаружения устройства называется сканированием или дискаверингом. Он выполняется Central устройством, той стороной, которая хочет к чему-то подключиться. Процесс заключается в сканировании Bluetooth эфира на предмет так называемых Advertisement-пакетов, которые должно отправлять периферийное устройство. Advertisement-пакет — это крохотный пакет регулярно отправляемый периферийным устройством, когда оно хочет чтобы его нашли. Он обычно содержит базовую информацию, необходимую для того, чтобы понять что класс устройства: термометр, замок, самокат или другой айфон. В зависимости от режима работы устройства и настроек его энергопотребления, пакеты могут рассылаться с различными интервалом, от раза в несколько микросекунд, до раза в десятки секунд, поэтому длительность сканирования напрямую зависит от режима работы периферийного устройства.
Как только искомый девайс будет найден, мы можем подключиться к нему и спросить, какие сервисы он имеет и какие характеристики нам доступны в этих сервисах. Давайте перейдем ближе к коду.
Итак, мы хотим найти термометр, который для нас является периферийным устройством. Значит, мы в этом случае будем клиентом, то есть Central Device. Объект который представляет клиента в фреймворке CoreBluetooth имеет тип CBCentralManager . Как не сложно догадаться, всё взаимодействие c внешним устройством предполагается асинхронным. И еще проще догадаться, что Apple предпочла паттерн делегат для обеспечения асинхронной работы. Нужный нам делегат имеет тип CBCentralManagerDelegate и объект, реализующий этот протокол и будет получать уведомления о событиях связанных с поиском и подключением.
Как только мы будем готовы сканировать эфир, нужно вызвать метод scanForPeripherals у менеджера CBCentralManager . Как только наше устройство увидит новый рекламный пакет, будет вызван метод делегата didDiscoverPeripheral с объектом CBPeripheral в параметрах метода. Когда мы найдем нужное устройство или устройства, нам нужно остановить сканирование методом stopScan и вызвать connect указав экземпляр класса CBPeripheral .
Поиск сервисов
Как только соединение будет установлено, мы можем начать опрашивать устройство. С этого момента мы уже работаем с объектом CBPeripheral и его делегат CBPeripheralDelegate которые представляют внешнее устройство, к которому мы подключились. Чтобы считать какое-то значение (характеристику) сначала нужно найти сервис, в составе которого эта характеристика существует. Запустим поиск сервисов. Мы можем как указать сервис или сервисы которые нас точно интересует, либо не указывать их и найти все, что реализует устройство.
Тут нужно отвлечься и объяснить как мы можем отличать сервисы друг от друга. Идентификатором для них и их характеристик служит UUID, уникальный идентификатор который бывает двух видов: 16 бит и 128 бит. 128 битные идентификаторы мы можем генерировать и использовать на своё усмотрение при написании собственных клиент-серверных приложений. А вот 16 битные зарезервированы SIG. Помните, я говорил что эти ребята сильно упоролись и описали почти всё что взаимодействует или может взаимодействовать по BLE? Так вот они пронумеровали все эти сервисы и характеристики и дали им уникальный 16 битный UUID. Если вы когда-либо захотите разработать железное устройство, с которым сможет работать не только ваше приложение, то вам следует изучить их спеки и следовать этим рекомендациям. Ну а если вы разрабатываете приложение для какого-то класса устройств, вы можете использовать эту спеку чтобы найти идентификатор нужного вам сервиса. Мы ищем термометр, можем смело указывать UUID 0x1809 и игнорировать остальные (если они есть).
Поиск характеристик
Окей, мы нашли сервисы. О чем получим уведомление в делегате. Теперь схожим образом можем найти характеристики в них, для каждой вызовем discoverCharacteristics(for:) . Точно так же, мы можем указать UUIDы интересующих нас характеристик, так и получить все, но это будет медленнее. Когда процесс исследования характеристик завершиться делегат получит уведомление вызовом метода didDiscoverCharacteristicsForService а самы характеристики будут доступны в соответствующем свойстве.
Характеристики
На этом этапе мы наконец добрались до самого «вкусного» — до данных, а точнее, до характеристик. В большинстве несложных кейсов их можно разделить по типам операций которые они поддерживают: read, write, notify. На самом деле опций (корректнее — свойств) несколько больше, но в рамках сегодняшней статьи мы рассмотрим только эти.
Характеристика должна поддерживать хотя-бы одну из них, но может поддерживать и все вместе. Интересным тут является тип notify. Как не сложно догадаться, вместо прямого считывания, у нас есть возможность получить уведомление когда устройство самостоятельно решит отправить нам данные, например, когда они изменились. Возвращаясь к примеру с термометром, характеристика с единицей измерения будет иметь флаг read и write, а сама температура read и notify. Единицу измерения достаточно считать при подключении, а вот температуру считывать по таймеру — не лучшее решение. Мы же пытаемся быть Low Energy — постоянно опрашивать устройство может быть накладно как для нас, так и для периферийного устройства.
Для работы с характеристиками используется три основных метода:
- readValue(for:)
- writeValue(_, for:, type:)
- setNotifyValue(_, for: )
С чтением данных всё просто: дернули метод readValue — отправиться запрос на устройство. Ответ получим в делегате CBPeripheralDelegate когда данные придут. Тоже самое произойдет, если данные обновятся и мы будем подписаны на них с помощью setNotifyValue
Запись же бывает двух видов — withResponse и withoutResponse . Не вдаваясь в подробности, это запись с и без подтверждения. Конечно, withResponse медленнее, т.к. на каждый запрос записи будет генерироваться ответ. Это стоит учитывать особенно, для передачи относительно больших объемов данных — запись withoutResponse будет предпочтительнее в этом случае.
Ограничения
Кстати, а что по лимитам? Не забываем что в названии маячит LE, что значит что он был спроектирован с максимальной экономией на всём, в том числе и размерах пакетов. BLE — это совсем не про стриминг и большие объемы данных. Скорость по стандарту 4.0 согласно Википедии всего 0,27 Мбит/сек.
По умолчанию, размер пакета с полезной информацией равен 23 байта, из которых 3 зарезервированных системой. Остаётся 20 байт полезной нагрузки. Работая с BLE вам придется столкнуться с этим ограничением и придумывать как делить ваши данные на пакеты вручную, т.к. очень часто 20 байт оказыватся недостаточно. В ряде случаев, когда обмен информацией будет происходить с современным смартфоном, данное ограничение может быть увеличено вплоть до 512 байт. CoreBluetooth берет на себя ответственность за переговоры о максимальном MTU, ровно как и на автоматическое деление на пакеты, если это поддерживается устройством. Если вам нужна другая скорость или объемы, то вероятно вам нужно использовать L2CAP канал и работать более низкоуровнево, минуя GATT, благо такая возможность есть с iOS 11 (только для устройств Apple).
Серверная часть
На данном этапе вы уже познакомились со всеми ключевыми классами и понятиями CoreBluetooth и скорее всего уже сможете написать своё первое приложение которое будет подключаться к BLE устройству. А что если этим устройством будет другой айфон? Давайте в кратце рассмотрим обратную сторону, сторону сервера или в нашем случае, Peripheral.
По аналогии с CBCentralManager , для создания сервера у нас есть CBPeripheralManager и его CBPeripheralManagerDelegate . Для создания нашего сервиса нам нужно будет в первую очередь создать сервис и его характеристики. Пусть у нас будет только один сервис с единственной характеристикой доступной только для чтения. Ответная часть CBService на стороне сервера — это CBMutableService . Да, API CoreBluetooth не «освифтили», поэтому у нас есть префикс Mutual для мутабельных версий классов. При создании нам нужно указать UUID, который можно сгенерировать в консоле командой uuidgen и указать основной ли это сервис у нашего устройства.
После создания сервиса его нужно наполнить характеристиками. Их представляет класс CBMutableCharacteristic . При его создании указывается
- UUID
- Свойства
- Начальное значение (для статичных характеристик)
- Права доступа
Собираем наше крохотное дерево с одним листочком, добавляем в менеджер и можем заявить о себе путем рассылки рекламных пакетов. Для этого у CBPeripheralManager есть метод startAdvertising . На вход он принимает словарь с параметрами рассылки. Я не хочу углубляться сейчас в детали структуры рекламного пакета, но кое-что хотел бы подсветить.
В начале рассказа о CBCentral я намеренно упустил момент, что при сканировании эфира можно указать UUID сервисов в которых мы заинтересованы. Согласитесь, было бы глупо и долго сканировать эфир, и потом подключаться ко всем найденым устройствам просто чтобы узнать есть ли у них искомый сервис или нет. Вместо этого сервер может добавить в рекламный пакет UUID наших главных сервисов, а клиенты при сканировании смогут фильтровать устройства которые им не интересны без подключения и считывания списка сервисов. Сделать это мы можем как раз указав соотвествующий ключ в упомянутый ранее словарь на начале Advertising`а.
Как только начнется рассылка пакетов, мы получим соответсвующее уведомление в делегат. И как только к нам подключиться клиент. Ничего не произойдет. У делегата менеджера нет соответствующего метода. Вместо этого, у нас есть методы для реакции на события чтения, записи и подписки на характеристики. Используя эти методы мы можем решить готовы ли мы сейчас предоставить или записать значение, провалидировать его и так далее.
Состояния
До сих пор я ничего не говорил о ситуациях когда Bluetooth недоступен или выключен. Состояние менеджера очень важно отслеживать и выполнять операции только в разрешенных состояниях, иначе не избежать крешей. Менеджер, будь то Central или Peripheral может находиться в следующих состояниях:
- unknown
- resetting — BLE стек перезагружается
- unsupported — BLE не поддерживается
- unauthorized — Пользователь отклонил передача прав
- poweredOff — Bluetooth выключен
- poweredOn — Bluetooth включен, можно работать
Начинать поиск устройств, рассылать Advertisement пакеты и даже добавлять сервисы в менеджер можно только в poweredOn состоянии, поэтому обделить вниманием метод этот метод делегата не получиться, на это нам намекает и сам протокол делегата менеджера — метод для отслеживания состояния единственный помечен как обязательный.
Безопасность
Как уже упоминалось не раз, в BLE вопрос энергоэффективности всегда ставился в первый ряд. Поэтому, по-умолчанию весь трафик между устройствами не шифруется. Экономятся и ресурсы ЦП и байты в пакетах. Такой трафик может быть легко перехвачен или даже подменен злоумышленником. Для большинства прикладных задач, которые инжинеры решают с помощью BLE, такой вариант вполне подходит. Ведь нет ничего страшного, если кто-то перехватит температуру вашего термометра или заряд батареи. Но есть и случаи, когда важно защитить приватные данные от чтения злоумышленником или быть уверенным что запись происходит от доверенного источника.
В случае, когда требуется дополнительная защита, можно установить соотвествующие права на характеристику. При попытке чтения или записи такой характиристики сервер отклонит процесс, сообщив, что общение должно быть зашифровано, ответив на запрос ошибкой Insufficient Authetication. Чтобы продолжить, клиенту нужно создать защищенное соединение, которые мы чаще привыкли называть пейрингом, реже — бондингом.
Процесс пейринга может быть различен для разных устройств, кто-то требует ввода константных чисел, кто-то показывает цифры на экране обоих устройств или просто просит подтвердить соответствие. В результате пейринга будут сгенерированы ключи на обоих сторонах процесса и общение будет зашифровано.
После удачного пейринга, нужно заново подключиться к устройству и перечитать характеристику. К счастью, CB берет весь этот процесс на себя, скрывая под капот все эти сложные действия. То есть, если вы попытаетесь считать или записать защищенную хар-ку, то CoreBluetooth провернет все эти действия и вы как ни в чем ни бывало получите ответ в делегате, только чуть позже чем обычно.
Пермишенны
Говоря о безопасности, стоит упомянуть о том, что с недавних пор Apple требует указания в Info.plist текста с объяснением для конечного пользователя для чего вашему приложению нужен доступ к Bluetooth. При первой попытке сканирования или начала отправки рекламных пакетов, система спросит пользователя разрешает ли он использовать Bluetooth, точно так же, как это обычно происходит при запросе прав на фотогалерею или пуш уведомления. У соседей по платформе, в Андроид, система также требует прав на локацию низкой точности, т.к. потенциально можно сканирование можно использовать для определения положения пользователя. Возможно, такие правила не за горами и в iOS.
Переподключение
При работе с Bluetooth, как и с любой другой технологией связи, случаются разрывы соединения. Разрыв может быть вызван как по инициативе одной из сторон, так и при потере сигнала. Фреймворк CoreBluetooth устроен таким образом, что пытается постоянно поддерживать соединение до тех пор, пока не будет вызван метод cancelConnection(from:) . Таким образом, если связь прервалась по причине неустойчивого соединения, или же при выключении удаленного устройства, CoreBluetooth будет пытаться восстановить соединение в фоновом режиме пока запущено ваше приложение. Он самостоятельно будет сканировать эфир, и как только появиться возможность соединиться сделает это. Кажется довольно простой вещью, но поверьте — вам не захочется писать этот алгоритм с нуля. Коллеги по платформе, опять же не имеют такого механизма из коробки и команде iOS сэкономил несколько дней обсуждений и имплементации.
В примере выше рассмотрели кейс, где дисконнект был неожиданным для нас явлением. Но стоит рассмотреть переподключение как естественный процесс жизненного цикла. Допустим, поработав с устройством пару минут, мы узнали от него всё что хотели на данный момент, и не хотим больше тратить ресурсы на поддержание соединения. В этом случае мы можем сохранить уникальный UUID переферийного устройства и вызвать метод cancelPeripheralConnection() . Позже, когда нам снова потребуются какие-то данные от утройства, мы можем использовать сохраненный UUID для подключения. Подсвечу тот факт, что метод connect принимает на вход параметр экземпляр класса CBPeripheral, который не имеет публичного конструктора. Для получения экземплара у нас есть метод retrievePeripherals(withIdentifiers:) у CBCentralManager , которому можно скормить массив UUID.
Важно, что метод работет уже не CBUUID, а с UUID из Foundation библиотеки, т.к. это уже платформенная реализация и не имеет референса в спецификации CoreBluetooth. После маппинга UUID в массив CBPerepheral можно к ним подключаться.
Тут может образоваться вопрос, как быть, если искомое устройство не в зоне видимости Bluetooth или же ушло в сон на какое-то время. В этом случае. ничего не произойдет. Мы не получим ошибки таймаута или какой-то другой. CoreBluetooth будет пытаться подключиться к устройству бесконечно, пока вы не вызовете cancelPeripheralConnection(:) . Такая логика может показаться странной, действительно, зачем мне бесконечно подключаться к термометру, если он не в зоне видимости? Но не забываем, что сценариве использования очень много, и мы работаем с LE его версией. Это значит, что какие-то устройства by design могут выходить в эфир на довольно редкие промежутки времени для экономии батареи. Тогда такое поведение приобретает смысл. В конечном итоге, накинуть логику с таймаутом намного легче, чем написать цепочку переподключения, будь этот таймаут системным.
Работа в бекграунде
Как и все ресурсоёмкие операции в iOS работа с устройствами в бекграунде по умолчанию недоступна по умолчанию. При сворачивании приложения, будь ваше приложение сервером или клиентом потеряет соединение и как и все остальные перестанет обслуживать все очереди. Но по возращению в форграунд, CoreBluetooth восстановит соединение.
Автоматическое восстановление соединения это конечно хорошо, но явно недостаточно. Полноценно контролировать процесс взаимодействия с устройствами в фоне можно проставив соответствующий бекраунд мод в Info.plist.
Для каждой роли, сервера и клиента, есть отдельный чекбокс. Можно отметить оба. При активации бекграунд мода, приложение сможет взаимодействовать с устройствами, читать и писать характеристики, сканировать сеть и т.д., но конечно же процесс этот не вечный и как это происходит с почти с любым приложением, рано или поздно iOS может выгрузить из памяти приложение. С этим ничего не поделать и придется с этим жить. Хорошая новость в том, что по возвращению в приложение, в CoreBluetooth есть возможность восстановить состояние, со всеми подключенными устройствами, найденными характеристиками и т.д. Всё выше сказанное распространяется на случаи, когда приложение было выгружено по просьбе системы, а не закрыто пользователем из таск-менеджера.
Еще раз напомню, что Apple серьезно позаботилась об энергопотреблении, поэтому процессы в бекграунде будут медленнее, например, сканирование будет происходить дискретно и менее интенсивно.
Важно отметить, что при реализации соединения между двумя iPhone, iPad или Mac без соответствующего бекграунд-мода, у серверной части уход в бекграунд будет сопровождаться отключением зарегистрированных сервисов, а не завершением Bluetooth соединения. То есть удаленная сторона (клиент) не получит события отключения, но получит уведомление didModifyServices о том, что часть сервисов у Peripheral устройства пропало. Помните, в этом случае вы подключены к одному физическому устройству — другому телефону, планшету или компьютеру, а не программе как в случае HTTP взаимодействия.
L2CAP соединение
В 2017 году Apple представила разработчикам возможность коммуницировать с Apple устройствами не только через GATT протокол, но и открывать своё низкоуровневое соединение через низлежащий протокол L2CAP. Это позволяет написать свою реализацию взаимодействия по радиоканалу, минуя ограничения характеристик GATT. Это, конечно, сложнее в реализации, чем читать и записывать характеристики, но всё равно достаточно просто.
Со стороны сервера, мы всё так же, должны просканировать эфир, найти и подключиться к устройству. Если устройство поддерживает такой тип соединения, оно будет содержать специальный сервис с характеристикой содержащей ID канала. Для начала обмена информацией нужно считать этот ID и попросить CBPeripheral открыть канал методом openL2CAPChannel() .
Если вы реализуете серверную часть, то вам нужно заявить о том, что вы поддерживаете L2CAP. Для этого, в соотвествующем менеджере есть метод publishL2CAPChannelWithEncryption() который подготовит канал, сервис и характеристику и автоматически опубликует нужные данные.
После успешного соделинения, делегаты соотвествующих сторон процесс получат уведомление didOpenL2CAPChannel с указанием канала. Сам канал имеет два свойства inputStream и outputStream которые позволят реализовать и чтение и запись данных по каналу используя стандартную для iOS / Mac абстракцию потоков.
Грабли
Мы уже очень близко к завершению моего повествования. В конце я бы хотел кратко осветить те грабли, на которые пришлось наступить при работе с CL.
Кеширование
Разрабатывая и отлаживая приложение с BLE всегда помните о кешировании над которым вы не властны. CoreBluetooth попытается закешировать и сервисы и характеристики для вашего устройства. Помимо этого, кешируется мета-информация, например имя устройства.
На одном из проектов, потребовалось написать симулятор железного устройтва, чтобы QA могли тестировать взаимодействие на всякие краевые кейсы, которые с реальным девайсом не воспроизвести, или воспроизведение было кране долгим. При написании серверной части, мы можем изменить имя нашего устройства в рекламном пакете и надеятся что мы увидим измененное имя. Если бы мы были единственными пользователями Bluetooth на устройстве, всё бы было замечательно: указали имя в реалмном пакете и именно его увидит клиент. Но Bluetooth на устройстве использует и ОС, часто отправляя рекламные пакеты с именем устройства из системных настроек. Например для быстрого обнаружения устройства сервисом AirDrop. Если устройство, где вы планируете тестировать вашу клиентскую часть уже поймала хоть один рекламный пакет, то имя закешируется и при попытке чтения имени CBPeripheral мы увидим именно это закешированное имя, а не то, которое указали в настройках рекламного пакета.
Тоже самое может коснуться и набора сервисов и характеристик для спейреных устройтв. Если вы добавите сервис после установки соединения, вполне вероятно что клиент его не может не увидеть.
Версионирование
Очень короткая “грабля” где я призываю вас предусмотреть характеристику с версией ПО. Если вы работаете с отдельным устройством такой привелегии может и не быть, но если реализуете клиент-серверное взаимодействие между Apple устройствами, то не поленитесь это сделать. Это уменьшит количество костылей в коде, когда вы будете догадываться о версии устройства или ПО по наличию/отсутствию того или иного сервиса или характеристики. Такое часто приходиться делать чтобы определить поддерживаемые функции на периферийном устройстве.
Хардварные проблемы
Готовьтесь что всё пойдет не так, как вы предполагали. Разработчики железа — тоже разработчики, у которых тоже случаются и баги и креши, но только релизный цикл обычно у них намного длиньше, особенно, когда у вас ограничены коммуникации с ними. Будьте готовы, что кто-то отойдет от стандартов. Например, не будет включать в рекламный пакет информацию о сервисах.
Так, я в самом начале моего пути на проекте с BLE я столкнулся с такой проблемой. Написал и отладил клиентскую сторону по документации, проверил с написанным симулятором, все отлично работает. Когда через месяц пришел реальный девайс — его просто нельзя было найти. Я вижу что он есть в эфире, а уведомления в делегат я не вижу. Несолько дней переписок и по счастливой случайности я методом перебора понимаю, что если отключить фильтрацию по UUID сервисов всё работает. Пришлось фильтровать по имени, а имя иногда менялось, и тут вспоминаем проблему с кешированием. Короче, весело.
Как я уже говорил в начале, устройство может и крешиться и зависать. К счастью, на физическом железном устройстве почти всегда есть watchdog который их перезагрузит, но понять что идет не так, может быть достаточно трудно. Как я уже говорил, там сидят такие же разработчики, и в такой низкоуровневой системе запросто можно поймать какой-нибудь рейскондишен. Я несколько раз ловил неожиданные перезагрузки устройства при чтении характеристик, когда для них нет данных, или когда они есть, но считывать их предполагалось в другой последовательности.