BLE під мікроскопом. Частина 3

image

BLE під мікроскопом. Частина 3
першою і другий частинах ми розглянули принципи побудови мереж BLE, а так само торкнулися необхідний інструментарій для роботи з ними. У третій частині ми займемося практичним застосуванням отриманих знань. Для цих цілей ми розглянемо проект на мікросхемі nRF51822 фірми Nordic.

Проект реалізовує передачу даних на рекламних каналах без використання стека.
Для того, що б запустити проект, необхідна мікросхема nrf51822 на будь-якому КІТ-е, програматор J-LINK, а так само встановлений SDK. Розпаковуємо проект і розміщуємо в директорію SDK, в папку де лежать приклади периферії. Це потрібно для того, що б не переписувати шляху до бібліотек. Прийняті дані можна побачити за допомогою програми nRF Connect.

image

Сьогодні ми розглянемо, як формується пакет для передачі по каналах BLE. Найцікавіше для нас знаходиться в файлі ble_radio.c. Функцію radio_init() я запозичив у програмі сніфер від Nordic-a. Це найбільш відповідальна частина. Без правильної ініціалізації радіоканалу ми взагалі не побачимо ніякі посилки. Кожні 100 ms програма посилає в ефір три кадру на рекламних каналах. Як формуються посилки, ми зараз і розглянемо.

Починається посилка з заголовка. Залежно від прапора ble_adv_conn наш пристрій буде бачитися присоединяемым (ADV_IND) або не присоединяемым(ADV_NONCONN_IND). Відмінність між ними давалося першою частини. Тут лише хочеться зауважити, що в обох випадках вже виставлений прапор randon-ного МАС адреси. Якщо ж ми хочемо отримати public MAC адресу, то заголовковий байт буде 0х00 і 0х02 відповідно. Далі слід байт довжини всього пакету і службовий нульовий байт. Я так і не розібрався навіщо це потрібно. В ефір він не виставляється, але якщо його не буде, ми отримаємо зсув байтів в посилці.

Далі слід шість байт МАС адреси і блок прапорів. Тут треба вказати загальний формат заповнених даних. Спочатку йде байт довжини (LEN), потім ідентифікатор вмісту (TYPE), а потім вже самі дані (VALUE). Блок прапорів — це перший блок даних, який ми можемо побачити в програмі nRF Connect.

image

Далі записується ім'я пристрою. В даному випадку, після байти довжини, йде ідентифікатор 0х08. Він означає, що це скорочене ім'я пристрою. Якщо зробити ідентифікатор рівним 0х09, ім'я буде бачиться як повне. Для нас це не принципово, тому що ми працюємо без стека і всі запити відпрацьовуємо самі. У разі роботи зі стеком, на запит телефону повного імені, воно буде виставлено у відповідь посилці. Слідом за ім'ям йде блок заводських даних і контрольна сума. Слід зауважити, що ідентифікатором заводських даних є байт 0xFF, слідом за яким мають іти 2 байта ID виробника і самі дані. Це те поле, в якому ми можемо передавати будь-які свої дані.

image

Подібним чином посилка BLE може містити й інші дані, наприклад UUID пристрою або потужність пристрою (TYPE = 0x0A). Переглянути всі ідентифікатори можна тут. А ось як виглядає ця посилка в Wireshark. Ми бачимо, що ця програма дає значно більше інформації для розробника, ніж nRF Connect.

image

Однак це ще не все. Якщо ми сформуємо посилку в форматі маяка (ADV_NONCONN_IND), то вона буде прийматися на телефон спеціальною програмою. Для того, що б телефон побачив пристрій у форматі ADV_IND, необхідно правильно відпрацьовувати запит SCAN_REQ. Як зазначалося під другий для цього ми повинні вчасно виставити відповідь SCAN_RSP. Ці посилки ми можемо побачити тільки за допомогою сніфер. Вони виглядають наступним чином.

image

В цьому разі в них немає нічого цікавого. Перша (SCAN_REQ), крім заголовка, містить MAC адреси самого телефону і нашого пристрою. Друга (SCAN_RSP) — тільки заголовок і MAC-адресу гаджета. Однак повторна посилка може містити дані. Як вже говорилося раніше, це дозволяє передавати більше інформації на телефон. У цьому випадку, принцип заповнення посилки аналогічний тому, що ми розглянули вище. На цьому третя частина, присвячена вивченню посилок BLE, завершена.

Печерських Володимир
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.