Обработка виртуальных RINEX файлов от сетевого ПО Trimble GPBase

Наткнулись недавно на интересную картину при анализе виртуальных RINEX файлов, полученных сетевым ПО Trimble VRS3Net. Вот типичная картина:
непрерывность фазовых измерений:

Значение функции "код минус фаза" для VRS файла без ГЛОНАСС (L1):

Значение функции "код минус фаза" для VRS файла c ГЛОНАСС (L1):

Значение функции "код минус фаза" для VRS файла c ГЛОНАСС (L2):


Значение функции "код минус фаза" для реального приемника, GPS+ГЛОНАСС, измерения выполнены в аналогичное время:



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

Эти самые значения для ГЛОНАСС измерений выглядят более чем странно. Видно, что характер этих странностей повторяется для измерений на L1 и L2, что предопределяет отсутствие влияния этого фактора на пост-обработку двухчастотных измерений, когда формируются линейные комбинации измерений на псеводальностях и фазах L1 и L2.
НО: интересно какой эффект это вызовет при пост-обработке одночастотных измерений измерений GPS+ГЛОНАСС ровера?
Может есть у кого-то из форумчан опыт работы такими роверами совместно с виртуальными файлами от Trimble?
Очень надеюсь на авторитетное мнение от Stout.
Заранее спасибо.

С уважением,
Сергей

 

Я думаю здесь имеет место недоопределенность оцениваемых параметров модели, по которой формируются измерения для ГЛОНАССов. На графиках видны только 2 глонасса. Если это так, то говорить об адекватности используемой модели нельзя, так как отсутствует необходимая избыточность данных.

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

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

 

Сергей! график ухода часиков приёмника по обоим системам можете показать? внутренних часиков "приёмника" с которого получен VRS-rinex.
Сходил, взял лупу, присмотрелся на графики. А чего тут удивительного? значения такие же как с физ. приёмника.
Может смущает лохматость? Такая "шерсть" в GrafNav'е наблюдается, когда ровер и база не совпадают по rate. Например базу интерполировали, тогда график будет справедлив тольно на пиках этой "шерсти". моё мнение.

 

Сергей, посмотрите, пожалуйста, на эти данные. Что можно сказать про них?

 

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

Нет, спутников ГЛОНАСС было 7, просто на представленном графике приведены значения для PRN1-PRN42, а были еще 43, 50, 54, 57 и 58.

Причем здесь "лохматость"? Уход двойного значения ионосферной задержки за 400 м можно считать нормальным?

Спасибо, Михаил, сейчас глянем.

 

Результат много лучше!
По-крайней мере сопоставим с тем, что я вижу на виртуальных файлах от GNSMART (GEO++), которые мне любезно предоставили российские коллеги.
Виртуальный RINEX:



(Добавление)
Хотя отличия от роверных измерений имеются:




(Добавление)
Вектор обработался отлично - с фиксированным решением и миллиметровыми погрешностями, но другого для L1+L2 никто увидеть и не ожидал.
Поменял стиль обработки на L1 GPS+GLONASS only - результат остался фиксированным, но СКО выросло в разы! Уточню - база 0,01 км

 

Последние графики для разностей код-фаза действительно адекватны. Наблюдаемые значения удвоенного ионосферного тренда лежат в допустимых пределах 20-30 м/час.

Сергей, если глонассов было 7, то почему не отображены остальные 5? С ними картина повторяется?

 

Да, повторяется, ниже привожу графики повторно в более лучшем качестве и по всем спутникам (соответствуют моему первому посту).


Напомню - характер поведения функций одинаков для L1 и L2 по соотв. спутнику.
(Добавление)
Ай-яй-яй,
Михаил, это же Spider-овский файл ... :)

Code:

SpiderWeb 4.0              2011 11 11 11:35     PGM / RUN BY / DATE 
Virtual Rinex                                               MARKER NAME         
VREF                                                          MARKER NUMBER       
Galation Hahubia    NAPR                              OBSERVER / AGENCY  

 

Да, этот файл создан по данным грузинской сети базовых станций GeoCORS.
http://178.249.16.8/spiderweb/frmIndex.aspx

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

