Читать далее...
Итак, казалось бы, какие трудности могут быть с привязкой наблюдений к точному времени в век доступных GPS-приемников, коль скоро известно, что работа всей системы GPS (как и ГЛОНАСС и Galileo) основана на обработке спутниковых сигналов, в которые время «вшито» с точностью, как минимум, до долей микросекунд. Но обычный «туристический» GPS-приемник не имеет необходимых средств, чтобы вывести настолько точные временные метки наружу. Существуют специальные приемники, имеющие выход строба «1PPS», который передает информацию о начале секунды с точностью до микросекунд, и этот сигнал можно использовать для отсчета времени, если наблюдательное оборудование (камера, например), умеет это делать. Но обычно у любителя ничего такого под рукой нет, а типичный GPS-приемник смартфона или подключаемый к компьютеру «туристический», обеспечивают точность на уровне секунды. До сих пор популярен 9,6-килобитный протокол обмена, где передача одного информационного сообщения занимает десятки миллисекунд, и происходит раз в секунду, а этот интервал еще и выдерживается с небольшой точностью.
Вторая проблема произрастает из невысокой точности большинства встроенных в бытовые компьютеры (а также фотоаппараты) часов реального времени. Ситуация, когда часы устройства убегают или отстают на несколько секунд в сутки вполне типична, а в отдельных случаях суточный дрейф достигает нескольких десятков секунд. Таким образом, к сожалению, нельзя полагаться при таймингах астрономических явлений на единожды сделанную синхронизацию дольше нескольких часов (а то и минут, в зависимости от требований точности), и приходится выполнять эту синхронизацию регулярно.
Ну и третья пичалька произрастает от того, что, хотя компьютер и «быстро думает» по человечьим меркам, но выполняет несколько (десятков) программных процессов одновременно, переключаясь между ними одним (двумя, четырьмя, двенадцатью) процессором(ами) под командованием операционной системы, которая не всегда может гарантировать, что определенное приложение (например, которое записывает картинку с камеры) получит управление в определенный момент. Это напрямую относится к Windows XP/7/8, которые не являются операционными системами реального времени. Отсюда следует, что, во-первых, всегда есть задержка между получением картинки, ее привязкой ко времени и фактической выгрузкой на носитель, и, во-вторых, эта задержка далеко не всегда остается предсказуемой. Тут можно было бы сесть и заплакать. Но когда слезы высохнут, можно попробовать оценить масштабы временных ошибок для разных вариантов наблюдений.
Читать далее...
К примеру, я потестил такой «визуальной петлей» QHY5L-II в EZPlanetary при 800х600, получил среднюю задержку 83 мс (+/-16 мс); на 320х240 было 42 мс (время считывания с сенсора уменьшилось). QHY5V в QGVideo32 показала время задержки меньше времени обновления экрана (< 17 мс), а FireCapture c Genius Trek320R – 95 мс. Тестилось на одном компьютере, на других значения будут немного другими.