Тайминг астрономических событий

[acmajor]

Для привязки видео (немножко в другой задаче) я применят такую матрицу светодиодов. По сигналу PPS зажигается первый светодиод, через мсек. тухнет и зажигается второй, горит тоже 1 мсек и т.д. как вся матрица отработала,тухнет и ждет следующий PPS. Таким образом привязка идет не только к каждому PPS, но и в интервале между ними (для оценки нестабильности каждого кадра). Может имеет смысл сделать подобное и поместить в углу кадра? Конечно изменив длительность работы матрицы до 0,7 сек. чтоб 0,3 сек. был перерыв для отождествления прихода нового PPS.

[xd]

Мы с @1212Lupus примерно так же делали: запускается бегущий огонёк по матрице с разными величинами задержки. Пришлось очень сильно заморочиться, чтобы обеспечить качество шкалы времени при этом.

[Serj]

Ха, очень VEXA напоминает. http://www.dangl.at/vexa/vexa.htm

[TMN]

Или EXTA http://www.dangl.at/exta/exta_e.htm

[acmajor]

Да. Действительно похоже. Когда я это делал прототипов не нашел. Не нашли и патентоведы не мои местные, не в ФИПСе. Не помню когда это у меня вылилось это в железе, но патент меня уговорили оформить гораздо позже. И произошло это в 2011 году. Судя по Вашей ссылке страничка создана в 2008 году. 

[TMN]

Друзья! Может ли кто объяснить, что за хрень выдаёт Dimension 4, когда строит историю синхронизаций? Всё время строится какая то пила. Доводя величину синхронизации до половины секунды, она обрывается до значений в единицы миллисекунд и так некоторое время держится. Затем опять начинается нарастание величины синхронизации и всё периодически повторяется. Я думал, что это особенности моего компьютера, или сервера, где я получаю точное время. Но оказалось, что эта пила присутствует везде. Я проверял на 3 компьютерах, на виндоус семёрке и десятке, менял серверы точного времени, в т.ч. и заграничные, менял провайдеров интернета. Я менял интервалы коррекции от секунд до десятков минут. Везде присутствовала эта характерная пила. Причём коррекция времени аж на пол секунды никак не обнаруживалась на ходе системного времени. 

[acmajor]

Когда я занимался проблемами синхронизации ПК и Сервера (операционка реального времени QNX-4) у меня получалась аналогичная пила для внутренних часов любого ПК. Угол наклона (в том числе нарастающий или ниспадающий) и время между обнулениями графика однозначно зависели от  времени тика ОС (тик - квант времени который ОС выделяет для каждого отдельного процесса, работающего в многозадачной среде). Эталоном выступала физическая метка GPS-приемника, измеряемая величина была количество тактов генератора процессора (порядка 2 ГГц.). Как система знала когда нужно добавить или отнять константу чтоб выровнять кол-во тиков - до сих пор не понимаю!!! При любых значениях тика поправка не превышала значение установленного при старте ОС тика. К сожалению QNX-4 не имеет возможность установить тик меньше 10 миллисекунд и провести более точные измерения для этой ОС не получится.

[TMN]

Ну, яснее картина не стала! Самое интересное, эта пила обнаружилась в программе Dimtnsion4 не так давно - 3 или 4 года назад. А до этого была заурядная история синхронизаций, когда график состоял из совершенно случайных отклонений, в равной степени имеющих как положительные, так и отрицательные значения коррекции времени.

[acmajor]

А как проходят измерения? Что является эталоном и что измеряемой величиной? Эти измерения производятся отдельной железякой или это программа в ПК? Если программа, то какая ОС? В Win_XP у меня были расхождения внутренней шкалы времени с эталоном в 1,2 сек (при загрузке ЦП 100%). После многочисленных измерений я пришел к выводу, что за время (текущее, мировое) и временные интервалы должно отвечать отдельное, независимое устройство.

[TMN]

