🏠: it

Собрал часы

Когда-то давно мой отец сделал настольные часы из каких-то останков «Электроники», которые работали без корпуса и выглядели примерно так:

Изображение без описания
Фото из Музея советской электроники

Заметная часть моего детства прошла среди развороченных телевизоров, магнитофонов и прочей техники, я играл с радиодетальками, поэтому вид электронных внутренностей был привычен, не вызывал никаких негативных эмоций, и работающие часы без корпуса смотрелись гораздо интереснее, чем в корпусе. А ещё они отлично светились ночью, озаряя комнату магически-зелёным светом своего ваккумно-люминесцентного индикатора.

Не то чтобы мне хотелось иметь дополнительный источник светового загрязнения у себя дома, но частенько, просыпаясь ночью, хотелось бы знать, который час. Сейчас для этого я вынужден включать экран телефона, который очень неприятно бьёт светом в глаза, или вставать с кровати и нажимать кнопку «стационарного» (на самом деле SIP) телефона, который тоже показывает правильное время.

Собственно, набор требований к часам такой:

  • Светятся в темноте, но неярко;
  • Дешёвые;
  • Сами синхронизируют время, т. е., не требуют ручной подводки;
  • Питание от сети, никаких батареек.

Начал поиски готовых вариантов. Удивительно, но под такие, казалось бы, простые требования найти готовые недорогие часы я так и не смог. Часы, в которых есть wi-fi или которые умеют получать время по GPS, есть, но стоят они каких-то неприличных денег и называются «умными», т. е., обладают большим количеством никому не нужных функций. Оказалось, что часы с автосинхронизацией как отдельный прибор, а не как встроенный функционал чего-то большего — это редкость и, судя по ценникам, роскошь.

Во время поиска подходящего варианта узнал от коллеги, что есть так называемые часы с радиоконтролем, а именно — умеющие синронизировать время по протоколу DCF77, но стоят они тоже недёшево, к тому же, передатчик расположен в Германии, и Москва находится фактически на самом краю области приёма сигнала. Я прочёл на форумах, что синхронизация таких часов здесь — это вопрос везения, в основном она проходит ночью, когда меньше радиопомех, а ещё желательно жить повыше и иметь окна, обращённые на запад. Так как окна у меня обращены на юг, живу я за пределами Москвы, да ещё и на востоке, и высотой этажа похвастаться не могу, поэтому я оставил эту идею. Интересно, что и в России есть много служб точного времени — RWM, RBU, RTZ, но часов, способных использовать эти службы, я в продаже не обнаружил.

Остался единственный вариант — сделать часы самому. Идея заключается в том, что нужно найти какой-то микрокомпьютер, который умеет подключаться к интернету по wi-fi, по протоколу NTP получать оттуда точное время и показывать его на подключаемом экранчике, отсчитывая секунды самостоятельно до следующего сеанса синхронизации. Так как вычислительной мощности от этого микрокомпьютера не требуется, поэтому такой вариант, как Raspberry Pi, отпадает: здесь нужно что-то более миниатюрное и дешёвое.

Экран должен быть маленьким — всё-таки, я не на вокзал часы делаю. Мне очень нравятся часы на газоразрядных лампах (nixie tubes), которые смотрятся просто великолепно:

Но для моих познаний в электронике собрать такое слишком сложно, к тому же, эти лампы ярко светят и кушают относительно много электричества, да и корпус для такого великолепия нужно делать посерьёзнее, и блок питания нужен какой-то особый, то есть, задача сильно усложняется. Я обнаружил проект часов в интернете, которые мне подошли бы (Nixie Tap), но этот проект уже давно находится в подвешенном состоянии и неизвестно, будет ли он реализован вообще.

В результате, нашёл ровно то, что мне было нужно, на сайте arduinolab.pw, заказал железки, которые там рекомендуют, на AliExpress:

  1. Сам микрокомпьютер: LoLin NodeMcu V3 WIFI IoT development board based on ESP8266 — в районе 200 руб.
  2. Светодиодный дисплей: RobotDyn 4-Digit LED Display Tube, 7-segments, TM1637, 30x14 mm — примерно 100 руб.

Вид готовых часов без корпуса

Питается это хозяйство от стандартного зарядного устройства для телефона с проводом USB-microUSB. Я хотел собрать вариант 2.0, который с часами реального времени, и заказал их тоже, но впоследствии с ними у меня не заработало, к тому же оказалось, что микрокомпьютер прекрасно и сам справляется со счётом секунд. Код я взял на сайте Стива Кемпа, немного изменив его параметры. В частности, там часы синхронизируются с интернет-серверами каждые 5 минут, что безумно часто и так в принципе нехорошо делать, да и ни к чему.

