Использование лицензионных копий программного обеспечения открывает для Вас возможности его модернизации в будущем и избавляет от наличия проблем некорректной его работы в настоящем ‎ ‎ ‎ OEM 615: двухчастотный GNSS модуль нового поколения от NovAtel ‎ ‎ ‎ Приемник сигналов GPS на основе ОЕМ модулей NovAtel Inc. (Hexagon Group, Калгари, Канада), предназначен для высокоточной геодезической съемки в жестких полевых условиях. Идеальное устройство для применения в качестве полевой базовой станции или при выполнении геодезических работ в  режиме с пост-сеансной обработкой. ‎ ‎ ‎ GNSS RTK ровер SatLab SL500 полностью соответствует стандартам качества Европейского союза. Корпус выполнен из высокопрочного полимера - General Electric Xenoy 5220U — который прекрасно выдерживает суровые условия эксплуатации. Приемник имеет полный набор сертификатов EC, RoHS и FCC, идеально сохраняет характеристики работы даже при сильной тряске и вибрации.

Уважаемые посетители форума! 

 

В случае возникновения проблем с регистрацией напишите письмо администратору на электронную почту:  

Тема для обсуждения структуры т.н. VRS-файлов сети ZAKPOS

Re: Тема для обсуждения структуры т.н. VRS-файлов сети ZAKPO

Сообщение Aleks » 15 дек 2011, 16:16

Саша, а хранятся ли на сервере данные станций в формате Trimble (DAT, например)?
Интересуют, прежде всего, измерения HUST и MIGZ за 8 декабря с 8 до 10 (UTC).

Нет, в DAT ничего не хранится. Софт пишет данные для постобработки в Rinex. Однако сами приемники HUST и MIZG пишут для страховки данные еще в формате T01.
Aleks
Специалист
 
Сообщения: 554
Зарегистрирован: 13 ноя 2009, 00:44

Re: Тема для обсуждения структуры т.н.VRS-файлов сети ZAKPOS

Сообщение kukin » 15 дек 2011, 16:30

Aleks писал(а): пишут для страховки данные еще в формате T01.

Сергей это наверно и имел в виду, T01/T02 стандартный формат данных для многих приемников Trimble.
kukin
Специалист
 
Сообщения: 545
Зарегистрирован: 15 янв 2010, 22:16
Откуда: Украина, Ужгород

Re: Тема для обсуждения структуры т.н. VRS-файлов сети ZAKPO

Сообщение Сергей Флерко » 16 дек 2011, 12:25

Приношу всем свои извинения. В процессе обработки сам себя запутал :)
Итак, ниже привожу результаты обработки измерений 08.12.2011 (2 часа с темпом 1 Гц), в обработку включен треугольник - "VRS_MKRS - HUST - MIZG". При обработке фиксировались координаты только виртуальной станции VRS_MKRS (файл сформирован на точку стояния реальной станции MKRS):
VRS_MKRS 48 22 43.17324 | 22 42 33.56717 | 188.142 (FIXED 3D)

Результаты получены следующие:

HUST:
HUST 48 10 34.16748 | 23 17 38.21328 | 219.413 m - каталог ZakPos
HUST 48 10 34.16773 | 23 17 38.21419 | 219.435 m - обработка только GPS
HUST 48 10 34.16775 | 23 17 38.21412 | 219.434 m - обработка GPS+GLONASS

MIZG:
MIZG 48 31 32.34606 | 23 30 04.62776 | 496.705 m - каталог ZakPos
MIZG 48 31 32.34622 | 23 30 04.62869 | 496.690 m - обработка только GPS
MIZG 48 31 32.34624 | 23 30 04.62863 | 496.689 m - обработка GPS+GLONASS

А вот это результаты аналогичной обработки, но от реальной станции MKRS (GPS only):
HUST 48 10 34.16785 | 23 17 38.21328 | 219.414
MIZG 48 31 32.34615 | 23 30 04.62772 | 496.695

Расстояния в сети (округлены до метров):
VRS_MKRS-MIGZ: 60.823 км
VRS_MKRS-HUST 48.889 км
MIZG-HUST: 41.794 км
Вложения
Zakpos.gif
Конфигурация сети
С уважением,
Сергей

