Шура Люберецкий

…и прочих ностальгических консолях:

https://blog.openai.com/gym-retro/

Пишут интересное:

For games that have a sparse reward or require planning more than a few seconds into the future, existing algorithms have a hard time. Many of the games in the Gym Retro dataset have a sparse reward or require planning, so tackling the full dataset will likely require new techniques that have not been developed yet.

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

Раз уж про Market for Lemons вспомнил – надо бы еще написать про дешевое говнище планшеты на Android.

Для начала – необходимый ликбез по поводу графической подсистемы ОС Android, или почему такой параметр, как “разрешение экрана”, для мобильных устройств стал, в первом приближении, почти неактуален. Впрочем, об этом можно догадаться хотя бы по тому, что определяющим “потребительским” параметром давно стала диагональ экрана – а разрешение печатают где-то мелким шрифтом на обороте коробки. Дело в том, что при разработке Android всерьез задумались о том, как одни и те же элементы управления будут выглядеть на экранах с разным разрешением, и приняли важнейшее решение – все размеры отображаемой на экране графики указываются в “условных единицах” dp – density-independent pixels. Один dp равен примерно 1/160 дюйма – или одному пикселю на экране со “средней”, по мнению разработчиков андроидовской графики, плотностью пикселей в 160 точек на дюйм.

Благодаря этому, например, размер “средней” кнопки в интерфейсе любого приложения для Android, равный, согласно рекомендациям для дизайнеров пользовательского интерфейса, 48×48 dp, соответствует примерно 7,62×7,62 мм на экране – независимо от того, планшет это или смартфон, какое у него реальное разрешение экрана, диагональ и так далее. Размеры в dp автоматически масштабируются под экран устройства – для интерфейсов с тачскрином это очень важно.

Когда я работаю в Windows на своем ноутбуке, меня особо не волнует, что где-то внутри операционной системы “прибито гвоздями” предположение о том, что имеющийся у меня экран имеет плотность пикселей 96 точек на дюйм (это соответствует, скажем, 14-дюймовому монитору с разрешением 1024×768 – очень хороший экран для PC середины 90-х; в Mac’ах за несколько лет до того за “стандарт” приняли 72 точки на дюйм, приравняв пиксель на экране к типографскому пункту). На самом деле “мои” 14 дюймов имеют разрешение 1600×900 – это аж 131 точка на дюйм, в полтора раза больше. Разве что когда я пересаживаюсь от “настольного” монитора (22 дюйма, 1920×1080, в точности 100 точек на дюйм) за ноутбучный, первые несколько минут все кажется слишком мелким – но этот эффект довольно быстро проходит. Теоретически, в Windows последних версий есть механизмы, позволяющие настраивать размер элементов управления в зависимости от параметров экрана – но как всегда, они глючные и отягощенные “обратной совместимостью”; заодно большинство нужных мне программ не очень комфортно использовать, когда разрешение экрана по вертикали меньше 900 пикселей (при масштабировании не совпадающих с точками на экране).

Но в отличии от Windows с управлением мышкой или подобными устройствами ввода, в Android повсеместно используются тачскрины – и объяснять пользователю, что вместе с новым телефоном, оснащенным экраном офигенно высокого разрешения, ему понадобятся пальцы в полтора раза тоньше, никто особо не хочет. Поэтому в любое устройство на Android среди прочих параметров системы “зашивается” плотность пикселей экрана – это значение позволяет пересчитывать из dp в реальные точки на экране.

Например, экран с разрешением 1920×1080 в устройстве с Android вполне может иметь диагональ, скажем, 10, 7 и 5 дюймов – это будет, соответственно, 220, 320 и 440 точек на дюйм – и один dp в операционной системе будет равен 1,375, 2 или 2,75 пикселям на экране. Заодно замечу, что “средняя” на момент разработки первых версий Android плотность пикселей, равная 160 точкам на дюйм, сегодня оказывается довольно днищенской – сложно найти приличное устройство с таким экраном.

Все вроде бы хорошо и логично – но ровно до тех пор, пока прошивки под эти самые планшеты не начинают делать китайцы. Уже не первый раз сталкиваюсь с тем, что на, к примеру, десятидюймовом планшете “прошито” количество пикселей на дюйм, соответствующее в лучшем случае семи-, а то и пятидюймовому экрану. Да, главный экран там выглядит довольно симпатично, значки крупные, все красиво – но стоит лишь запустить какую-то программу – и на большом десятидюймовом экране появляется интерфейс, рассчитанный под смартфон.

В чем причина? Китайцы предпочитают вообще не заморачиваться с тем, для какого именно устройства они делают “сборку” Android. Пофигу, телефон ли это или планшет – плотность пикселей установят такую же, какая работала в прошлый раз. То, что интерфейс некоторых программ превращается в убогую “телефонную” версию – авось никто и не заметит.

