На днях должны подвезти спирт, и я смогу наконец-то подготовить криостат к тестовой откачке и, если течей не будет, испытанию холодом в наших условиях.
А для этого нужно иметь надежную систему сбора температур. Я уже писал о тестировании системы в жидком азоте. Теперь же решил откалибровать при помощи точного омметра и посмотреть, как датчики себя в комнатной температуре будут вести.
Подробности )
Я уже давно сделал регистратор температуры, но только на этой неделе дошли руки. Почему-то АЦП оказался сгоревшим, пришлось при помощи промышленного фена (т.к. паяльную станцию с феном нам еще не купили) выпаять старую АЦП и впаять новую, заодно заменив "кренку" (видимо, из-за нее и сгорел старый АЦП, т.к. на его ногах питания были все +12В). Дня три я убил на код (который и сегодня допиливал, но так до конца и не исправил все баги), в результате получилось вот что:
Термодатчики в банке с азотом
Банка с азотом

Еще фото и текст )
В ходе "внезапно обнаруженных особенностей" шаговых двигателей, которые предполагается использовать в криостате ИК-спектрометра (в пиковом режиме работы они выделяют 50 Вт!), а также для изучения, насколько драйвер ШД L6208N хуже драйвера TB6560AHQ, я на этой неделе провел кое-какие испытания.

Для затравки — видео:

это позорище — "измерительная установка", использующаяся в эксперименте.

Подробней )
В документации на датчики Холла (A1101), которые я буду использовать для определения текущей позиции турелей в спектрометре, сказано, что гарантированно они работают при температурах выше -40°C. Мне стало интересно: а при какой же температуре реально эти датчики будут отключаться? А также я решил проверить, не сдохнут ли они совсем, если их совершенно заморозить в жидком азоте.
Ну, а чтобы уж зафиксировать это "для истории" (да и рук не хватало, чтобы сопротивление записывать), я снял видео:



Заодно, пока весь азот не выкипел, я решил проверить, насколько врут разные терморезисторы:



Подробности )
Итак, с подключением датчиков я более-менее разобрался: подал всем на "+" питание +3.3В; "минусы" подключил к ногам МК (пока что использовал ноги для аналогового мультиплексора), работающим в пушпульном режиме; ноги "data" термодатчиков через диоды (Шоттки у меня пока нет, поэтому воткнул какие-то советские с неплохим прямым падением) — к общей шине. В итоге, если сразу же после команды задания адреса на мультиплексор дать команду чтения шины ZacWire, как раз успеваешь считать первую порцию данных (потом уже читать бесполезно: вероятность наткнуться на начало пакета == процентов 10).

Текст, графики )

Помимо попытки найти зависимость фокуса от температуры я еще проанализировал зависимость между температурой зеркала и подкупольного. Результаты получились из разряда "отсутствие результата — тоже результат": зависимость фокуса от температуры разных элементов крайне неявная (коэффициент корреляции мал, стандартное отклонение велико); зависимость температуры зеркала от разности температур между ним и подкупольным та же, что и была раньше (для изменения температуры зеркала на 1°C за один час в подкупольном температура должна отличаться на 10°C).

подробности )
Так как в прошлый раз использовались все данные, т.е. было очень много точек с явными выбросами, решено было хорошенько их проредить: теперь брались лишь те фитсы, которые были получены непосредственно после процедуры фокусировки. И опять получилось то же самое — две явные группы точек:
Temp_vs_foc_LR_corr
Зависимость отсчетов фокуса БТА от температуры трубы


Аппроксимация прямой дала значение F = -0.15*T + 39.80 — практически то же самое, что и было раньше. Стандартное отклонение от прямой составляет 1.68 — в общем случае многовато, однако, похоже, что если сделать интерполяцию по группам, то получится лучше. Но уж очень смущает положительный наклон кривой в области отрицательных температур. Явно здесь что-то не так. Чтобы получить более точные значения надо вешать на стакан лазерный дальномер и снимать показания каждый день. Может быть, тогда будет хоть что-то понятно...

немного кода )

