Решение навигационной задачи GPS по данным RINEX

Здравствуйте! Хочу представить на ваш суд свою программу, которую я создал в рамках магистерской диссертации. Программа решает навигационную задачу GPS псевдодальномерным методом, используя избыточное число псевдодальностей, измеренных по C1-коду.

Особенности:
- решение производится на основе данных из RINEX- файлов (навигационного сообщения nav и файла наблюдений obs). Достаточно перетащить одновременно nav и obs файл на exe-шник и программа запустится. Также, можно переименовать файлы в nav.n и obs.o соответственно и просто запустить exe
- в программу вводится интервал времени для которого требуется решение (час мин с - час мин с) в пределах одних суток, а также значение индекса солнечной активности F10.7 для этой даты (если не знаете, вводите 120)
- возможность ручного ввода точных и априорных координат посредством файла Input.txt. Если такой файл поместить в каталог с программой, то программа считает оттуда 6 значений декартовых координат: 3 - точные координаты x, y, z, ещё 3 - априорные x0, y0, z0. Если же этого файла нет в каталоге, то программа возьмёт координаты из obs-файла и будет их использовать и как точные и как априорные
- вывод результатов осуществляется на экран и в выходной файл Output.txt
выводится решение в декартовых координат (x, y, z), а также в геодезических координатах (B, L, H), ошибка позиционирования относительно точных значений для каждой декартовой координаты. В файл помимо этого выводится 4-я неизвестная, которая вбирает в себя поправку на уход часов приёмника

При решении учитываются следующие моменты:
- коррекция времени навигационного сообщения спутников на время прохождения сигнала
- поворот Земли за время прохождения сигнала
- "уход" часов каждого спутника
- самоустраняется "уход" часов приёмника
- ионосферная (модель, разработанная в стенах ИГУ GEMTEC) и тропосферная (упрощенная, точность до дм) задержки
программа написана на языке Си

Может кому-нибудь моё творение будет интересным. С удовольствием отвечу на вопросы, у самого тоже есть)

 

Вопросы есть следующие;
1. Нужно ли время от опорной эпохи t_k = t_sv - t_oe, выраженное в секундах от начала недели GPS корректировать на ход часов спутника?
dt(t_sv) = a_f0 + a_f1 * (t_sv - t_oe) + a_f1 * (t_sv - t_oe) ^ 2 + dt_r - T_GD
где

t_sv - момент времени наблюдения в секундах от начала недели
t_oe - опорная эпоха (время навигационного сообщения) в секундах от начала недели
a - коэффиценты скорости и ускорения хода часов спутника
dt_r - релятивистская поправка
T_GD дополнительная поправка для одночастотного приёмника

2. После каждой итерации (получения позиции приёмника) и нахождения геометрического расстояния до спутника нужно ли при расчёте времени на момент передачи сигнала добавлять в расчёт ионосферную и тропосферную задержки?

r = sqrt((x - x_i) ^2 + (y - y_i) ^2 + (x - x_i) ^2)
t_k = (t_sv - t_oe) - r / c или t_k = (t_sv - t_oe) - r / c + ионосферная модель + тропосферная модель

где
x, y, z - позиция приёмника
x_i, y_i, z_i - позиция спутника

 

И года не прошло, как я увидел таки разработку земляков из ИГУ!
Имею вопросы.
1. Сохраняется ли актуальность публичного обсуждения вашей разработки к настоящему времени? Если не сохраняется, то просто промолчите. Если актуальность сохраняется, но публичное обсуждение не желательно, то позвоните мне - найдем время поговорить.
2. А чем, собственно, ваш подход и алгоритм, его реализующий отличаются от хорошо известных, доступных в "сети"? Про модель GEMTEC вместо модели Клобучара для учета влияния ионосферы, я понял, а что еще?
3. Насколько хорошо ваши вычисления сходятся с вычислениями по "известным" алгоритмам и программам? Ответ я почти знаю, но хочу услышать вашу оценку.

 

Шкипер, добрый день!
Пишу курсовую работу по данной тематике. Есть вопросы касаемо RINEX файлов и еще несколько вопросов, могли Вы на них ответить?

 

Всем здравствуйте! Совсем не было времени заходить на этот замечательный форум, и, надо сказать я приятно удивлён, что кто-то заинтересовался решением навигационной задачи. Я успешно защитил магистерскую диссертацию и теперь продолжаю работать в данном направлении, учась в аспирантуре. Пишите на почту clausxxx@rambler.ru, я отвечу на все вопросы.

 