В подобном были замечены многие из китайских производителей – в том числе и вроде бы приличные, а не какой-то noname с aliexpress.

Для начала – вводная: в соответствии с Указом Президента России № 202 от 9 мая 2017 г. в Волгограде, Екатеринбурге, Казани, Калининграде, Москве, Нижнем Новгороде, Ростове-на-Дону, Самаре, Санкт-Петербурге, Саранске и Сочи в период с 25 мая по 25 июля 2018 года будут, в частности, запрещены оборот и ношение гражданского и служебного оружия и патронов к нему. Если вы думаете, что лично вас это никак не коснется – все равно проверьте, не завалялся ли у вас где, скажем, газовый баллончик, “пневматика” или “травмат”, можно очень серьезно “попасть”. Подробнее об этом написал sanches на “Лайфе”:

https://life.ru/t/%D0%BE%D1%80%D1%83%D0%B6%D0%B8%D0%B5/1119694/proshchai_oruzhiie_chiegho_stoit_opasatsia_vladieltsam_ghazovykh_ballonchikov_i__shokierov

Я же расскажу о другом – сегодня в электричке я увидел рекламу МР-512С – версии “мурки” с уменьшенной до 3 Дж дульной энергией. Обычная МР-512 без буковок имеет дульную энергию 7,5 Дж (то есть является пневматическим оружием, но продается вообще без лицензии), либо с буковкой М имеет дульную энергию аж 25 Дж (пневматическое охотничье оружие, нужна лицензия). Здесь же рекламируется “конструктивно сходное с оружием” изделие – фактически, игрушка, на которую действие 202 указа не распространяется. Реклама красивая, со слоганом “Открой сезон дачного биатлона” или как-то так.

А теперь следите за руками – даже если очень захотеть пострелять из “пневматики” по пивным банкам, то ближайшие два месяца купить что-то из “безлицензионного”, с дульной энергией до 7,5 Дж, все равно не удастся (ни один магазин не будет рисковать лицензией). Остаются только “конструктивно схожие с оружием изделия” с дульной энергией до 3 Дж – та самая МР-512С. Заодно “Калашников” бьет ценой – предлагая самую “нищенскую” версию всего за 4000 рублей. В общем, “мурка” этим летом превращается в хит на рынке дешевой “пневматики”.

Китайская бумага для ЛУТ – для тех, кому надоела глянцевая из журналов. Печатать надо на “блестящей” стороне, процесс “переноса” – точно такой же, как обычно (китайцы пишут, что надо использовать ламинатор – но и утюгом получается приемлемо). Главное отличие – легко отделяется, не требуя “оттирания” пальцем (хотя намочить все-таки желательно). Пачка из 10 листов A4 стоит 80 рублей, в моем случае китайцы обсчитались и прислали 20 – но слегка мятых. Возможно, имеет смысл отрезать кусочки и приклеивать их при печати на “подложку” из обычной бумаги.

Пленочные трафареты OSH Stencils – приемлемо, но в целом не очень аккуратно – в паре мест на довольно простом трафарете из серии “AtMega и два резистора” есть дефекты, правда, особо ни на что не влияющие. “Мостики” между площадками с шагом 0,8 мм получились какие-то уж очень тонкие (может, конечно, это косяк моего проекта – но надо записать в блокнотик что-то типа “не забыть проверить припуск маски и трафарета”). Везут из Штатов, самый экономичный вариант – трекающийся до Домодедово (или что там у вас ближе) USPS First Class w/Tracking (и тут наврали!). Минимальный заказ мне обошелся в 8,45 $ (чуть больше 500 рублей) – что, конечно, дешевле Резонита (там аналогичный заказ обошелся бы в 2000 рублей за подготовку производства, что-то около 100 рублей за сам трафарет и 400 рублей доставка – итого 2500 рублей). Стальной трафарет аналогичных размеров у этих товарищей стоил бы около 18 долларов – то есть уже 1100 рублей. В общем, интересно для всякой мелочевки, не критичной ко времени.

А вот как в 2018 году кошерно запитывать всякие автомобильные приблуды на микроконтролерах? Мне знакомы два варианта.

Первый, быдлячий: использовать линейный стабилизатор напряжения наподобие 78L05 или КР142ЕН5А, что примерно одно и то же. Достоинства – дешево и крайне тупо, недостатков же куда больше. При потреблении хотя бы в 0,1 А линейный стабилизатор должен рассеивать 0,9 Вт – то есть работать практически в режиме печки. Не очень ясно поведение “кренки” и при характерных “автомобильных” особенностях входного напряжения. Успокаивать себя словами “вон в терратрипе стоит и ничего” не получается – видели бы вы тот терратрип :)

