Вводное размышление на тему эксплуатации литий-титановых аккумуляторов (LTO). Это пост для инженеров или для тех, кому нравиться изучать разный электронный DIY. Как я рассказывал в других своих постах, я занимаюсь изученем механик построения автономных сенсорных сетей. Ранее в одной из статей, мной было упомянуто, что LTO являются краеугольным камнем электропитания автономных устройств, находящихся зимой на улице. Автономные — значит, не имеющие возможности самообогрева. Зимой на улице — значит, на морозе при значительном минусе.

Специфика литий-титановых аккумуляторов

Li-Ion, Li-Pol, Li-Fe-Po категорически запрещено заряжать при отрицательных температурах. Также их емкость значительно снижается с каждым градусом нарастающего мороза. LTO лишены этих недостатков, насколько это соотносится с реальностью, я не знаю, но, исходя из того, что я о них изучил к данному моменту, даже если это частично правда, это единственно доступный вид АКБ для моих поделок. При всей крутости LTO у них есть один косяк: их рабочее напряжение находится в диапазоне от 1,5 до 2,8 В. Это приводит к «некоторым сложностям» в поиске готовых микросхем для их зарядки. Когда речь заходит о том, чтобы зарядить Li-Ion, то доступны решения на любой вкус: от самых базовых CC/CV до навороченных суперконтроллеров, меряющих по отдельности температуры каждой ячейки, имеющих цифровой интерфейс для управления и снятия телеметрии и стоящих как, км... все остальные электронные компоненты на плате вместе взятые. Технически зарядка LTO ничем не отличается от зарядки Li-Ion, кроме напряжения. И вот тут, когда речь заходит о том, чтобы выдать 1,5 В, пасуют 99% контролеров. А те единичные решения, которые удалось нарыть с помощью святой Астры, стоят совершенно космических денег и предназначены для каких-то, видимо, очень дорогих промышленных решений, где стоимость одного компонента в 50–100$ не кусается. В общем, пришел к пониманию того, что нужно делать свой зарядник.

Теория реализации СС/CV

CC/CV зарядник, в общем-то, довольно простое устройство, это buck-преобразователь, к которому прилепили шунт для измерения тока, и работает он в двух режимах управления скважностью ключей: либо ограничивает напряжение на выходе, либо ток в зависимости от фазы заряда. Всё остальное — контроль температур, учет мощности, MPTT, балансировка, определение уровня заряда покоя, защиты — уже навески вокруг этой базовой схемы.

Есть два пути реализации собственного СС/CV Buck:

1. Полностью цифровой, взять микроконтроллер помощнее и запрячь его управлять MOSFETами на основании измеряемых АЦП выходного напряжения и тока. Плюсы схемы в том, что МК берет на себя полный контроль над всем процессом. На этом они заканчиваются и начаются минусы. Первый кроются в скорости реакции микроконтроллера на изменения обратной связи. На высоких скоростях преобразования он может просто не успеть отреагировать на выброс напряжения, и это не то чтобы очень хорошо. Расчеты показали следующее, что на частоте тактирования МК в 144 МГц будет доступен следующий гап на принятие решений между переключениями MOSFET.

   - 100 кГц: 1440 тактов (период 10 мкс).

   - 200 кГц: 720 тактов (период 5 мкс).

   - 300 кГц: 480 тактов (период ~3,33 мкс).

   Т. е. на 100 кГц у прошивки есть всего 1440 тактов на отработку всего алгоритма регулирования. Не так уж и много. Второй минус основывается на том что на плату налипает куча переферии которая обычно спрятана в корпус одной микросхемы - mosfet ключи, half-brige драйве, boost для его питания.

2. Гибридный метод. В этом случае берется какой-то типовой buck-контроллер вроде MP1584, и МК вмешивается в его петлю обратной связи, осуществляя подмес напряжения посредством ЦАП. Плюсы, очевидно, в выносе контроля ключа на аппаратный уровень, скачки входного напряжения больше не стоят под возможностью не успеть поправить PWM. А вот с минусами тут туго. Они были до того момента пока я не разобрался с тем как работает FB компаратор микросхем подобных MP1584.

