Защита аккумулятора от глубокого разряда

Пока контроллер магнитной рамочной антенны питается от литиевого аккумулятора 4S2P, который установлен на самой антенне. Это старый аккумулятор от пылесоса, который собран из ячеек Samsung ICR18650-22F на 2200 мАч каждая. В силу своего возраста они потеряли часть ёмкости и уже не могут работать по прямому назначению, но для питания самоделок вполне подходят. Заменил родной разъём аккумулятора на XT60 и сделал ответную часть с выходом на приборные разъёмы для заряда.

По документации производителя эти ячейки считаются "пустыми" при напряжении 3 В на ячейку, а при 2,75 В нужно прекращать разряд во избежании необратимых изменений. К сожалению плата защиты аккумулятора не отключает выход при достижении 11 В и даёт разряжать его дальше. Чтобы не мучить батарею добавил в код контроллера функцию отслеживания напряжения питания и отключения контроллера, если напряжение питания станет ниже 12 В.

Порог в 12 В выбрал в связи с тем что на плате сейчас нет узла который отключит всю плату целиком. Контроллер может выключить драйвер шагового мотора, WiFi и уйти в режим глубокого сна, но это снижает потребление тока только до 14,5 мА при 86,5 мА в режиме ожидания команд.

Попробовал разобраться из чего складывается это потребление:

• 1,5 мА - WeMos D1 Mini в режиме защиты аккумулятора
• 7,5 мА - потребление линейного стабилизатора
• 5,5 мА - остаются на драйвер шагового мотора

Самым прожорливым потребителем оказался линейный стабилизатор LF33CV, но его ток холостого хода вполне соответствует документации (до 12 мА).

У WeMos D1 Mini уже есть встроенный делитель напряжения для АЦП, который позволяет подавать на вход A0 до 3,3 В. Добавил в схему дополнительный делитель напряжения в виде сопротивлений R1 и R2 чтобы была возможность измерять до 35 В.

Принципиальная схема контроллера в формате Kicad находится в директории "kicad" в репозитарии проекта.

Другие посты по теме:

• Магнитная рамочная антенна из алюминиевого обруча
• Дистанционная настройка рамочной антенны
• Управление антенной из SDR приложения

Возня с Kyverno

Какое-то время пришлось возиться с Kyverno в GKE и решил сделать пометки для истории. Началось всё с обратной связи от разработчиков, которым Kyverno не давал создать сервис Knative.

Failed to create Ingress: admission webhook "validate.kyverno.svc-fail" denied the request: resource Ingress/NAMESPACE/SERVICE was blocked due to the following policies disallow-empty-ingress-host: disallow-empty-ingress-host: The Ingress host name must be defined, not empty.

Это результат работы политики disallow-empty-ingress-host, которая написана без учёта того что одинаковые kind Ingress может быть у разных apiVersion и скорее всего они будут несовместимы.

Добавил исключение в конфигурацию, но обновление чарта с политиками Kyverno завершилась с ошибками:

admission webhook "validate-policy.kyverno.svc" denied the request: no unique match for kind Service
admission webhook "validate-policy.kyverno.svc" denied the request: no unique match for kind Ingress

