Описание
Как выглядит устройство и какая у него схема описывать не буду. В интернете, включая русскоязычный, полно информации по описываемым радиомодулям. Скажу только, что в моем случае для управления был использован микроконтроллер 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).
This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.
Want something else to read? How about 'Grievous Censorship' By The Guardian: Israel, Gaza And The Termination Of Nafeez Ahmed's Blog
Комментариев нет:
Отправить комментарий