Вариант второй – заморочиться и вкорячить импульсный преобразователь. Их выпускается довольно много, и при желании они позволяют вписаться в довольно скромные габариты (скажем, LM53601 вполне официально занимает всего лишь 11,2×12,7 мм со всей обвязкой – правда, и стоит в Москве от 441 рубля в розницу). Более дешевый и распространенный вариант – MC34063A (10-30 рублей в зависимости от объема партии), к сожалению, требующая гораздо более габаритной обвязки. Это сложно назвать проблемой – но когда размеры устройства определяются блоком питания, возникает ощущение, что что-то здесь не так.

Короче говоря – а подскажите какой-нибудь DC/DC преобразователь со следующими параметрами:

- входное напряжение 8-24 В (можно более широкий диапазон);
- выходное напряжение 3,3 В;
- выходной ток 500 мА;
- цена с минимально необходимой обвязкой в пределах 100 рублей в московской рознице;
- габариты “готового” БП по возможности меньше.

Ну или объясните убедительно, что можно не выпендриваться и ставить те же “кренки”.

UPD Во всяких Январях и прочих Микасах никто не стесняется ставить обычные линейные стабилизаторы – так и буду поступать в не особо потребляющих устройствах.

Раз уж последние записи у меня – про connected car и тому подобную ерунду – то вспомнился такой вот эпизод. Я как-то признался, что пробовал писать параметры от электронного блока управления двигателя в файл формата EDF, который обычно используется для всякого рода измерений в биологии и медицине. Нет, ну никто же не запрещает в поле Patient’s name написать GAZ-3111? В остальном же формат прекрасно подходит для 8- и 16-битных данных от ЭБУ (их туда можно писать вообще почти без обработки). Меня, правда, за это назвали извращенцем – ну что ж, бывает.

А вот недавно приспичило мне поискать первоисточник фразы о том, что команда McLaren “в течение одной гонки получает около 750 миллионов цифр от своего гоночного болида”. Взята она, как оказалось, из русского перевода выступления исполнительного директора фирмы McLaren Electronics Питера ван Манена на TED и целиком звучит так:

We’re logging about 500 different parameters within the data systems, about 13,000 health parameters and events to say when things are not working the way they should do, and we’re sending that data back to the garage using telemetry at a rate of two to four megabits per second. So during a two-hour race, each car will be sending 750 million numbers.

Замечу, что переводчики здесь накосячили, переведя numbers, как “цифры”. Речь, скорее всего, идет о 32- или 16-битных числах, получаемых от датчиков.

Меня, как известного извращенца (см. выше) заинтересовала содержательная часть выступления ван Манена – где он рассказывает, что цинично пытаясь казаться хорошими McLaren Electronics установила систему, похожую на формульную телеметрию, в детской больнице Бирмингема, сумела намерить что-то хорошее, и в целом даже кому-то помогла.

Так вот – что является бОльшим извращением – использовать для записи параметров “автомобильной” телеметрии формат, изначально предназначенный для записи физиологических параметров, или использовать для регистрации физиологических параметров автомобильную систему телеметрии?

Редкая дискуссия про повсеместную “уберизацию” обходится без хотя бы опосредованной ссылки на статью “Market for Lemons” Джорджа Акерлофа (который за нее удостоился аж Нобелевской премии по экономике), приведенной скептиками. “Автомобилисты” слышали про нее с довольно большой вероятностью – на примере рынка подержанных автомобилей показывается, что при некоторых условиях (основное из них – продавец знает о качестве товара больше, чем покупатель) рынок чего угодно скатывается в продажу дешевого говна. Русский перевод и краткий пересказ в Википедии – к вашим услугам.

Вот интересно – верно ли такое следствие: “рынок любых технически сложных товаров/услуг скатывается в продажу говна?” Мне кажется, что да.

Вот приходит мне иногда спам – мол, хватит кормить автосервисы, купите у нас чудесный диагностический адаптер (банальный китайский ELM327) и не заморачивайтесь с ремонтом авто! Как человек, знающий, чем ДМРВ отличается от BDSM, я в это все сразу не верю. Даже если зайти на сайт продавцов чудодейственного устройства – то он буквально кричит “не покупайте это говно!”. Признаки лохотрона, разумеется, элементарные. Если вас хотят надурить – то попадете вы на классическую страничку-лендинг, сделанную прямо по учебнику “Landing page for dummies”.

Впрочем, “товарный бизнес”, заключающийся в перепродаже лохам китайского дерьма с алиэкспресса – это ерунда. Вот некие чуваки придумали аж целый стартап на основе примерно той же идеи – в разъем OBD-II, присутствующий во всех более-менее современных автомобилях, втыкается чудо-коробочка, “считывает ошибки”, и через мобильное приложение записывает в ближайший автосервис, предложивший наименьшую стоимость ремонта. Вам уже смешно? Но идея настолько поразила отечественного блоггера gorynych1, что он написал длинный текст с многозначительными выводами о том, что наконец-то паразитам из автосервисов придется поумерить аппетит:

https://gorynych1.livejournal.com/207768.html

В комменты пришел настоящий автомеханик ploughlike_elk и немного покритиковал идею, заодно, правда, немного перейдя на личность автора поста:

