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

    Данная статья на 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).
    • +30
    • 43,9k
    • 9
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 9
    • +2
      Ваша тема очень удачно перекликается вот с этой.

      каким будет потребление самого смартфона

      Там докладчик как раз указал на то, что при «неправильной» настройке телефон может сесть за 3 часа. Я так понимаю, что там тоже связь как таковая не устанавливается. Вероятно, дело в написании правильного алгоритма.
      • 0
        Пробовал когда-то работать с этими RF24l01. Правда это очень давно было. 2 шт, на прием и передачу.
        Схему подключения найти не было проблемы, а вот с кодом не сложилось.
        Открыл официальную документацию (она называется «RF01 programming guide»). Схема вроде есть, код- написано Demo. Что значит демо?
        Потом выяснилось, что производитель умышленно дал не рабочий код и пример. Это больше всего выбесило. Вот нахрена такое делать?
        Убил бы.

        Перерыл весь интернет, нашел 1-2 рабочих кода с форумов и статей. Помощи спрашивал, ISP отлаживал, так и не удалось запустить. На прием вроде бы работал (запустил без CRC проверки, ловил все шумы из космоса, светодиод мигает, вроде работает, и то не факт), передача не запускалась.
        Хотелось выкинуть это говно за 5$ и купить нормальные модули подороже с человеческой документацией.
        • 0
          Раз вы разбирались с этой технологией — может ответите на мой вопрос. Я тут всё жду, когда появятся звонилки с BT4.0 в надежде, что можно будет с них звонить и шарить интернет через BT, но на днях закрались подозрения что BTLE передаёт совсем мало информации и в таком юзкейсе неприемлем. Сомнения оправданы? Может быть видели где-нибудь графики потребления энергии разными версиями BT?
          • +2
            Звонилки? Все выходящие нынче топовые телефоны имеют поддержку Bluetooth 4.0, и как следствие BLE. Сам же BLE создан как раз для передачи небольших объемов информации, поддержки передачи голоса у него нет, т.к. не хватает пропускной способности. Интернет через него шарить теоретически можно, но это добро-пожаловать в эпоху модемов. Его ниша — умные часы (отображение небольшого кол-ва информации с телефона) и датчики (запись небольшой информации в телефон), т.е. там, где объем данных мал и имеются жесткие требования к питанию.
          • 0
            В реальных применениях по цене это видимо не очень оправдано.

            Чип NRF24L01 (или клон) стоит в районе 1.9CNY =$0.3.
            Attiny13 — $0.5.

            А например чип CSR1010, в котором есть настоящий BLE + встроенный микроконтроллер, стоит $1.1.
            • +1
              Странно, а в виде готовых модулей, все True-BLE очень сильно проигрывают в стоимости. В случае чипа CSR прибавьте еще внешнюю память для прошивки. Для по-настоящему массового устройства даже несущественная разница в цене может и оправдаться. Хотя для массового продукта, использовать устройство основанное на хаке не совсем и корректно.
              • +2
                Да, меня это тоже удивляет. Вот буквально вчера нашёл такой модуль за $3.5, но это скорее исключение.

                EEPROM-ка там, строго говоря, не обязательна, т.к. в чипе есть однократно-программируемый ROM для прошивки. Ну и клон AT24C512C у китайцев стоит $0.2. В сумме по рефдизайну CSR, даже с EEPROM и двумя дорогими маленькими кварцами, у меня получалось где-то $2.0 с учётом платы и монтажа.
            • 0
              Спасибо за публикацию. Возник вопрос. Основная вишка то BLE мало кушает, неужели nrf24l01 по энергоэффективности такой же, у меня их десяток, и очень захотелось бы их заюзать как ble.
              • +1
                Малое потребление BLE достигается за счет того, что модуль просыпается на очень короткие промежутки времени и при некоторых настройках чуть ли не 1 раз в 5 секунд. В момент передачи потребление не сказать что и низкое. Общая концепция nRF24l01 В моем примере Broadcast пакет можно слать так же не часто, засыпая в промежутках, как следствие — потребление будет сравнимым с BLE.

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.