Я прошлый раз, намучившись с распайкой элементов на прототипе системы сбора термомониторинга ГЗ БТА, грешил на то, что при нагреве стеклотекстолит расширяется, а после остывания опять сжимается, в результате чего изображение получается мельче!
Не тут-то было!!! Решил сегодня точно это проверить. Перевел на пробный кусок калибровочную сетку. Масштаб получился 1-в-1 — сколько на сетке, ровно столько же и на стеклотекстолите. А вот на сетке масштаб совершенно не совпадал с исходным. Оказалось, что принтер при печати уменьшает изображение, да еще и неравномерно: чтобы сохранить верный масштаб, перед печатью нужно по Y увеличить изображение в 1.042 раз, а по X — в 1.048 раз!
Вот такое западло. Пока я ЛУТил всякую мелочевку, где не было "многоножек", проблемы не замечал.

Вот так-то! Доверяй принтеру, но проверяй, не масштабирует ли эта зараза при печати!
Потихоньку решил сделать standalone управлялку FLI'шными ПЗСками, турелями и фокусерами. Сделал поверхностный рефакторинг "mytakepic", пока только ПЗС управляет. Решил отдельную репу не делать, а положить в тот же mytekepic отдельной директорией. Словил сегодня утром kernel panic — видимо, модуль ядра, который я в виртуалбоксе для новых ядер портировал, на компутере забыл обновить. Поставил его в автозагрузку на всякий случай.
Помимо старых функций добавил еще возможность открывать/закрывать затвор (нужная функция) и задавать старт экспозиции по внешнему триггеру. Пришлось, правда, еще и в исходниках библиотеки поковыряться: документация к ней совсем уж унылая. Очень хочется сделать в userspace, но лень.
Переписывать написанный в 2005 году модуль ядра под 4.12!
Вот такие засранцы эти FLI. Не понимаю, как в других обсерваториях с их продукцией работают. Неужели выделяют специальный старый компьютер с ядром 2.6?
Но Линус сотоварищи тоже хороши. Мало того, что поля различных структур претерпели за это время значительное изменение, так еще и API радикальным образом исковеркали: то аргументов другое количество, то функция по-другому именуется, то ее вообще нет...
Обновляю генту на подопытной машине. Приходится периодически бегать в противоположный конец коридора, чтобы смотреть, как там дела. Перезапуск sshd ни к чему не приводит — безо всяких ошибок перезапускается, ps показывает, что все ОК, а с рабочего компьютера соединения нет. И nmap показывает, что 22 порт закрыт.
Вот же бесовщина!
А мне надо пофиксить баги в модуле fliusb, который вызывает kernel panic при попытке сделать scatter-gather bulk_read (ага, вот попытки этого и вызвали у меня вчера крах файловой системы; ставлю генту в виртуалбоксе, буду там баловаться; а как резерв, если в виртуалбоксе не выйдет, хочу еще "запасной" компьютер помучить). Модуль был писан еще под ведро 2.6, кто-то его обновил под 4.9.0, но даже на моем 4.9.4 хватаю кернел паник ☹
Жаль, что кода в библиотеке такая уйма, что переносить его в userspace — дело как минимум 6 человекомесяцев, а для меня так и все полтора человекогода! Вот и тянут этот чертов модуль ядра с его deprecated кусками...

UPD: вот действительно чертовщина! Перезагрузил рабочий компьютер сегодня утром (как раз emerge -e world закончил восстанавливать все установленное), и ssh на второй компьютер заработал!
UPD2: ан, нет. Первый раз проскочило, теперь опять кирдык...
UPD3: выяснил причину:

139/tcp  open   netbios-ssn
443/tcp  closed https
445/tcp  open   microsoft-ds
3389/tcp open   ms-wbt-server

кто-то на вендомашине сидит с таким же IP!
Ну, конечно, не так, но таки ССЗБ. Уже четвертый час reiserfsck пытается мой рабочий винт восстановить. Эксперименты, так их... Подробности позже допишу.
Подробности )

Ах, да. Читаем gentoo wiki как загрузиться в однопользовательский режим. Лично для меня было сюрпризом, что "single" в первый уровень не попадает!
а на деле — около 2.4В. Причем, падение на стабилитроне меняется от напряжения! Вот такие стабилитроны я когда-то брал для защиты портов микроконтроллеров (резистор + стабилитрон — проще, чем резистор + 2 диода).
Дальше )
Почти с месяц назад (буквально как только я вернулся из Лыткарино) Маськин телевизор перестал показывать.
Все не доходили руки, намедни разобрал, скачал схемы и вынул блок питания. Прозвонка ничего не дала. Гугол подсказал, что в таких случаях чаще всего причиной является смерть светодиодов подсветки. И начались изыскания...