И вот, проводя эти рассуждения, я столкнулся с еще одним моментом.

Обратная сторона - питание от LTO

Пока писал статью, разбирался с компонентной базой и пришел к пониманию того, что «специфика» эксплуатации LTO прослеживается и со стороны потребителя электропитания от этого вида АКБ. Если в схеме 1S Li-Ion будет стабильно выдавать > 3 В, то в случае с LTO напряжение может проседать до 1.5 В. И вот тут есть затыка, сделать boost с 2.8-3.0 В — задача тривиальная. А вот попробуйте найти хоть что-то, что без бубна сможет забуститься с 1.5 В, и вас постигнет неудача. Там начинается область необычных решений, вроде начального бутстрэппинга логики преобразователя, потому что работать он на таких напряжениях не может, а значит нужно сначала как-то запитать логику и ключ, контроллер прокачает немножко тока, создаст достаточное напряжение для того, чтобы питать сам себя. В общем, начинается зоопарк. Поэтому, судя по всему, эксплуатация схем 1S для LTO — идея сомнительная. Но как только мы делаем 2S, картина тут же меняется, на выходе по напряжению мы получаем почти что Li-Ion-1S, со слегка завышенным концом до 5.6 В. Из этого вообще изи можно получить любой ряд напряжений, включая 10 для питания драйвера ключей в цифровой схеме. Но... Привет, управление ячейками и балансировка.

Отладка

Данное поделие нужно как-то отлаживать. Тут опять есть развилка из двух путей:

• Пробовать на реальном АКБ. Честно говоря, впороть пару-тройку банок в целях разработки чего-то нового мне не жалко. Проблема в том, что всё, что связано с литием, нормально так взрывается и горит. Иногда не сразу и с не самым очевидным началом процесса дезинтеграции. Делать это в квартире несколько страшновато, уже был опыт общения с пожарными в эпоху самодельных печатных плат, более не хочется.

• Сделать тестовую нагрузку. Но если вы думаете, что это просто резистор большой мощности, то так, как бы, увы, нет.

Аккумулятор — это не просто сопротивление, это источник ЭДС. А значит, нужно, чтобы тестовая нагрузка могла, во-первых, ограниченно пропускать через себя заданное количество тока, либо ограничивать напряжение на входе. Т. е. в сути это обратная конструкция тому, что нужно сделать для зарядки. Если имитируется фаза CC, контроллер нагрузки ограничивает ток, если фаза CV — ограничивает нагрузку по падению напряжения на входе. Реализовать такое можно на MOSFET в линейном режиме, с обратной связью через операционный усилитель. Т. е. контроллер средствами ЦАП задает напряжение смещения в зависимости от фазы имитации степени заряда АКБ, которое приоткрывает MOSFET. Естественно, транзистор в таком режиме начинает работать как доменная печь, выделяя огромное количество тепла. Для этого на него вешается массивный радиатор, вероятно, с вентилятором, дабы это тепло отводить.

Релазизация

Так как задача получается довольно комплексной, решил разбить ее на пять последовательных этапов:

1. Так как у меня есть цель — освоить embedded rust на максимальном количестве платформ, пришло время для WCH. Я уже потыкал кодовую базу на rust по этому МК, выглядит симпатично. Сейчас задача — оппробировать схемотехнику обвязки этого МК. Судя по документации, это практически клон STM32 с «нюансами». Тут я уже накидал тестовый девборд для следующей итерации заказа печатных плат.

2. Создание базовой cc/cv зарядки по гибридной схеме и отладочной нагрузки. От полностью цифровой версии, после взевшивания всех плюсов и миносов я решил отказаться на корню. По итогу должен получиться работающий cc/cv контроллер, который может контролировать фазу зарядки и ее параметры.