Увы, всё делается в ПК. Я бы с удовольствием пользовался внешними устройствами, которые отвечают за точное время, но таковых не имею. Всё получаемое мной время проходит через обработку компьютером и только потом поставляется в программы - потребители этого времени. Как я уже писал, программа Dimension 4, которая синхронизирует систему, испытывалась при работе в различных условиях. В винде семёрке и десятке, на разных компьютерах, при подключении различных серверов точного времени, при работе через две различных провайдерских сети и даже при работе с сервером точного времени во внутренней сети. Пила присутствовала везде. Недоумение возникает ещё из за того, что несколько лет назад этой пилы не было. Dimension 4 сама производит измерения отклонений времени, синхронизирует часы и строит историю синхронизаций. Ради любопытства я сравнивал время, полученное Dimension 4  и программой синхронизации по GPS. Обычная разница составляла 0,03 - 0,04 сек. Во вложении видна эта разница. Программа NMEATime2 прописывала график отклонения и коррекции времени. Интересно, что первый участок графика, где очень маленькие колебания отклонения времени (синий график) и коррекции времени (красный график), получен во время работы астрономической камеры в программе SharpCap 4.0 При отключении камеры колебания отклонения времени резко возрастают (средняя часть графика), хотя держатся возле нуля. И в конце графика я запустил Dimension 4, который стал по своему корректировать время, что видно по провалу графика на величину приблизительно -0,037 сек.

[acmajor]

  Все ОС, которые не РВ(реального времени) сильно зависят от загрузки и любая внешняя синхронизация это не исправит. ОС с поддержкой РВ тоже не фонтан, но там есть фиксированные (постоянные) кванты времени, которые отдаются тому или иному процессу. Если программе синхронизации установить приоритет выше пользовательского (где нибудь на уровне системного), то можно получить вполне приемлемые результаты. В ОС QNX-4-25 с приоритетом 21 (пользовательский по-моему не выше 17, а максимальный системный 24) я получал привязку внешнего сигнала (LPT-порта) в районе 80 микросекунд. Для привязки к GPS-секунде мне пришлось сделать отдельную железяку на микроконтроллере ATMega8515 с внешним кварцем и ежесекундной корректировкой начала секунды по GPS-секунде (погрешность приемника 250 нсек). Описание можно посмотреть на сайте Российского ФИПС, патент на полезную модель №108865. В принципе я там постарался подробно описать механизм работы устройства. Это отдельно стоящая железяка, которая только следит за временем и привязывает внешние сигналы к мировому с погрешностью 0,5 мксек. Но еще раз повторюсь: ни одна из испробованных ОС(Windows, МСВС, Linux) не являлись РВ (реального времени) и погрешность от измерения к измерению плавала в десятки тысяч процентов!!! Конечно для каждой ОС персонально. И основная проблема не в точности привязки события (миллисекунды, микросекунды или наносекунды) а в том, что это не контролируемая (плавающая) величина. И учесть ее практически не реально. Приемник GPS обязательно должен иметь физический выход ТТЛ-секунды (PPS). Для каждого такого импульса через примерно 0,2 сек. приемник выдает по СОМ-порту сообщение с временем на сколько этот импульс не совпадает с истинным мировым.

[TMN]

Перевёл статью "Использование часов Windows с сетевым протоколом времени (NTP) для тайминга покрытий". https://disk.yandex.ru/i/lQYc2OY20kEUMw Для тех, кому интересно. Исходник статьи здесь https://iota-es.de/JOA/JOA2020_2.pdf .

[TMN]

Выложил небольшое видео касающееся точности 1PPS сигналов на дешёвых GNSS модулях https://youtu.be/EYKO_1yKmGI

[TMN]

Выложил небольшую обучалку для тех, кому надо подключить GNSS модуль к компьютеру. https://youtu.be/DbeQhYpnq64

[Астровитянин]

Я правильно понял из вашего видео, что точности этого свистка достаточно для тайминга покрытий звезд астероидами? Решил снова попробовать понаблюдать покрытия, в начале нулевых активно этим занимался, но только с секундомером. Сейчас приобрел новую камеру, можно теперь заморочиться съемкой видео покрытий.

[TMN]

Даже не то, что достаточно, но и избыточно. Точность определения момента покрытия определяется длительностью экспозиции кадра. В пределах экспозиции вы не сможете определить, когда произошло покрытие. Обычно длительность экспозиции 40 мс. (25 к/с) для формата PAL. На астрокамерах fps может быть и больше, но вряд ли больше 100 к/с. А у этих мигалок точность получения времени (точность привязки мигания к UTC) это единицы микросекунд. Даже у самых кондовых мигалок, о чём свидетельствуют и мои опыты. Этого, сами понимаете, хватает за глаза. Та свистулька, фото которой вы представили - я бы её не покупал. Не то, чтобы она была неточной, но я такую свистульку знаю. Она работает только в системе GPS да и модули у них 7-го поколения. Если америкосы захотят нам отключить GPS, то это будет простым куском пластмассы. Есть свистульки с очень похожим корпусом на котором написано не GPS/Glonass, а GPS/GLONASS/Beidou (или что то подобное). Эти честно ловят все группировки, которые прописаны на корпусе, и даже такие как Galileo и QZSS при определённых махинациях в программе U-Center. Кстати, посмотрел Вашу камеру. Не знаю оправдано ли, но у меня есть определённые сомнения. Она имеет буферную память, которая может придерживать выдачу видеопотока по своим каким то соображениям. И если таки камера это делает, представляете, как это сказывается на точности тайминга!?

