Создание изолированного NTP-сервера только с 1PPS и без внешнего “временного” ввода (без GPS)

Я хочу, чтобы небольшой NTP сервер (Chrony) предоставлял время различным компьютерам, расположенным на одном учебном подводном аппарате, подключенном с помощью Ethernet-кабелей. Для нас в первую очередь важно, чтобы различные части аппарата синхронизировались друг с другом с отклонением менее 10 мс на протяжении нескольких дней.

Некоторые электронные устройства синхронизируются напрямую с помощью источника 1PPS, поэтому важно, чтобы NTP сервер и источник 1PPS были синхронизированы.

Синхронизация “системного времени” с реальным временем не обязательна, но было бы хорошо, если бы она была бесплатной.

В настоящее время у нас есть:

• Источника частоты 1PPS
• Встроенный компьютер с RTC, который считывается при запуске
• GPS-приемник, но на него в идеале нельзя полагаться, так как GPS не работает под водой.

В настоящее время мы подаем сигнал 1PPS и GPS-строку в USB-Serial преобразователь (FTDI), затем это считывается gpsd, который правильно берет сигнал 1PPS и GPS-строку для Chrony. Это работает и дает нам около 2 мкс синхронизации с 1PPS и GPS.

Существующая конфигурация имеет ограничения для нашего применения:

1. gpsd требует действительную GPS-временную строку для инициализации времени, это не всегда доступно, так как у нас плохой прием GPS на воде и совершенно отсутствует под водой.

2. gpsd также требует непрерывные действительные строки для обработки прерывания 1PPS. Это в основном проблема, если мы хотим отключить GPS-приемник под водой, чтобы сэкономить энергию, но при этом хотим продолжать синхронизацию с 1PPS.

3. Как только GPS теряется или GPS-устройство выключается, системное время начинает отклоняться от источника 1PPS.

Я понимаю, что “gpsd” сильно зависит от GPS, поэтому я использую неправильный инструмент.

Вопросы:

1. Возможно ли подать 1PPS напрямую в Chrony?

   1.1 Может ли Chrony использовать этот 1PPS и только системное время, не получая реальный источник времени, кроме RTC?

2. Существуют ли примеры того, как добавить источник /dev/pps, используя RI или DCD пин преобразителей USB-to-Serial FTDI? Например, что делает gpsd под капотом, но без его использования.

Частично отвечая на свои собственные вопросы на основе нашего опыта и ошибок.

Вопросы: 1. Возможно ли подать 1PPS напрямую в Chrony?

Ответ: 1 Конфигурация Chrony использует 2 метода для получения PPS:

• Получить его из SHM1 (разделяемой памяти), куда его помещает gpsd
• Получить его напрямую из устройства /dev/pps

Пример конфигурационных строк:

refclock SHM 1 refid PPS precision 1e-9
refclock PPS /dev/pps1 refid PPS2 precision 1e-9

Некоторые потенциальные подводные камни, касающиеся задержек, также описываются в Часто задаваемых вопросах.

Вопросы: 1.1 Может ли Chrony использовать этот 1PPS и только системное время, не получая реальный источник времени, кроме RTC?

Ответ: 1.1 Да, если вы добавите эту строку:

local stratum 10

Тогда Chrony вернется к локальным часам, если потеряет все свои источники. Это также кажется необходимой строкой для того, чтобы сервер времени продолжал быть работоспособным, если у него есть только источник /dev/pps и нет данных от GPS.

Вопросы: 2. Существуют ли примеры того, как добавить источник /dev/pps, используя RI или DCD пин преобразителей USB-to-Serial FTDI? Например, что делает gpsd под капотом, но без его использования.

Частичный ответ (обходной путь) 2: gpsd будет принимать pps как от RI, так и от DCD и передавать временные данные в SHM1. gpsd также автоматически создает виртуальное устройство /dev/pps1 и связывает его с последовательным портом, это не тот же самый 1PPS, который используется внутри gpsd!

При использовании ppstest на /dev/pps1 вы можете видеть переходы PPS для DCD, но нет перехода для RI. Использование ppscheck на последовательном порте показывает переходы pps как для RI, так и для DCD.

Мы полагаем, что gpsd разрабатывает собственную новую схему обнаружения 1PPS, но виртуальный порт /dev/pps1 использует устаревший ldattach (линейная дисциплина), который жестко закодирован только для DCD. смотрите этот пост.