P.S. В среду, выйдя после отпуска на работу, я обнаружил на столе посылочку с элементами (терморезисторы, макетка на STM32F4 с ethernet на борту, АЦП, набор всяких разных пустых макеток). Как только смогу, займусь. Для начала надо будет научиться работать по SPI с АЦП, напаять терморезисторов, подключить два термодатчика с I2C и оставить это все на долговременный мониторинг, тем временем пытаясь поднять стек TCP/IP на новой макетке с STM32.
Уже давно мы хотели определить, есть ли явная зависимость между значением фокусного расстояния (по датчику на P2) в первичном фокусе БТА от температуры. А вчера (отчасти в рамках помощи студенту, готовящему отчет, но по большому счету — интереса ради) я сделал небольшие расчеты. Оказалось, что некоторая корреляция есть, но уж больно она невелика.
Подробности )

В предыдущей записи [livejournal.com profile] vlkamov попросил меня немного разбавить текст картинками, что я и сделал. А сейчас я хочу на примере моделированного среза изображения показать, в чем же заключается суть алгоритма.
Все подробности — под катом. А здесь же для того, чтобы разжечь интерес читателя, покажу один график:
Signal_filtered
Уровни интенсивности оригинального ("Original") и восстановленного по "фотографиям" с разными экспозициями ("HDR") сигнала.

Подробности )

Про HDR

May. 11th, 2013 12:32 pm
Вот посмотрел я сегодня еще раз те жалкие картинки, которые мне сделал hugin вместо HDR, и подумал, что надо бы все-таки реализовать свою HDR-собиралку (теоретически, т.к. hugin — всего лишь обертка, запускающая консольные утилиты, можно ей вместо hugin_hdrmerge свое подсунуть).
Теорию я уже приводил на ЛОРе, да и частично реализовывал при анализе камеры Apogee. Т.к. здесь работа ведется с png-файлами, все сильно упрощается (правда, надо где-то сохранять сведения об экспозиции каждого кадра, иначе ничего не получится): открываем одновременно все файлы, затем построчно считываем их, строка за строкой заполняя результирующее HDR-изображение. Обработка элементарная: отбрасываем значения ЧБ-интенсивности, близкие к 0 или 255; далее делим оставшиеся интенсивности на экспозиции; вычисляем медиану; сохраняем логарифм полученного значения во временный файл (лучше, пожалуй, double использовать), параллельно вычисляя максимальную и минимальную величину логарифма. В другой или этот же файл сохраняем данные о цвете, которые берем из того изображения, где уровень серого в данном пикселе лежит где-нибудь так в диапазоне 176..230 (надо экспериментально подобрать).
По окончании обработки всего изображения преобразуем наш бинарник в нормальный png-файл.
Такой способ обработки все шумы максимально уменьшит, кроме шумов на уж очень темных местах (т.е. на темных участках изображения с максимальной экспозицией). Их придется восстанавливать, предварительно пройдясь медианным фильтром.

В общем, если не забуду об этой идее, как-нибудь от скуки реализую. UPD )
Итак, в поисках возможных решений, как таки заставить ноутбук быть человечнее, я даже создал тему на ЛОРе и в ЖЖ ru_linux.
Помощь зала и гугла дала возможность еще кое-что добавить.
кое-что )
Так как сегодня нам на весь день отключали свет, делать было нечего, и решил я почертить на ноутбуке. А заодно и проверить, на сколько же времени работы хватит заряда батареи.
дальше )
Итак, что получается: средняя скорость разряда составляет чуть больше 19% в час. Индикатор (batti) показывал в самом начале, что батареи хватит на четыре с лишним часа. Судя по графикам, это действительно так. Надо будет через годик посмотреть, насколько сильно деградирует аккумулятор.
С зарядом вообще получается красота: прямо таки то, что и должно быть. Изначальная скорость — около 60% в час. Все эти выбросы — обычный цифровой шум, а выброс на графике скорости заряда при достижении 100% обусловлен, по-видимому, тем, что "железо" считает полностью заряженной батарею при достижении некоего уровня, немного не доходящего до теоретического "полного заряда".
Я уже, наверное, с неделю пытаюсь набрести на более-менее приличный алгоритм аппроксимации дуги окружности вида (x²+y²=R²), но только сегодня набрел на отличную книгу, написанную автором уймы статей на подобную тематику — Николаем Черновым. Самой приятной неожиданностью было то, что помимо этой замечательной книги, в которой автор исследует множество алгоритмов аппроксимации прямых и окружностей, на его домашней страничке есть и готовый код к книге.