1. Актуальность сохраняется, допускаю публичное обсуждение вплоть до публикации исходного кода (за исключением исходника модели ионосферы)
2. Собственная реализация алгоритма нужна лишь для того, чтобы можно было без затруднений вносить изменения в решение для проверки тех или иных предположений. По сути, моей главной задачей было создание инструмента для автоматизации обкатки различных версий модели ионосферы GEMTEC и исследования возможностей дифференциально-временного режима, идея которого родилась на кафедре радиофизики.
3. Мои результаты выглядят несколько хуже чем например в решениях RTKPost (RTKlib) и rinexpvt (GPS Toolkit) в среднем от их решения моё гуляет до 1,5, может 2 метров. Я связываю это с плохонькой моделью тропосферы, используемой у меня в программе и, возможно, с тем, что я не использую весовую матрицу измерений псевдодальности, алгоритм RAIM, что могло бы повысить точность.

На данный момент проект несколько изменился, и я обязательно в ближайшем будущем выложу новую версию, также была создана программа Sat, которая по эфемеридам из навигационных файлов RINEX рассчитывает положения интересующих спутников во временной развёртке с начального момента времени по конечный момент с определённым шагом. Программа может работать как с эфемеридами GPS, так и ГЛОНАСС, кроме того, если в качестве входных данных указать координаты приёмника, программа рассчитает геометрическую дальность до спутника, а также азимут и угол места спутника.

 

И снова здравствуйте! Давно закончил магистратуру и уже третий год обучаюсь в аспирантуре, а программа всё это время дорабатывалась, и я хотел бы снова выложить её здесь, не исключено, что это кому-то будет интересно.
Вот её отличия от предыдущей версии
- устранено множество ошибок и недоработок;
- оптимизирована работа с эфемеридами, благодаря чему скорость решения навигационной задачи выросла в 10 раз;
- теперь есть выбор моделей тропосферы: Саастамойнена, Саастамойнена в интерпретации Дэвиса, GCAT;
- добавлена поддержка RINEX файлов эфемерид версии 3;
- добавлена возможность решения с использованием точных эфемерид .sp3;
- добавлена возможность работы со спутниками GALILEO;
- добавлена модель ионосферной задержки NeQuickG (родная для GALILEO);
- добавлена модель ионосферной задержки ГЛОНАСС из нового ИКД;
- реализована возможность решения отдельно по любой из псевдодальностей C1, C2, P1, P2, а также двухчастотный режим P1 + P2 и C1 + C2;
- расширена выходная информация в файле (теперь отображается число задействованных спутников в решении, СКО в плоскости, по высоте, 3D-СКО, PDOP, VDOP, HDOP).

--- Сообщения объединены, 22 дек 2018, Оригинальное время сообщения: 22 дек 2018 ---

А вот программа Sat для расчёта координат и скоростей спутников (NAVSTAR, GLONASS, GALILEO), а при указании точки наблюдения, рассчитывает азимут и угол места. В качестве исходного файла можно использовать как эфемериды RINEX, так и .sp3.
Эти программы я использую в рамках диссертации по теме моделирования полного электронного содержания и ионосферных мерцаний. Буду рад, если кто-нибудь решит протестировать их и выскажет замечания, также, с удовольствием отвечу на вопросы о навигационной задаче и методах её решения.

 

А компот Compass?

 

Что касается Beidou - я планирую добавить поддержку их спутников, но в данный момент не могу уделить на это время, так как на работаю над коррекции ионосферной задержки при помощи карт GIM (IONEX), а так же внедряю методику расчёта ПЭС Мыльниковой, разработанную в ИСЗФ СО РАН. Кроме того, в рамках диссертации было бы любопытно "пощупать" модель IRI, да вот беда - исторически сложилось, что открытый исходный код в научной среде как правило написан на FORTRAN или в лучшем случае Pyton, и переписывать это на Си - то ещё удовольствие)

 

Зачем переписывать?
P.S. Правильное написание Python
P.P.S. Всё сами с нуля или использовали чьи-то наработки?

 

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

Разрабатывал с нуля с 2010 года, когда ещё писал курсовик на 3 курсе - тогда это был тупо расчёт методом Ньютона координат приёмника по 4 спутникам, но потом как-то всё разрослось) Из заимствований у меня только расчёт азимута в декартовых координатах (брал из GPSTk) и реализация интерполяции Ньютона-Невилла из RTKLib (очень кратко и оптимально написана функция). Весь парсинг мой авторский и формулы из кучи перелопаченной литературы. Зачем я всё это делал, если есть open-source проекты, спросите вы? Для постепенного решения поставленных задач мне гораздо проще было постепенно разрабатывать свою программу, нежеле пытаться разобраться в чужом, громоздком коде, причём что в RTKPost, что в RINEXPvt (GPSTk) тогда было немало багов, которые могли сильно исказить результаты исследований. Да и вносить быстро изменения проще и быстрее, когда знаешь буквально каждую строчку.

--- Сообщения объединены, 23 дек 2018, Оригинальное время сообщения: 23 дек 2018 ---

