Кратковременная и долговременная стабильность часов

[wrest]

wrest в сообщении #1378213 писал(а):

Вряд ли (но тут я не знаю чесговоря) какое-то приложение, которое мерит ход настенных маятниковых часов, может пользоваться gps-ом сперва для определения систематичекой погрешности системных часов гаджета, чтобы потом её учитывать скажем при определени длительности ста-двухсот-трехсот полупериодов (ака полуколебаний - "тиков" и "таков").

А такое приложение нашлось! Правда, для ПК (windows-linux-macos).
В это приложение специально встроена функция, которая слушает одногерцовые тики в течение 15 минут и калибрует себя по ним.
15 минут берется из-за того что в кварцевых часах есть такая штука как пропуск импульсов, но за 15 минут как правило все усредняется.
Поскольку известно что кварцы штуки очень стабильные при постоянной температуре, то калибровка предполагается в два этапа: сперва засечь точность кварцевых часов, скажем видеометодом с периодом 10 суток (это даст погрешность примерно в 10мс в сутки это около 0.1 ppm), а потом уже этими часами калибровать программу (она посчитает отклонение от кварцевых часов, к нему добавить собственное отклонение часов). Точность калибровки предполагается 0,1 spd, т.е. порядка 1 ppm.

P.S. Если кому интересно -- это open source приложение, гитхаб тут : https://github.com/vacaboja/tg

-- 25.10.2019, 10:36 --

Dmitriy40 в сообщении #1378721 писал(а):

Для сравнения параметры обычного часового кварца на 32768Гц: начальная точность ±20ppm, температурный дрейф 0.04ppm/°C²,

Кстати, я тут сподобился померить одни из часов. Лежащие при средней комнатной температуре 25 градусов часы уходят на 1с в сутки, а на руке (это 33 градуса) на 0,9с то есть 1,1 ppm на 8 градусов. Примерно в два раза лучше чем ваша цифра 0.04ppm/°C² но порядок да, такой.

[Dmitriy40]

wrest
Засада в том что постоянная средняя температура не гарантирует нулевого ухода, зависимость же от температуры не линейная, в квадратичная, и значит важна не только средняя температура, но и конкретный её вид за всё время анализа (грубо говоря уход времени при +5°С в течении 4ч не равен уходу времени при +2°С в течении 10ч, хотя средняя температура одинакова). Потому кстати не имеет особого смысла мерить уход точнее десятых долей ppm в комнатных условиях дольше пары часов - температура успеет уйти, особенно если в интервал попадётся переход день-ночь. И потому же уход за ровно сутки будет немного разным при контроле в разное время суток (например с 9ч до 9ч или с 15ч до 15ч или с 23ч до 23ч). Насколько именно разным - зависит от конкретного графика изменения температуры в течении суток, но прикидочно порядка 0.1ppm.

[Emergency]

Хотелось бы уточнить два момента.

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

2. При включении GPS начинается процедура синхронизации часов спутника с часами (кварцем) приемника. Естественно программно-аппаратно, путем подачи напряжения смещения на кварц, что позволяет плавно перестраивать его частоту. Без достижения синхронизации с часами спутника, GPS на приемнике просто не заработает.

[wrest]

Emergency в сообщении #1422423 писал(а):

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

Это, знаете ли, "в пользу бедных". Ну типа "Волга впадает в Каспийское море"...

-- 25.10.2019, 20:34 --

Pphantom в сообщении #1378596 писал(а):

У нас каждый очередной курс, доживший до астрометрической практики, стабильно интересуется вопросом о том, может ли NTP заменить хронометры/ГНСС (со сравнительно сложной процедурой сверки и прочими шаманскими действиями по определению поправки часов), и стабильно же получает примерно один и тот же результат: до 0.1 с все нормально (за вычетом разовых неудачных случаев, которые иногда все же встречаются), еще порядок получится, если сильно повезет. Еще лучше - совершенно нереально.

Вы не могли бы все-таки раскрыть подробнее -- что именно регулярно не удается сделать студентам? Что они делают и что такое "результат до 0.1с"?

[Pphantom]

wrest в сообщении #1422437 писал(а):

Вы не могли бы все-таки раскрыть подробнее -- что именно регулярно не удается сделать студентам? Что они делают и что такое "результат до 0.1с"?

Так куда уж подробнее (особенно если прочитать предыдущие сообщения и учесть контекст)... Идея состоит в том, что данные серверов NTP можно использовать как источник точного времени вместо штатной процедуры для определения поправки часов. На практике в пределах $0.1$ секунды - можно, а иногда ошибка оказывается еще в несколько раз меньше (что, правда, можно выяснить только путем сравнения данных NTP с более аккуратными методами). Дальше - никак, причем ошибки оказываются систематическими. Как-то раз один особо упертый товарищ попытался поискать систематику и даже что-то нашел... с квазипериодом в районе полутора недель. Будущие теоретики придумали сразу несколько гипотез, призванных объяснить сие, но, как показали последующие замеры, толком ни одна не сработала. В общем, банальный экспедиционный пассажный инструмент оказывается точнее.

[wrest]

