Прошу помощи. Какова структура вышеназванных файлов? Как благодаря данным из этих файлов можно высчитать позиционные данные?
.. Описание структуры RINEX Если речь о навигационной задаче (автономно), то решаем систему уравнений: Xi, Yi, Zi - координаты i-го спутника в геоцентрической прямоугольной СК (которые необходимо рассчитывать из файла nav) Pi - псевдодальность от приемника до i-го спутника (которые записаны в файле Obs) x,y,z - определяемые координаты приемника b - расхождение шкалы времени приемника и системного времени GPS Все записано на фиксированный момент времени. Остальное читать, читать и читать, для подробного описания, думаю места на форуме не хватит :)
кому не сложно, разложите, пожалуйста, по полочкам: 1. Какие данные указываются в obs и nav файлах 2. какие исходные данные необходимы для создания obs и nav? 3. Имея исходные данные в каком-нибудь формате , можно ли с помощью какого-нибудь программного средства преобразовать их в Rinex? Сергей Флерко дал ссылку на описание структруы Rinex, за что ему большое спасибо, а у меня даже времени нет разобраться самому. Помогите, пожалуйста, кому не трудно. Заранее спасибо.
Подскажите, пожалуйста: чем отличаются файлы nav и auto,предоставляемые на сайте SOPAC? и какой из них нужно использовать для обработки в ПО (Добавление) все понял. Авто-для всех станций. NAV-только для какой-то определленной GPS-станции.
Исправляете до точки имя любого файла с расширением N до требуемого названия станции и получаете файл AUTOю Навигационные файлы ОДИНАКОВЫ для приемников всего мира (если суточные или если записаны в одно и то же время)
В OBS или O - измерения: кодовые, фазовые и Доплера, значения отношения сигнал / шум бинарные файлы ИЗМЕРЕНИЙ GPS (GNSS) приемников, но не бытовых (навигационных), а способных выдавать на выход (СОМ порт или регистрировать в память) именно "сырые" измерения (кодовые и фазовые) Можно, если это данные "сырых" измерений, но не NMEA. У каждого производителя свои программы-конвертеры, но есть и универсальные варианты программ
Не совсем корректное утверждение. Если приёмники находятся по разные стороны Земли, то в одно и то же время они видят разные спутники, значит, навигационные файлы будут существенно разными. Для примера скачал данные станций alic (Австралия) и stjo (Канада). Навигационные файлы содержат очень мало одинаковых эфемерид, поэтому не получается обработать наблюдения alic с навигационным файлом stjo и наоборот. Вывод: используйте навигационный файл от сравнительно близкой станции или файл auto - он содержит ВСЕ эфемериды. Возможно.
Смотря что определять. Для чего используются измерения частоты Доплера: а) для определения скорости потребителя б) для сглаживания кодовых измерений в) для синхронизации измерений базы и ровера (приведения на одно время) г) для починки фазовых слипов (в измерениях Доплера нет скачков) Задачи (а) и (б) для геодезии неактуальны, (в) и (г) решаются другими способами. Файлы наблюдений большинства перманентных станций не содержат измерений частоты Доплера или содержат измерения только на одной частоте (место экономят), и ничего - точность не хуже.
Конечно, зависит от модели Вашего приемника, но: после первоначального скачивания эфемерид время приемника устанавливается с точностью ± 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мм. Наш приёмник поддёргивает свою шкалу, но я хотел спросить об общем случае.