3. Реализация алгоритма для зарядки Li-Ion сборок 1S. Тут должно родиться прошивка, которая имплементирует процесс зарядки Li-Ion. На этом этапе, собственно, должно получиться то, что сейчас выполняет CN3791 для зарядки одноq банки Li-Ion от солнечной панельки.

4. Адаптация схемы и алгоритма под зарядку Li-Ion сборок по схеме 2S. Учу код и железо работать с двумя ячейками.

5. Адаптация прошивки под LTO. К этому моменту будет готов контроллер для зарядки литиевых аккумуляторов с любой химией, адаптация к LTO будет сводиться лишь к правке констант в прошивке и тестировании на реальных АКБ.

З. Ы.

На этом графоманию, пожалуй, и закончу. Далее в отдельном цикле статей буду описывать процесс разработки зарядки и практической эксплуатации титаната. А также... Задача это для меня факультативная, пока есть куда более приоритетные цели, вроде научить шлюзы сенсорной сети ходить в интернет через LTE/NB-IoT. Но понемногу буду ее пилить, потому что в некоторой перспективе эксплуатация LTO станет бутылочным горлышком для моих экспериментов.

Перенес пинборд-прототип тестирования энергопотребления на схемотехническое решение. Как я описывал ранее, такая конструкция совершенно не годится для работы с какими бы то ни было режимами энергосбережения. Что подверглось жесткой оптимизации и переработке:

• ESP32. LDO, питающий схему на 3V3, был вынесен полностью и заменен на back-boost преобразователь на TPS63802 с током холостого хода 11 мкА. Не сказать, что это самый хороший вариант, но он доступен мне прямо сейчас. Более оптимальным вариантом будет TPS63900, но это задачка на будущее. Всё остальное с девкита ESP32 было отправлено на вынос — USB-концентратор, светодиоды и прочее ненужное. ESP32-C5 имеет встроенный JTAG, линии D+ и D- были выведены на сервисный разъем.

• MPTT-зарядка на CN3791 была перенесена в точности по даташиту.

• INA3221 — так же по даташиту с добавлением RC-фильтров на шунты.

• ATGM336H — тут самые радикальные изменения по сравнению с моделью. Убран EEPROM, мне не нужно хранить данные без питания, МК конфигурирует GPS полностью на старте. LNA заменен на усилитель из даташита (AT2659S). VBAT замкнут напрямую на 3V3 схемы, держать отдельную батарейку в аккумуляторном устройстве смысла я не вижу, умер основной аккум — умерло вообще всё, пока не зарядилось.

Было добавлено 4 разъема:

• USB 2.0 для внутрисхемного JTAG

• К солнечной панели

• К аккумуляторной сборке

• Разрыв для токоизмерительного щупа для измерения тока в режиме сна

Плату заказал, приедет после праздников, буду собирать.

Ну и немного драмы. Столкнулся с удивительным фактом, что даже на Алике интегральные компоненты штучно сейчас стоят дороже, чем на модулях. Т. е. дешевле купить готовое устройство и снять с него микросхему, чем покупать нулевую. Появился легкий нанос радиолюбительской практики из нулевых, когда на Митинском радиорынке на блохе (олды москвичи, я думаю, вспомнят это место) продавали всякий хлам с разборок и в том числе выпаянные компоненты. Ну что я могу сказать, ситуация, конечно, грустная.

Прошлые посты серии:

Как я сенсорную сеть изобретал ч.4

Как я сенсорную сеть изобретал ч.3

Как я сенсорную сеть изобретал ч.2

Как я сенсорную сеть изобретал ч.1

