OBS и NAV

А то, что у долготы и широты ограниченное число разрядов, Вас не смущает? Только за счёт этого погрешность может достигать 11мм. А режим работы какой? Вы что, в RTK работаете?
Для таких задач NMEA - не лучший выбор. Может, стоит посмотреть "родной" протокол приёмника?

 

Саша, а как же GGALONG?
(Добавление)
Example:

(Добавление)
Тем не менее:
Using NMEA as a GPS Timing Reference

 

Да, это я понял. Особенно про разряды координат.
Вы правы, нужно смотреть родной протокол.
Нет, работаем не в RTK.

 

Именно для этого случая я и считал, вот только в расчётах ошибся

Тогда зачем гнаться за миллиметровой точностью, если у Вас погрешность определения координат гораздо выше?

 

Система, наверное, строится для пост-обработки и необходимо с максимальной точностью подручными средствами отметить время прихода маркера (может и ошибаюсь)... Без сигнала PPS точно не обойтись.
(Добавление)
и, кстати, маловероятно, что переход на внутренний формат данных приемника (не NMEA) даст сколь более точный вариант синхронизации без импульса 1 PPS.

 

Речь шла не о синхронизации, а о привязке времени измерений.

 

измерений чего? координат в NMEA сообщении?
Тут бы неплохо было бы прояснить ситуацию.

 

правы и Сергей:

и Александр:

Я мечтал, чтоп измерительный девайс на борту привязывал "на лету" свои измерения к точному времени, для облегчения постобработки.
У девайса есть внутренние часы, но очень дряненькие, пользоваться ими не можно. Импульс TTL своих событий он посылать умеет.
Девайс может писать в лог файл разные события и комментарии к ним, вот я и думаю чтоп он писал туда свои события и противопоставлял им точное GPS время. Вот и всё что я хочу.

 

Здравствуйте, к своему большому удовольствию обнаружил этот форум, зачитался, и теперь хочется внести свою лепту.
По образованию я не профессиональный геодезист, но в морской геодезии и сейсмике с 90х годов. С миллиметровыми точностями мы не работаем по очевидным причинам, а вот что касается сбора данных и точной синхронизации по времени - это к нам (более точное время требуется, наверное, только в аэрофотосъемке) :)

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

Итак, обычная задача - система регистрации данных должна:
а) получить каким либо образом точную отметку времени UTC от внешнего устройства;
б) вычислить поправку к своим внутренним часам;
в) принять данные от других сенсоров (у которых нет своего точного времени), назначить им время по своим часам + внести поправку, получив таким образом "время по GPS".
Надо сразу отметить, что между последовательными отметками из п. а) время измеряется исключительно по встроенным в систему записи (даталоггер, компьютер и т.д.) часам.


1. Самая грубая ошибка заключается в самом факте передачи информации о точном времени через поток NMEA. Приемник производит внутренние измерения в запланированные моменты времени (обычно раз в секунду) по своим часам, далее требуется время на навигационное решение. К моменту, когда расчет закончен, сформировано текстовое сообщение и началась передача данных, уже прошло некоторое время (Latency). В старых тримблах 4000 это было порядка 0.5-1.0 секунды, наверняка в новых приемниках это значение ниже, но оно никуда не делось. Например вы получили сообщение GGA со значением времени 12:00:01 и поправили часы в своей программе, но на самом деле оно пришло в 12:00:01.3 ! Значение Latency непрогнозируемо.
Решения:
1.1 Некоторые приемники позволяют выдавать Skewed-координаты, т.е. пересчитанные на момент начала передачи по NMEA. Соответственно время в заголовке тоже поправлено и имеет дробные секунды;
1.2 Некоторые приемники выдают значение Latency отдельным полем в сообщении NMEA (например дополнительное поле в GGA), но это уже нестандартный формат;
1.3 В профессиональных навигационных программах (например для батиметрии, морской сейсмики, подводного позиционировани) в настройках оборудования можно задать Data Latency вручную. Подбирается экспериментальным путем.

2. Задержка передачи данных по каналу RS-232:
2.1 Она разная при различных baudrate, причем стандарт RS-232 не гарантирует передачу данных равномерным потоком, это на совести разработчиков аппаратуры;
2.2 Аппаратная задержка контроллера последовательного интерфейса. В свое время голландская компания QPS (известная продуктом QINSy для гидрографии) протестировала несколько плат-расширителей COM-портов, а также порты реализованные на материнской плате. Как и предполагалось, больше всего на задержку влияет размер буфера. В микросхемах 16550 (на материнской плате) это 16 байт, в Intelligent Board это могут быть килобайты.
Cамая минимальная и стабильная задержка была у COM-портов, встроенных на материнской плате, с отключенным буфером FIFO. Далее идут они же с FIFO разного размера, затем Non-intelligent мультипортовые платы (это те же 16550, только в количестве 4-8 штук на одной плате и все делят одно прерывание), затем Intelligent Boards (несколько 16550 + собственный процессор на борту + огромный буфер). Хуже всего дела обстоят у Ethernet-серверов RS232, переходников USB-RS232, Bluetooth - для real-time приложений они вообще не годятся т.к. задержка драйверов непредсказуема.