https://gorynych1.livejournal.com/207768.html?thread=1910168#t1910168

Если хочется больше подробностей – то вот тот же ploughlike_elk расписывает, как соотносятся “ошибка”, прочитанная диагностическим сканером, и возможная стоимость устранения неисправности (спойлер: никак):

https://ploughlike-elk.livejournal.com/356963.html

Горыныч немного бомбанул и расписался аж четырьмя записями, где прогнозировал счастье человечества и кабздец нехорошим автомеханикам, в особенности лж-юзеру ploughlike_elk:

https://gorynych1.livejournal.com/208825.html
https://gorynych1.livejournal.com/208945.html
https://gorynych1.livejournal.com/209339.html
https://gorynych1.livejournal.com/209820.html

В конце концов, правда, он, по ЖЖшным меркам, слил дискуссию, забанив канадского автомеханика после набега сочувствующих.

PS Особенно хороши, конечно, измышления Горыныча про Wrench – службу “выездных автомехаников”. Сервис, хочу заметить, не первый, и даже не единственный – но и как все аналоги, отнюдь не совершивший революции в деле авторемонта.

Делаю сейчас одно устройство, в котором используется так называемая K-линия – немного напоминающий UART автомобильный диагностический интерфейс (он же ISO 9141). Преобразователей из K-линии в UART и подобные интерфейсы (тот же RS232) придумано довольно много, мне лично нравится вариант на логической микросхеме. Из обвязки нужно всего лишь два резистора, диод и транзистор, а стоимость деталей в чип-и-диповской рознице – менее 50 рублей (особенно, если не гнаться за какими-нибудь низковольтными вариантами логики), а “оптом” – думаю, упадет рублей до 10-15.

Для состоятельных парней выпускаются специализированные микросхемы – всякие MC33199, MC33290, L9637, или более актуальная (то есть еще встречающаяся в продаже) Si9243 – внутри там примерно то же самое, только в корпусе SOIC-8. В розницу эта микросхема стоит около 70 рублей, оптовая цена опускается до 40.

А теперь следите за руками – специализированная микросхема оказывается выгоднее, если к стоимости компонентов добавить стоимость монтажа. В случае с решением “на логике” мы имеем 22 точки пайки, а на специализированной микросхеме – всего 8. Стоимость ручного (точнее, “полуавтоматического”) монтажа – что-то порядка 2-3 рублей за точку пайки – и 14 “лишних” точек съедят всю экономию.

Конечно, стоимость “одного транзистора” или “одного соединения” в виде дискретного элемента или в составе микросхемы, отличающиеся порой на несколько порядков, приведены в любой книжке – но как-то об этом не задумываешься, пока не столкнешься “вживую”.

PS А заодно можно сделать вывод, что “узкоспециализированная” микросхема более выгодна и для производителя, чем “универсальная” стандартная логика – себестоимость их производства одинакова, а вот продать первую можно значительно дороже.

Православно ли использовать ладан вместо канифоли при пайке?

vitus_wagner подкинул ссылку на MIT-овскую статью по модной теме беспилотных автомобилей. Анонс – “В MIT разработали систему, которая позволяет беспилотным автомобилям ездить по сельским дорогам без точной карты” – не очень точно отражает суть работы. Системы типа nVidia DAVE2, довольно простые в реализации (у меня есть даже подборочка материалов по теме) точно так же могут вертеть рулем в нужном направлении, и для своей работы требуют только видеокамеру, смотрящую вперед – данные от GPS и карта там необязательны.

Что отличает эту систему от “нейросетевого” подхода – даже не детерминированность, пусть даже она и приятна (есть несколько публикаций, показывающих, что нейросеть по образцу сделанной в nVidia “сходит с ума” при некоторых манипуляциях с картинкой – вплоть до того, что пытается повернуть совсем в другую сторону, если изменить в картинке на входе всего один пиксель). Внимательно попробуйте осознать описание DAVE2 – эта система определяет угол поворота руля, исходя из картинки, которую видит перед собой “водитель”. Но… Посмотрите на эту схему, в том или ином виде присутствующую в любом вводном материале про спортивное или “экстремальное” вождение:

Три траектории, изображенные здесь – это три разных способа прохождения одного и того же поворота, в той или иной степени “хорошие” (в зависимости, конечно, от прочих факторов). Для наглядности изображена “шпилька” – поворот на 180°, но вся та же теория остается верной и в том случае, если угол будет другим. “Осознанное” управление автомобилем предполагает, что водитель, подъезжая к повороту (из левого нижнего угла картинки), определит точку поворота руля и точку апекса – и, соответственно, траекторию в повороте. Но обратите внимание, что видимая картинка при приближении к повороту во всех трех случаях одинакова – так что система, полагающаяся в своем принятии решений только на текущий видеокадр, очевидно будет неспособна “выбирать” траекторию. Обратите внимание на то, как в ролике nVidia нейросеть “крутит” руль, дергая его туда-сюда (примерно на 7:32):