Ядрен батон! )
Заметил еще пару месяцев назад, но с тех пор ядро не обновлял еще.
В терминале (сначала грешил на xfce4-terminal, но в "голой консольке" то же самое) после того, как введешь команду reset (бывает иной раз нужно, если мусор сыплется и сбивает форматирование) намертво отваливается локаль.
Ну, то есть locale выдает КОИ8-Р, как и положено, но вот буквы не отображаются.
Сидел сейчас, man termios читал. Неужто в ядро воткнули чертов хрюникод? Это ж жесть!!!
В общем, ждать, пока появится 100% рабочий микроконтроллер совсем нет времени.
Поэтому принято решение: из говна и палок при помощи ардуины (для которой прошивка готова и отлажена) на камаковской макетке собрать временную схему — до полной модернизации системы управления.
И впредь никаких чертовых AVRок!
Чип сегодня получили, но ничего не вышло.
Я превратил ардуину в программатор, она увидела чип в плате и даже прошила его. И все...
Сигналы на светодиоды подсветки крестов весело идут. Судя по длительности, чип работает на положенных 8МГц.
А вот USART… В зависимости от U2X он выдает то 333 бода, то 666! Вот же чертовщина! Что бы я ни писал в UBRRH/UBRRL, скорость меняется только при изменении U2X!
Похоже, лыжи не едут...
Весь день убил (правда, было еще несколько отвлекающих факторов) на компиляцию avr-toolchain, запуск демо в среде ардуино (не зря, оказывается, я себе эту безделушку купил: на ней можно будет отлаживать код для динозавра ATmega8535) и запуск простейшей мигалки отсюда.
Ну да ладно: STM8 и STM32 намного тяжелее шли! Правда, здесь еще надо будет с архитектурой познакомиться, но, сдается мне, что хватит тупейшего ногодрыга (такого убожества, как плата управления первым SCORPIO, я еще не встречал! Надо же додуматься шаговиками рулить, формируя полную диаграмму, а вместо ключей используя ТТЛ-логику "И-НЕ"!).
Судя по схеме, больше одного ШД одновременно работать не может, импульсы подаются на все двигатели сразу, а выбор конкретного двигателя определяется подачей нуля на соответствующие логические элементы.
В пятницу посмотрю, что там нагородили внутри... Явно, в новой схеме нужно будет идти по пути миниатюризации (движки жрут мало, можно какие-нибудь совсем малюсенькие драйверы ШД использовать) и перво-наперво гигантские трансформаторы заменить на 15-амперный импульсный БП на 12 Вольт.
Сел я сегодня разбираться, почему после перестановки магнита из позиции 'A' колеса фильтров в позицию 'B' турель не опознала его. Оказалось банально — пока я его запихивал, не заметил, как он перевернулся. В итоге датчик Холла не срабатывал. Все заработало, но как я попытался своей утилиткой HSFW_management переименовать позиции фильтров в EEPROM турели, наткнулся на пару багов. И пришлось открывать старый код и исправлять. Напомню, это управлялка турелью High Speed Filter Wheel от Edmunds Optics. Я даже видео на тытрубу выкладывал.
Как же сложно ориентироваться даже в своем коде после того, как его больше полугода не видел! И более свежим взором смотришь, и видишь иной раз прямо-таки откровенный быдлокод! Кстати, из-за этого я, когда нужно будет сделать очередной автогид к очередному прибору, буду делать по максимуму с нуля; я уже и придумал, как более качественно смещения вычислять — по аналогии с алгоритмом astrometry.net (только будет все намного проще, т.к. постоянный масштаб и смещения незначительные). Это позволит избавиться от проблем на переполненных полях.
Ковыряясь в коде управлялки турелью, нашел кучу совершенно алогичных и противоречивых конструкций в разборе параметров командной строки. Исправил. Вроде работает нормально — по крайней мере, я проверил все возможные комбинации выбора нужной позиции, все было ОК. И переименование работает — но почему-то турель сыплет ошибками при попытке переименования колес G и H, хотя их фильтры переименовываются. Ну да черт с ними — мы будем работать только с A…E — это колеса на 5 50-мм фильтров (а оставшиеся три — на 8 более мелких).
Все, можно вечером с чистой совестью пить пиво.
Что-то никак не хочет мой сокет-клиент нормально детектировать отсоединение сервера. Вроде уже каких только проверок ни добавил, а все равно вчера при отключении света, когда компьютер, сидящий на упсе, выжил, а кубитрак отключился, после включения кубитрака клиент упорно продолжал пытаться читать закрытый сокет вместо того, чтобы пересоединиться.
В итоге я нарукожопил эдакий сторожевой таймер: если за определенное время никаких сообщений от сервера не приходит, клиент пересоединяется.