Решения:
2.3 Навигационный софт делает оценку RS-232 Tranmit Latency на основе значения baudrate. Например при скорости порта 9600,8-n-1 на передачу одного символа тратится 10 бит, или 1/9600*10 = 1.04 мсек. Дальше дело техники, можно получить сообщение целиком и, зная его длину, сделать оценку как давно оно начало передаваться. Можно сделать еще точнее и считать время передачи сразу после расшифровки заголовка (например $GPGGA,hhmmss). Меньше байт --> меньше ошибок из-за неравномерности потока данных;
2.4 Важно расшифровать время и поправить часы в программе как можно раньше. Например в потоке идут сообщения ZDA, GGA, VTG, RMC и т.д. Все они приходят в программу в разное время, хотя имеют одинаковое значение hhmmss. Поэтому лучше брать время из ZDA, т.к. это сообщение всегда (насколько я знаю) идет первым и имеет самую короткую длину. Плюс имеет дату, в отличие от остальных;
2.5 Критичные ко времени данные (например Inertial Sensors типа компенсаторов качки, датчиков крена, компасов и т.д.) заводить через встроенные на материнку COM-порты или Non-Intelligent Board. Но тут тоже палка о двух концах - такие сенсоры валят поток и по 50, и по 100 измерений в секунду, можно запросто загрузить систему что она просто начнет терять данные. Нужен компромисс.

Сами понимаете что ни о каких микросекундах тут даже говорить не приходится :) Вот мы и подошли к PPS. Вкратце процедура следующая.

3.1 Если в приемнике GPS разрешен вывод PPS, сначала по RS232 приходит сообщение со значением времени в обычном текстовом виде (в тримблах 4000 сообщение передавалось примерно за полсекунды до импульса PPS);
3.2 В программу навигации приходит импульс PPS, который тут же маркируется встроенными часами.
3.3 Теперь считается поправка к часам используя значение из п.1. В принципе можно поменять местами п.3.1 и 3.2, от этого ничего не изменится.

Тут уже можно говорить о нескольких микросекундах.

Осталось оценить точность времени в сообщении NMEA и импульса PPS, тут разные приемники ведут себя по разному. В первую очередь это зависит от того в какой момент производится измерение фазы C/A (code phase, из неё формируется псевдодальность путем добавления целого количества миллисекунд). Обычно это "целые GPS-секунды". Часы в приемнике дрейфуют, но регулярно поправляются и остаются в пределах -0.5/+0.5 мсек, хотя судя по сообщениям выше значения могут быть меньше.

В приемниках начального уровня последовательность такая:
4.1 Измерение планируется на момент, когда в часах приемника будет целая секунда (отличается от системного GPS-времени, см.выше);
4.2 В момент 4.1 производится одновременное снятие показаний со всех каналов;
4.3 Полученные C/A-phase переводятся в псевдодальности;
4.4 Решается навигационная задача, в результате чего имеем координаты и разницу часов приемника и системного GPS-времени dT;
4.5 Если dT больше определенного значения (0.5 мсек), часы в приемнике однократно корректируются. Поэтому можно наблюдать в тримблах как dT изменяется от -0.5 мсек до 0.5 мсек (или наоборот, в зависимости в какую сторону дрейфуют часы) и затем скачкообразно меняет знак, т.е. время в приемнике исправляется ровно на 1.0 мсек. В разных приемниках эти пределы разные;
4.6 Полученные в п.4.4 координаты передаются пользователю в NMEA, время предварительно поправляется в UTC.
ВНИМАНИЕ: время в строке NMEA в приемниках начального уровня - это время произведенного измерения фазы C/A, т.е. часов приемника, а это -0.5/+0.5 мсек ! Это же относится к сырым данным (например RINEX), собранных таким приемником.

В геодезических приемниках важное отличие в первом пункте:
4.1 Измерение планируется на момент, когда в часах приемника будет целая секунда + предполагаемое значение dT. Оно предсказывается на основе dT предыдущей эпохи и дрейфа часов, с точностью несколько наносекунд. Trimble называет их Synchronized Measurements. Соответственно данные в NMEA и RINEX будут иметь метку времени, синхронизированную с целой секундой системного времени GPS с точностью наносекунд. Нужно еще точнее ? Тогда либо Trimble Thunderbolt, в котором генератор частоты находится в термостате, либо атомный стандарт.

Если я правильно понимаю, отличия в п.4.1 - это исключительно маркетинговое ограничение, т.к. в реализации не представляет никакой сложности. Trimble славится такими решениями...


Ну и наконец сам импульс PPS. С какой точностью будет передан его фронт, зависит от канала передачи:
5.1 Некачественный кабель может размазать фронт импульса, лучше всего использовать коаксиальный кабель или, на крайний случай, витую пару;
5.2 Длина кабеля должна как-то учитываться, например она конфигурируется в приемнике Trimble Thunderbolt. Разные типы кабелей имеют разную эффективную длину задержки сигнала (например 10м физической длины превращаются в 15м задержки PPS);
5.3 Момент передачи импульса PPS. С геодезическими приемниками всё понятно, с более простыми - всё неочевидно... Хотя где-то читал что в любых приемниках импульс PPS привязывается именно к системному времени, т.е. с учетом dT.


Есть еще один способ маркировать события - вводить импульс события в сам GPS-приемник (если в нем реализована возможность External Event Mark). Тогда не нужны ни NMEA, ни PPS.

Извините если написал сумбурно, будет интересно узнать как обстоят дела в приемниках других фирм, не только Trimble.

Напоследок немного юмора из жизни. Как-то на eBay случайно наткнулся на рубидиевые стандарты частоты (они там стоят до 200$), продавец в описании написал что одно из применений - использование в аудиофильских CD-приводах. Им уже не хватает проводов из серебра, бескислородной меди, ламповых усилителей... Замахнулись на атом! Джиттер им в CD-приводах мешает :) Вот это УШИ !

 

chnav
"Респект и уважуха" (с). Просто снимаю шляпу...
Добро пожаловать на Форум!