А представьте, если это будет происходить не на сухой дороге и не на смешной скорости, а в гололед? На небольшой скорости, имея отличный “запас” сцепления шин с дорогой, можно позволить себе игнорировать “физику” движения автомобиля – что и делают сейчас последователи nVidia. Если же дорожные условия становятся чуть более сложными – то так можно оказаться и в кювете.

Так вот, важнейшее, на мой взгляд, новшество в подходе MIT – это определение траектории, исходя из конфигурации дороги. Границы дорожного полотна их система определяет с помощью лидара, сканирующего пространство вокруг автомобиля с частотой 5 раз в секунду. Затем строится “локальная” траектория (довольно примитивным, правда, образом – ровно посередине между левой и правой обочинами “вписывается” сплайн, то есть достаточно гладкая кривая), и до очередного обновления автомобиль движется по этой траектории. Никто, в общем, не мешает “вписывать” траекторию и более “правильным” образом – скажем, между правой обочиной и серединой дороги, как предписывают ПДД.

Заметьте, насколько это отличается от подхода “авось нейросеть научится” :)

Открыл для себя творчество группы Orfeus. Венгры играют весьма бодрый power metal и поют на своем инопланетном языке аж с 1988 года. От выступления на венгерском телевидении в 1993 году пустил слезу – но несмотря на колхозный вид, уже тогда играли здорово:

Группа существует и сейчас, изредка записывает альбомы (Metal Archives знает о трех), и в целом выглядит достойно.

А то в предыдущей записи слишком многа букв :)

Столкнулся с небольшим багом в примерах к микроконтролеру CC3200 (ARM Cortex-M4 + WiFi). Если в многозадачной системе поменять настройки WiFi (они пишутся в подключенную к микроконтролеру флешку), а затем перезапустить сопроцессор WiFi (для применения новых настроек) способом, указанным во всех примерах, можно получить полностью неработоспособный WiFi – настройки не успевают записаться (ну вот так мне показалось – особо в подробности не вдавался). Решение очевидное – небольшая пауза при перезапуске. Я озвучил его на форуме техподдержки коллеге по несчастью 26 апреля в 1:25 PM по форумному времени – а ровно через три с половиной часа сотрудник техподдержки предложил то же самое в соседней теме.

Закон парных случаев?

Для начала – о том, как делать не надо. Вот представьте, что вам надо сохранять в какой-нибудь базе данных показания каких-нибудь датчиков, чтобы потом показывать их в модном веб-приложении. Вы уже хотите написать что-то в таком духе?

CREATE TABLE measurements (
    measurementID int NOT NULL AUTO_INCREMENT,
    sensorID int NOT NULL,
    time datetime NOT NULL,
    value double NOT NULL,
    PRIMARY KEY (measurementID)
)

Это очевидно неправильно – имел удовольствие несколько лет подряд наблюдать за эволюцией небольшой SCADA-системы, где хранение данных организовали примерно так. Пока датчиков было немного – оно работало, но примерно на сотне-другой обновляющихся примерно раз в 5-10 секунд датчиков потребовало для работы некоторых костылей. Для начала – в БД перестали записывать “небольшие” изменения данных – скажем, меньше 5% (величина была выбрана довольно произвольно – не надо спрашивать, соответствует ли такой подход требованиям технического задания :) ) от предыдущего сохраненного значения. Затем – по мере накопления данных соорудили чудовищную систему из триггеров и хранимых процедур, которая автоматически создавала “архивные” таблицы сравнительно небольшого размера. Впоследствии, конечно же, выяснилось, что эта система временами глючит и иногда новую таблицу для архива надо создавать вручную.

Наконец, на одном из объектов в дополнение к привычным “медленным” газоанализаторам поставили два десятка акселерометров – и тут все повалилось уже серьезно. Во-первых… нет, для начала в нулевых. Не надо говорить мне, что datetime в SQL неспособен хранить данные с “разрешением” меньше секунды, а опрашиваемый раз в секунду акселерометр бесполезен – тут речь шла уже о том, чтобы записать в базу хоть что-то. А теперь во-первых – показания акселерометров меняются сравнительно быстро и под фильтр “небольших” изменений данных не подпадают, и во-вторых – отказы БД стали чуть ли не ежесуточными. Считайте сами – в сутках 86400 секунд, и при двух десятках пишущих что-то датчиков мы влегкую получаем 1,7 миллиона записей в сутки. Да, часть из них отфильтруется – но и миллиона строк хватит, чтобы популярные СУБД с SQL хорошо и надежно “легли”.

Признаться, я списывал многое из этих проблем на невысокую квалификацию разработчиков этой системы, но после доклада Сергея Аксенова “Антипаттерны разработки программных комплексов для интернета вещей” на Inothings++ понял, насколько героические люди используют SQL для хранения такого рода данных. Про выбор СУБД в видео – с 4:28:

