Разрядился фитнес-браслет Huawei Band 6, а родной кабель для зарядки забыли в другом городе. Выйти из ситуации можно если знать полярность подключения питания к браслету, но распиновку в Интернете я найти не смог.
Можно было попробовать подавать 5В на контакты, но я не уверен что в браслете есть защита от неправильной полярности. Попробовал прозвонить защитный диод как в этом видео, но в моём случае мультиметр не показал наличие диода.
Продолжаю дорабатывать свой проект электронной нагрузки. Стол, который я занял для своей "мастерской" во время летних каникул, пришлось освободить и для удобства переноски закрепил все платы на основание.
Чтобы вся эта конструкция не каталась по столу снизу прикреплены приборные ножки из резины. Для измерения тока и напряжения реализовано четырёх-проводное подключение.
В процессе тестирования электронной нагрузки на большой мощности (больше 220W при подключении к автомобильному аккумулятору) заметил что нагрузка не поддерживает заданный ток и он заметно изменяется по мере прогрева силовой платы.
Сначала было подозрение на схему ЦАП, которая представляет собой 8-битный R-2R из резисторов 1% точности, но замер напряжения на выходе не показал отклонений во время работы (колебания в десятые доли милливольта я не беру во внимание).
Начинал этот проект больше года назад, но тогда он был собран практически полностью по схеме из этого видео. Печатная плата была изготовлена методом ЛУТ (Лазерно-Утюжная Технология) по макету из видео (спасибо Артуру за исходники платы). В моём случае применены 4 полевых транзистора IRFP054NPBF, которые без проблем держат ток 20A при напряжении 15V на входе нагрузки (ограничение мощности в 300W, которое связано с максимальной рассеиваемой мощностью корпуса транзисторов TO-247). Еще пришлось увеличить номинал керамических конденсаторов в цепи обратной связи ОУ (Операционный Усилитель) с 1nF до 100nF (с 1nF была паразитная генерация начиная с определенной мощности).
Регулировка мощности делалась переменным резистором и этого полностью хватало для проверки блоков питания, но в случае разрядки аккумуляторов для проверки их ёмкости нужно было следить за напряжением и вовремя отключать силовую часть. В доработанном варианте схемы измерения ёмкости использовалось реле, которое замыкало вход ОУ на землю при достижении минимального напряжения - это отключало силовую часть нагрузки.
Неспеша обновляю хосты с Debian Bullseye до Debian Bookworm и на той неделе столкнулся с ситуацией когда не получилось привычным способом обновить сервер с установленным Nextcloud 25.
В Bookworm поставляется PHP 8.2 который не поддерживается в Nextcloud 25, а сначала обновить Nextcloud до 26 в Debian Bullseye тоже нельзя, т.к. в Nextcloud 26 удалена поддержка PHP 7.4.
В этом случае придется следовать процедуре ручного обновления, предварительно обновив дистрибутив до Debian Bookworm в котором уже PHP 8.2.
Собрал пакеты Midnight Commander 4.8.30 для Debian/Ubuntu с архитектурами i386, amd64, armel, armhf и arm64. Пакеты для i386 и armel есть только в тех дистрибутивах, где они поддерживаются официально (в Ubuntu есть не все):
Инструкция по подключению репозитария. Больше информации о бинарных сборках Midnight Commander можно найти на странице https://midnight-commander.org/wiki/Binaries.
Использование PCRE2 для поиска не включено, т.к. в этом случае пакет не собирается в Ubuntu Trusty. В апреле следующего года будет EOL для Ubuntu Trusty и можно будет собрать пакет с поддержкой PCRE2.
Новость про смену лицензии появилась еще на прошлой неделе, но только сегодня дошли руки разобрать ленту и расстроиться. Из важного я вижу два абзаца:
End users can continue to copy, modify, and redistribute the code for all non-commercial and commercial use, except where providing a competitive offering to HashiCorp. Partners can continue to build integrations for our joint customers. We will continue to work closely with the cloud service providers to ensure deep support for our mutual technologies. Customers of enterprise and cloud-managed HashiCorp products will see no change as well.
Vendors who provide competitive services built on our community products will no longer be able to incorporate future releases, bug fixes, or security patches contributed to our products.
Я не юрист и не разбираюсь во всех тонкостях лицензирования, но для меня это выглядит плохо. Еще хуже, чем смена лицензии на продукты Elastic или отказ от публицации всех исходников у RedHat (я почти не пользуюсь этими продуктами и не сильно расстроился). У Gruntwork есть пост по поводу смены лицензии Terraform и как это изменение повлияет на их клиентов.
Что делать дальше? Ну например зафиксировать версии продуктов HashiCorp на тех, которые еще выпущены под лицензией MPL (например Terraform 1.5.5). Но такая фиксация в будущем обернется трудностями с исправлениями уязвимостей (в первую очередь актуально сетевых сервисов вроде Vault и Consul) и возможно к созданию форков.