Кстати, у нас сегодня опять выходной — республиканский. Задолбали уже эти выходные, но, следуя традиции по выходным высыпаться, я таки пришел на работу не к восьми утра, а чуть позже — к девяти. Погода пасмурная с намеком на то, что пойдет дождь. Прогноз на неделю вперед тоже неутешительный — видимо, уже начались наши "муссонные" дожди с мая по июль.
Пока выдалась хорошая погода на выходных, я решил наконец-то провести операцию, которую нужно было сделать давным-давно: заменить разбитый подрамник на новый (купленный еще зимой).
История его покупки длилась около двух месяцев: сначала я пытался купить его в "экзисте". Но там постоянно были какие-то проблемы. Понятно, что я не хотел покупать "фирменный" подрамник почти за червонец, поэтому искал замены. И на каждую замену мне в экзисте приходил ответ: "отказ поставщика". В конце-концов я плюнул, вернул деньги (для этого пришлось выслать им отсканированное заявление) и со второй попытки купил подрамник с кодом STHN350090 в "пятой передаче". Обошелся он мне в 5237р. Кума забрала его, как только он пришел в магазин, и еще больше месяца он у нее на балконе валялся. А потом Алēнка привезла его в поселок (когда я был в Коуровке) и он лежал в гараже. Вот и сам виновник торжества:

Больше фото )
Сижу на unstable, т.е. у меня ACCEPT_KEYWORDS="~amd64". Сегодня после длительного перерыва открыл kicad и обнаружил, что версия 4.0.5 совершенно неюзабельная (невозможно работать с печатными платами)! Хочу для kicad сделать keywords только amd64. Редактирование package.keywords ничего не дало, т.к. плевать portage хотел на мои указания, когда глобально unstable стоит!!!
Решил проблему указанием >sci-electronics/kicad-4.0.4 в package.mask. Но это не выход, т.к. вручную очень не хочется потом править это, когда версия стабильной станет.
Есть ли вариант автоматом запретить нестабильные версии кикада ставить?
Днем я сделал "мультик" из кадров, полученных до и после того, как пиксели на изображении неба в all-sky начали "плыть". Он поразительно напомнил процесс прожигания бумаги зажигалкой: сначала все в порядке, потом вдруг возникает темное пятно и от него ползет волна... Появилась догадка, что виной всему подогрев матрицы, который приводит к растеканию заряда при длительных экспозициях. И как только появились первые признаки растекания:

я начал эксперимент.
Дальше )
Итак, в растекании пикселей на больших экспозициях в центральной зоне кадра был виноват непрерывно работающий подогрев матрицы. Следовательно, нужно все-таки доделать реализацию управления демоном — пусть архиватор, анализируя данные болтвудовского датчика, отправляет команды, когда включить нагреватель, и когда выключить. Понятно, что после дождя или снега его обязательно нужно включать на какое-то время.
Оставлю это здесь, в этом случае проще будет найти в случае необходимости.
Программное обеспечение для получения и архивации данных с all-sky камеры SBIG-340 и датчика облачности Boltwood Systems )
Боюсь, это так и останется единственной документацией (кроме комментариев в коде) к этим демонам.
Сегодня прикрутили all-sky на его положенное место и он заработал (пока в полутестовом режиме). Я все пытаюсь подобрать оптимальный алгоритм для расчета экспозиций. Поначалу то, что было хорошо в условиях помещения, оказалось жутко перекопленным в дневном свете. Пришлось двигать рамки. Получилось вот так:

Дальше )
Полдня пробился в попытках поставить solidworks в виртуалбоксе, получилось. Но тормоза настолько нереальные, что работать в этом невозможно. Почитав сравнительные статьи, понял, что мне и "компаса" за глаза хватит.
Сижу, рисую фотометр для Z-1000 (большую часть времени, правда, смотрю ролики на тытрубе, как какую-нибудь операцию сделать; надо определенно найти учебник по этой штуке — это эффективней должно быть, чем ролики мотать). К счастью на стандовском сайте были чертежи ротаторов, а вот турели от edmund optics придется самому рисовать — никакого сервиса, очень негативное отношение у меня к этой фирме (напомню, управлялку пришлось писать, используя обратный инжиниринг).
Картинка:

Единственным недостатком запуска "компаса" в виртуалбоксе является то, что элементы меню, попадающие на окно вида, исчезают. Видимо, особенности проброса аппаратного видеоускорения через виртуалбокс.
Ребятки, работая с сокетами, учитывайте, что это вам не файлы!
Мне пришлось забульбенить логгер, чтобы понять эту простую истину: если клиент закрыл со своей стороны сокет, то read() вернет 0, как если бы данных не было, а select() спокойно отработает. Вывод таков. Нельзя писать
if(!(rd = read(sock, buff, BUFLEN-1))) continue;

после вызова select(), надеясь, что ошибка произойдет в select() и соответствующим образом будет выявлена. Ни в коем разе! select() скажет, что данные на входе есть. А вот read() в этом случае вернет не отрицательное значение, а 0!
В общем, писать надо так:
if(!(rd = read(sock, buff, BUFLEN-1))){
    putlog("socket closed. Exit");
    break;
}

September 2017

S M T W T F S
     1 2
3456789
1011 12 13141516
17181920 212223
24252627282930

Syndicate

RSS Atom

Style Credit

Expand Cut Tags

No cut tags
Page generated Sep. 25th, 2017 04:09 am
Powered by Dreamwidth Studios