Идея понятна – реляционные СУБД расчитаны на количество строк порядка миллионов (десятков миллионов – если у вас поблизости есть грамотный администратор баз данных), а как легко посчитать – это всего лишь суточный архив сравнительно небольшой системы. Впрочем, случай “Стрижа” еще более-менее прост – частота опроса каких-нибудь ЖКХшных счетчиков относительно небольшая, всего несколько раз в сутки. А что делать, если хочется хранить, скажем, данные по 16 каналам АЦП с небольшой в общем-то частотой дискретизации в 16 тысяч выборок в секунду? Нет, я прекрасно представляю, как это сделать “на файлах”, и это совсем не сложно – простенький формат хранения данных можно полностью реализовать за неделю неспешной работы (собственно, что-то наподобие edflib, но работающее на микроконтролере с сотней килобайт памяти я написал в прошлом году где-то за несколько дней):

Implementing EDF takes a week. EDF+ takes a few weeks but is better and more powerfull. If you still decide to start with EDF, it is wise to adopt the 12 simple additional EDF+ specs.

Не смотрите, что он предназначен для записи всяких физиологических данных – я в таком виде пробовал всякие обороты двигателя, расход воздуха и прочее время впрыска записывать, они в этот формат прекрасно вписываются :)

Еще из полезного чтения – статья Luca Deri о системе, названной им tsdb – построенной поверх Berkeley DB системе, обеспечивающей хранение миллионов (!) временнЫх рядов (time series – собственно, это общее название для такого рода данных). Решение не совсем подходящее для моего случая – но опять же содержащее несколько полезных идей.

Для начала – система, многократно превосходящая по производительности решения на основе SQL, реализована всего лишь в 1000 или около того строк кода на Си. Именно это и вдохновило меня на написание собственного решения – 1000 строк это совсем немного, а следовательно, должно быть довольно просто. Второе – данные желательно каким-либо образом объединять – если в tsdb это сделано довольно произвольным образом (в базе много редко обновляемых временных рядов), то в моем случае я просто решил писать “секундные” (или соответствующие какой-то доле секунды) записи, как в EDF.

В общем, осознав эти “три источника и три составные части”, я взял пивка и засел за Visual Studio – и примерно за вечер написал прототип базы данных, оптимизированной под мои требования – десятки-сотни одновременно записываемых временных рядов с частотой дискретизации от единиц до тысяч Гц. Собственно, по факту получился тот же EDF, только записанный в Berkeley DB. Выбор довольно произвольный (прежде всего – ее используют в tsdb) – но эта, так сказать, “встраиваемая СУБД” поразила меня своей простотой. Немного не радует лицензия – хотя при желании могу выложить код на какой-нибудь гитхаб для очистки совести.

Что могу сказать? Не прилагая никаких усилий в части оптимизации, на собственном ноутбуке я “из коробки” получил скорость записи в базу данных около 40-50 Мбит/с (похоже, упираясь в производительность жесткого диска) – причем, судя по всему, падения производительности с ростом числа записей в БД не происходит. Например, в БД размером около 11,5 Гб – это чуть меньше 1,5 миллионов записей по 8 килобайт (в каждой из записей – по 4000 “точек”, каждая из которых – двухбайтовое целое) никакого снижения скорости записи или чтения я не наблюдал (дальше просто стало жалко жесткий диск). Что забавно – тесты “на чтение” демонстрируют полезность кеширования – сначала 10 000 записей читаются за долгие 8 секунд, а затем, если повторить тот же тест “не отходя от кассы” – за 0,22 секунды. Не видел бы – не поверил.

Графики рисовать не буду – там при моих объемах записей в основном почти прямые линии. Возможно, что производительность и деградирует на больших объемах данных – но мне лень расходовать на проверку этого десятки гигабайт.

PS А если вам все же нравится SQL – почитайте, как правильно организовывать хранение time series в реляционной БД:

https://blog.timescale.com/time-series-data-why-and-how-to-use-a-relational-database-instead-of-nosql-d0cd6975e87c

И все-таки хочу напомнить, что решение “на коленке” практически не уступает приведенному в статье по ссылке в плане производительности (и да, надо бы проверить его с четырехгигабайтным кешем :) ).

…что на внутренней стороне коробочки с Intel Edison изображен боевой беспилотник MQ-9 Reaper:

Кажется, в детской практически книжке Борисова переход от картинок к условным обозначениям радиодеталей происходил где-то на десятой странице, непосредственно после решения вопроса “где достать детали для детекторного приемника”. Тем более удивительным мне представляется, что на популярных сайтах “про Ардуино” вместо простой и практически очевидной принципиальной схемы оперируют вот такими красивыми картинками с одним лишь недостатком – понять, что же здесь изображено, весьма затруднительно.

