BLE под микроскопом. Часть 302.02.2017 22:19

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 = 0×0A). Посмотреть все идентификаторы можно здесь. А вот как выглядит эта посылка в Wireshark. Мы видим, что эта программа дает значительно больше информации для разработчика, чем nRF Connect.

image

Однако это ещё не всё. Если мы сформируем посылку в формате маяка (ADV_NONCONN_IND), то она будет приниматься на телефон специальной программой. Для того, что бы телефон увидел устройство в формате ADV_IND, необходимо правильно отрабатывать запрос SCAN_REQ. Как указывалось во второй части для этого мы должны своевременно выставить ответ SCAN_RSP. Эти посылки мы можем увидеть только при помощи сниффера. Они выглядят следующим образом.

image

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

Печерских Владимир

Комментарии (1)

  • 2 февраля 2017 в 21:01

    0

    ↑

    ↓

    Конспективно.
    Но если публикуете проект, то неплохо бы проверить, что он собирается.

    …\…\…\…\Source\templates\arm\arm_startup_nrf51.s
    …\…\…\…\Source\templates\system_nrf51.c
    …\…\…\…\Source\keil_arm_uv4.lnt

    Первые два я еще смогу найти. А третий?

© Habrahabr.ru