Комментарии 14
Спасибо за статью, очень интересно! Добро пожаловать на хабр. Написал в личку предложения по улучшению.
В моём случае всё отлично завелось. Сразу делаем symlink для ttyUSB0 в виде gps0
Это не пропадет после перезагрузки?
Одна проблема - точность временных интервалов доставки пакетов через USB стек нивелирует точность самого GPS. Более правильное решение - работать через железный RS-232, дергая одну из ног выходом PPS приёмника.
С развитием технологий уже перестает хватать точности обычного NTP и приходится мигрировать на PTP. Один из примеров - SMPTE 2210.
Ага, получается непредсказуемый джиттер вносит еще и сам USB-UART конвертер? Особенно если это какой-нибудь китайский CH***?
Более правильное решение - работать через железный RS-232, дергая одну из ног выходом PPS приёмника.
То есть юзать только дискретный PPS и вообще не читать NMEA-данные?
Конвертер тупой, вряд-ли он может вносить существенный джиттер. Вносит сам USB - конвертер оправил пачку данных, а дальше ждем пока у системы появится свободное время обработать прерывание, вычитать данные из буфера, передать их в userspace и обработать текст протокола. С парсингом NMEA, насколько помню проблем нет, но для максимальной точности желательно учитывать длину соединительного провода и время передачи самих сообщений на такой небольшой скорости интерфейса - это всё вносит фиксированную задержку. Таких проблем как раз и нет при использовании PPS, но само ядро еще должно быть собрано с его поддержкой, а в случае NAS это маловероятно.
Конвертер тупой, вряд-ли он может вносить существенный джиттер
Да не совсем, это целый контроллер, со своими многоуровневыми буферами. Спецификации задержек в даташите я не нашел.
но для максимальной точности желательно учитывать длину соединительного провода и время передачи самих сообщений на такой небольшой скорости интерфейса - это всё вносит фиксированную задержку
Это точно в пределах погрешности)
Таких проблем как раз и нет при использовании PPS, но само ядро еще должно быть собрано с его поддержкой, а в случае NAS это маловероятно.
А как в этом случае решается "проблема" no-realtime обработки этого всего со стороны ядра?
Так в USB есть изохронный режим - будет какое-то запаздывание, но фиксированное. А вот как потом точно по времени ловить момент перехода ноги RS232 между состояниями - не поделитесь?
Изохронный режим есть, но используется в основном для передачи аудиотрафика и ограничен по битрейту. Интересно стало даже теперь в каком режиме работают конвертеры интерфейсов.
Ловить - через Kernel PPS. Интерфейс в ядре есть, gpsd умеет им пользоваться.
Вот ссылочка, думаю будет полезна - https://habr.com/ru/company/ruvds/blog/509890/
FT232 (к примеру), да и сама STM32, работают в BULK. Ну и за неимением лучшего (аппаратного RS232 в большинстве современных девайсов), некий колхоз с участием USB-Audio выглядит приемлемым способом ввести в компьютер что-то низкочастотное и критичное по времени.
Кстати, хорошая статья, там раскрывается вопрос "ради чего это все".
PPS ±5 μSec
Интерфейс USB 2.0 ±100 μSec (100000 nSec)
NTP по сети ~±30 mSec
Интересно, но .... И главное, зачем, если есть интернет?
Synology NAS добавляем сервер точного времени с синхронизацией от GPS