Выложили фотографии остатков американских “Томагавков”. В мятых железках я не особо понимаю, а вот что касается электроники – интересно, куда делись многочисленные эксперты, которые ставили диагноз по фотографиям “черного ящика” Су-24?

По на водке Биссо Атанасова – заходим на сайт “Таманской винной компании” (страна должна знать своих героев!), прокручиваем страничку донизу и видим сделанные безвестным веб-дизайнером “счетчики”, сообщающие нам, что с 480 га виноградников “компания” умудряется получить 82 984 320 литров вина в год и разлить их в 55 000 000 бутылок.

Делим одно на другое – хрен с ними, с бутылками по полтора литра (объем стандартной винной бутылки вдвое меньше, если что) – но вот урожайность в 1729 гектолитров с гектара, на порядок больше “нормальной” заслуживала бы нобелевской премии по биологии.

Вывод из этого довольно простой – “Таманская винная компания” в основном занимается розливом привозного “виноматериала” не самого высокого качества. Заходим на том же сайте в раздел “Каталог” и запоминаем – это так называемое “вино” брать не стоит.

Как известно, в своем крестовом походе против Телеграма Роскомнадзор придерживается тактики РВСН – “точность попадания компенсируется мощностью заряда”. Телеграм, говорят, пока не накрыли, а вот подсеть, через которую работает гугловская баннерокрутилка, заблокировали надежно.

Надо бы в качестве ответки на американские санкции включить Adblock на государственном уровне. Будет достаточно ассиметрично, а заодно – приятно.

Хочу поделиться впечатлениями от сборки и использования контролера печки для пайки оплавлением по мотивам описанного Олегом Артамоновым – собственно, это будет большой и развернутый комментарий к статье по ссылке:

http://olegart.ru/wordpress/reflow-soldering/

Собственно, такой девайс понадобился мне для сборки относительно “серийных” изделий – но что значит “серийных”? Скажем, “серые коробочки” для любительского и ретро-ралли разошлись уже тиражом в несколько десятков штук – правда, в процессе проектирования находится более продвинутый вариант. Пайка вручную даже пяти AtMega, пусть даже в “человеческом” корпусе с шагом выводов 0,8 мм – занятие малоинтересное по определению. В общем, запаивая к новому сезону очередную “партию” коробочек, я задумался – а нельзя ли как-то упростить это дело?

Вариант с заказом производства в том же “Резоните” я не расмматривал – во-первых, стыдно заказывать изготовление штучных партий устройств, где всех деталей – AtMega, пара резисторов и оптопара, во-вторых – это получалось относительно дорого (в частности, стоимость “подготовки производства” в 3000 рублей, даже будучи “размазанной” на партию в десяток изделий, все равно оказывалась в числе значимых статей расходов). Наверное, 3000 можно потратить как-то иначе – например, вот на такую печку.

В принципе, вариантов переделки электродуховки в печку для пайки довольно много, но иностранцы почему-то не склонны к экономии в такого рода проектах. Например, зачем-то они используют твердотельные реле – да, это стильно, модно и молодежно, но одновременно – довольно дорого (раза в два дороже “дискретных” тиристора и оптопары). Зачастую используют готовые контролеры типа Controleo – да, с ним вся переделка печки сводится к правильному подключению проводов, но сам контролер стоит совершенно неприличных денег (да, силовой части в нем нет, придется городить несколько твердотельных реле и блок питания, а это дополнительные расходы). Короче говоря, контролер за авторством Олега Артамонова показался мне более приближенным к российским реалиям – с легкодоставаемыми компонентами (все есть в Чип-и-Дипе и Терраэлектронике) и в целом доступный для повторения.

Сама электродуховка “для опытов” досталась мне бесплатно, будучи вытащенной из лежащего на балконе хлама. Подходящие дешевые печки стоят “в магазине” что-то около 2000-3000 рублей, б/у можно найти либо в собственном хламовнике (бесплатно), либо на каком-нибудь авито (недорого).

Плату устройства я немного переделал – во-первых, заменил SMD-шные резисторы и конденсаторы на выводные (просто их у меня много, да и паять вручную кучу SMD совсем неинтересно), во-вторых, сделал ее односторонней с несколькими перемычками на верхнем слое – для изготовления по “лазерно-утюговой” технологии (кстати, переход с SMD на выводные детали это дело значительно упрощает). Заодно выкинул “лишнее” – например, USB-порт и реле. Избавившись от USB, можно было бы попробовать и заменить микроконтролер на более дешевый – как выясняется, прошивка с ампутированным обменом по USB прекрасно влезет и в AtMega8, но я понадеялся, что получится использовать готовую прошивку без доработок. Забегая вперед, скажу – они понадобились, в первую очередь из-за того, что в выкидывании всякого ненужного барахла я немного поторопился и избавился от термодатчика TMP37.

