Автомобильная сигнализация на ESP32 + GSP + GSM и BLE метки для аутентификаци
Понадобился специфичный вариант «сигнализации в машину». Можно было использовать сочетания покупного иммобилайзера и GPS трекера (делал так). Но, захотелось сделать свое, адаптированное под мои хотелки. Делал исходя из «а почему бы и нет». Однако, с практическим применением (поставил в машину).
Хотел бы поделится опытом не очевидных проблем «на пути».
Все что хотел из функциональности — сделал.
В качестве токена аутентификации — BLE токен.
Работа только через SMS.
В качестве «датчика вибрации» гироскоп с аналоговыми выходами XYZ.
Микрофон.
Время жизни от LiFePo4 6000mA x 2 2S, в автономе, оказалось около 10 дней. Несколько мало. И это основная проблема сборки из таких модулей.
Не стал делать SMS команду блокировки двигателя/зажигания. Все же рискованно. Но, при необходимости, любой функционал внешнего управления через SMS добавить не сложно.
Чем меня не устраивают готовые сочетания бюджетных «трекер+иммобилайзер»:
Нет информации о источнике/причине Alarm (можно только на вход ACC трекера подать выход на сирену/пищалку иммобилайзера и/или датчика удара)
Аутентификация только по своим RF меткам из комплекта иммобилайзера.
Управление по паролю, а не по списку телефонов.
Не настраиваемая информация в SMS и вообще фиксированный набор команд.
Если хочется не через SMS (не хочется), то только фиксированная инфраструктура/ПО.
Все действия в иммобилайзере начинаются только от ACC ON.
В результате схемотехнически получается ничуть не проще (датчик удара есть вкорячивать в схему установки уровня на входе ACC ON трекера и схема зарадки аккумулятора и аккумулятор дополнительный).
Гироскоп.
Взял первый попавшийся из старых запасов (маркировка затерлась. Даже не знаю какой). С гироскопом вообще проблем не оказалось. Показания снимаются через ADC DMA непрерывно. Перепробовал несколько вариантов алгоритмов обработки сырых данных XYZ. В результате остановился на варианте с двумя интегрированными показателями определяющим «медленное» изменение (машину грузят/поднимают) и «быстрое» (удар). Некоторое влияние оказывал SIM800L в режиме обращения к сети (передача). Но при разносе питания через разные DC-DC и физическом удалении платы SIM800L это влиение практически исчезло.
SIM800L.
Основные проблемы — это пиковое потребление модуля и его влияение (помехи) в это время на все остальное. Удалось победить это следующим:
как можно более короткие провода Rx, Tx между ESP32 и SIM800L
Модуль SIM800L и его антена не вплотную к всему остальному.
Резистивный делитель согласования уровней ESP32 и SIM800L с номиналами как написано в официальной документации на SIM800L.
Подключение только к UART1 (GPIO 16,17). Я не знаю что и почему, но с UART2 (GPIO 18,19) от помех избавится до конца не удалось. Но вот чудо (нашел упоминание об этом)! При перепайке на UART1 16,17 все искажения трафика исчезли.
Помехи проявляются искажением данных в канале UART.Т. е. через раз получение не искаженной RING и уведомление о SMS. Выглядит это как «R@ING» (пример.не более) и т.п. искажения. Исключительно только когда SIM800L включает передатчик (по току видно).
Еще не очень понравилось потребление модуля. По факту это около 50mA на 4V. И даже включение режима Sleep «AT+CSCLK=1» не сильно улучшает картину. Пишут, что очень много подделок, который только иммитируют sleep и вообще жрут как не в себя в idle.
NEO-6M.
Никаких программных неожиданностей с ним не было. Но лично у меня оказалась явная переделка или подделка (скорее всего NEO-5 чип). Потребляемый ток 50mA на 3.3V. Это много. Выполнение UNX команды CFG-RXM Power Save Mode никак на потребление не влияет. А отключение через UNX команду RF тракта снижает потребление всего до 18mA. И ниже этого не опустить. Либо переделывать плату, заменяя резистор, через который питается активная антенна, на ключ, управляемый с ESP32.
Хотя, чего можно ожидать от модуля, взятого за 500р на озоне.
ESP32.
ESP32 запитанная 3.3V от DC-DC в режиме без использования BLE scan то же оказалось довольно прожорливая. Вместе с гироскопом (отдельно не мерял) тянет 40mA. В остальном никаких особенностей/проблем нет.
В режиме скана меток BLE — 120mA.
Режим «поднят WiFi и запущен Web сервер для настроек» — 160mA. Хотя это не принципиально (ACC ON — внешний источник питания).
Эксперименты по питанию.
Первоначальный вариант я записал от Li-ion 1S. Но быстро отказался от такого варианта:
требует перепайки на плате ESP32 типичного дешевого AMS1117–3.3 на что то с меньшим падением напряжения. Иначе AMS1117 в купе с защитным диодом (есть на платах ESP32 от переплюсовки) снижает используемую емкость Li-ion вообще до 20–30%
Li-ion плохо ложится в разрешенный диапазон напряжений SIM800L.
Li-ion потенциально пожароопасны.
Единственное преимущество — это простота схемы питания. Остальное сплошные фатальные недостатки.
Выбрал LiFePo4. По причине меньшей пожароопасности. Но, использование LiFePo4, имеет свои недостатки:
Меньшая емкость по сравнению с Li-ion.
Не возможно хоть как то оценить остаточный заряд на середине графика разряда. Напряжение 3.2V может быть как и на 80% так и на 20% остаточной емкости. Для чего то это хорошо. А вот для информирования о состоянии заряда не очень.
Выводы и результат.
Собирать на дешевых модулях просто (20 минут на пайку), но результат не оптимизирован вообще и плохо поддается оптимизации ни по току (времени автономной работы) ни по размеру.
Но, для машины не так принципиально. Маленькая коробочка (170×113x48mm) с автономом в 10 дней и зарядом аккумулятора во время езды — для меня вполне подходит.
ссылка на исходники: https://github.com/mmMikeKn/gps-gsm-esp32
Писал на C (не на C++) просто по приколу. Вспомнить как это.
Сборка стандартыми средствами IDF под Windows (google «esp idf download»).
Habrahabr.ru прочитано 7549 раз
