Pull to refresh

Поддельное BLE-устройство на nRF24l01

Wireless technologiesNetwork standards
Данная статья на 90% основывается на заметке «Bit-Banging» Bluetooth Low Energy. Все началось с того, что потребовалось запустить распространенные сейчас трансиверы на чипе Nordic nRF24l01. В процессе поиска примеров работы с ними я и наткнулся на вышеупомянутую статью. Являясь обладателем телефона с поддержкой Bluetooth 4.0 (который и включает в себя Bluetooth Low Energy), подумал: а почему бы не попытаться повторить эксперимент?

Описание


Как выглядит устройство и какая у него схема описывать не буду. В интернете, включая русскоязычный, полно информации по описываемым радиомодулям. Скажу только, что в моем случае для управления был использован микроконтроллер NXP LPC1343 (для него и представлена прошивка внизу).

Как обычно, чудес не бывает: пример не захотел работать в виде «как есть». Во-первых на странице присутствует явное повреждение форматирования, во-вторых сразу видно что есть проблема с байтом длины. Какие еще опечатки и неточности присутствуют в описании, мне оставалось только гадать. Однако, после непродолжительных правок все заработало.

BLE-устройство сильно отличается от всех прочих «синих зубчиков», достаточно упомянуть, что стандартный поиск устройства в Android не ищет BLE: для их обзора требуются отдельные приложения. BLE устройства — отдельное ответвление в Bluetooth-технологии, фактически это еще один стандарт. Видимо, он разрабатывался с оглядкой на возможности малопотребляющих трансиверов на 2.4ГГц. Отсюда и итоговое сходство.

А сходства следующие:
  • Одинаковые рабочие частоты 2.4GHz с поддержкой скорости 1Mbps и пересекающаяся сетка каналов.
  • Одинаковые байты стартовые байты 10101010 или 01010101 (преамбула).
  • Одинаковая модуляция сигнала: GFSK.
  • Возможность задать в nRF24l01 адресацию 4 байтами.

Но вот и отличия:
  • Разные алгоритмы CRC. Благо в nRF24l01 его можно отключить и заниматься расчетом программно в микроконтроллере.
  • nRF24l01 после каждой передачи отключает PLL. Это подкладывает свинью в реализации протокола, т.к. повторный запуск PLL требует приличное время.
  • BLE поддерживает пакеты данных с длиной до 39 байт. У nRF24l01 это значение ограничено 32 байтами.

Именно из-за последнего пункта полноценного протокола BLE поднять не получится. Однако, мы можем составить корректный Broadcast-пакет, который участвует в процессе поиска устройства.

Код составления пакета:
	buf[L++] = 0x42;	//PDU type, given address is random
	buf[L++] = 0x11;	//17 bytes of payload
	buf[L++] = MY_MAC_0;//0xEF
	buf[L++] = MY_MAC_1;//0xFF
	buf[L++] = MY_MAC_2;//0xC0
	buf[L++] = MY_MAC_3;//0xAA
	buf[L++] = MY_MAC_4;//0x18
	buf[L++] = MY_MAC_5;//0x00
	buf[L++] = 2;       //flags (LE-only, limited discovery mode)
	buf[L++] = 0x01;
	buf[L++] = 0x05;
	buf[L++] = 7;       //name
	buf[L++] = 0x08;
	buf[L++] = 'n';
	buf[L++] = 'R';
	buf[L++] = 'F';
	buf[L++] = ' ';
	buf[L++] = 'L';
	buf[L++] = 'E';
	buf[L++] = 0x55; //CRC start value: 0x555555
	buf[L++] = 0x55;
	buf[L++] = 0x55;
	//...
	btLePacketEncode(buf, L, chLe[ch]); // crc calculate

Программа делает только одно: инициализирует радиомодуль специальным образом, составляет пакет и отправляет его. Этого достаточно, чтобы телефон показал устройство в поиске.


Как использовать


После того, как мой телефон увидел приложение, сразу встал вопрос: а можно ли каким-то образом использовать эту «подделку»?

Ограничения в чипе nRF24l01 не дают возможности поднять полноценный BLE-протокол и заканчиваются на том, что телефон «видит» нечто, но никаким образом с ним работать не может. Соответственно, передача данных в устройство отметается сразу, а вот что с передачей данных в телефон? Имя и мак-адрес телефон определяет, а это уже какая-никакая информация, а что еще?

А еще можно передавать и наши данные. Для этого необходимо в буфер добавить дополнительные поля. Лучше всего для этого подходит тег MANUFACTURER_DATA=0xFF. Данных за раз можно передавать не более 32 байт (ограничение модуля nRF24l01), при этом часть их тратится на передачу служебных структур BLE. В чистом остатке остается около 32-6-3-3 = 20 байт. Из них 2 байта уйдут на заголовок, таким образом «наших» данных может быть 18 байт. Но стоит учесть, что данный расчет я привел для безымянного устройства.

Применения


Теоретически данный хак можно использовать и в реальных устройствах. Стоимость nRF24l01 кардинально ниже true-BLE-модулей. В смартфон можно передавать данные с каких-либо датчиков, причем как и в случае с BLE, датчики могут иметь батарейное питание.

Если взять связку из примитивнейшего ATtiny13 и nRF24l01, получится устройство копеечной стоимости. Разместив десяток или сотню таких в большом помещении (к примеру, ТЦ) можно развернуть локальную систему позиционирования, которая в приложении точно покажет где же находится владелец телефона.

К сожалению, для меня открыт вопрос: каким будет потребление самого смартфона. Все-таки связь с устройством не устанавливается, приходится постоянно проводить сканирование. Может кто знаком с темой и сможет прокомментировать.

ANT+


В довесок, исследовал возможность реализации взаимодействия nRF24l01 с ANT+ устройствами. Здесь, к сожалению, все потеряно. Если байт синхронизации в BLE и nRF24l01 совпадает, то в случае с ANT-протоколом работать ничего не будет: последний имеет отличный от них вектор.

Ссылки


  • Оринальная статья: «Bit-Banging» Bluetooth Low Energy
  • Модифицированная версия утилиты BluetoothLeGatt. Добавлен вывод тела пакета при поиске. В данном теле видны передаваемые приложением данные. Экран работы утилиты представлен выше.
  • Исходный код работы с модулем.
  • Бинарник с прошивкой микроконтроллера LPC1343 (мост USB-SPI).
Tags:nrf24l01+blebluetoothbluetooth 4.0diy или сделай сам
Hubs: Wireless technologies Network standards
Total votes 32: ↑31 and ↓1 +30
Views57.4K

Popular right now

Top of the last 24 hours