Заодно я поменял габариты платы, рассчитывая вписать ее в корпус Gainta G767 (я придерживаюсь той точки зрения, что проектируя печатную плату – надо сразу задуматься, в какой корпус ее поставить) – но с этим облажался по-крупному. Конечно, надо было сначала купить этот корпус и промерить его “по месту” – но я понадеялся на чертеж и лоханулся с размерами. Вот какое там расстояние между крепежными отверстиями для платы? Я подумал, что в чертеже ошибка – но нет, кто-то додумался указать расстояние именно между этими двумя точками. Интересно, каким инструментом его можно замерить? Добавлю еще, что вычислить расстояние между крепежными отверстиями возможно лишь в том случае, если известны диаметры стоек.

Еще из моей лажи – я не сразу заметил, что несмотря на то, что дисплеи Winstar WH1602A (самый дешевый в продаже) и WH1602J (а этот использован в схеме) имеют очень похожие разъемы, назначение выводов в этих разъемах совсем разное – и после того, как я просто припаял дисплей к плате на “гребенке” и долго выяснял, почему он не работает, мне все равно пришлось сидеть и долго запаивать проводочки :)

Довольно важный вопрос, почему-то обойденный стороной в описании на сайте Олега – калибровка датчика температуры. Судя по всему, в ранних прошивках она была жестко зашита в контролер – а в выложенной на сайте версии прошивки появилась возможность немного варьировать параметры. К сожалению, описания этого процесса либо нет, либо оно погибло вместе с сайтом fclab.ru – так что кратенько прокомментирую, что нужно сделать. Используемая в устройстве термопара типа K (как в мультиметрах) имеет практически линейную характеристику в интересующем нас диапазоне от +25 до +250 °С – поэтому в EEPROM микроконтролера прошиваются два 16-битных числа, первое из которых для термопары равно 31 (расчет этого коэффициента можно увидеть в файле thcouple.c в исходниках прошивки) – и без особой необходимости менять его не надо. Второе число задает сдвиг шкалы – в единицах, равных 1/4 °С. Например, значение -100 увеличит показания температуры на 25 °C, а 100 – напротив, уменьшит их на ту же величину. Так как я выкинул термодатчик, показания которого принимались за температуру холодного спая термопары, пришлось записать в эту ячейку памяти -100 – приняв “комнатную температуру” за 25 °C. Конечно, можно было бы сделать и лучше – но, как показала практика, и так нормально. Показания прибора, когда термопара засунута в чайник с кипящей водой – около 96-97 °С, что можно считать более-менее приемлемым. Так как я выкинул дополнительный термодатчик, пришлось все-таки поставить WinAVR и добавить в прошивку обнуление показаний канала АЦП, к которому тот был подключен – иначе “градусник” начинал безбожно врать.

Да, еще один волнующий многих вопрос по поводу прошивки – какие использовать значения fuse. В принципе, все написано и в тексте – но чтобы не вдумываться в фразы типа “в конфигурации отключены DIV8, JTAGEN и HWBEN” – приведу здесь значения, которые мне подсказал “AVR fuses calculator” – L=0xDE, H=0xDD, E=0xCF.

Больше, наверное, никаких проблем и не возникло – ну разве что внезапно выяснилось, что в Москве проблематично недорого купить термопару – имеющаяся у меня термопара от мультиметра в металлическом корпусе оказалась довольно инерционной в показаниях, а провод явно пованивал при нагреве до 250 °C. Да, в некоторых магазинах (Промэлектроника, например) термопары типа K можно купить рублей за 100 – но только не в том случае, если такое желание внезапно возникло в пятницу в конце рабочего дня. В общем, проще и дешевле всего оказалось купить в Юлмарте самый дешманский мультиметр модели 838 (кстати, сравнив его со своим десятилетней давности Mastech 830, я просто офигел, насколько деградировали дешманские мультиметры). Заодно мне достались два разъема-”банана” – термопару я подключил проводками к клеммной колодке.

С учетом покупки мультиметра бюджет проекта составил примерно те самые 3000 рублей, которые жаба не позволила тратить на “подготовку производства” в Резоните – и надо сказать, что я в целом остался доволен – даже нанося паяльную пасту (я взял на пробу Multicore CR36) вручную из шприца (медицинского, с обрезанной толстой иглой), удалось добиться вполне приемлемого количества брака (прежде всего слипшихся ножек на микросхемах с малым шагом – это исправляется с помощью паяльника и “оплетки для выпайки”). Но главное – это скорость монтажа, нанести пасту, расставить детали и сунуть несколько плат в печку получается намного быстрее, чем в случае, когда все надо запаивать вручную. Надо бы попробовать нанести паяльную пасту через трафарет – я, конечно, попробовал вырезать какое-то подобие трафарета из прозрачной пленки, но ножом это делать неудобно, и те же ножки микроконтролера я объединил в одну широкую прорезь – замыканий получается меньше, чем при ручном нанесении, но все равно они иногда случаются.

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