Электронная нагрузка 300W

Начинал этот проект больше года назад, но тогда он был собран практически полностью по схеме из этого видео. Печатная плата была изготовлена методом ЛУТ (Лазерно-Утюжная Технология) по макету из видео (спасибо Артуру за исходники платы). В моём случае применены 4 полевых транзистора IRFP054NPBF, которые без проблем держат ток 20A при напряжении 15V на входе нагрузки (ограничение мощности в 300W, которое связано с максимальной рассеиваемой мощностью корпуса транзисторов TO-247). Еще пришлось увеличить номинал керамических конденсаторов в цепи обратной связи ОУ (Операционный Усилитель) с 1nF до 100nF (с 1nF была паразитная генерация начиная с определенной мощности).

Регулировка мощности делалась переменным резистором и этого полностью хватало для проверки блоков питания, но в случае разрядки аккумуляторов для проверки их ёмкости нужно было следить за напряжением и вовремя отключать силовую часть. В доработанном варианте схемы измерения ёмкости использовалось реле, которое замыкало вход ОУ на землю при достижении минимального напряжения - это отключало силовую часть нагрузки.

Обновление Nextcloud 25 с Debian Bullseye до Debian Bookworm

Неспеша обновляю хосты с 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

Собрал пакеты Midnight Commander 4.8.30 для Debian/Ubuntu с архитектурами i386, amd64, armel, armhf и arm64. Пакеты для i386 и armel есть только в тех дистрибутивах, где они поддерживаются официально (в Ubuntu есть не все):

• Debian Buster (i386, amd64, armel, armhf, arm64)
• Debian Bullseye (i386, amd64, armel, armhf, arm64)
• Debian Bookworm (i386, amd64, armel, armhf, arm64)
• Debian Sid (i386, amd64, armel, armhf, arm64)
• Ubuntu Trusty (i386, amd64, armhf, arm64)
• Ubuntu Xenial (i386, amd64, armhf, arm64)
• Ubuntu Bionic (i386, amd64, armhf, arm64)
• Ubuntu Focal (amd64, armhf, arm64)
• Ubuntu Jammy (amd64, armhf, arm64)
  

Инструкция по подключению репозитария. Больше информации о бинарных сборках Midnight Commander можно найти на странице https://midnight-commander.org/wiki/Binaries.

Использование PCRE2 для поиска не включено, т.к. в этом случае пакет не собирается в Ubuntu Trusty. В апреле следующего года будет EOL для Ubuntu Trusty и можно будет собрать пакет с поддержкой PCRE2.

HashiCorp сменил лицензию своих продуктов с MPL на BSL

Новость про смену лицензии появилась еще на прошлой неделе, но только сегодня дошли руки разобрать ленту и расстроиться. Из важного я вижу два абзаца:

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) и возможно к созданию форков.

Не работает vagrant ssh в Windows 10

 Если после успешного создания виртуальной машины в Vagrant вы не можете зайти в нее через SSH, то проверьте какую версию ssh она использует (vagrant ssh --debug). В Windows 10 появился встроенный клиент SSH (c:\Windows\System32\OpenSSH\ssh.exe) и если он установлен (его можно удалить), то скорее всего будет ругаться на права доступа к приватному ключу:

W:\test>c:\Windows\System32\OpenSSH\ssh.exe -i .vagrant\machines\default\virtualbox\private_key -p 2222 vagrant@127.0.0.1
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions for '.vagrant\\machines\\default\\virtualbox\\private_key' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key ".vagrant\\machines\\default\\virtualbox\\private_key": bad permissions
vagrant@127.0.0.1: Permission denied (publickey).

Это известная проблема (#9433 и #9831) и достаточно указать Vagrant предпочитать бинарники из своего дистрибутива вместо системных

W:\test>set VAGRANT_PREFER_SYSTEM_BIN=0
W:\test>vagrant ssh
Linux bullseye 5.10.0-22-amd64 #1 SMP Debian 5.10.178-3 (2023-04-22) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Mon Aug 14 11:56:53 2023 from 10.0.2.2
vagrant@bullseye:~$

Чтобы не задавать переменную каждый раз ее нужно прописать в список переменных для пользователя или всей системы.

Разное поведение плат Arduino при работе через последовательный порт

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

Чтобы отладить работу с протоколом я взял свободную Arduino Leonardo и набросал для нее скетч, который эмулирует поведение электронной нагрузки. После отладки стал переносить код протокола в основной скетч уже моей электронной нагрузки (которая сделана на базе Freeduino 2009, аналога Arduino Duemilanove) и столкнулся с проблемой, что программа на компьютере больше не определяет что подключена электронная нагрузка.

ASRL/dev/ttyUSB0::INSTR
SerialInstrument at ASRL/dev/ttyUSB0::INSTR
probe
<class 'pyvisa.errors.VisaIOError'>
('VI_ERROR_TMO (-1073807339): Timeout expired before operation completed.',)
VI_ERROR_TMO (-1073807339): Timeout expired before operation completed.
error reading bytes
no answer
ko
No instruments found

Был уже поздний вечер и хотелось увидеть реальные показания и потому сразу попробовал поменять местами Freeduino и Arduino Leonardo - не помогло. Разные распиновки для I2C и не инициализируется периферия. Залил скетч эмулятора в обе платы и стал сравнивать их поведение - на Leonardo все просто работает, а на Freeduino - ошибка. Обратил внимание что отличаются названия портов - у Leonardo это /dev/ttyACM0, а у Freeduino это /dev/ttyUSB0, но почему на одном работает, а на втором - нет я не понял и пошел спать.

Минимальное напряжение AREF для ADC

Нужно было измерить линейность R-2R ЦАП после резистивного делителя (было интересно насколько просядет максимум сигнала и сохранится ли линейность). Исходный сигнал лежит в диапазоне от 0V до почти напряжения питания (в моем случае было 0V - 4.95V), но для моих целей нужно чтобы сигнал был в пять раз меньше (0V - 0.5V).

Измерения делались через АЦП Atmega32U4 (Arduino Leonardo) - у этого микроконтроллера есть несколько вариантов опорного напряжения АЦП:

• DEFAULT - 5V;
• INTERNAL - 2.56V;
• EXTERNAL - то, что подается на пин AREF;

Вначале попробовал вариант с 2.56V, но это в шесть раз больше чем максимум измеряемого сигнала и хотелось лучшей точности. Стал пробовать вариант EXTERNAL - подал на пин AREF 0.5V относительно земли и получил "зашкал" на АЦП - все значения были 1023 даже если на вход подавалось 0V. Вначале грешил на "кривую" ардуину и стал прозванивать пины микроконтроллера и сверяться с даташитом - никаких ошибок не нашёл.

А потом поднял напряжение AREF до 1V и оно заработало! В гугле на первой странице есть описание этой проблемы. Я не поленился и пошёл перечитывать даташит, но ничего про минимальное напряжение AREF в нем не нашёл. Если верить документации Arduino, то на AREF можно подавать от 0V до 5V и либо это целиком зависит от микроконтроллера, либо в документации стоит поправить.