Сделал макет тестового стенда для изучения энергопотребления. Схема, в общем-то, простейшая: есть устройство, которое изображает из себя автономный узел и всеми силами пытается прожить на аккумуляторе, подзаряжая его солнечной панелью и исполняя различные программные кульбиты вроде ухода в различные режимы сна, жонглированием периферией, радиоканалом и даже физическим отключением частей схемы. Между всем этим делом оно (прошивка) собирает информацию о параметрах электропитания и отправляет эти данные на второй узел, используя mesh Burelom. Второй узел находится на стационарном питании и работает в режиме шлюза. Зацеплен на Wi-Fi роутер и шлет телеметрию от первого узла на сервер. Там она агрегируется и выводится через UI для анализа.

Паразитные токи

Про макет я сказал не просто к слову, а потому что прототипы на девкитах и энергосбережение — это взаимоисключающие понятия. Причина в том, что на этих платах либо используются очень бюджетная периферия, либо они обвешены компонентами, которые не нужны в реализуемой задаче. К примеру, на девкитах ESP32 присутствуют оба их вида. Стабилизатор AMS1117 (и ему подобные) имеет ток собственного потребления 5–10 мА, USB-концентратор CH334 и RGB-светодиод WS2812B — по 1 мА. Каждый индикаторный светодиод — по 5–10 мА. Когда у вас помимо девкита ESP32 на пинборде еще GPS, StepUp, MPTT, INA, это всё накидывает нехилый оверхед на токопотребление, превращая устройство в печку. Текущий стенд в рабочем режиме имеет расход 200 мА/ч. Совершенно безумная цифра для автономного устройства. С одним АКБ 18650 жить ему дай бог сутки, и никакая 5 Вт солнечная панель и софт с режимами сна не выведут его на стабильный режим долговременной работы. Поэтому следующим этапом будет перенос всего этого зоопарка на свою плату, с выкидыванием всего ненужного и подбором правильных компонентов. В общем-то вот именно такую производительность имеют модули Мештастик T-Beam. Я помню, что после жонглирования всеми возможными параметрами прошивки мне удалось достичь ресурса модуля в 30 часов. И это очевидный предел без значительных аппаратных и программных оптимизаций, достижение коих и ставлю себе в задачи. Далее идет в некотором смысле отчет о проделанной работе, как и в прошлых статьях, инженерная графомания, фотографии пинбордов на предметах мебели и ссылки на код.

Узел 1

К железяке было прикручено:

• Трехканальный инвалид INA3221 для измерения тока/напряжения (простите, по-другому не могу назвать это поделие).

• MPTT контроллер CC3791

• Солнечная панель 6v 5w с алика

Почему INA3221 — инвалид. Сам по себе чип — это отличный инструмент для измерения тока/напряжения в промежуточных точках устройства. Ситуация, когда такой измеритель ставится в разрыв произвольного провода, называется hi-end измеритель. Авторы же модуля решили почему-то, что это излишний функционал, и перемкнули все CH- линии на землю, таким образом ограничив модуль применением только в конечных точках (точка стока тока) устройства. Т. е. из отличного hi-end измерителя сделали кропнутый low-end. Пришлось его грубо доработать напильником. Как это сделать в деталях, я расскажу в отдельной статье.

MPTT-контроллер нужен для зарядки Li-Ion аккумуляторов прямиком от солнечной панели. Каналы INA были установлены в разрыв между солнечной панелью и MPTT, между MPTT и АКБ и между АКБ и устройством. Таким образом, устройство стало осведомлено о том, какой ток/напряжение дает солнечная панель, сколько от этого дела уходит на зарядку и сколько потребляет устройство в целом + уровень зарядки АКБ. Итоговое изделие имеет следующий вид:

Программно в нем был реализован простейший PowerManager, который читает INA3221 и преобразует полученные данные в удобочитаемый формат. Дальше они пакуются в proto-объект и выкидываются в меш-сеть к узлу 2.

Узел 2

