В это статье я хочу описать свой опыт проектирования и разработки периферийного устройства BLUETOOTH в формате скорее летописи, потому как пытаясь описать процесс в одной статье получается слишком много текста и пояснений.
Немного пред истории почему вообще GATOR как и зачем.
Несколько лет назад я, как это обычно и бывает, совершенно случайно познакомился с командой разработчиков софта. Поскольку я довольно плотно занимаюсь разработкой электроники, мне предложили поучаствовать в одном незамысловатом, как показалось вначале, проекте. Мне предложили поучаствовать в разработке устройства которое с одной стороны имеет BLUETOOTH интерфейс, с другой RF приемо/передатчик <1GHz и этот приемопередатчик нужен для считывания радио-ключей брелков и передачи считанного ключа в эфир. Странная идея какая-то, есть алиэкспресс и дешевые брелки по 3$, хотите открывать шлагбаумы со смартфона, открывайте, нелепица какая-то.
НО…, Я НЕ ПОНЯЛ НИЧЕГО!!!
GATOR это не просто прибор, - это система взаимодействия которая не заканчивается на "открывашке". К примеру, договорились мы поехать к моему другу с семьей на выходные, у него въезд на территорию закрыт автоматическими воротами, и ворота не на против подъезда, до них ещё пилить и пилить, и тут два варианта, - или мой друг ждет с брелком на морозе или я с семьей жду в машине "авось кто-нибудь поедет". Однако если есть GATOR, достаточно отправить ключ и я из приложения открою ворота как родным брелком.
И тут признаться меня концепт зацепил!!! Все "брелки" в одном месте, GATOR сам подскажет каким ключом что открывать по геолокации в сматфоне, не знаю у кого как, у меня микростресс когда я стою перед шлагбаумом и не могу понять почему "бараноподобный" шлагбаум не открывается!!! А сейчас шлагбаумы наставили везде, причем у родителей, шлагбаум поставили вообще без спроса! А скорая например как проезжать будет? В теории если GATOR есть у всех, то проблема "к подъезду" вообще отпадает, "но это уже совершенно другая история".
На пальцах объяснить сложно, поэтому ролик, если позволите:
Реализация электронной начинки.
К слову сказать, систему начали разрабатывать ещё в 2017.
Прототип устройства, февраль 2018.
Первая ревизия устройства, сентябрь 2018.
Кандидат на финальную ревизию:
И всё было хорошо... кроме цены... А кому нужен дубль пульта по цене десяти оригинальных пультов, даже такой "волшебный"?
Задача поставлена просто:
Снизить конечную цену устройства.
Сохранить функционал.
Исходный код прошивки и плат у стороннего разработчика, и с ним связь утрачена.
Посмотрим на первый пункт, цена состоит из: стоимости изготовления печатной платы, стоимости элементной базы, сложности пайки устройства. Второй пункт, - принято. И учитывая третий пункт, - начинать придется с нуля.
Уменьшаем:
Плата в 4-ре слоя, переделаем в 2-х. У MCU, в финальном кандидате, оригинальное посадочное место, чтобы вывести из под него дорожки диаметр сверловки 200мкм, гарантийный поясок 50мкм и прям в посадочных площадках, таким образом станок сверловки нужен мегаточный и при металлизации необходимо металлизировать до "завальцовывания" переходных отверстий, это стоит денег.
Элементы. В первую очередь, уменьшим количество компонентов, выберем чипы со схожей функциональностью, но дешевле (интересный момент, даже казалось бы незначительные компоненты могут привнести в стоимость ощутимый прирост, например кнопки или светодиоды).
Сложность пайки, в нашем случае это количество слоев пайки. Было два, перенесем все компоненты на одну сторону.
Приблизительная блок схема устройства для меня представлялась какой-то такой:
Состав начинки (основные модули):
NRF52832, Bluetooth Transport и MCU - Nordic Semiconductor.
СС1101 <1GHz трансивер - Texas Instruments.
Power controller NCP170AXV330T2G - ON Semiconductor.
STMC08, контроллер заряда ST Microelectroncs.
Как уже писал выше, я предлагал уменьшить количество компонентов и тут мы всей командой попались... заменив дискретные компоненты в трактах антенн на согласующие баласты. Это был провал, мощность излучения и приема оказалась мизерной! И вышел вот такой прототип:
Ага, работа над ошибками, коротко прям (хотя ревизий было ...,B,C,D,rev. E) :
Согласующие баласты не дают "правильной" мощности в антенну.
Нет отверстий под крепление в корпусе.
Устройство должно понимать когда его подключили к внешнему питанию по USB чтобы просыпаться (и не спать, например в машине когда подключено).
Кнопки слишком высокие, повлияют на толщину корпуса устройства.
Переделываем и получаем в итоге GATOR ONE:
Реализация прошивки устройства.
В устройстве предполагается работа с Bluetooth, чтение/отправка радио-кодов посредством CC1101 и как в любом уважающем себя устройстве BOOTLOADER.
Начнем с BLUETOOTH.
Nordic Semiconductor, работа с чипами этого производителя дает как плюсы так и минусы разработчикам. Чиркану про крупные.
Плюсы:
Nordic "дарит" своим пользователям для разработки прошивок в nrf51/52 чипы бесплатную лицензию на Segger Embedded Studio.
Достаточное количество примеров реализации, и уже готовый BLUETOOTH стек.
Так же NORDIC поставляет бесплатное программное обеспечение для смартфонов под управлением IOS и ANDROID в котором можно оценить пригодность разрабатываемой прошивки устройства (nRF Connect for Mobile (Android), nRF Connect: Bluetooth App).
Минусы:
В SEGGER студии работает только отладчик SEGGER и нужен оригинальный, то что продают на али не подойдет, нужна версия JLINK 6.7d или выше. Иначе отладчик просто не увидит чипов от Nordic, а при попытке обновления китайского программатора, сам программатор превращается в "тыкву".
BLUETOOTH стек реализован внутри некоего суррогата динамической библиотеки которую NORDIC называет Soft Device, Soft Device крайне капризная штука, например, стоит где-то в отлаживаемом приложении остановиться в Breakpoint, после возобновления выполнения кода SoftDevice выкинет вас в свой внутренний обработчик ошибок и программа повиснет. Поэтому отладка с включенным софт девайсом превращается в какой-то фарс. Сам NORDIC предлагает отлаживать устройства посредством "COM порта", то есть выводить лог, состояние устройства, результаты обработки в UART и в терминале смотреть что происходит. Если вы попытаетесь "потрогать" пины GPIO отданные в SoftDevice, например под "моргание синим светодиодом" или что ещё хуже вы не дай бог решите прочитать состояние таймера которым пользуется SoftDevice или решите вообще куда-то полезть и не ублажите SoftDevice, то вас ждет HADR FAULT! Это жесть как усложняет жизнь разработчика. А ещё, чуть не забыл, SoftDevice для работы кроме куска FLASH памяти нужен ещё кусок памяти SRAM, поэтому не забудьте расположить стек своей реализации повыше иначе будите ловить "глюки" даже в "безглючном" коде, как точно настроить положение стека есть на форуме NORDIC.
Таким образом если мы используем SoftDevice, то долговременная память микроконтроллера будет выглядеть следующим образом:
Далее всё просто, берем закупаемся инструментом разработчика, например вот таким (к слову, на борту этого инструмента JLINK присутствует):
...качаем Segger Embedded Studio, получаем лицензию, скачиваем SDK от NORDIC, из списка примеров выбираем реализацию близкую к тому что мы хотим получить, вносим небольшие правки, например название устройства, указываем к каким GPIO подключены элементы интерфейса, кнопки/светодиоды. Компилируем и получаем что -то вот такое:
...разрабатываем протокол общения с мобильным устройством, и реализуем его в устройстве.
В общем виде команды протокола:
Подключение к устройству.
Статус устройства (батарея, режимы работы...).
Команды устройству.
Данные от устройства.
Пишем небольшое тестовое приложение для проверки протокольных команд...
Далее BOOTLOADER.
Статей на тему реализации загрузчика в NRF предостаточно, реализовать особых сложностей не представляет. Тут я остановлюсь на принципе работы загрузчика от NORDIC.
Прошивка в устройство шифруется сертификатом, сертификат генерирует сам разработчик, не используйте тот что в примере, эт глупость. При генерации файла обновления можно указать текущую версию прошивки и запретить "откатываться" на меньшую версию. Я бы рекомендовал этого не делать, лучше в приложении следить за обновлениями, нередко бывают случаю что пользователю необходимо откатиться на предв. ревизию.
Второй момент, загрузчик должен содержать именно ваш сертификат, и контрольная сумма записанного в память приложения должна совпадать с тем что прописано в установках загрузчика, если что-то из этого не совпадает, SoftDevice останавливает работу устройства, это нужно для того, чтобы вашу прошивку не "слили левым" загрузчиком. А со стороны разработчика это выглядит так, прошивку перекомпилировали, прошили, - устройство встало! Поэтому отключайте проверку на этапе отладки устройства, и включайте в релизной версии.
"Завис в бутлоадере":
Радиочастотная часть реализации прошивки.
Первая ревизия устройства содержала два трансивера, один обслуживал частоту до 500MHz, второй от 0,5 до 1GHz. Такая реализация нам не подходила (стоимость), поэтому на этапе разработки задумка была использовать один трансивер, два тракта передачи и переключать тракты используя высокочастотный SWITCH PE4259.
Поэтому я разбил всю радиочастотную область на две основные и несколько побочных
Побочные: 315MHz, 434MHz, 435MHz, 868MHz, 912MHz.
В основных радиочастотных областях переключаться между антеннами, а в побочных менять настройку AGC внутри трансивера CC1101.
С отправкой сигнала, сложностей нет, настраиваем частоту передачи, включаем соотв. антенну. Отправляем.
Сложности есть с чтением сигнала.
Мы не знаем на какой частоте работает брелок который мы читаем.
Мы не знаем "битовую плотность" сигнала который читаем.
Мы не знаем алгоритм читаемого сигнала (заголовок, шифрование).
№ 1:
Настраиваем CC1101 на замер RSS в радиоканале, пробегаем все наши частотные диапазоны, находим наивысшую "силу" сигнала, встаем на этой частоте. Точность определения частоты можно проверить используя SDR SHARP и приемник, скажем TERRATEC.
№2:
Настраиваем CC1101 "слушать" эфир на найденной нами частоте, и в течении 30мс запоминаем "задержки" между "вышедшими" из демодулятора CC1101 фронтами. Сортируем их по 30% отклонению. Отбрасываем "большие" и "редкие" значения, суммируем, делим на кол-во, - вуаля.
Пакет CAME, шлагбаум оснащенный таким модулем можно открыть простым перебором:
Hormann BiSecure, тут AES шифрование:
Статичный код FAAC 868MHz:
№3
И это самая объемная задача.
Как видно из пункта №2 разновидностей типов шифрования как у дурака махорки и их столько сколько есть производителей! Это всё нужно "пощупать в руках" и понять как и каким алгоритмом оно шифруется, как отправляется. Стандартной темой считается проверять серийный номер и счетчик брелка, то есть почти все или даже скажем все шифрованные коды устроены по одному принципу, при каждом нажатии внутри брелка счетчик брелка увеличивается на 1, счетчик добавляется в последовательность вместе с серийным номером брелка, последовательность шифруется и уже зашифрованной отправляется в радиоканал, приемник расшифровывает последовательность, сверяет серийный номер брелка, и счетчик, если счетчик не изменился или серийный номер не занесен в "базу" приемника, приемник игнорирует полученную посылку.
Вот так выглядят к примеру три посылки DOORHAN (шифрование KEELOQ ), чтобы их расшифровать необходимо знать мануфактурный ключ длинной 64 бита, учитывая алгоритм шифрования, простым перебором на обычном компьютере вычислить данный ключ возможно, но жизни не хватит... (жирным выделена зашифрованная часть, курсив - расшифрованная):
0x87318DCCB5826053 ==> 81CC062E
0x87318DCC108FCFDF ==> 81CC062F
0x87318DCCE381BD59 ==> 81CC0630
И это только один алгоритм.
Таким образом абсолютного решения третьей задачи не существует, поэтому GATOR развивается и по сей день.
Про то как мы писали GATOR на IOS/ANDROID и как мы писали серверную часть очень хотелось бы написать в следующих статьях, если эта окажется интересной/познавательной.
Спасибо за внимание. Удачи, благ и добра!!! И С Наступающим Новым Годом!!!
P.S.
Если вдруг кому-то интересно мы опубликовались на KICKSTARTER'e.
И наше приложение в APP STORE.