____________________
Precise Thinking ...
New NovAtel OEM7:: http://www2.novatel.com/OEM7
Аватара пользователя
Сергей Флерко
Специалист
 
Сообщения: 1219
Зарегистрирован: 20 июн 2007, 16:43
Откуда: Харьков, Украина

Re: Тема для обсуждения структуры т.н. VRS-файлов сети ZAKPO

Сообщение Aleks » 16 дек 2011, 13:58

Кардинальное решение по борьбе с головной болью - отрубить голову. Я бы не спешил этого делать. ГЛОНАСС всегда можно "вырезать" на этапе пост-обработки.

Я бы сказал не голову отрубить и аппендикс вырезать (и то при воспалении :).
При постобработке подавляющее большинство вообще не вникает, что куда и как, а просто щелкает мышкой в каком-нибудь дремучем софте. Если я все же отключу Глнасс для VRS, то только по умолчанию, которое однозначно большинство устроит, а для любителей креатива по согласованию Глонасс для VRS будет оставлен.
Aleks
Специалист
 
Сообщения: 554
Зарегистрирован: 13 ноя 2009, 00:44

Re: Тема для обсуждения структуры т.н. VRS-файлов сети ZAKPO

Сообщение Сергей Флерко » 16 дек 2011, 14:01

Aleks писал(а):Если я все же отключу Глнасс для VRS, то только по умолчанию, которое однозначно большинство устроит, а для любителей креатива по согласованию Глонасс для VRS будет оставлен.


Саша, Вас приведенные выше результаты не убедили в обратном?
С уважением,
Сергей

____________________
Precise Thinking ...
New NovAtel OEM7:: http://www2.novatel.com/OEM7
Аватара пользователя
Сергей Флерко
Специалист
 
Сообщения: 1219
Зарегистрирован: 20 июн 2007, 16:43
Откуда: Харьков, Украина

Re: Тема для обсуждения структуры т.н. VRS-файлов сети ZAKPO

Сообщение Aleks » 16 дек 2011, 14:13

Да я знаю это все, я вообще тему создал по "рекомендации" уважаемого Kukinа. В одном он прав на 100%, у людей масса старинного софта, который может криво отреагировать на такой Глонасс.
Aleks
Специалист
 
Сообщения: 554
Зарегистрирован: 13 ноя 2009, 00:44

Re: Тема для обсуждения структуры т.н. VRS-файлов сети ZAKPO

Сообщение Aleks » 16 дек 2011, 16:02

Уважаемые! Я бы Вас попросил запостить выводы и, возможно, рекомендации по обработке данных от VRS с Глонасс при постобработке от ZAKPOS.
Как мне кажется, чтобы было проще для рядовых пользователей, стоит оттолкнуться от приемников пользователей, т.е. типа если у Вас одночастотный GPS приемник, данная тема Вам погоды не делает .. :) и т.д.
Aleks
Специалист
 
Сообщения: 554
Зарегистрирован: 13 ноя 2009, 00:44

Re: Тема для обсуждения структуры т.н. VRS-файлов сети ZAKPO

Сообщение kukin » 16 дек 2011, 16:41

Сергей Флерко писал(а): приведенные выше результаты не убедили в обратном?

Сергей, выложите пожалуйста отчеты по обработке векторов, что и как участвовало.
kukin
Специалист
 
Сообщения: 545
Зарегистрирован: 15 янв 2010, 22:16
Откуда: Украина, Ужгород

Re: Тема для обсуждения структуры т.н. VRS-файлов сети ZAKPO

Сообщение Сергей Флерко » 16 дек 2011, 17:27

Тут отчет по одному из векторов, скажите, что именно добавить - я добавлю.
Вывод итогового отчета GrafNet - не самое простое дело :)
Вложения
VRS-MIZG.zip
(99.51 КБ) Скачиваний: 130
С уважением,
Сергей

____________________
Precise Thinking ...
New NovAtel OEM7:: http://www2.novatel.com/OEM7
Аватара пользователя
Сергей Флерко
Специалист
 
Сообщения: 1219
Зарегистрирован: 20 июн 2007, 16:43
Откуда: Харьков, Украина

