Почему сгорел лабораторный блок питания

В процессе тестирования новой электронной нагрузки погиб мой лабораторный блок питания. Он успел отработать около 5 минут, после из него вышел весь "волшебный дым" и в комнате запахло "жареной" электроникой. Эти 5 минут ЛБП работал на максимальных для него 30V/3A (90W) т.к. мне нужно было убедиться что охлаждение электронной нагрузки справится с 90W тепла.

Вскрыв корпус ЛБП для ремонта я увидел сгоревшую дорожку от трансформатора до диодов моста. Ради уменьшения нагрева были установлены диоды шоттки SB560 (60V 5A) - в теории это давало полуторный запас прочности. Прозвонка диодов показала что два их четырёх закоротило и это привело к выгоранию дорожки (мощность трансформатора 250W и спалить дорожку ему не составило труда).

Проблема с обновлением rpi-eeprom в Raspbian Bookworm

У меня есть принт-сервер для HP LaserJet 1018 на базе Raspberry Pi B+ в котором установлен Raspbian и CUPS. В конце октября я без проблем обновил эту систему с Raspbian Bullseye до Raspbian Bookworm, но сегодня при установке обновлений выдало ошибку:

Errors were encountered while processing:
 raspi-firmware
 rpi-eeprom
E: Sub-process /usr/bin/dpkg returned an error code (1)
Setting up raspi-firmware (1:1.20231024+ds-1+rpt2) ...
stat: cannot read file system information for '/boot/firmware': No such file or directory
Error: missing /boot/firmware, did you forget to mount it?
dpkg: error processing package raspi-firmware (--configure):
 installed raspi-firmware package post-installation script subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of rpi-eeprom:
 rpi-eeprom depends on raspi-firmware; however:
  Package raspi-firmware is not configured yet.

dpkg: error processing package rpi-eeprom (--configure):
 dependency problems - leaving unconfigured
Processing triggers for initramfs-tools (0.142) ...
Errors were encountered while processing:
 raspi-firmware
 rpi-eeprom

Варианты получения двухполярного питания

Недавно наткнулся на описания микросхемы ICL7107, которая является основой многих мультиметров прошлых лет и не требует значительной обвязки, и решил собрать на её базе миллиомметр. Эта микросхема требует двухполярное питание +5V/-5V и для быстрой проверки я использовал два блока питания на 5V, которые были соединены последовательно, а средняя точка выполняла роль общего провода (земли).

В случае лабораторного блока нет проблем получить -5V от отдельной обмотки трансформатора, но если рассматривать автономный вариант с питанием от батареи или аккумулятора, то всё немного сложнее. Я нашёл несколько вариантов схем для получения двухполярного питания из однополярного и протестировал их.

Первые шаги с OpenTofu

Из-за недавней смены лицензии Terraform возникла неопределенность с его дальнейшей судьбой в коммерческих проектах. В качестве ответа был создан форк OpenTofu, который будет развиваться под эгидой Linux Foundation и я попробовал оценить готовность OpenTofu с точки зрения drop-in replacement для Terraform.

Насколько мне известно, OpenTofu был форкнут с Terraform 1.5.5 (последняя версия под лицензией MPL) и никакой разницы с Terraform 1.5.x быть не должно. Я тестировал два последних релиза OpenTofu (1.6.0-alpha2 и 1.6.0-alpha3) и на первый взгляд достаточно создать алиас terraform на tofu чтобы все просто заработало, но всплыли нюансы.

Почему перегорает предохранитель при включении трансформатора

Столкнулся с перегоранием предохранителя на входе разделительного трансформатора при его включении в сеть без нагрузки. Изначально был установлен быстрый предохранитель на 1A (в маркировке указана буква "F") и его хватило на несколько таких включений.

В теории, при включении трансформатора в сеть, его пусковой ток в десятки раз больше номинального тока и быстрые предохранители успевают перегореть. Кроме того важно в какой момент периода синусоиды трансформатор включается - если на пике, то пусковой ток будет минимальным, но если "повезет" включить во время прохождения нуля, то пусковой ток будет максимальным.

Чтобы проверить эту теорию на практике, собрал схему для регистрации пускового тока - тороидальный трансформатор мощностью 10VA подключён к выходу разделительного трансформатора через шунт 0.1Ω. При токе в 1A на шунте будет падение напряжения в 0.1V. Бросок тока буду регистрировать осциллографом, второй канал который подключен параллельно сопротивлению. Использование разделительного трансформатора продиктовано соображениями безопасности, к тому же запрещается подключать осциллограф к сети без дифференциальных щупов (у меня таких не водится из-за значительной цены последних).

Доработка импульсного блока питания

Попросили оживить игрушечную гоночную трассу от которой был утерян блок питания. На коробке с игрой указано 6V, но после подключении лабораторного блока питания заметил два момента:

• машинки ехали задом-наперед (т.е. у родного блока питания минус был на центральном контакте, а плюс - на кольце)
• машинки ехали довольно медленно, даже если "давить газ в пол"

Поменяв полярность и подняв напряжение до 8V играть стало веселее, но все же достаточно первым нажать на газ и просто держать до последнего круга - никакого соревновательного момента нет. Поднял напряжение до 9V и на закруглении трассы машинки стали слетать если не притормозить. Играть стало заметно интереснее.

BTRFS warning (device dm-X): block group XXXXXXXXXX has wrong amount of free space

При загрузке виртуалки с Linux стала появляться ошибка связанная с BTRFS - "BTRFS warning (device dm-X): block group XXXXXXXXXX has wrong amount of free space", где dm-X - устройство device mapper на котором находится BTRFS, а XXXXXXXXXX - номер блока файловой системы.

Sep 22 09:01:35 vbox kernel: Btrfs loaded, crc32c=crc32c-intel
Sep 22 09:01:35 vbox kernel: BTRFS: device fsid 683a86c5-a6f1-4b68-b0f9-5330e443a1e4 devid 1 transid 1769033 /dev/mapper/debian--jessie--vg-docker scanned by btrfs (191)
Sep 22 09:01:36 vbox kernel: BTRFS info (device dm-2): using crc32c (crc32c-intel) checksum algorithm
Sep 22 09:01:36 vbox kernel: BTRFS info (device dm-2): flagging fs with big metadata feature
Sep 22 09:01:37 vbox kernel: BTRFS info (device dm-2): disk space caching is enabled
Sep 22 09:01:37 vbox kernel: BTRFS info (device dm-2): enabling ssd optimizations
Sep 22 09:01:48 vbox kernel: BTRFS warning (device dm-2): block group 71072481280 has wrong amount of free space
Sep 22 09:01:48 vbox kernel: BTRFS warning (device dm-2): failed to load free space cache for block group 71072481280, rebuilding it now

Хотя и пишет что "rebuilding it now", но за несколько дней ничего не изменилось. В Linux fsck для BTRFS это заглушка, которая ничего не делает и потому придётся исправлять вручную.