Аппаратных изменений не приобрел. Программно для него был реализован MQTT-шлюз, реализующий контракт трейта Gateway меш-сети Burelom. Таким образом, всё, что приходит на этот узел, впихивается в соответствующий source-топик брокера. Сделать этот шлюз оказалось не самой простой задачей. Дело в том, что no_std-окружение Rust довольно ощутимо отстает по развитию от std. И если на std по запросу mqtt - крейты валятся как из рога изобилия, то вот для no_std их можно пересчитать по пальцам, да и, как оказалось, в удовлетворительном состоянии находится только один — rust-mqtt. Специально пилящийся для embedded применения. Все остальные либо как-то забагованы, либо реализуются только самый базовый функционал. Удивили клиенты, которые не умеют проводить даже basic-аутентификацию, зачем вообще такое позиционировать как законченную библиотеку? С rust-mqtt тоже, конечно, пришлось знатно повозиться из-за его супер-агностицизма к железу, у него не реализован внутренний цикл обработки mqtt-пакетов. В общем, логично, откуда автор знает, на какой системе это всё будет работать. Пришлось всё это дело написать, и заработало оно далеко не с первого раза. Но как результат, сейчас телеметрия стабильно уходит на сервер.

Второй интересный момент заключался с ESP-NOW. Я до этого уже упоминал, что этот протокол может работать параллельно с Wi-Fi. И вот сейчас открылась новая подробность о том, что, поскольку Wi-Fi ядро ESP32 не умеет мультиканальность, esp_now должен быть локнут на тот же канал, что и станция. А станция локается всегда на канал роутера, который может быть любым, если он жестко не залочен на самом роутере. Т. е. получается интересная картинка, что esp_now узла 2 знает, на каком канале ей сидеть, а узел 1 — нет. При этом канал этот может оказаться совершенно произвольным. Пришлось залочить канал на домашнем роутере, дабы вся сеть не рассыпалась просто оттого, что роутер решил, что ему комфортнее живется на другом канале.

Бекенд

Очень не хотелось тащить в телеметрию PostgreSQL просто по идеологическим соображениям. Но поднимать какой-нибудь Infux для того, чтобы просто поиграть с данными, тоже абсурд. Решил помучить дипсик на тему того, что вообще сейчас в индустрии СУБД для временных рядов. Выяснилось, там прямо золотой век, начиная от распределенного отечественно Clickhouse до локальных микрорешений вроде Chronix. Пораскинув мозгами, пришел к выводу взять tsink, который в зависимости от настроек может прикидываться от локальной файловой tsdb до серверного решения, умеющего в кластерную репликацию. Пока взял его локальную версию, работать с ним, конечно, одно удовольствие.

Фронтенд

Тут всё обычно для Rust экосистемы: мультиоконный Eframe и Tokio. Собственно, скриншот этого UI в шапке поста.

Что дальше?

1. Я хочу закончить это микрокобесие с пинбордами и перейти на сквозное прототипирование на печатных платах. Девкиты и макетки сильно ускорили процесс начальной разработки, но далее я считаю их потенциал исчерпанным.

2. Буду пробовать выполнять программные оптимизации, экспериментировать с режимами сна и работы с периферией.

Ссылки

• Узел 1 (менеджер электропитания + main)

• Узел 2 (mqtt продюсер, шлюз + main)

• Бек + Фронт (пока монолитом, весь код)

Начнем размышлять с того, что вообще для микроконтроллера есть время. Для него время — это тики внутреннего таймера на основе сигнала, задаваемого кварцевым резонатором. Первый момент сводится к тому, что он ничего не знает о глобальном времени. А значит, устройствам в сети нужно как-то договориться, чтобы они все имели одинаковое понимание, где они во времени находятся. Но это не панацея, потому что... Кварцевый резонатор — это крайне хреновый по стабильности источник времени. Даже высокоточные кварцы плывут во времени. Вот есть такая картинка с расчетом, насколько уплывают часы МК на кварцах разной точности за разные временные промежутки.

