usm78-gis
В этой ветке любое упоминание любого приёмника, отличного от uBlox, в любом контексте воспринимается вами в штыки. Я вроде никого не принижал и не восхвалял. Написал только что uBlox требует денег за сырые данные, а SiRF раздаёт их бесплатно. Чем бессовестный Trimble с успехом пользуется в целях экономии зеленых бумажек ))
Я несколько страниц назад приводил пример свежих на тот момент rineх с ГЛОНАСС. Вы можете попробовать обработать их в rtklib. Или поверить моей обработке и посмотреть на картинки там же. Там ГЛОНАСС в kinematic режиме был лучше gps (случайно). Попробуйте на тех же файлах режим Single по ГЛОГАСС. Я думаю тоже все будет хорошо.
Продублирую тот пост здесь.
Возможно вы пользуетесь не самой новой версией rtklib. Недавно была коррекция UTC на одну секунду. В rtklib 2.42p11 это учтено. В более старых патчах - не знаю.
UPD:
Посмотрел ваш conf.
Возможно дело в том что вы используете beta-версию 2.4.3. Попробуйте rtklib 2.4.2p11.
2all
У меня небольшой совет по методике лабораторного тестирования RTKLib (когда антенна зафиксирована). Сначала обработать данные как статику. Полученные координаты затем можно использовать как опорные для сравнения в режиме кинематики. Строится scatter plot (Kinematic vs Static). Кажется в RTKLib есть режим принудительного центрирования 2D-plot относительно фиксированной точки.
В случае malcontent, когда антенна стационарно закреплена на крыше, статику лучше сделать своим самым лучшим приёмником и самой лучшей антенной, далее использовать эти координаты как опорные.
Если кто-то уже проделывал такие построения, пожалуйста прикрепите скриншот.
Иначе по графикам видно что RTKLib получил фиксированное решение, а какова его абсолютная точность непонятно.
(added)
Также интересно узнать есть ли в RTKLib двухпроходная обработка: если за время сессии у конкретных спутников не было срывов фазы, то ambiguity должны быть одинаковыми, решение FIXED должно распространяться вторым проходом от конца сессии к началу. Пока что все графики отражают симуляцию RTK с нулевым возрастом коррекций. Т.е. лучше чем настоящий RTK, но хуже настоящей postprocessed kinematic.
Заранее благодарен за информацию т.к. сам с тонкостями RTKLib не знаком.
Извините, не подставил верную опрную точку в rtkplot. Основной целью было показать повышение стабильнотси фикс в двухсистемном решении. А точность одинаковая во всех случаях, независмо от системы, ~ 1см. В это предлагаю поверить наслово.
Абсолютную точность вы не узнаете и в режиме static.
Если под статикой вы имеете ввиду режим static в rtklib или что-то похожее на него, то можно обойтись просто усреднением точек, помеченных как фикс. Эфект будет тот же. Если фикс смещен в режиме kinematic то точно также будет смещено решение в режиме static, только шуметь будет меньше.
В rtklib есть режимы forward, backward, combined. combined - это как раз то о чем вы говорите.
Статика и кинематика по объективным причинам имеют разную точность и, самое главное, достоверность. Отличаются на порядок. Особенно если обработать статику от нескольких баз с последующим уравниванием.
Я не пытаюсь кого-то поймать за руку, я пытаюсь выяснить насколько можно доверять “зеленым” точкам в RTKLib. Верить на слово в геодезии не принято.
Статика - это в первом приближении решение kinematic, пропущенное через усредняющий фильтр. Если решение кинематик недостоверно (смещено, например, на 10 метров), то никаким усреднением достоверность повысить нельзя. Если взять несколько баз, то действительно будет надежнее, но статика здесь опять же непричем.
А если уж проверять точность, то за опору нужно брать другой поверенный инструмент. Вы же предлагаете проверять rtklib rtklib-ом.
Вот тот метод о котором вы говорили. https://www.dropbox.com/s/nbflf5856v5wbo9/static_vs_kinematic.jpg?dl=0
Зеленым кинематик, красным в центре статик с проходом вперед-назад. Но эта картинка ничего не говорит о точности, и тем более, достоверности. С тем же успехом можно было просто глазами прикинуть центр облака, и ткнуть туда опорную точку.
Жесть какая, неужели в RTKLib такое извращенное толкование этого метода ?
Режим обработки Static - картезианский вектор Base->Rover {dX,dY,dZ} в уравнивании единый на весь период сессии, в результате получается огромная избыточность измерений (не надо путать с усреднением). Чтобы нивелировать корелляцию между смежными эпохами (так уж устроены приёмники GNSS) и не получить слишком оптимистичную точность, для статики обычно делают прореживание 15 секунд. Чтобы получить достоверность (особенно с одночастотниками) пишут несколько часов. Так что не надо хихикать над достоверностью. Вы думаете нафига в программах обработки обязательный пункт - распечатка финального отчета.
В кинематике, по сути, каждое новое измерение не зависит от предыдущего, вектор {dXi,dYi,dZi} разный для каждой из эпох. Т.е. информация о статичном положении никак не используется.
За картинку спасибо, то что нужно. Видно что работает нормально, по крайней мере при базе в 4 метра.
Это у меня такое толкование ))). Я же написал, что в первом приближении. Простите, я не очень хорошо знаком с методами геодезических измерений. Но то что вы описали, не будет разительно отличатся от усреднения.
А вот по поводу времени записи, замечено очень верно. Чем дольше пишем, тем более низкочастотные составляющие ошибки, усреднением можно исключить. Так что, та десятиминутная запись которую я привел, мало говорит о возможной медленно меняющейся ошибке. В то что ее нет, я предложил поверить наслово.
Да уже не актуально, почему-то на версии 2.4.3 глонасс не работает Впрочем на 2.4.2р11 мне так и не удалось заставить его считать глонасс с точными эфемеридами. Хотя я подсунул ему совмещённый файл GPS+GLONASS с сайта NASA.
Зато я освоил PPP и в принципе считаю, что вполне можно жить без базовой станции. Да выбросы бывают за 1м, но блин при нынешних подложках это всего 3 пикселя.
chnav, я вычислил по RINEX дрифт часов для TPS Legacy используемого на ФАГС PULJ,
и сравнил его с моим EVK-M8T. Получилось 400-500 ppb vs. 80-100 ppb.
Это конечно не водородный мазер, как у SVTL, но тем не менее разница в 5 раз.
Мне попал в руки уже упоминавшийся здесь Holux SporTrak 1305, он же TwoNav Anima, он же
Medion S3877. В нем действительно имеется GPS приемник ublox.
Навигационная программа MNAVDCE.exe представляет из себя довольно интересную
вещь: используется Qt4 для wince6.0, но при этом зачем-то слинкована с droydsdkqt
( http://doc.qt.io/qt-5/androidgs.html )
Карты естественно ОСМ. Я давно мечтаю о qt версии rtknavi, может данное устройство
сподвигнет меня на это (хотя у него нет антенного разъема, но есть BT,BLE и ANT+).
Технические детали добавлю в вики.
Впрочем на 2.4.2р11 мне так и не удалось заставить его считать глонасс с точными эфемеридами. Хотя я подсунул ему совмещённый файл GPS+GLONASS с сайта NASA.