[acmajor]

В пределах экспозиции вы не сможете определить, когда произошло покрытие.

Позвольте с этим немножко не согласиться.
Если провести калибровку камеры (зависимость яркости эталонного источника от времени экспозиции ) можно получить минимум 0,1 времени экспозиции. Если звезда экспонируется полный кадр то суммарная ( сумма яркостей всех пикселей звезды) максимальна . Как только звезда экспонируется не полный кадр - суммарная яркость ее будет меньше.Нужно только получить ряд измерений одного объекта с разным временем экспозиции и получить зависимость яркости в кадре от времени экспозиции.  Для встроенного светодиода это не очень точное измерение (сильное влияние нестабильности источника питания, температуры и т.д.) то для слабой звезды в изображении это реально. Если питать светодиод от внешнего PPS со стабилизацией тока светодиода - то это тоже вариант.
Покрытием я не занимался, но в работе была похожая задача. Погрешность таких измерений меня не устроила и решил эту задачу дополнительой электроникой.

[TMN]

Позвольте с этим немножко не согласиться.

Ну, если  только немного. Степень экспонирования звезды на момент исчезновения или появления звезды оценивать довольно сложно, из за того, что звезда как раз очень нестабильный источник света. Основные причины этого турбуленция атмосферы и шумы. Кроме того, когда происходит явное изменение яркости звезды, не очень понятна его причина. Это может быть от того, что звезда недоэкспонирована при гашении звезды на границе 2 соседних кадров видео, а может быть просто частичный заход звезды за край астероида. Между прочим, светодиод на GNSS модуле очень стабилен как источник, как по  периодичности, так и по яркости вспышки, благодаря чему я могу для неё  оценивать ту долю экспозиции, где эта вспышка имеет ступенчатый переход яркости.

[acmajor]

светодиод на GNSS модуле очень стабилен как источник, как по  периодичности

А как он там термостабилизируется (просто я с такими приборами не работал)? На счет периодичности - с Вами согласен в пределах точности Ваших измерений (миллисекунды). Положение фронта PPS и его длительность (по паспортным данным на изделия РИРВ) по памяти в пределах 250 нс. Вполне согласен, что для 100 к/сек это что слону дробина.
А какое время проходит от начала покрытия до полного покрытия? Я в этом к сожалению не силен. Если это несколько кадров, то ведь можно построить аппроксимацию графика. Турбулентность для объектов на уровне фона это смерть! Но если объект достаточно яркий, то тоже ведь его можно усреднить из предыдущих кадров? Шумы кадра внесут конечно гораздо больше нестабильности яркости чем турбулентность.
На счет недоэкспонированности соседних кадров я как раз предполагал, что длительность каждого кадра стабильна хотя-бы в пределах 1 сек. (возможно это желаемое). Она однозначно гуляет, но это может десятки минут, а в соседних 10-20 кадрах она ведь должна быть одинаковой (ну может с разницей 1-2%).

[TMN]

Честно говоря, не знаю как термостабилизируется модуль. Я даже не вижу в этом необходимости, так как приходящие 1PPS  импульсы каждый раз корректируют работу внутреннего таймера.
Переход от полной яркости звезды и её гашением как правило очень быстрый - порядка. единиц миллисекунд. Иногда и дольше, когда скорость тени по поверхности земли мала, или звезда имеет значительный угловой размер. Бывает, видно гашение звезды в течении 2 кадров, редко 3. Колебание яркости сигнала из за турбуленции и шумов для моего оборудования 1/2 - 1/3 от среднего уровня сигнала, и не менее 1/6. Стабильность частоты кадров довольно высокая. Т.е., если я устанавливаю какую то частоту кадров, то через любые равные промежутки времени я получаю равное количество кадров. Однажды я снимал в течении 1,5 часов и все кадры уместились в положенное время. Нарушение закономерности происходит на форсированных скоростях съёмки, но я на таких никогда не снимаю покрытия.