Re: Тема для обсуждения структуры т.н. VRS-файлов сети ZAKPO

Сообщение kukin » 16 дек 2011, 18:08

Сергей Флерко писал(а):что именно добавить - я добавлю.

Меня интересует только отчет по спутникам, которые принимали участие в обработке вектора.
В отчете TBC есть изображение графика участия спутников в обработке к примеру
Такой график я и хотел бы увидеть.
Я предполагаю, что Вы дважды обрабатываете только по GPS, глонасс просто игнорируется (поскольку ПО не воспринимает ГЛОНАСС).
Топкон тулс для меня остался загадкой, как там все таки работать в географических координатах, результаты резко отличаются от тримбла и нователа, да и отчеты слишком "сдержанные".
kukin
Специалист
 
Сообщения: 545
Зарегистрирован: 15 янв 2010, 22:16
Откуда: Украина, Ужгород

Re: Тема для обсуждения структуры т.н. VRS-файлов сети ZAKPO

Сообщение Сергей Флерко » 16 дек 2011, 18:14

Роман,

Последний график в отчете - это количество спутников, измерения по которым принимали участие в обработке вектора, аналогичный график при обработке "GPS only" содержит от 7 до 9 спутников. GrafNet не TBC и повторить аналогичные картинки я не могу. Могу выложить такой же отчет по стилю GPS only.

Я предполагаю, что Вы дважды обрабатываете только по GPS, глонасс просто игнорируется (поскольку ПО не воспринимает ГЛОНАСС).

Поверьте, я могу определить в GrafNet обрабатывался ГЛОНАСС или нет, но для собственного контроля скинул данные в support NovAtel, откуда получил однозначный ответ:

I processed your data. I did very basic steps:
1 - Created a new project and added the 3 GPB files
2 - Set VRS_MKRS as control with your coordinates
2 - Processed all baselines using "GPS+GLONASS"
3 - Processed all baselines using "GPS"

I left all the settings at the defaults, except I processed "both" directions. I tested "forward only" and got very similar results for both styles of processing.

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

____________________
Precise Thinking ...
New NovAtel OEM7:: http://www2.novatel.com/OEM7
Аватара пользователя
Сергей Флерко
Специалист
 
Сообщения: 1219
Зарегистрирован: 20 июн 2007, 16:43
Откуда: Харьков, Украина

Re: Тема для обсуждения структуры т.н. VRS-файлов сети ZAKPO

Сообщение Сергей Флерко » 16 дек 2011, 18:40

Я бы Вас попросил запостить выводы и, возможно, рекомендации по обработке данных от VRS с Глонасс при постобработке от ZAKPOS.
Как мне кажется, чтобы было проще для рядовых пользователей


Саша, давайте еще подождем выводов независимого эксперта.,
С уважением,
Сергей

____________________
Precise Thinking ...
New NovAtel OEM7:: http://www2.novatel.com/OEM7
Аватара пользователя
Сергей Флерко
Специалист
 
Сообщения: 1219
Зарегистрирован: 20 июн 2007, 16:43
Откуда: Харьков, Украина

Re: Тема для обсуждения структуры т.н. VRS-файлов сети ZAKPO

Сообщение kukin » 16 дек 2011, 18:53

То, что ответил суппорт, можно детям в садике объяснять (простите за прямоту).
Я не сомневаюсь, что Вы обрабатывали и по ГЛОНАСС, я тоже учитываю ГЛОНАСС в обработке. НО! В тбц приятно то, что он отображает какие эпохи принимались для обработки а какие отбраковывались для каждого из спутников. Повторюсь в нашем случае ГЛОНАСС отбраковывается в новых версиях ПО, а в старых дает ложный результат.
Я понимаю, что это разное ПО, и многие вещи просто не существуют в том или ином ПО.
Но могу ли я получить ответ, принимаются ли ГЛОНАСС спутники в обработку, или отбраковываются в момент обработки.
Я думаю в GrafNet есть функция отключения конкретных спутников в ручную, я попрошу сделать одну "хитрость", принудительно заставить GrafNet "опираятся" на спутники ГЛОНАСС:
Оставьте в обработке только 29, 16, 21 спутники GPS и возможно один на свой выбор. Это заставит программу "опереться" на глонасс поскольку обработка по GPS не даст фиксированного результата. Если в таком случае получится фиксированный результат(и он будет близок к заявленным выше результатам), значит ГЛОНАСС полезен и входит в обработку, у меня тогда появятся вопросы к ПО постобработки Тримбл, а отпадут вопросы к Закпос.
kukin
Специалист
 
