А то, что у долготы и широты ограниченное число разрядов, Вас не смущает? Только за счёт этого погрешность может достигать 11мм. А режим работы какой? Вы что, в RTK работаете? Для таких задач NMEA - не лучший выбор. Может, стоит посмотреть "родной" протокол приёмника?
Саша, а как же GGALONG? (Добавление) Example: (Добавление) Тем не менее: Using NMEA as a GPS Timing Reference
Да, это я понял. Особенно про разряды координат. Вы правы, нужно смотреть родной протокол. Нет, работаем не в RTK.
Именно для этого случая я и считал, вот только в расчётах ошибся Тогда зачем гнаться за миллиметровой точностью, если у Вас погрешность определения координат гораздо выше?
Система, наверное, строится для пост-обработки и необходимо с максимальной точностью подручными средствами отметить время прихода маркера (может и ошибаюсь)... Без сигнала PPS точно не обойтись. (Добавление) и, кстати, маловероятно, что переход на внутренний формат данных приемника (не NMEA) даст сколь более точный вариант синхронизации без импульса 1 PPS.
правы и Сергей: и Александр: Я мечтал, чтоп измерительный девайс на борту привязывал "на лету" свои измерения к точному времени, для облегчения постобработки. У девайса есть внутренние часы, но очень дряненькие, пользоваться ими не можно. Импульс 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-приводах мешает :) Вот это УШИ !
