Да, все это ображает текущую ситуацию с облачностью. Бывает кратковременная облачность, которую ветер надул и через минуту уже сдул — это отображается в виде пика на графике.
Тут в целом полезно смотреть тенденцию. Я еще отдельно отображаю дельту между температурой неба и температурой окружающего воздуха и на основе этого значения произвожу достаточно точную оценку ясности неба.
Прошу прощения за столь запоздалый ответ. Только сейчас увидел Ваш вопрос :(
И датчик и камера работают прекрасно, и продолжают приносить результаты, за всё время эксплуатации не выявлено никаких проблем и сбоев. От влаги особых проблем нет, т.к. она довольно быстро испаряется. И собственно осадки позволяют очистить датчик.
Вот, например, что он намерял за минувшие сутки:
В gnupredict есть модуль «control radio», а в gqrx есть опция «remote control».
Активируются оба модуля, программы соединяются через локальный сокет и дальше в отдельном окне контроллера радио можно задать параметры управления — настроить приемник на заданную частоту (можно выбрать из списка избранных спутников-транспондеров) и начать трекать частоту, в этом режиме как раз и происходит коррекция в зависимости расстояния от спутника.
Прошлым летом занимался активным приемом сигналов спутников NOAA-18 и NOAA-19.
Антенна — квадрифиляр из трубок от кондиционера. Приемник — такой же RTL.
Софт — Gnupredict на Linux и GQRX. Первая программа удобно отображает пролеты всех спутников и умеет управлять приемником GQRX, корректируя частоту, в зависимости от допплеровского сдвига.
Постобработка записанного сигнала в Audacity (стерое в моно, компрессия и ресемплинг) и получение финального изображения в WxToImg.
В августе собеседовался в Google (Цюрихский офис).
Прошло все довольно своебразно, сначала со мной поговорил рекрутер из Лондона, который в итоге отправил на техническое hangouts интервью с инженером из Цюриха.
Только вот отправили меня по направлению software engineer, хотя я сам системщик-эмбеддер.
Это собственно и всплыло в процессе собеседования, инженер даже немного удивился почему меня к нему отправили.
После собеседования мне прислали фидбек, что по направлению software engineer они мне не могут ничего предложить, т.к. я мол embedded/firmware engineer, так они решили. В общем то здраво :)
И добавили еще, что сейчас ищут hiring team по этому направлению и предложили созвониться что бы обсудить всё. Я согласился на созвон и после этого Google пропал, так и не дождался ответа :)
В сентябре правда прислали заполнить анкету небольшую, что бы я дал уже свой фидбек по поводу процессе собеседования и интервьюверов, я там конечно в дополнительных заметках описал возникшую ситуацию.
Так что еще и такого плана бардак небольшой присутствует.
Интересно, спасибо )
Буквально сегодня общался с рекрутером из Google, правда они сами меня нашли. Так же предлагают Цюрих.
На следующей неделе будет первое техническое интервью, тут даже больше интересно попробовать и проверить себя.
Сам рекрутер звонил из Лондона, общались через Hangouts и это действительно было не очень, частые фризы, рассыпание картинки и заикания звука.
Спасибо за полезную статью.
Вопрос о реализации исполнительной схемы узла защиты.
Чем лучше всего размыкать относительно мощную постоянку (110 вольт и токи до 7А)?
Есть H-мост для старых ДПТ на 110 вольт, токовый шунт воткнуть в цепь — не проблема, но как (и где) тут лучше всего отключать питание в случае аварии двигателя?
А кто-нибудь из присутствующих пробовал перебираться за рубеж из Крыма (через Киев, разумеется)?
Огромное количество таких вот историй, как уехать куда-то из Москвы, Киева и т.п. больших городов России, Украины, а о переезде из таких вот сложных регионов — тишина, видимо историй успеха не так уж и много…
Пару недель назад получил на Linkedin предложение пособеседоваться в Facebook, хорошо общались с рекрутером, отправил резюме (вполне адекватное, со ссылками на github (где много различных проектов, в том числе достаточно навороченных) и личный сайт), после этого рекрутер «пропал» и никаких сообщений я больше не получал.
Есть подозрение, что их могло отпугнуть текущее место жительства и работы. По крайней мере слышал подобные истории, но все же надеюсь что это все слухи.
Вот про такое бы почитать.
Изображения как такового нет. Значения с групп ФЭУ суммируется и просто измеряется.
В результате для наблюдаемого объекта строится диаграмма распределения гамма-квантов.
Т.к. вся процедура чтения по факту вызывается пользовательским приложением, то и выполняется этот код в контексте читающего потока приложения.
К самому ядру это отношения не имеет.
Соответственно если вдруг где-то застрянет железо — то в ожидании застрянет лишь пользовательское приложение, в методе read() на символьном устройстве. Это не подвесит остальную систему с прочими приложениями и процедура вполне подлежит завершению.
Не выставление бита может означать какой-то серъезный сбой с платой, и очевидно работать с ней дальше не выйдет. В случае же отвала лишь датчика — пауза все равно будет выставлена и из памяти будет прочитано нулевое значение.
Конечно если есть возможность — лучше всего использовать прерывания, но в данном случае они недоступны.
Об одном из таких, других, способов я уже писал довольно давно. Это netlink.
Еще один способ — через виртуальные файловые системы (/proc, /sys). В частности именно таким образом различные утилиты получают от ядра информацию таблице маршрутизации, запущенных процессах, обращениях к диску и т.п.
Другой механизм — системные вызовы, через него с ядром общается, например, стандартная библиотека С.
Вообще наверное стоит написать отдельную статью, о способах общения с модулем ядра и подробнее про netlink рассказать, интересная штука.
Честно говоря пока не задавался этим вопросом.
Пока слабо представляю себе как собрать статистику по пользователям. У производителя есть официальный форум, но он полупустой и там чаще вопросы либо конкретно по железу, либо Windows. Все таки железка специализированная.
В нашем случае драйвер используется в системе управления телескопом, такие рабочие станции стараюсь не обновлять без особой надобности, а если ядро новое все таки приедет — руками пересобрать 10 секунд :)
Спасибо!
Код писался и тестировался на ядре версии 3.16, дистрибутив — Debian Jessie.
Также проверял на Scientific Linux 7.3, проблем не было, правда версию ядра сейчас не вспомню…
Это телескоп гамма излучения.
24 зеркала, фокусирующих свет на 4 приемные корзины. В каждой корзине — 37 ФЭУ (фотоэлектронный умножитель).
Телескоп улавливает Черенковские вспышки от влетающих в атмосферу гамма-частиц.
Тут в целом полезно смотреть тенденцию. Я еще отдельно отображаю дельту между температурой неба и температурой окружающего воздуха и на основе этого значения произвожу достаточно точную оценку ясности неба.
И датчик и камера работают прекрасно, и продолжают приносить результаты, за всё время эксплуатации не выявлено никаких проблем и сбоев. От влаги особых проблем нет, т.к. она довольно быстро испаряется. И собственно осадки позволяют очистить датчик.
Вот, например, что он намерял за минувшие сутки:
Активируются оба модуля, программы соединяются через локальный сокет и дальше в отдельном окне контроллера радио можно задать параметры управления — настроить приемник на заданную частоту (можно выбрать из списка избранных спутников-транспондеров) и начать трекать частоту, в этом режиме как раз и происходит коррекция в зависимости расстояния от спутника.
Антенна — квадрифиляр из трубок от кондиционера. Приемник — такой же RTL.
Софт — Gnupredict на Linux и GQRX. Первая программа удобно отображает пролеты всех спутников и умеет управлять приемником GQRX, корректируя частоту, в зависимости от допплеровского сдвига.
Постобработка записанного сигнала в Audacity (стерое в моно, компрессия и ресемплинг) и получение финального изображения в WxToImg.
Прошло все довольно своебразно, сначала со мной поговорил рекрутер из Лондона, который в итоге отправил на техническое hangouts интервью с инженером из Цюриха.
Только вот отправили меня по направлению software engineer, хотя я сам системщик-эмбеддер.
Это собственно и всплыло в процессе собеседования, инженер даже немного удивился почему меня к нему отправили.
После собеседования мне прислали фидбек, что по направлению software engineer они мне не могут ничего предложить, т.к. я мол embedded/firmware engineer, так они решили. В общем то здраво :)
И добавили еще, что сейчас ищут hiring team по этому направлению и предложили созвониться что бы обсудить всё. Я согласился на созвон и после этого Google пропал, так и не дождался ответа :)
В сентябре правда прислали заполнить анкету небольшую, что бы я дал уже свой фидбек по поводу процессе собеседования и интервьюверов, я там конечно в дополнительных заметках описал возникшую ситуацию.
Так что еще и такого плана бардак небольшой присутствует.
Буквально сегодня общался с рекрутером из Google, правда они сами меня нашли. Так же предлагают Цюрих.
На следующей неделе будет первое техническое интервью, тут даже больше интересно попробовать и проверить себя.
Сам рекрутер звонил из Лондона, общались через Hangouts и это действительно было не очень, частые фризы, рассыпание картинки и заикания звука.
Вопрос о реализации исполнительной схемы узла защиты.
Чем лучше всего размыкать относительно мощную постоянку (110 вольт и токи до 7А)?
Есть H-мост для старых ДПТ на 110 вольт, токовый шунт воткнуть в цепь — не проблема, но как (и где) тут лучше всего отключать питание в случае аварии двигателя?
Огромное количество таких вот историй, как уехать куда-то из Москвы, Киева и т.п. больших городов России, Украины, а о переезде из таких вот сложных регионов — тишина, видимо историй успеха не так уж и много…
Пару недель назад получил на Linkedin предложение пособеседоваться в Facebook, хорошо общались с рекрутером, отправил резюме (вполне адекватное, со ссылками на github (где много различных проектов, в том числе достаточно навороченных) и личный сайт), после этого рекрутер «пропал» и никаких сообщений я больше не получал.
Есть подозрение, что их могло отпугнуть текущее место жительства и работы. По крайней мере слышал подобные истории, но все же надеюсь что это все слухи.
Вот про такое бы почитать.
В результате для наблюдаемого объекта строится диаграмма распределения гамма-квантов.
К самому ядру это отношения не имеет.
Соответственно если вдруг где-то застрянет железо — то в ожидании застрянет лишь пользовательское приложение, в методе read() на символьном устройстве. Это не подвесит остальную систему с прочими приложениями и процедура вполне подлежит завершению.
Не выставление бита может означать какой-то серъезный сбой с платой, и очевидно работать с ней дальше не выйдет. В случае же отвала лишь датчика — пауза все равно будет выставлена и из памяти будет прочитано нулевое значение.
Конечно если есть возможность — лучше всего использовать прерывания, но в данном случае они недоступны.
Еще один способ — через виртуальные файловые системы (/proc, /sys). В частности именно таким образом различные утилиты получают от ядра информацию таблице маршрутизации, запущенных процессах, обращениях к диску и т.п.
Другой механизм — системные вызовы, через него с ядром общается, например, стандартная библиотека С.
Вообще наверное стоит написать отдельную статью, о способах общения с модулем ядра и подробнее про netlink рассказать, интересная штука.
Пока слабо представляю себе как собрать статистику по пользователям. У производителя есть официальный форум, но он полупустой и там чаще вопросы либо конкретно по железу, либо Windows. Все таки железка специализированная.
Я их уведомил, отправил ссылку на github, ответили «Спасибо» и на этом переписка закончилась :)
Код писался и тестировался на ядре версии 3.16, дистрибутив — Debian Jessie.
Также проверял на Scientific Linux 7.3, проблем не было, правда версию ядра сейчас не вспомню…
24 зеркала, фокусирующих свет на 4 приемные корзины. В каждой корзине — 37 ФЭУ (фотоэлектронный умножитель).
Телескоп улавливает Черенковские вспышки от влетающих в атмосферу гамма-частиц.
Код компилируется потому что в языке С — это вполне допустимая конструкция, называется designated-initializer