расчет координат точки на местности используя исходные данные модуля навигатора

Добрый день. Вот есть файл эфемерид. jpl06502.sp3 там вот так:
#aP1992 6 23 0 0 0.00000000 96---------------------
## 650 172800.00000000 900.00000000 48796 0.0000000000000
+ 16 2 3 11 12 13 14 15 16 17 18 19 20 21 23 24 28 0
+ 0 0 0 4 87 96 0 0 0 0 0 0 0 0 0 0 9
+ 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
+ 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
+ 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
++ 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
++ 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
++ 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
++ 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
++ 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
%c cc cc ccc ccc cccc cccc cccc cccc ccccc ccccc ccccc ccccc
%c cc cc ccc ccc cccc cccc cccc cccc ccccc ccccc ccccc ccccc
%f 0.0000000 0.000000000 0.00000000000 0.000000000000000
%f 0.0000000 0.000000000 0.00000000000 0.000000000000000
%i 0 0 0 0 0 0 0 0 0
%i 0 0 0 0 0 0 0 0 0
/* CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
/* CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
/* CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
/* CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
* 1992 6 23 0 0 0.00000000
P 2 14310.979640 -5328.672860 -21637.619370 99999.999900
P 3 -21076.439240 1608.306560 16179.441050 99999.999900
P 11 -2921.769120 13747.458840 -22314.016750 99999.999900
P 12 -18718.935220 -16693.891550 -9431.453100 99999.999900
P 13 20208.843830 -15109.732990 8113.304750 99999.999900
P 14 12655.585290 20439.798920 11041.124870 99999.999900
P 15 16271.353580 15617.293880 -14153.381810 99999.999900
.............................................................. Не могу понять расшифровку файла. Здесь есть явные координаты спутников. но не знаю как определиться. Если не сложно, - опишите, как этот текст прочитать.

 

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

 

есть такой сайт: https://www.google.com/
он очень быстро находит ответы на вопросы:
ftp://igs.org/pub/data/format/sp3c.txt
ftp://igs.org/pub/data/format/sp3_docu.txt
ftp://ftp.igs.org/pub/data/format/sp3d.pdf

 

Спасибо конечно....... Где то здесь. на Вашем сайте у одного человека написано, - если тебе сложно найти самому. - не стесняйся. спроси, и мы поможем. Я конечно буду пытаться искать сам, разбираться. но если Вам подсказать не сложно. то может вы это сделаете....... мне много в чем разбираться ..... еще......

 

я подсказал - читай документацию к формату, там всё расписанно

 

Удобное описание формата SP3-c.
Наводите курсор на интересующее поле, и во всплывающем окошке будет подсказка

 

Чтобы сравнить координаты спутников по бортовым эфемеридам и по файлу SP3 вам прийдектся реализвать два совершенно разных алгоритма !!!
Бортовые эфемириды (которые навигационные RINEX-файлы) это предиктивные данные, в виде параметров орбиты, скорости и прочих коэффициентов.
SP3-файл это КООРДИНАТЫ спутников на определенный момент времени с векторами скоростей, чтобы можно было интерполировать на любой момент между соседними замерами. Эти координаты получены уравниванием данных со станций мониторинга по всему миру.
Формулы из методички бесполезны для файла SP3.

 

Ну второй алгоритм реализовывать не обязательно. Достаточно рассчитать координаты спутников по бортовым эфемеридам на моменты времени, приведенные в файле SP3 и сравнить результаты

 

В общем да, можно второй не программировать.
Но это можно делать, когда уверен в своём алгоритме по эфемеридам. В противном случае, получив ГАРАНТИРОВАННУЮ разницу в результатах, так и не узнаешь - это ошибки в формулах/программе или это (естественные) ошибки в бортовых эфемеридах. Для поиска грубых ошибок в своей программе - более нескольких метров - может сгодиться.

 

Добрый день. что то я совсем запутался во времени t . У меня приходит (на какой то момент времени)от модуля 4 байта, - вот например 15, 52, B1, C7. перевожу, получаю 357740999. Но это ведь неправильно. в примере из методички, t = 325730.3569292; значит я что то не так делаю с форматом? 8 байт в double я перевел. там где исходные данные корня квадратного большой полуоси, а здесь что надо сделать?

 

0x1552B1C7 = 357740999, это ToW в мсек, делим на тысячу, получаем (double) 357740.999

Тут вылезет другая проблема - это время по приёмнику, которое не совпадает с GPS. Надо учесть уход часов приёмника.

 

я именно так и предположил. и у себя в программе так же сделал. но в методичке отчего то 6 знаков после запятой. у меня не так. 1552b1c7 это 357740999 а если взять 1552b1c8 будет 357741000 здесь явно не получается точности 6 знаков после запятой. или этого, того что есть, достаточно?

 

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

Небольшое пояснение, скорее всего в случае с uBlox не понадобится т.к. "само получится как надо", но кухня там гораздо серьёзнее ))

Раскрыть Спойлер Свернуть Спойлер

Это итерационный процесс. Если упрощенно
1. Берём время измерения по часам ПРИЁМНИКА t(0);
2. Вычисляем координаты спутника на это время t(0) (т.к. время не совпадает с GPS то естественно в координатах будут ошибки)
3. Решаем навигационную задачу, в процессе решения получаем координаты XYZ и уход часов приёмника dT
4. Корректируем t(1)=t(0)+dT
5. Повторяем в цикле п.п. 2-3 для итерационных t(i)

На самом деле сходится очень быстро по двум причинам
1. Потому-что скорость спутников на 5 порядков меньше скорости света.
2. Приёмник сам прогнозирует и планирует время измерения таким образом, чтобы подгадать целые GPS-секунды (т.н. synchronized measurements).
Для примера у моего Сёрфа частота дискретизации и, соответственно, точность планирования synchronized measurement составляет около 16 MHz, т.е. дискретность ~62 наносекунды, за это время спутник пролетает около 0.3 мм - для бытового приёмника можно игнорировать, даже итераций не надо делать ))
У геодезических оцифровка раз в 10 лучше и точнее, там уже бОльшую роль играет джиттер опорного генератора.

 

(т.н. synchronized measurements). то есть, - тот факт, что у меня в сообщении получаются практически целые секунды, - это не ошибки моего считывания, или интерпретации полученных данных, а "реверанс" в мою сторону спутника, который передает псевдодальности в момент времени наиболее удобный мне для расчетов? или модуля, который на мой запрос передает мне псевдодальности в "удобный" момент времени...... отчего же в методичке, столь точное число...

 

Спутник передаёт сигнал непрерывно, НО все спутники синхронизированы, если SV1 передаёт очередной фрейм в момент времени 123456.000, то будьте уверены что остальные спутники начали излучать сигнал с такой же меткой времени ровно в этот же момент (с поправкой на ошибку часов самого спутника, там доли наносекунд, они есть в эфемеридах и учитываются в расчетах). НО в ваш приёмник сигналы от разных спутников прийдут в разное время. Это и есть псевдодальность.

Да, определенно GPS-приёмник делает огромную услугу, погоняя время измерения псевдодальностей. А потом выдаёт вам их из буфера.

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

 

Мне кажется там опечатка......... данные и сам расчет тоже именно GPS. и в других источниках видел расчет именно этот. .......но проверю еще, может и правда не ту методичку выбрал......

 

Это неверно. Координаты спутника нужно рассчитывать не на момент приёма, а на момент излучения сигнала спутника, и он будет разный для разных спутников.
Итерационный процесс нужен потому, что система уравнений нелинейна. Расчёт координат спутника можно в итерационный процесс не включать.

 

Время для расчета у меня берется из сообщения от навигатора,
B5 62 02 10 - заголовок
40 01 - размер данных
C0 7F 77 07 - Врем¤ недели измерени¤ по локальному времени приемника. rcvTow \ в мс
EC 07 - Номер недели измерени¤ по локальному времени приемника. week
0D - Количество спутников, дл¤ которых дальше идет информаци¤
00 - резерв
Carrier Phase 0-7 | Pseudo Range 8-15 | Doppler 16-19 | SV 20 | QI 21 | SNR 22 | Lock 23 |

00 5A 76 C9 B7 AD C6 C0 D2 3C 97 6E D0 4C 73 41 74 C1 A7 C4 1F 07 25 00
00 00 F0 D0 EC C1 F3 C0 40 E7 6C 2D BF 5D 74 41 E0 50 E3 43 03 04 11 03
80 1B 9B 7E B9 18 52 41 20 B7 08 5B 89 B0 75 41 C9 75 7C C5 20 07 2B 00

то есть оно одно для всех. для которых на момент запроса информации от модуля есть псевдодальности.......