Сообщения: 545
Зарегистрирован: 15 янв 2010, 22:16
Откуда: Украина, Ужгород

Re: Тема для обсуждения структуры т.н. VRS-файлов сети ZAKPO

Сообщение gnss-dev » 22 дек 2011, 10:37

По результатам моего анализа данных VRS-файлов, я делаю следующее заключение - VRS-измерения по Глонасс формируются с аномалиями, которые представляют собой тренды в фазе порядка нескольких единиц метров. В результате чего корректная фазовая обработка данных измерений не представляется возможной.

Ваши предположения относительно наличия ухода фазы от кода порядка 200-400м пока ничем не подтверждаются. По этому поводу я уже писал - причина в некорректно сформированных файлах эфемерид ГЛОНАСС, из-за которых используемая утилита Novatel отображает неверные данные и вводит Вас в заблуждения. Элементарная проверка характера данной зависимости вручную на калькуляторе показала отсутствие данных аномалий в VRS-измерениях.

Как разработчик ПО постобработки могу поделиться собственными соображениями по этому поводу. Обработка фазовых измерений ГЛОНАСС с получением фиксированного фазового решения является нетривиальной задачей и не имеет в общем случае единственного решения. Основная причина этого - отличительная особенность архитектуры системы ГЛОНАСС которая состоит в частотном разделении каналов. Это приводит к тому, что: а) при составлении вторых разностей не исключаются ошибки часов приемников; б) ошибки обусловленные нелинейностью аналоговых радиотрактов приемников также не компенсируются. В итоге гарантированная возможность получения надежных фиксированных фазовых решений может быть достигнута только при использовании либо однотипных, либо откалиброванных друг относительно друга приемников. (Кстати поэтому Novatel и не ввели функцию получения фикс. решений ГЛОНАСС в свои пакеты, так как это может привести с ошибкам решений. А в продукте RTKPost имеется соответствующая опция режима разрешения неоднозначностей "Auto calibration").

Судя по всему такой ГЛОНАСС никому не будет нужен. Так что его можно смело отключать до лучших времен (установления и устранения причин)
gnss-dev
 
Сообщения: 9
Зарегистрирован: 07 дек 2011, 12:51

Re: Тема для обсуждения структуры т.н. VRS-файлов сети ZAKPO

Сообщение gnss-dev » 22 дек 2011, 12:09

Вот график остаточных отклонений базовой линии VRS159-UZHL (соответственно L1 и iono-free).
Решения фиксированные (по GPS). Остатки спутников GPS в нулях, по глонасс - в диапазоне +-10 циклов.
Вложения
anomalies_vrs_glo_L1.png
L1
anomalies_vrs_glo_iono_free.png
iono-free
gnss-dev
 
Сообщения: 9
Зарегистрирован: 07 дек 2011, 12:51

Re: Тема для обсуждения структуры т.н. VRS-файлов сети ZAKPO

Сообщение kukin » 22 дек 2011, 13:33

gnss-dev писал(а):Ваши предположения относительно наличия ухода фазы от кода порядка 200-400м пока ничем не подтверждаются. По этому поводу я уже писал - причина в некорректно сформированных файлах эфемерид ГЛОНАСС, из-за которых используемая утилита Novatel отображает неверные данные и вводит Вас в заблуждения. Элементарная проверка характера данной зависимости вручную на калькуляторе показала отсутствие данных аномалий в VRS-измерениях.

Вот работа моего "калькулятора"(ИМХО:что-то тут не так):
R24______________C1________________L1____________________L2______________________P2
11_12__8__8__0__0.0000000
MKRS________19903277.342______106431775.858_________82780289.439_______________19903280.873
VRS_________19903263.010______106431059.161_________82779848.183_______________19903267.753
Δn______________14.332__________716.697________________441.256______________________13.12
11_12__8__9_40__0.0000000
MKRS________19764344.861______105688833.982_________82202443.800_______________19764348.762
VRS_________19764333.314______105688232.171_________82202092.191_______________19764338.211
Δn______________11.547__________601.811_______________351.609________________________10.551