В Правилах предоставления сервиса кластера серверов точного времени pool.ntp.org не рекомендуется синхронизация чаще, чем раз в полчаса, и вообще — чем реже, тем лучше. Я поставил 36 часов (129600 секунд), как там советуют делать, и за этот интервал вообще не заметно, чтобы часы отклонялись от эталонного времени — точность хода прекрасная. В коде также реализована возможность обновлять встроенную программу прямо через wi-fi (ArduinoOTA), но мне так и не удалось её задействовать — может быть, код устарел, да и в данном случае эта функция не очень нужна, в принципе. Прочие технические подробности можно прочитать в моём Карманном справочнике.

В итоге, я получил точнейшие и дешёвые часы, на которых нет ни одной кнопки. Всё, что им нужно — это питание и доступ к интернету через wi-fi. В качестве корпуса я использовал упаковку от велосипедного ремкомплекта, который я отмыл от наклеек и прорезал в нём необходимые отверстия канцелярским ножом.

Часы в сборе

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

Нормализация громкости

Меня всегда интересовало, существуют ли какие-то критерии правильной нормализации громкости аудиодорожек. Ну, что обычно подразумевается под нормализацией, так сказать, в быту? Простой пересчёт пиков до отметки в 0 дБ. Однако, результат чаще всего неудовлетворителен — динамический диапазон, т. е., разница между самым громким и самым тихим звуками вроде бы сохраняется (хотя ещё вопрос, так ли это в действительности при простом пересчёте), но сама по себе общая громкость может не повыситься совсем или повыситься незначительно из-за того, что самые громкие звуки, которых может быть один-два на всю запись, уже нормализованы и их повышать уже некуда, а остальной материал так и остался где-то снизу, и слышно его всё так же плохо.

Понятно, что простая линейная нормализация не подходит и нужна какая-то динамическая (в сочетании с компрессией), причём желательно основанная на каких-то объективных критериях. Последнее время я увлёкся изучением возможностей совершенно прекрасного консольного медиаконвертера ffmpeg, где я обнаружил аудиоплагин loudnorm, как раз занимающийся нормализацией аудиосигнала по стандарту Европейского вещательного союза EBU R128.

Какими основными критериями оперирует loudnorm?

  1. Общая громкость (Integrated loudness), измеряемая в единицах абсолютного значения громкости (Loudness units relative to full scale, LUFS). Общая громкость вычисляется на основании анализа звуковых частот и уровня сигнала, применимое к чувствительности человеческого слуха к ним.
  2. Точный пик сигнала (True peak), измеряемый в децибелах (dB). Это одномоментное наивысшее значение пика сигнала во всём звуковом материале, то есть, грубо говоря, самый громкий звук. По этому критерию как раз и делается линейная нормализация, описанная мной в начале статьи.
  3. Диапазон громкости (Loudness Range, LRA), измеряемый в единицах громкости (Loudness units, LU). Разница между самым громким и самым тихим звуками.
  4. Порог (Threshold). Я до конца не понял, что это за критерий, но вероятно, ниже этого порога сигнал не обрабатывается.

Чтобы повысить качество обработки аудиодорожки, loudnorm предусматривает обработку в два прохода. Первый — сбор данных, второй — непосредственно обработка с параметрами, полученными во время первого прохода. В интернете есть статья автора loudnorm, где он показывает на примере, как это работает. За основу там взят документ американского Сообщества аудиоинженеров AES TD1004.1.15-10 Recommendation for Loudness of Audio Streaming and Network File Playback, где в рекомендациях сказано, что общая громкость (Integrated loudness) не должна быть выше -16 LUFS и ниже -20 LUFS, а максимальный пик (True peak) не должен превышать -1.0 dB.

Что касается диапазона громкости (Loudness Range, LRA), то здесь нужно действовать по ситуации. Я нашёл на сайте AudioKinetic рекомендации по максимальному уровню LRA, там даны примерные значения для разных условий:
- Домашний кинотеатр — 20 единиц - Гостиная — 18 единиц - Кухня — 15 единиц - Гостиная (поздний вечер) — 9 единиц - Общественный транспорт, мобильное устройство — 6 единиц

Чем шумнее вокруг, тем меньший динамический диапазон нужно выставлять, чтобы расслышать все звуки в записи. Чем больше и громче динамики, тем больший LRA возможен. В общем, однозначного критерия здесь быть не может, хотя некоторые значения мы выяснили.

Перейдём, наконец, к практике. Имеется DVD-Video с полукустарно записанным концертом классической музыки, имеющий стандартные проблемы: громкие аплодисменты, тихая музыка и речь ведущей концерта. Графически аудиодорожка выглядит так:

Оригинальная аудиодорожка до обработки loudnorm

Делаем первый проход для сбора данных. Берём среднее значение из рекомендуемых для общей громкости -18 LUFS и рекомендуемый максимальный пик -1.0 dB. Диапазон громкости и порог, как значения неизвестные или приблизительные, пусть высчитываются автоматически.