Pphantom
Я правильно понимаю, что делалось примерно следующее:
Студенческая программа на компьютере синхронизировалась по NTP (по всем "канонам", с выбором сервера с минимальным джиттером и т.п.), под "синхронизировалась" понимаем вычисление смещения к системным часам, и затем, пока синхронизация не ушла (10-20 секунд или меньше), подавала какой-то сигнал на какое-то внешнее устройство, скажем точно в начале очередной секунды, и этот сигнал сравнивался с эталонным (ну скажем, 1PPS с GPS приемника) и оказывалось, что разница с эталонным сигналом почти всегда была больше 10мс.

[Pphantom]

Не совсем. Локальный стандарт частоты регулярно синхронизировался по NTP (да, со всеми этими оговорками) в течение наблюдательной ночи и при последующей обработке наблюдений сравнивался с другими доступными источниками (собственнные наблюдения, рубидиевый стандарт, радиосигналы точного времени, GPS/ГЛОНАСС). Разница почти всегда больше 100 мс и совсем всегда больше 10 мс.

[wrest]

Pphantom в сообщении #1422452 писал(а):

Не совсем. Локальный стандарт частоты регулярно синхронизировался по NTP (да, со всеми этими оговорками)

Извините мою тупость, но что за локальный стандарт частоты, который надо синхронизировать несколько раз за ночь?
И как стандарт частоты вообще можно синхронизировать со временем?

[Pphantom]

wrest в сообщении #1422455 писал(а):

Извините мою тупость, но что за локальный стандарт частоты, который надо синхронизировать несколько раз за ночь?
И как стандарт частоты вообще можно синхронизировать со временем?

Эм... а просто часы вас устроят?

[wrest]

Pphantom в сообщении #1422456 писал(а):

Эм... а просто часы вас устроят?

Да, но вопрос - зачем синхронизировать часы несколько раз за ночь (т.е. несколько часов) - сохраняется. Просто если они такие плохие, то неудивительно что уходят на 100мс...

А причины анализировали почему 10мс не получалось (уж не говоря о 100мс)?
Протокол же "заточен" на учет задержек и все такое. Средняя ошибка же не должна, по идее, превышать джиттер задержки (которая roundtrip), который также меряется протоколом. Или намерянный джиттер был эти самые 100мс?

[Pphantom]

wrest в сообщении #1422462 писал(а):

Да, но вопрос - зачем синхронизировать часы несколько раз за ночь (т.е. несколько часов) - сохраняется. Просто если они такие плохие, то неудивительно что уходят на 100мс...

Во-первых, кашу маслом не испортишь. Во-вторых, конечно, с учебными целями без этого можно обойтись, но для реальной работы (и соответствующей точности) это совсем не лишняя процедура. Кроме этого, вы невнимательны - про ход часов порядка 100 мс не говорилось, речь шла об ошибках NTP.

wrest в сообщении #1422462 писал(а):

Средняя ошибка же не должна, по идее, превышать джиттер задержки (которая roundtrip), который также меряется протоколом. Или намерянный джиттер был эти самые 100мс?

Ключевое слово - средняя. Она-то обычно составляет штуки мс, но то, что ошибка однократного измерения не будет больше, это не гарантирует.

[wrest]

Pphantom в сообщении #1422465 писал(а):

Ключевое слово - средняя. Она-то обычно составляет штуки мс, но то, что ошибка однократного измерения не будет больше, это не гарантирует.

Но вы-то говорили что "разница почти всегда больше 100мс", а теперь, что "обычно составляет штуки мс"
Я не понимаю, помойму на бытовом языке "почти всегда"="обычно" :(

P.S. Мы же одинаково под средней ошибкой понимаем среднеквадратическое отклонение? Ну или в крайнем случае среднее арифметическое модулей. Да и джиттер то ведь это тоже среднеквадратическое отклонение задержки...

[Pphantom]

wrest в сообщении #1422467 писал(а):

Но вы-то говорили что "разница почти всегда больше 100мс", а теперь, что "обычно составляет штуки мс"

Да, наверное, надо выражаться аккуратнее.

Дело в том, что постоянный поток данных с NTP, вообще говоря, не нужен. Нужны разовые отсчеты (порядка десятков штук за ночь), которые сравниваются с другими данными при последующей обработке. И вот среди этих отсчетов почти всегда находится отклонение, большее 100 мс, которое портит обработку, если основывать ее на данных NTP (как минимум соответствующие данные придется выбросить). Отклонение (или отклонения), большие 10 мс, находятся наверняка.

wrest в сообщении #1422467 писал(а):

Мы же одинаково под средней понимаем среднеквадратичную? Ну или в крайнем случае среднее модулей. Да и джиттер то ведь это тоже среднеквадратичное отклонение задержки.

Да. Но это не оценка модуля отклонения сверху.

[wrest]

Pphantom
То есть из десяти ночных замеров по NTP, каждый из которых не к случайному серверу, а к тому из длинного списка, с которым наименьший джиттер задержки, либо к 4-5 серверам с "хорошим" джиттером, с усреднением смещения по ним, почти всегда как минимум один оказывается хуже 100мс, хотя в среднем ошибка по этим десяти замерам - единицы мс. Так?

[Pphantom]

Да.