Завершил сборку нового лабораборного блока питания на 30В/3А. В отличии от моего предыдущего лабораторника, который работает в импульсном режиме и способен выдавать до 23В и 5А, новый работает в линейном режиме, расчитан на большее напряжение, не дает помех в нагрузку и хорошо ограничивает ток.
Сегодня дошли руки до распаковки набора для сборки лабораторного блока питания 0-30V, 0-3A который продается на каждом углу AliExpress. Операционные усилители, которые шли в наборе, не имеют никакой маркировки
Но если верить шелкографии на печатной плате, то это должны быть TL081. В комментариях к товару несколько человек писали о мертвых операционных усилителях поэтому я сразу заказал комплект на замену на всякий случай.
Перед тем как впаивать комплектующие стоит проверить их на работоспособность. Все кроме операционных усилителей можно проверить в тестере транзисторов, но операционные усилители нужно проверять отдельно.
В интернете нашлась несложная схема для проверки операционного усилителя (YouTube / KiCad)
Собрал ее на макетной плате
Если операционный усилитель исправен, то все четыре светодиода мигают попеременно парами. Это очень простой тест, но достаточный чтобы отличить мертвую деталь от рабочей. Для более подробного теста нужно хотя быть проверить напряжение смещения и скорость нарастания напряжения. На эту тему есть хорошее видео продолжительностью 50 минут, но на мой взгляд оно того стоит.
Все три "безымянных" операционных усилителя прошли тест, но я на всякий случай поставлю их в панельки, чтобы потом не мучиться с выпаиванием.
Обновил Raspberry PI 4 с Debian Buster до Debian Bullseye и подключил схему управления оборотами вентилятора чтобы сделать его тише. Для управления PWM я использую GPIO 16.
 |
| https://www.raspberrypi.org/documentation/computers/os.html |
В прошлый раз я тестировал на OpenELEC с python 2.7, но в Bullseye используется python 3.9.2. Для работы с GPIO в Debian нужно установить пакет python3-rpi.gpio
$ sudo apt-get update $ sudo apt-get install python3-rpi.gpio
Теперь можно установить сервис для управления оборотами в зависимости от температуры процессора
$ git clone https://github.com/tataranovich/Raspberry-Pi-PWM-fan.git
$ cd ./Raspberry-Pi-PWM-fan/
$ sudo python3 fan.py
Traceback (most recent call last):
File "/home/andrey/Raspberry-Pi-PWM-fan/fan.py", line 42, in <module>
GPIO.setup(FAN_PIN, GPIO.OUT, initial=GPIO.LOW)
RuntimeError: Not running on a RPi!
Затеял обновление своего сборочного окружения, которое используется для компиляции пакетов для armel, armhf и arm64 архитектур. Сейчас оно построено на Raspberry PI 4 2GB и загружается с SD карточки на 32GB в которой /var/cache/pbuilder/build использует bcache поверх NFS и ram диска (подробности есть тут).
Это прилично ускоряет сборку в pbuilder, но только если размер билда не превысит размер ram диска. Raspberry PI 4 умеет загружаться с USB без плясок с бубном и поэтому самым простым решением для ускорения будет отказ от SD карт. Для этого я прикупил Orico M.2 NVMe SSD enclosure и Kingston A2000 на 256GB.
Собрал пакеты Midnight Commander 4.8.27 для Debian/Ubuntu с архитектурами i386, amd64, armel, armhf и arm64. Пакеты для i386 и armel есть только в тех дистрибутивах, где они поддерживаются официально (в свежих Ubuntu их нету). Заодно добавил поддержку Debian Bullseye, который вышел недавно.
Инструкция по подключению репозитария. Больше информации о бинарных сборках Midnight Commander можно найти на странице https://midnight-commander.org/wiki/Binaries.
Изначально эта проблема попала ко мне с описанием "Нестабильная работа Solr на всех окружениях". В админке Drupal сайта тестирование настроек Solr в большинстве случаев завершалось с ошибкой, но сам поиск хоть и очень медленно, но работал.
Сперва выполнил пробный запрос к Solr из одного из контейнеров чтобы подтвердить наличие проблемы - с приличной задержкой, но запрос выполнился. Повторил запрос в цикле и получилось что время выполнения запроса "скачет" от 100 миллисекунд до 12 секунд. Чтобы исключить проблемы с DNS попробовал подключиться к Solr по IP, а не по FQDN - запрос выполняется быстро. Повторяю тест используя IP вместо FQDN в цикле и результат находится в пределах 100 - 150 миллисекунд. Выходит что проблема в DNS, но пока не ясно виноват kube-dns или вышестоящий DNS сервер к которому обращается kube-dns. Попробовал обращаться к другим доменам, например www.google.com - поведение аналогичное. Описание проблемы меняется с "Нестабильная работа Solr на всех окружениях" на "Нестабильная работа DNS в GKE на всех окружениях".
Чтобы зайти на виртуальную машину через SSH в GCP удобно использовать команду gcloud compute ssh, но по умолчанию используются ключи, которые добавляются на уровень проекта, либо в саму виртуальную машину. Чтобы зайти с авторизацией по паролю нужно указать опцию --plain
$ gcloud compute ssh <instance> --plain --project <gcp-project> --zone <gcp-zone>
Такой подход удобен когда у виртуальных машин нет публичных IP адресов и можно подключаться используя Identity Aware Proxy (IAP) без промежуточных решений вроде AWS Workspace, bastion host или VPN.