BLE під мікроскопом. Частина 2
частина 3
У першій частині ми проаналізували для чого був придуманий стандарт 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 дуже велика і постійно розвивається. Тому ми звичайно ж не змогли описати всі особливості цього протоколу. Але для початкового старту цієї інформації більш ніж достатньо. Додаткову інформацію можна почерпнути тут, тут і тут.
Печерських Володимир
