Статика - это в первом приближении решение 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+).
Технические детали добавлю в вики.
Работает, но поменять-то ничего нельзя, такая же ситуация и с rtkgps(+).
Автор rtklib затаился как советский партизан, и не исправляет даже
элементарные ошибки. Тут уж невольно задумаешься о своей собственной версии.
С этой стороны да, плохо. Но я не силён в плюсах, а QT мне вообще не нравиться. Вижу вариант в отделении полноценно логики в либу, а гуй дальше привязывай кому, что удобней.
Ну так оно уже и сейчас так и есть.
Я вот думаю прямо немедленно сделать rnx2rtkp2, где все опции из .conf файла
будут доступны из командной строки через getopt_long.
Я ни разу не пробовал, но знаю о возможности поставить mono на linux. Поэтому UI воссозданный на c# должен завестись. Надо только wrapper написать с перегоном данных в примитивные типы, вот тут у меня опыта нет, но я часто видел подобное.
Надо обязательно попробовать!
Нужен отттакенный бубен и 100500 библиотек из винды, чтобы хоть что-то заработало.
Инфа трёхгодичной давности, но тогда оно мне сильно не понравилось.
Чем дальше в лес, тем больше дров. Добавил в библиографию диссертацию
на тему Network RTK. Формулы там тоже в ворде (имхо, прямое оскорбление читателя),
но так как они не очень сложные, то разобраться можно.
По поводу ANTEX есть подозрение, что антенные параметры учитываются только в
режиме RTK и PPP, т.е. в дифференциальном постпроцессинге они игнорируются (при том что rtklib
игнорирует азимутальную зависимость PCV).
u-blox официально выложил на сайте прошивку 2.01 для ublox-M8 UBLOX_M8_201.89cc4f1cd4312a0ac1b56c790f7c1622.bin: https://www.u-blox.com/sites/default/files/UBLOX_M8_201.89cc4f1cd4312a0ac1b56c790f7c1622.bin
это вернуло меня к вопросу, почему они так упорно не желают
выложить прошивку с поддержкой галилео.
Какие более или менее бюджетные варианты есть на сегодняшний день
для использования GPS(+галилео) в двухчастотном варианте ?
Впрочем на 2.4.2р11 мне так и не удалось заставить его считать глонасс с точными эфемеридами. Хотя я подсунул ему совмещённый файл GPS+GLONASS с сайта NASA.
