а на деле — около 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;
}
и все никак не добью чертовых демонов мониторинга неба! Перезапуск по крону 1 раз в сутки — не вариант, т.к. почему-то клиент, слушающий сокет, не отмирает, а продолжает висеть на закрытом сокете.
А у демона другая проблема, вот этот кусок кода:
        if(pthread_create(&handler_thread, NULL, handle_socket, (void*) &newsock))
            WARN("pthread_create()");
        else{
            DBG("Thread created, detouch");
            pthread_detach(handler_thread); // don't care about thread state
        }

запускает поток для очередного клиента. Но по непонятной причине после того, как клиент отвалится, поток продолжает висеть в качестве зомби!
Думаю, надо временно логгирование действий забульбенить с таймаутами, чтобы выяснить наконец-то, где же кроется косяк. Вот такой из меня рукожопый горе-погромист.
Стал я на машине с дурацким scientific linux собирать свои велосипеды для all-sky и болтвуда. Замучился уже!
Во-первых, дистр, рассчитанный на то, что он будет стоять на компе "офисной крысы" — совершенно неудобная для работы вещь! Мало того, что там поцтерошлака вагон, так еще и заголовочные файлы от библиотек идут в отдельных пакетах! Нужно было все-таки потратить 2-3 дня своего времени, и поставить туда генту!
Во-вторых, то, что превосходно компиляется gcc 5.4.0, вызывает сегфолты на gcc 4.8.5. Занятно, что сегфолт этот моим рукожопием вызван: я инициализирую дефолтное имя файла константной строкой, а потом в ней заменяю точку, отделяющую суффикс от имени, на '\0'. Похоже, новый gcc создает эти константы на стеке, в то время как старый честно их в RO пихал.
UPD: в репах Scientific Linux нет ds9! Это ж просто деление на ноль! Какой он после этого, нафиг, scientific? Может, там еще и fftw3 и т.п. нет?..
UPD2: блин, там еще и локаль через задницу настраивается! Уже 10 минут гуглю, как koi8-r по умолчанию сделать — в дефолтной установке нет locale-gen, но ведь должен же быть механизм! Не хрюникодом же пользоваться, в конце-то концов!!!
Знание — сила, а незнание — мощный велосипедогенератор.
За 5 дней опытной эксплуатации демоны, обслуживающие болтвудовский датчик и all-sky почему-то наплодили уйму неотмерших потоков (хотя в коде выход из потока правильный), в результате несчастный кубитрак был загружен на 170%, и компиляция элементарного кода длилась две минуты! Эту проблему решил добавлением перезапуска демонов в cron.daily.
Вчера все это хозяйство разместили на Цейссе (но пока не устанавливали на крыше), включив во время отсутствия электричества (на Цейссе-то упсы, которые не меньше двух часов даже с рабочим телескопом выдержат). В итоге время на кубитраке получилось неправильным. По идее, это должно было устраниться, как только появится сеть — ведь на кубитраке запущен ntp-демон. Как бы не так! Решил опять велосипедно: отменой автозапуска бесполезного ntp-демона и добавления ntpdate в cron.hourly.
Удивился куче логов в /var/log (хотя это одноплатник — он вообще логи в оперативке должен хранить, или даже лучше в /dev/null). Т.к. проблема глубокая, решил ее лишь настройкой logrotate ротировать ежедневно, оставляя по 1 логу.
Ну и вообще, до сих пор негодую, что дебилиан перешел на systemd! Хоть у меня и есть репа генты для кубитрака, собранная в чруте, но очень проблематично обновляться: надо вынимать флешку и перезаливать образ. Что долго и совсем неудобно, когда эта флешка черт-те где. Пришлось вместо генты ставить эту дрянь. Судя по выхлопу systemctl, запущена толпа ненужных сервисов. Что-то поприбивал, но как бороться с автозапуском ненужного wpa_supplicant, не убивая идиотский нетворкманагер, не понимаю. Вообще логика создателей армбиана не ясна для меня: какой идиот на сервер будет пихать нетворкманагер или системД? А уж тем паче, если это — сервер на одноплатнике!

Тьфу! Выпустил пар. Отдохну, а после обеда продолжу накапливать гнев — мне еще на серваке с Scientific Linux (ага, тоже с поцтерошлаком) разворачивать логгирующие демоны и апач с proftpd настраивать… Ну почему наши информатики используют это порождение Красной Шапки? И сами же матюкаются на костыли с поцтерошлаком. Как те мыши с кактусом!
Кто бы мог подумать, что сохранение старых параметров порта может привести к "поломке" коммуникаций?
Как только я закомментировал вот это:
        if(ioctl(comfd, TCGETA, &oldtty) < 0){  // Get settings
            /// "Не могу получить настройки"
            WARN(_("Can't get settings"));
            signals(2);
        }

так сразу демон all-sky стал нормально работать!

Вот как такое может быть? Подозреваю, что какой-нибудь баг в коде модуля для FTDI…
В попытке написать скрипт автозапуска демонов all-sky и cloud sensor, пока еще мне не подсказали о /dev/serial, я что-то эдакое записал в порт камеры, проверяя на нем, не является ли он болтвудовским датчиком.
В итоге коммуникация с камерой работает нормально, а вот картинку она не отдает. Точнее, отдает первую порцию данных с недостачей в несколько байт, а дальше молчит.
Пока я тут методом тыка пытаюсь разобраться, заодно послал запросы в техподдержку и на форум SBIG ­— вдруг таки дадут полноценный протокол? А вообще, это свинство — делать такие дорогие железки, и не сопровождать их уж если не SDK, так хотя бы полноценной документацией!

UPD: если запустить fits_capture.py отсюда, то изображение считывается, и дальше мой демон работает без проблем.
Ну вообще мистика какая-то — ведь в питоновом скрипте все точно также, разве что чтение блокирующее! Похоже, что-то я намудрил с ioctl'ами... Неужто TIOCEXCL в этом виноват? Потому как все остальное осталось таким же, каким и было.

July 2017

S M T W T F S
      1
23 4 5 6 78
9 101112 131415
16171819 202122
23242526272829
3031     

Syndicate

RSS Atom

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 20th, 2017 02:36 pm
Powered by Dreamwidth Studios