Тут будет лирическое отступление
Читать далее...
Итак, казалось бы, какие трудности могут быть с привязкой наблюдений к точному времени в век доступных GPS-приемников, коль скоро известно, что работа всей системы GPS (как и ГЛОНАСС и Galileo) основана на обработке спутниковых сигналов, в которые время «вшито» с точностью, как минимум, до долей микросекунд. Но обычный «туристический» GPS-приемник не имеет необходимых средств, чтобы вывести настолько точные временные метки наружу. Существуют специальные приемники, имеющие выход строба «1PPS», который передает информацию о начале секунды с точностью до микросекунд, и этот сигнал можно использовать для отсчета времени, если наблюдательное оборудование (камера, например), умеет это делать. Но обычно у любителя ничего такого под рукой нет, а типичный GPS-приемник смартфона или подключаемый к компьютеру «туристический», обеспечивают точность на уровне секунды. До сих пор популярен 9,6-килобитный протокол обмена, где передача одного информационного сообщения занимает десятки миллисекунд, и происходит раз в секунду, а этот интервал еще и выдерживается с небольшой точностью.
Вторая проблема произрастает из невысокой точности большинства встроенных в бытовые компьютеры (а также фотоаппараты) часов реального времени. Ситуация, когда часы устройства убегают или отстают на несколько секунд в сутки вполне типична, а в отдельных случаях суточный дрейф достигает нескольких десятков секунд. Таким образом, к сожалению, нельзя полагаться при таймингах астрономических явлений на единожды сделанную синхронизацию дольше нескольких часов (а то и минут, в зависимости от требований точности), и приходится выполнять эту синхронизацию регулярно.
Ну и третья пичалька произрастает от того, что, хотя компьютер и «быстро думает» по человечьим меркам, но выполняет несколько (десятков) программных процессов одновременно, переключаясь между ними одним (двумя, четырьмя, двенадцатью) процессором(ами) под командованием операционной системы, которая не всегда может гарантировать, что определенное приложение (например, которое записывает картинку с камеры) получит управление в определенный момент. Это напрямую относится к Windows XP/7/8, которые не являются операционными системами реального времени. Отсюда следует, что, во-первых, всегда есть задержка между получением картинки, ее привязкой ко времени и фактической выгрузкой на носитель, и, во-вторых, эта задержка далеко не всегда остается предсказуемой. Тут можно было бы сесть и заплакать. Но когда слезы высохнут, можно попробовать оценить масштабы временных ошибок для разных вариантов наблюдений.
Наблюдателю нужно привязать секундомер или часы фотоаппарата к точному времени. Традиционный способ — радиосигналы точного времени, например, передаваемые «Маяком» или специальными радиостанциями (
http://ru.wikipedia.org/wiki/RWM ,
http://ru.wikipedia.org/wiki/Бета_(служба_времени) ). Некоторые из них требуют специальных декодеров. В западной части России принимается сигнал немецкого ретранслятора DCF77 (
http://ru.wikipedia.org/wiki/DCF77 ) , по которому синхронизируются некоторые модели электронных часов. По факту для наших краев с бытовым оборудованием доступен только «Маяк», причем его надо слушать эфирным приемником, а не по Интернет-радио, т.к. в последнем случае добавляется задержка буферизации в несколько секунд. Поскольку основным «синхронизирующим агентом» является сам наблюдатель, то именно он «переносит» момент точного времени на секундомер или камеру, нажимая кнопку. В принципе, можно использовать и экран GPS-приемника с секундным отсчетом или иные часы, если есть уверенность в их высокой точности, и на крайний случай — показания предварительно синхронизированных часов компьютера (тут обычно не известна задержка отображения информации и она может достигать половины секунды). Во всех этих случаях главным «тормозом» является нервная система наблюдателя и инерционность кнопок и дисплеев (особенно охлажденных ЖКИ) или интерфейсного ПО. При этом можно ожидать точности в районе 0,2 — 0,8 сек. Синхронизацию желательно выполнить незадолго до явления (для данного покрытия — в шесть или семь часов вечера).
2. Фото/видеонаблюдения с фиксацией компьютером. Условимся, что время компьютера впечатывается в кадр программным образом (описанной ранее приличной GPS-впечатывалки в наличии нету).
Камера не может мгновенно передать картинку в память компьютера. Темп считывания, скорость интерфейса связи, производительность компьютера и архитектура программы накладывают определенные ограничения. Как раз в этом случае, эта задержка (между съемкой и впечатыванием времени в кадр) может быть более-менее определенно измерена и ее среднее можно учесть. Метод прост — фокусируем камеру (ставим максимальную скорость считывания и разумную выдержку 20-40 мс) на экране компьютера, куда выводится изображение с этой камеры, и где в кадр впечатывается метка времени. Помимо «бесконечного коридора» можем получить в кадре две метки времени, разнесенные промежутком задержки (как правило, он кратен периоду обновления экрана, например 17 мс @ 60Гц). Эта задержка сильно изменяется в зависимости от камеры, софта, разрешения, производительности компьютера и т.п. (ее лучше бы измерить на своем сетапе) и имеет порядок 10 — 100 мс (но это не точность абсолютной привязки, а лишь некая дельта, из этой привязки вычитаемая!).
Читать далее...
К примеру, я потестил такой «визуальной петлей» QHY5L-II в EZPlanetary при 800х600, получил среднюю задержку 83 мс (+/-16 мс); на 320х240 было 42 мс (время считывания с сенсора уменьшилось). QHY5V в QGVideo32 показала время задержки меньше времени обновления экрана (< 17 мс), а FireCapture c Genius Trek320R – 95 мс. Тестилось на одном компьютере, на других значения будут немного другими.
Вряд ли изготовители ПО пытаются в софте учесть эти задержки (для иных, кроме покрытий целей такая точность не востребована). В принципе, точность на уровне 0,1 секунды — уже неплохо, лучше ведь «ручного» метода. Но тут всплывают другие вопросы.
Практически нереально в быту измерить задержку внутри системы между получением времени от системных часов и ее впечатыванием в кадр. Можно, впрочем, считать, что она не превышает нескольких мс (т.к. не изменяет темпа съемки по отношению к ситуации с отключенными метками), и не оказывает заметного влияния на точность (но подсказывает, что чем меньше будет запущено других процессов, тем лучше, особенно антивирусов и фаерволов, сетевых качалок, каких-либо серверов и прочего высокоприоритетного или «событиягенерящего» софта).
И как-то нужно установить часы так, чтобы
исключить при этом нервную систему наблюдателя со свойственными ей тормозами. Наверно, самым доступным способом, не требующим особого оборудования (только доступа в Интернет) является синхронизация со специальными серверами времени в Интернете (служба
NTP). Такие серверы применяются в больших и малых сетях с давних пор и нужны для синхронизации времени различных узлов между собой (ведь, напомню, встроенные в систему часы могут иметь сильный дрейф или вообще отсутствовать). Синхронизация достигается передачей временных меток от надежного источника с учетом времени распространения сообщений по сети, которое измеряется в процессе. Так как нагрузка и конфигурация маршрутов в Сети никогда не остается постоянной, расчет задержки основывается на усреднении времени задержки от нескольких попыток. Метод имеет типичную точность не хуже 120 мс, часто лучше (вплоть до 10 мс, но довольно непредсказуемо).
Простой клиент NTP встроен в Windows (закладка «Время Интернета»), но он не очень удобен для точной синхронизации. Можно установить программу
NetTime (
http://www.timesynctool.com/ ), она более гибка в настройках (и есть подозрение, что смена секунд на индикаторе внутри программы сделана более равномерно, чем на обычной панели Windows, что может иметь значение, если компьютер используется как часы для ручной синхронизации секундомера).
Источниками сигналов точного времени для NTP являются точные GPS-приемники, атомные часы и прочие высокоточные источники. Эти устройства образуют так называемый «нулевой слой» (stratum 0) NTP, но они не могут обслуживать запросы клиентов непосредственно, поэтому они синхронизируют часы NTP-серверов первого слоя (stratum 1), которые и являются самым точным «отвечающим» уровнем иерархии NTP. Однако понятно, что число клиентов в Сети велико, а атомных часов — как раз наоборот, и stratum 1 быстро ушел бы в DOS. Поэтому, «считается приличным», прицеплять к stratum 1 серверы следующих слоев — stratum 2, 3 и т. п., которые и обслуживают сотни и тысячи клиентов. С одной стороны, чем больше номер слоя, тем потенциально менее точно идут его часы, но с другой — тем выше вероятность хорошей связи с этим слоем, т. к. он может быть ближе по маршруту. Список серверов можно найти в Интернете. Для нашего региона может представлять интерес сервер
ntp.deman.ru, который, по описанию, расположен в Новосибирске, относится к stratum 1 и имеет на нулевом уровне GPS-приемник со стробом 1PPS. И хотя моветон цеплять клиентов на stratum 1, «ради науки» и на небольшой промежуток времени, думаю, это будет оправдано. В качестве запасного варианта можно предложить
ntp.kuzspa.ru (пока оно работает), стоящий в Новокузнецке в сети РЦТК. Это сервер stratum 2 или 3 (в зависимости от доступности верхних слоев). Грубое соотнесение данных двух этих серверов (и обычного GPS) не показывает больших разногласий (хотя оно таки грубое, да).
Окно NetTime выглядит так:
В нем отображены: текущее время, время предыдущей попытки синхронизации, время предыдущей успешной синхронизации и вычисленная поправка к часам, оставшееся время до следующей попытки, строчка об успешности синхронизации и режиме работы (приложение/служба). Ниже таблица со списком серверов, их состоянием, вычисленной поправкой к часам, задержкой маршрута (кабельные каналы, как правило, быстрее реагируют, чем беспроводные) и описанием ошибки, если таковая была. Кнопка «Update Now» принудительно запускает синхронизацию.
Кстати, по умолчанию, туда забиты серверы открытого пула NTP (0.nettime.pool.ntp.org и т. п.), которые выбираются автоматически из большого числа серверов stratum 2 и выше. Это обеспечивает хорошую доступность, и в принципе, нормальную точность. Но можно изменить настройки («Settings...») для нашей задачи, как на рисунке. Здесь занесены упомянутые серверы и уменьшен интервал автообновления (Update interval) до 5 минут. За это время большая ошибка не должна набежать. Хотя технически можно установить автообновление и через несколько секунд, это приведет к повышенному трафику (в том смысле, что та сторона может вас отрубить как сильно «беспокойного» клиента) и может привести к искажению информации о длительности покрытия (если автообновление случится посреди покрытия и коррекция, к примеру с +50 мс перепрыгнет на –50 мс, то вы потеряете или обретете лишние 100 мс). Собственно при попытке закрыть окно с такими настройками NetTime строго напомнит нам о том, что не надо напрягать чужие серверы почем зря и предложит автоматически исправить «ошибки». Ответим вежливым, но строгим «нет». Теперь NetTime, пока есть связь, через определенные интервалы будет корректировать часы компьютера. Если при наблюдениях не предвидится возможности использовать сеть, то стоит экспериментально загодя измерить, на какую среднюю величину в час дрейфуют часы вашего компьютера, чтобы потом вычислить поправку времени.
Грубая комбинация задержек фиксации, описанных выше, и обычной точности NTP приводит к величине максимальной ошибки в районе 150 мс. Правда, без специальной методики и оборудования, все задержки учесть тут не удастся ввиду сложности системы и непостоянства задержек. Также важно испытать все заранее и «привыкнуть» к числам, присущим вашему оборудованию.
