OBS и NAV

Прошу помощи. Какова структура вышеназванных файлов? Как благодаря данным из этих файлов можно высчитать позиционные данные?

 

..

Описание структуры RINEX

Если речь о навигационной задаче (автономно), то решаем систему уравнений:



Xi, Yi, Zi - координаты i-го спутника в геоцентрической прямоугольной СК (которые необходимо рассчитывать из файла nav)
Pi - псевдодальность от приемника до i-го спутника (которые записаны в файле Obs)
x,y,z - определяемые координаты приемника
b - расхождение шкалы времени приемника и системного времени GPS

Все записано на фиксированный момент времени.

Остальное читать, читать и читать, для подробного описания, думаю места на форуме не хватит :)

 

кому не сложно, разложите, пожалуйста, по полочкам:
1. Какие данные указываются в obs и nav файлах
2. какие исходные данные необходимы для создания obs и nav?
3. Имея исходные данные в каком-нибудь формате , можно ли с помощью какого-нибудь программного средства преобразовать их в Rinex?

Сергей Флерко дал ссылку на описание структруы Rinex, за что ему большое спасибо, а у меня даже времени нет разобраться самому.
Помогите, пожалуйста, кому не трудно. Заранее спасибо.

 

Вот еще ссылочка:
Описание формата RINEX

А в каком формате есть?

 

Подскажите, пожалуйста: чем отличаются файлы nav и auto,предоставляемые на сайте SOPAC?


и какой из них нужно использовать для обработки в ПО
(Добавление)
все понял. Авто-для всех станций. NAV-только для какой-то определленной GPS-станции.

 

Исправляете до точки имя любого файла с расширением N до требуемого названия станции и получаете файл AUTOю Навигационные файлы ОДИНАКОВЫ для приемников всего мира (если суточные или если записаны в одно и то же время)

 

да,спасибо, я понял

 

В OBS или O - измерения: кодовые, фазовые и Доплера, значения отношения сигнал / шум

бинарные файлы ИЗМЕРЕНИЙ GPS (GNSS) приемников, но не бытовых (навигационных), а способных выдавать на выход (СОМ порт или регистрировать в память) именно "сырые" измерения (кодовые и фазовые)

Можно, если это данные "сырых" измерений, но не NMEA. У каждого производителя свои программы-конвертеры, но есть и универсальные варианты программ

 

а если в obs записывать лишь псевдодальности, возможно решение позиционной задачи?

 

Не совсем корректное утверждение. Если приёмники находятся по разные стороны Земли, то в одно и то же время они видят разные спутники, значит, навигационные файлы будут существенно разными. Для примера скачал данные станций alic (Австралия) и stjo (Канада). Навигационные файлы содержат очень мало одинаковых эфемерид, поэтому не получается обработать наблюдения alic с навигационным файлом stjo и наоборот.
Вывод: используйте навигационный файл от сравнительно близкой станции или файл auto - он содержит ВСЕ эфемериды.

Возможно.

 

спасибо

наверняка, точноть то хуже будет, если без частот решать

 

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

 

понятно, большое спасибо

 

Доброго дня.
Возник вопрос: какова точность времени в NMEA протоколе?

 

Конечно, зависит от модели Вашего приемника, но:
после первоначального скачивания эфемерид время приемника устанавливается с точностью ± 10 мс, после получения навигационного решения точность шкалы времени приемника будет уже в пределах ± 1 мкс . IMHO на эту цифру и надо рассчитывать при считывании времени с NMEA сообщения.

 

Я знаю, что, например, приёмники Trimble 5700 не "поддёргивают" внутреннюю шкалу времени приёмника к системному. Т.е. в сырых наблюдениях можно наблюдать как отличие шкалы времени приёмника от сист. растёт от ~0 до 2500 мкс, затем приёмник меняет знак накопившийся ошибки на -. И всё повторяется до +2500 мкс. Затем заново.
Я говорю о типе приёмников, в которых внутр. время "поддёргивается" редко, либо приёмники имеют 2 хронометра.
У Novatel, topcon, Javad.. и т.п. такого нет, там постоянно (с опр. дискр.) шкала синхронизируется.
Я пока не понимаю какое время приёмник валит в протокол NMEA. И будет ли разница в шкалах времени между первым и вторым типами приёмников в сообщении NMEA.
А 10E-6 с - это понятно, и вполне устроило бы, если точно знать, что это системное время.
Я может где чушь несу, не обессудьте, просто разбираюсь пока.

 

В сообщении NMEA указывается время фиксации местоположения по Гринвичу именно этим приёмником, т.е. разница в сообщениях для разных типов приёмников будет, и будет даже для разных приёмников одного типа (т.к. время фиксации у каждого будет своё). Но при формате записи "hhmmss.ss" никаких 2500мкс, а тем более, 10E-6с Вы не увидите - точность представления времени 0.01с.

 

Александр, а как сделать так, чтобы получать время в реал тайме с точностью хотябы уверенный 4 знак?
Ну в реалтайме, с задержкой 1-2 сек.

 

Если приёмник не поддёргивает шкалу к целой секунде, то по-моему никак.
А зачем Вам нужна такая высокая точность? Для координат и скорости вроде и такой точности хватает. Может быть, для синхронизации времени? Тогда нужно использовать сигнал 1PPS (а он привязан к целой секунде с высокой точностью) и его метку времени.

 

Мне нужно чтобы приёмник фиксировал мах. приближенное к системному GPS время, а подключённый дивайс видел это самое время. Поскольку скорость высокая 35-40 м/с, то 10e-4с это на земле ~4мм. Вот я и хочу быть уверенным за 4мм.
Наш приёмник поддёргивает свою шкалу, но я хотел спросить об общем случае.