Вообще, моя основная деятельность далеко не научная, а аспирантура и исследования - это моё хобби, просто считаю, что если в какой-то области получается, бросать не стоит. И написание Navi и Sat зачастую происходит "на озорстве", без каких-либо коммерческих замашек и не "из под палки".

 

IMHO: догоняете, но не догоните. Просто удел увлечённо человека сегодня лишь хобби свое обосновывать... Криптовалюты недавно можно было без капвложений "майнить"... Время ушло... Актуальности моделирования ионосферной задержки кустарными способами не просматривается... От слова "совсем"...
Жаль...
ЗЫ. А вызываемый внешний исполняемый модуль таки предпочтительнее...

 

Тут вы сильно заблуждаетесь. Последняя версия принятого стандарта Fortran насчитывает 25 дней – Fortran 2018. И эти нововведения уже частично поддерживаются транслятором Intel. Основной вектор развития Fortran – поддержка многопроцессорности, матричные вычисления, где ему до сих пор нет равных.
GNU Compiler Collection позволяет достаточно просто объединять программы на разных языках в один исполняемый файл, если вам по каким-то причинам не нравится механизм DLL.
Кстати, BERNESE и GAMIT/GLOBK написаны в основном на фортране.

 

Догонять даже пытаться не буду, ибо над подобными проектами работает множество светлых голов, а я один, и мне нужно просто решить свои задачи. Мне достаточно, что у нас получаются близкие результаты, значит я всё болоее-менее правильно понимаю. Хотел одно время в рамках педагогической практики дать студентам курсовые, дипломы, типа прикрутить к программе возможность решения взвешенной системы уравнений (RAIM), сделать хотя бы примитивный PPP, да вот те, кто мог, и хотел это сделать на 3 курсе переехали в города побольше (Новосибирск, Москва), а брать кого-то, кому лишь бы курсовик закрыть, мне не нужно.

Я буду очень признателен, если Вы поделитесь "не кустарными методами" моделирования ПЭС (соответственно задержки) в ионосфере, хотя бы идеями... Я всегда открыт для критики и предложений!
Согласен, что в прикладном смысле ионосферная задержка - ничто, ибо её просто можно убрать двухчастотным приёмником, а для одночастотного гаджета где-нибудь недалеко от цивилизации всё равно работает привязка к дорогам, соотвественно модели Клобучара будет вполне достаточно. Но GNSS - это прекрасный инструмент для исследования ионосферы и именно в этом ключе я и работаю, ведь точное моделирование ПЭС имеет большое значение для радиофизики, в противном случае на международных конференциях и симпозиумах столь живо не интересовались этой темой. Хотя возможно это театр, в котором люди нахваливают друг друга, проявляют синтетический интерес к подобным разработкам, чтобы зарабатывать регалии и номинальные статьи в рецензируемых журналах... Возможно я в чём-то "понтуюсь", но знаю, что не сделал ничего выдающегося, а просто переписал формулы из литературы, и исправил опечатки в них, я лишь делаю для коллектива инструмент для исследований потому что умею и не претендлую на их лавры) Возможно кому-то нужно сделать что-то подобное, хотя бы из академического интереса, и я готов в этом помочь, поэтому делюсь информацией своими программами на форуме.

С точки зрения времени, потраченного на разработку - согласен. С точки зрения скорости обработки данных - весомый аргумент в сторону моего подхода.

P.S. Я очень благодарен Артёму за объективную, реалистичную, "технарскую" оценку моих действий. Спасибо!

--- Сообщения объединены, 23 дек 2018, Оригинальное время сообщения: 23 дек 2018 ---

Хм, благодарю за информацию! Мне стоит покопать в этом направлении, а то, чувствую, я после NeQuickG переписывание IRI просто не выдержу) Просто я насмотрелся у себя в ИСЗФ на ужасы быстродействия FORTRAN 77/IDL и у меня выработалась стойкая неприязнь к интерпретируемым языкам...

 

У нас (Калининградский Филиал ИЗМИРАН) программа на FORTRANe обрабатывает месяц RINEX-файлов (для одной станции) не более, чем за час...

 

А исходный код чего зажал? Не уж то продавать намереваешься?

 

У меня к вам два вопроса:

1. Что означает слово обрабатывает?
2. Какая версия RINEX-файла?

 

В недавнем прошлом относительно развала СССР (2007 год ориентировочно) мы версию RINEX 2.11, часового примерно сеанса наблюдений, "кредовским" коллективом программистов в Минске примерно календарный год "обрабатывали"... С выплатой заработной платы всем заинтересантам...
А Фортран-77 я начал потихоньку изучать лишь сейчас... Хобби вырисовывается...ГЫ... А еще фотоаппаратов"Зенит" в четырех модификациях и черно-белую негативную фотопленку к ним закупил, балбес...