ffmpeg -i in.wav -af loudnorm=I=-18:TP=-1:print_format=json -f null -

После окончания анализа получаем следующие данные:

[Parsed_loudnorm_0 @ 000000eef2eeea80]
{
"input_i" : "-22.27",
"input_tp" : "0.03",
"input_lra" : "20.10",
"input_thresh" : "-33.99",
"output_i" : "-19.39",
"output_tp" : "-1.00",
"output_lra" : "13.20",
"output_thresh" : "-30.08",
"normalization_type" : "dynamic",
"target_offset" : "1.39"
}

Запускаем второй проход в соответствии с полученными данными. Параметр -ar 48k нужен для сохранения результата в файл с частотой сэмплирования 48000 Гц. Если этого не сделать, то на выходе будет файл с нечеловеческими 192000 Гц. Это преобразование связано с наиболее точным поиском точного пика сигнала (True peak), но полагаю, что в данном случае этим можно пренебречь.

ffmpeg -i in.wav `
-af loudnorm=I=-16:TP=-1:measured_I=-22.27:measured_TP=0.03:measured_LRA=20.10:measured_thresh=-33.99:offset=1.39:print_format=summary `
-ar 48k out.wav

После окончания обработки получаем следующую картину:

[Parsed_loudnorm_0 @ 0000003e678ee8c0]
Input Integrated: -22.3 LUFS
Input True Peak: +0.0 dBTP
Input LRA: 20.1 LU
Input Threshold: -34.0 LUFS

Output Integrated: -16.2 LUFS
Output True Peak: -1.0 dBTP
Output LRA: 13.0 LU
Output Threshold: -26.8 LUFS

Normalization Type: Dynamic
Target Offset: +0.2 LU

Видно, что общая громкость стала на 6,1 выше, несмотря на то, что максимальный пик снизился на единицу, в соответствии с рекомендованным значением. Динамический диапазон стал уже на 7,1 — это привело к более ровному звучанию без резких перепадов громкости, но и сохранило динамику.

Результат обработки в графическом виде:

Обработанная аудиодорожка

Субъективно могу сказать, что стало гораздо лучше. Приведу отрывки из записи, где есть большой перепад громкости.

— - До обработки (—, —)

Upd: Всё же, нужно задавать динамический диапазон вручную, чтобы автомат не зажимал его слишком сильно. В итоге, более-менее универсальные параметры получились следующие: -af loudnorm=I=-16:TP=-1:LRA=18. Если LRA уже узкий, то он обратно не разжимается, насколько я успел заметить.

Красота на работе

Недавно научился прошивать микропрограммы в сетевых устройствах фирмы APC, теперь прошиваю всё, до чего могу дотянуться.

Сегодня на очереди были распределители питания в серверной (говоря проще, это такие длинные «пилоты» для серверных стоек, но только жутко умные, сетевые и с экранчиком).

Было Стало

Наконец-то

Хорошие новости — появились более-менее стабильные сборки Armbian на свежем ядре для моего нового сервера Orange Pi PC 2. Красноглазие продолжается!

First stable test images (CLI or desktop) with a modern #64bit kernel 4.13.5 for H5 based #OrangepiPC2
https://t.co/5LTv523zaS #docker #iot pic.twitter.com/y6KZJkD7ZU
— armbian (@armbian) October 9, 2017

https://twitter.com/armbian/status/917440345880834053

Как я менял батарейки в бесперебойниках

Закупили батареечек для ИБП на работе, последние несколько дней плотно занимаюсь их заменой.

Сначала нужно достать батарейный блок.

Отвинчиваем 8 винтиков, открываем крышку.

Выдёргиваем перемычки, отколупываем самоклеящиеся ножки.

Меняем батарейки, соединяем, наклеиваем ножки обратно.

Блок готов.

Не забываем и об эстетике. Упаковываем старые батареи обратно в коробки, прокладываем шлейф для удобного извлечения.

Упаковываем колпачки от клемм в пакетик.

Куча фантиков от батареек — в отдельной коробке.

Складываем коробки со старыми аккумуляторами в аккуратный штабель.

С большой Симметрой закончили, дальше идём менять батарейки в полуторакиловаттном бесперебойнике. Здесь есть несколько особенностей — батареи приклеены к основанию батарейного блока на двусторонний скотч, и просто так руками выковырять батареи из этого блока невозможно. Приходится брать гаечный ключ из твёрдого металла и, упираясь в боковую часть одной батареи, выкорчёвывать другую, затем наоборот. Также, у клемм есть стопор, который нужно отстёгивать, вклинивая туда тонкую шлицевую отвёртку.

Ну вот, наконец-то работа закончена.

Поеду-ка я домой, пожалуй.