R23______________C1________________L1____________________L2______________________P2
11_12__8__8__0__0.0000000
MKRS________20344877.823______108831377.550_________84646650.799_______________20344883.243
VRS_________20344864.842______108830541.487_________84645988.182_______________20344870.826
Δn______________12.981____________836.063_____________662.617_______________________12.417
11_12__8__9_40__0.0000000
MKRS________23383750.046______125087227.840_________97290073.269_______________23383759.080
VRS_________23383738.598______125087335.288_________97290144.601_______________23383748.798
Δn______________11.448____________-107.448_____________-71.332_______________________10.282


G16 _____________C1________________L1____________________L2______________________P2
11_12__8__8__0__0.0000000
MKRS________22772780.998______119671752.581_________93250710.073_______________22772780.085
VRS_________22772784.364______119671754.923_________93250765.840_______________22772788.251
Δn______________-3.366__________-2.342________________-55.767______________________-8.166
11_12__8__9_40__0.0000000
MKRS________21180053.489______111301912.859_________86728757.281_______________21180052.411
VRS_________21180058.591______111301927.656_________86728823.352_______________21180063.016
Δn______________-5.102____________-14.797_____________-66.071_______________________-10.605

Вырезки из тела файлов наблюдений VRS и MKRS за одни периоды времени.
А вот к вычислениям график(предоставленный уважаемым Сергеем Флерко):
Изображение
совсем забыл указать и этот:
Изображение
gnss-dev писал(а):Как разработчик ПО постобработки могу поделиться собственными соображениями по этому поводу. Обработка фазовых измерений ГЛОНАСС с получением фиксированного фазового решения является нетривиальной задачей и не имеет в общем случае единственного решения. Основная причина этого - отличительная особенность архитектуры системы ГЛОНАСС которая состоит в частотном разделении каналов. Это приводит к тому, что: а) при составлении вторых разностей не исключаются ошибки часов приемников; б) ошибки обусловленные нелинейностью аналоговых радиотрактов приемников также не компенсируются. В итоге гарантированная возможность получения надежных фиксированных фазовых решений может быть достигнута только при использовании либо однотипных, либо откалиброванных друг относительно друга приемников.

То есть работа GNSS RTK от сети - это всемирный обман? Изображение
gnss-dev писал(а):А в продукте RTKPost имеется соответствующая опция режима разрешения неоднозначностей "Auto calibration").

Ага эффект от неё очень и очень интересный(обработка сугубо по GLONASS)!
RTKpost_GLONASS.JPG


gnss-dev писал(а):Судя по всему такой ГЛОНАСС никому не будет нужен. Так что его можно смело отключать до лучших времен (установления и устранения причин)

Физические станции обрабатываются грамотно, а виртуальные дают ложный результат (как ТБЦ, так и РТКпост). По этому для начала надо найти причину, а потом решать выключать ли ГЛОНАСС, лишить пользователей ГЛОНАССа, это не решение проблемы!
kukin
Специалист
 
Сообщения: 545
Зарегистрирован: 15 янв 2010, 22:16
Откуда: Украина, Ужгород

Re: Тема для обсуждения структуры т.н. VRS-файлов сети ZAKPO

Сообщение kukin » 22 дек 2011, 15:11

Давайте рассмотрим R15 спутник на графике указан как 52 (52-37=R15), это один из наиболее ярких примеров "ухода"
R15______________C1________________L1____________________L2______________________P2
11 12 8 8 0 0.0000000
MKRS________22327310.394______119310367.608_________92796973.937_______________22327316.432
VRS_________22327298.156______119308954.327_________92795845.051_______________22327303.555
Δn____________12.238____________1413.281_______________1128.886___________________12.877

11 12 8 8 30 0.0000000
MKRS________21699142.663______115953631.320_________90186178.680_______________21699149.516
VRS_________21699130.220______115952577.139_________90185329.224_______________21699136.476
Δn____________12.443____________1054.181_______________849.456___________________13.04