Чуть подробней )

Итак, нагулявшись в отпуске я таки решил вернуться к своим баранам.
Прежде, чем начать писать что-то для разложения нормалей к волновому фронту по упомянутым раньше функциям Жао, я решил попробовать обычное разложение. Для этого с сайта mathworks был сворован исходник функции zernfun2 (которая вычисляет полиномы), а также deco (которая выполняет декомпозицию).
Функцию deco пришлось маленько подправить (она вычисляла коэффициенты на основе двойного численного интегрирования, что крайне медленно). Но получилось довольно-таки сносно.



Чуть подробней )
Наконец-то нашел я время вернуться к обработке гартманнограмм.
Гартманнограммы я сгенерировал при помощи уже описанной модели, из нее получил значения нормалей к волновому фронту, преобразовал их в полярные координаты и далее стал пытаться восстановить волновой фронт так, чтобы получить нечто похожее на оригинальный.
Оригинальный волновой фронт имеет следующий вид:

подробнее )

Сегодня я закончил-таки подбор параметров полноценного синусного механизма с упорным подшипником. Т.к. tex4ht выдает какую-то фигню, а latex2html имеет слишком много картинок, которые мне лень загружать (а ftp на narod не работает через проксю), выкладываю ссылочку на описание в pdf.
Исходники )
Хоть нормальных наблюдений вчера провести не удалось (погода была ужасной), мы успели по крайней мере снять несколько гартманнограмм Веги для измерения точного положения фокальной плоскости для нового светоприемника (многострадального Apogee).
Подробности ) В итоге получили, что нам надо отрезать 14мм от стоек крепления светоприемника. Отрежем, а на следующую техническую ночь проведем повторные измерения. Если все будет ОК, сделаем уже нормальный прибор, с турелью фильтров. И будем раз в месяц-два проводить позиционные измерения и снимать гартманнограммы. Правда, еще бы найти время, чтобы довести до ума восстановление профиля зеркала по гартманнограмме + автоматизировать позиционные измерения.
Решил я (в основном - для себя, чтобы не забыть) описать результаты тестирования светоприемника Apogee Alta U16M с матрицей Kodak KAF-16803 (судя по стоимости светоприемника — немногим более 10 килобаксов, матрицу эту подобрали на помойке). Начальство поручило нам с Тимуром проанализировать, насколько поганый этот светоприемник и можно ли его использовать для ненаучных задач (например, для оценки экстинкции). В конце марта-начале апреля мы провели нужные измерения, а потом долго их обрабатывали.
Подробности )
P.S. К сожалению, у ЖЖшки отвалилась функция добавления картинок в сам ЖЖ, так что пришлось все кидать на imageshack.
P.P.S. Сегодня (10 мая) я таки умудрился домучить libapogee2.2 (которую нашел где-то на просторах интернета), чтобы она считывала мне кадр с ПЗС. Однако, несмотря на то, что экспозиция протекает нормально, температура устанавливается какая надо, все пиксели полученных изображений содержат 65535.
Буду доламывать дальше: все-таки, эта камера нам нужна будет для работы и надо обязательно научиться полностью управлять ею.
Алексей Балакин (профиль на ЛОРе) давно уже разрабатывает проект MathGL, предназначенный для построения разнообразных графиков: как простых, так и очень сложных. Недавно он выпустил вторую версию этой библиотеки.
Библиотека предназначена для работы с разными ЯП, но для меня прежде всего интересен порт ее в Octave (чтобы можно было "по-быстрому нашлепать" красивых графиков для отчетов/презентаций и т.п.). О нем я и расскажу.
Read more... )
Сижу сейчас с больной головой (по поселку ходит ГРИПП, меня тоже зацепило) и пытаюсь написать что-нибудь для попиксельной обработки FITS-файлов (плоские поля), которые мы наполучали, начиная с вчерашнего обеда, с Apogee'вского светоприемника.
Обнаружил, что для чтения шапок FITS-файлов в Octave ничего нет. Нашел нечто похожее для матлаба и немного видоизменил.
Получилось вот что )

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:43 pm
Powered by Dreamwidth Studios