В общем отделаться по-быстрому исключением и закинуть улучшение в бэклог не вышло. Выпустил новый релиз чарта с подправленными политиками (/v1/Service вместо Service и networking.k8s.io/*/Ingress вместо Ingress) и раз полез в Kyverno, то заодно подтянул изменения с нижних окружений, которые касались Kyverno.

В числе этих изменений было и обновление версии самого Kyverno. Полистал коротенький upgrading kyverno, но там подсветили только риск при обновлении до 1.13, которая уже была позади. Список изменений в GitHub это просто компиляция сообщений из комитов, но на всякий случай полистал и его. Обновление версии Kyverno в GKE принесло проблему, которая не проявлялась в AKS - большое количество полиси отчётов стали содержать ошибки вида:

Управление антенной из SDR приложения

 Продолжение проекта магнитной рамочной антенны. В прошлый раз был добавлен актуатор для КПЕ в виде шагового мотора и сделана прошивка для микроконтроллера. В этот раз я полностью собрал антенну и сделал автоматическое управление из SDR приложения.

Для автоматического управления антенной взял Raspberry PI 3 Model B у которого на борту есть WiFi и Ethernet. Поскольку антенна будет стоять на балконе (на котором не предусмотрена розетка Ethernet), то пока единственным вариантом соединения с raspberry будет WiFi.

Продолжение истории с Cilium в GKE

Какое-то время назад я писал про отваливающиеся пробы у подов в GKE кластере после установки Cilium. Тогда пришлось сделать шаг назад и удалить Cilium из кластера чтобы не блокировать команды разработки.

Отладку продолжил в изолированном кластере и в итоге получилось решить изначальную проблему с отваливающимися пробами. Около двух недель как Cilium снова управляет сетью в GKE, но периодически приходится решать мелкие проблемы.

Из свежего - несколько часов разбирался почему некоторые поды определённых демонсетов становятся "not ready" спустя несколько часов после создания. Интриги добавляло что это происходило ночью и один из них смог сам починиться и продолжить работу. Эта проблема отличалась от той, с которой я разбирался в отдельном кластере, т.к. там поды не проходили проверки сразу после создания. В итоге причина снова была в Cilium.

Дистанционная настройка рамочной антенны

 Это продолжение проекта магнитной рамочной антенны. Такие антенны настраиваются на очень узкий участок диапазона и при смене частоты в приёмнике нужно менять настройки антенны. Это не особо удобно даже если антенна стоит рядом и становится проблемой, если она находится на балконе. Чтобы не бегать каждый раз на балкон делаю электропривод для конденсатора переменной ёмкости.

Для вращения вала КПЕ буду использовать шаговый электродвигатель 17HS4023 формата NEMA17. Я раньше не имел дела с такими моторами и взял размер NEMA17 т.к. они используются в 3D принтерах и найти их в местных магазинах не составляет проблемы. На барахолках можно поискать б/у шаговики от принтеров или сканеров. Шаговые моторы от оптических (CD/DVD) или флоппи приводов выглядят слишком мелкими и скорее всего смогут вращать вал КПЕ только через редуктор.

Ошибка "metadata.resourceVersion: Invalid value: 0: must be specified for an update" в Terraform после редактирования ресурса

После редактирования ресурса knativeserving в Kubernetis кластере через kubectl edit Terraform не может применить к нему изменения через gavinbunney/kubectl провайдер:

│ Resource: "operator.knative.dev/v1beta1, Resource=knativeservings", GroupVersionKind: "operator.knative.dev/v1beta1, Kind=KnativeServing"
│ Name: "knative-serving", Namespace: "knative-serving"
│ for: "/tmp/1389615405kubectl_manifest.yaml": error when patching "/tmp/1389615405kubectl_manifest.yaml": knativeservings.operator.knative.dev "knative-serving" is invalid: metadata.resourceVersion: Invalid value: 0: must be specified for an update
│ 
│   with kubectl_manifest.knative_serving,
│   on knative.tf line 163, in resource "kubectl_manifest" "knative_serving":
│  163: resource "kubectl_manifest" "knative_serving" {

Я пробовал использовать параметр force_conflicts = true, но это не даёт эффекта.

Исправляется ошибка удалением аннотации kubectl.kubernetes.io/last-applied-configuration с нужного ресурса.

kubectl -n knative-serving annotate knativeserving knative-serving kubectl.kubernetes.io/last-applied-configuration-

Обновление прошивки HP ProBook 440 G8

Сменил свой домашний ноутбук с Dell Latitude E7470 на HP ProBook 440 G8. Переставил NVME SSD диск из Dell в HP и заодно решил обновить последнему прошивку.

До обновления была установлена версия прошивки T85 Ver. 01.22.00 от 22 августа 2025:

$ sudo dmidecode -t 0      
# dmidecode 3.6
Getting SMBIOS data from sysfs.
SMBIOS 3.3 present.

Handle 0x0000, DMI type 0, 26 bytes
BIOS Information
	Vendor: HP
	Version: T85 Ver. 01.22.00
	Release Date: 08/22/2025
	Address: 0xF0000
	Runtime Size: 64 kB
	ROM Size: 32 MB
	Characteristics:
		PCI is supported
		PC Card (PCMCIA) is supported
		BIOS is upgradeable
		BIOS shadowing is allowed
		Boot from CD is supported
		Selectable boot is supported
		EDD is supported
		Print screen service is supported (int 5h)
		8042 keyboard services are supported (int 9h)
		Serial services are supported (int 14h)
		Printer services are supported (int 17h)
		ACPI is supported
		USB legacy is supported
		Smart battery is supported
		BIOS boot specification is supported
		Function key-initiated network boot is supported
		Targeted content distribution is supported
		UEFI is supported
	BIOS Revision: 22.0
	Firmware Revision: 51.44

HP предлагает обновление прошивки в виде исполняемого файла для Windows, который можно скачать со страницы поддержки продукта. На момент написания этой заметки доступна версия 01.23.00 Rev.A от 16 января 2026 (имя файла sp168956.exe).