11 12 8 9 0 0.0000000
MKRS________21606328.804______115457660.265_________89800422.372_______________21606336.032
VRS_________21606316.360______115457041.293_________89799911.745_______________21606322.714
Δn____________12.444____________618.972_______________510.627___________________13.318

11 12 8 9 30 0.0000000
MKRS________22055927.948______117860172.829_________91669041.032_______________22055935.947
VRS_________22055917.446______117860009.844_________91668884.919_______________22055925.100
Δn____________10.502____________162.985_______________156.113___________________10.847

11 12 8 9 59 59.0000000
MKRS________22956221.991______122671040.344_________95410820.106_______________22956230.912
VRS_________22956211.301______122671280.501_________95410977.525_______________22956219.891
Δn____________10.69____________-240.157_______________-157.419___________________11.021

Отчетливо видно фаза уходит в "минус", относительно реального приемника (у GPS такого не наблюдается). Конечно эти примеры не претендуют на эталон, поскольку в реальном приемнике тоже убегает фаза относительно кода, но однозначно не столь ярко, как в VRS.
Я не имел шанса обрабатывать измерения в ПО от NovAtel, но уверенность в справедливости анализа и обработки ПО этого производителя, лично у меня растет.
kukin
Специалист
 
Сообщения: 545
Зарегистрирован: 15 янв 2010, 22:16
Откуда: Украина, Ужгород

Re: Тема для обсуждения структуры т.н. VRS-файлов сети ZAKPO

Сообщение gnss-dev » 22 дек 2011, 15:18

kukin писал(а):Вот работа моего "калькулятора"(ИМХО:что-то тут не так):

Ваш и мой калькулятор считают правильно, просто по случайности я выбирал "хорошие" спутники, для которых разность не превышала 20м, что вводило в заблуждение меня. :? Приношу свои извинения. Инструмент NovAtel здесь не причем

kukin писал(а):То есть работа GNSS RTK от сети - это всемирный обман? .

Я считаю что в общем случае да. Вы видели и слышали чтобы кто-то работал в RTK-сети по чистому ГЛОНАСС. Я допускаю такую возможность только если станции и роверы однотипные(либо откалиброваны производителем). Да никто и не спорит что ГЛОНАСС полезен в RTK, но только в качестве поддержки GPS-ов

kukin писал(а):Физические станции обрабатываются грамотно, а виртуальные дают ложный результат (как ТБЦ, так и РТКпост). По этому для начала надо найти причину, а потом решать выключать ли ГЛОНАСС, лишить пользователей ГЛОНАССа, это не решение проблемы!

Я говорю о необходимости отключения ГЛОНАСС только в отношении VRS. Ибо пользователи с ним наломают дров.
gnss-dev
 
Сообщения: 9
Зарегистрирован: 07 дек 2011, 12:51

Re: Тема для обсуждения структуры т.н. VRS-файлов сети ZAKPO

Сообщение kukin » 22 дек 2011, 16:11

gnss-dev писал(а):Я говорю о необходимости отключения ГЛОНАСС только в отношении VRS. Ибо пользователи с ним наломают дров.

Ну это всплыло в ноябре этого года, только вот не пойму, как до меня это не открыли?
Ведь такая ситуация с ГЛОНАСС была прослежена с окончания 2009 года - первые мои файлы, тогда работал c тримбл 5800 (он работает только с GPS).
Обидно за то, что Trimblе сказать нечего, кроме как порекомендовать обновление :shock:
kukin
Специалист
 
Сообщения: 545
Зарегистрирован: 15 янв 2010, 22:16
Откуда: Украина, Ужгород

Пред.

Вернуться в ZAKPOS: сеть постояннодействующих GNSS станций

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1



Сервер мережі референцних станцій - ZAKPOS. Дані референцних станцій, дані VRS-станцій, актуальні дані про стан мережі Інформаційний сайт мережі референцних станцій - ZAKPOS. Довідкова інформація, новини, партнери, форум, контакти Рейтинг GPS Клуба. GPS навигаторы. GPS мониториг. GPS трекеры. ГЛОНАСС
cron