Кстати, анализируемые вами данные Trimble получены из сети ZakPos?
Тогда это не VRS3Net, а предыдущее ПО.

 

Именно так, у меня были данные от GNSMART (GEO++) любезно предоставленные Сашей Янкушем для анализа. Так вот эти данные очень похожи на Ваши - от Spider:


Очень бы хотелось увидеть любой виртуальный файл именно от Вашего производителя. Сетей то много по миру - можно сделать запрос на короткий файлик?
Хотелось бы аккуратно разобрать ситуацию по ZakPos-у, без всяких обид и упреков, просто понять истину: почему получаются не самые лучшие результаты при обработке измерений GPS+GLONASS...

 

к сожаленью у нас пока 4 базы и проблемы с провайдером, файлы получаются рваными и Тримблы всетаки в руководстве говорят о 5и базах для VRS

 

А на проблемные ринексы получаемые от VRS3Net взглянуть можно?

 

По ходу это не VRS3Net , а trimble GPServer 2.73:
вот VRS файлы от сети
а вот роверные измерения модулем OEMV-1g и натенной Antcom G3Ant
название файлов состоит из имени точки и высоты антенны без учета расстояния от нижнего крепления до фазового центра (=35мм)
Для теста можно использовать базовую станцию UZHL, лежит тут

 

Да они не то, что проблемные, лни более странные ...

 

По всей видимости дело в криво сформированных файлах эфемеридных данных Глонасс. В них то и дело попадаются кривые запись для 35-го глонасса (???):

Code:

24 11 11  8  8 45  0.0-5.449168384075D-05-9.094947017729D-13 3.150000000000D+04
___-1.765331054688D+03-1.936898231506D+00 0.000000000000D+00 0.000000000000D+00
____1.521096972656D+04 2.019407272339D+00-9.313225746155D-10 2.000000000000D+00
____2.037002441406D+04-1.673815727234D+00-1.862645149231D-09 0.000000000000D+00
35 1200 12  7 16 28 43.0 1.883982419968D-01-4.904547009790D+20-1.107588677000D+09
____3.524635008963D-314 9.603064483439D-04 0.000000000000D+00 8.500000000000D+01
____1.944000000000D+02 1.370039031328D-03 7.481826543808D-04-6.400000000000D+01
____2.398928185194D-03 2.656031716306D+04 1.197508314002D-19 0.000000000000D+00
 1 11 11  8  8 45  0.0-1.806309446692D-04 0.000000000000D+00 3.150000000000D+04
___-2.167903808594D+03-4.014253616333D-01 9.313225746155D-10 0.000000000000D+00
____2.044268066406D+04-2.030415534973D+00-9.313225746155D-10 1.000000000000D+00
____1.509505664063D+04 2.694686889648D+00-1.862645149231D-09 0.000000000000D+00

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

 

Уважаемый gnss-dev,

Большое спасибо за то, что уделили столь пристальное внимание и высказали свое экспертное мнение по виртуальным RINEX файлам. Если Вас не затруднит, посмотрите, пожалуйста, таким же образом на эфемериды ГЛОНАСС файлов OEMV-1G.
Заранее спасибо.

Сергей

 

В этих файлах нарушен формат данных для заголовочной секции CORR TO SYSTEM TIME, а в остальном вроде в порядке.

Рекомендую взглянуть на программку Rinex Viewer. В ней удобно просматривать данные и имеющиеся ошибки.

 

Спасибо, он у меня даже есть :) Просто подзабыл о нем ...

 

Михаил Караванов

Михаил, по ходу действительно проблема с формированием навигационных файлов ГЛОНАСС в ZakPos, это каким-либо образом "лечится" для Trimble GPServer (или для той программы, которая работает сейчас в сети)?

 

Эта проблема влияет и на обсервационный файл, поскольку одна лишь замена навигационных файлов проблему не решает (обработки по ГЛОНАСС нет).
Тут вопрос, "ядро" программы коверкает данные по ГЛОНАСС, это видно на графиках "убегающего" ГЛОНАСС.