При этом этот сплыв еще сильно зависит от температуры. Т. е. если у вас на улице, скажем, -20 или +40, дрейф будет еще выше. Очевидно, что со стандартными бюджетными кварцами 20-50 ppm уже за сутки вы получите критический рассинхрон даже для наивного хертибита сети. Через месяц он превратится в клюкву — дрейф пойдет уже на минуты. Даже если воткнуть сверхточный кварц, за сутки часы уедут на десятки мс. Для TDMA с микросекундной точностью это хана, уже через 30-40 часов устройство начнет промахиваться мимо слотов.

К чему всё это? Даже если устройства засинхронились, их часы тут же начинают плыть, и нужно делать эту синхронизацию постоянно, желательно несколькими возможными способами, чтобы, если один отвалится, можно было опираться на что-то еще.

Варианты получения времени можно разделить на два случая. В первом случае некоторое устройство назначается эталонным источником времени и рассылает пакеты синхронизации по сети. Получатели этих пакетов, соответственно, корректируют свои часы в соответствии с эталоном. Помним, что это так называемое монотонное время — количество X (подставить нс, мк, мс...) прошедших с момента старта эталона. Во втором случае сеть работает на основе глобального времени UTC. И получает это время устройство либо самостоятельно, либо через синхропакеты от устройств, которые его уже получили самостоятельно. Самостоятельно устройство может получить UTC может двумя способами: через GPS или через NTP.

Для получения времени по GPS очевидно нужно, чтобы устройство было снабжено GPS-приемником, в моем случае это ATGM336H. И устройство должно видеть спутники для установления фикса (устойчивого пространственного позиционирования). Приемник шлет пакеты ZDA, содержащие UTC-время и PPS-сигнал точного момента приема пакета, позволяя реконструировать UTC-время с точностью до микросекунд.

Для NTP требуется выход в интернет, благо ESP32 — это мастер подобных выкрутасов, для нее подключиться по Wi-Fi и в интернет сходить — тривиальная задача. Точность сомнительная, хотя драйвер NTP и пытается устранить джиттер (запрос до сервера — обработка — ответ от сервера), получается у него это хреновато из-за асимметричности маршрутов в интернете (запрос идет дольше, чем ответ, или наоборот). Каждый запрос будет давать ошибку в несколько мс. Насколько это критично? Ну чисто умозрительно не то чтобы очень, если грануляция слотов десятки... сотни мс. Для мк точности это, конечно, не проактит. Нужно будет выводить статическое среднее, но до этого мне пока дела нет, с хертбитом бы разобраться.

А что на практике? На практике получилась картина которая требует серьезных размышлений. Я реализовал небольшой планировщик, которые включает светодиод каждую десятую секунду UTC на две секунды. Вспоминаем схему из заголовка статьи и если лень ждать перематываем на 16 секунду, видео 240 fps:

Феномен оказался настолько любопытным, что я загрузил видео в редактор и решил посчитать тайминги.

• 18:00 - Вспыхивает светодиод на плате 3

• 18:07 - Вспыхивает светодиод на плате 2

• 18:17 - Вспыхивает светодиод на плате 1

Устройство 1 получает время через GNSS, оно имеет крайне высокую точность. Устройство 2 идет в интернет на NTP-сервер по Wi-Fi, возникают ассиметрия и джиттер. Часы вперед на 0.100 / 8 (240f/30f) = 12.5 мс. Далее устройство два передает по тому же Wi-Fi sync-пакет, сеть локальная, пакет широковещательный, джиттера нет, но передача пакета по воздуху занимает 0.070 / 8 = 8.75 мс. Стало интересно, а сколько времени займет NTP на компе.

59 мс — немало, т. е. 12,5 мс — и есть та самая ассиметричность интернет-маршрутов, про которую я писал выше. Какие из этого выводы? Как будто бы то, что если в сети будет имеется несколько точек синхронизации с NTP UTC, это может приводить к довольно ощутимому рассинхрону на очень коротких слотах. Промах в 10–20 мс для TDMA — это ощутимо. В общем, исследование получилось весьма любопытным. Код, который всё это делал, можно изучить тут.