Есть сборка под Андроид, но это не постобработка, а именно RTK с приёмниками u-Blox https://play.google.com/store/apps/details?id=gpsplus.rtkgps Базируется на RTKGPS от Alexey Illarionov
Может кому-то будет интересно, тут такой информации не нашёл. Попробовал, используя RtkLib 2.4.3 получить решение с применением корректирующей информации SBAS. Поправки принимались приёмником (Javad) со спутника Луч-125 (СДКМ). Место действия г. Москва. Результат вроде как получился не плохой. Единственное, пришлось немного подшаманить код RtkLib-а, так как он неправильно определял опорную эпоху ГЛОНАСС. Решение навигационной задачи осуществлялось в режиме реального времени по методу наименьших квадратов. Использовался код стандартной точности в частотном диапазоне L1 (L1C). Модель тропосферной задержки была установлена SBAS. Ионосферная задержка вычислялась по информации из карты вертикальных ионосферных задержек, представленных в сигнале SBAS. Угол отсечки для спутникового созвездия был ограничен маской в 5°. Результаты на суточном интервале (08.09.2019) получились такие: Так же не удержался :) и попробовал c помощью RtkLib получить PPP решение с применением корректирующей информации SBAS. С ходу правда сделать это не получилось, пришлось опять править код, чтобы заставить RtkLib в PPP решении корректно использовать только частоту L1C. Абсолютное отклонение в режиме PPP static для совместного решения (ГЛОНАСС+GPS) составило 12 сантиметров, 15 см для GPS и 12 см для ГЛОНАСС.
Фантастика, оказывается СДКМ запустили ! Интересно какие приёмники его поддерживают, особенно из бытовых.
По данным igs (http://mgex.igs.org/analysis/index.php) СДКМ передаёт сигнал SBAS с 2015 года, правда с небольшими перебоями в работе. СДКМ это SBAS в чистом виде, поэтому приёмники, поддерживающие SBAS, должны работать и с СДКМ. Хотя мой опыт работы с RtkLib говорит о том, что могут быть проблемы с поддержкой ГЛОНАСС. Кстати, разбираясь как работает SBAS, видел примеры, люди проверяя точность SBAS (WAAS, EGNOS) применяли поправки к ионосферно-свободной комбинации измерений или к сигналу L1P. Как потом выяснилось это может привести к ухудшению точности, так как SBAS передаёт поправки только для частоты L1C и не учитывает смещения между L1-L2 и L1C-L1P. А на счёт бытовых приёмников, мне вот, что понравилось - https://www.ion.org/publications/abstract.cfm?articleID=15929, SBAS применили к сырым измерениям телефона Samsung Galaxy S8 и получили улучшение точности в несколько раз. Для нескольких моих знакомых, заядлых лыжников, улучшение в несколько раз получаемого посредством телефона трека было бы маленьким чудом :).
В приёмнике должен быть прошит PRN этого спутника, если нет - работать точно не будет. Поэтому и спрашиваю про список подтвержденных приёмников.
Точного списка приёмников, наверное, нет, но приёмники таких производителей как Javad, Trimble, Novatel с которыми мне приходилось работать поддерживали сигнал СДКМ.
Как бы, портированное только РТКНАВИ. Заявлена возможность вместо потока дать на вход лог РТСМ, на ГИТХАБЕ пишет, что и РИНЕКС. В версии, доступной для установки с плэй стор РИНЕКС нету, есть БИНЕКС))) Кто пробовал подсунуть файл? Может, вот она, ППК?
А можете поделиться патчем исходного кода, а то приходится откатывать на версию 2.4.2 для РРР, что не удобно.
Я бы не назвал это патчем. Была задача сделать PPP используя поправки SBAS. Я быстренько для себя подправил код RtkLib, да так, что теперь PPP в нём работает только с SBAS и ни как иначе :). Вряд ли это то, что Вам нужно. Но если у Вас есть желание и время разобраться, я могу объяснить, что нужно подправить и как, чтобы в RtkLib заработало PPP для одной частоты.
Здравствуйте! Подскажите пожалуйста, можно ли в RTKPost одновременно (не по очереди) обработать наблюдения за несколько суток? Если можно, то как это сделать?
Оффтоп (Move your mouse to the spoiler area to reveal the content) В верхней строке "Time Start" "Time End" определяется обрабатываемый период. На сколько помню домер высоты обнуляется.
Читайте внимательно инструктив: If a wild‐card (*) is included in the file path, the wild‐card is expanded and the multiple files are used
Спасибо! Всё получилось. Обсчитал почти 2-суточный вектор ФАГС "Самара" (Исходный) - ФАГС "Нижний Новгород" (Определяемый). Разница от каталожных координат NNOV составила: X = -0.0054, Y = 0.0182, Z = 0.0195. Очень круто!
Можно получить сантиметровую точность с помощью rtknavi, в режиме static, в течении пары часов в режиме реального времени. Проверено на базах более 2000 км. В настройках rtknavi выбираем ионосферно-свободную комбинацию, тропосферу по модели, а для орбит и часов указываем сервис realtime ppp. Тут режима fix не будет, только float, слишком маленькая длина волны, но уже нет проблем с ионосферой и тропосферой, ошибки часов спутников уходят при двойных разностях, остается только ошибка местоположения спутников, но она уходит за счет realtime ppp. Тестировал сервисы от igs, ркс и спп. Через два часа с использованием сервисов от igs и ркс сходимость от эталонных координат не превышает 1-2 см, проверял на базах от тысячи до более двух тысяч километров. Единственное, не понятно почему, сервис realtime ppp от спп подкачал, сходимость в rtknavi даже за сутки превышала 20 см.
Хочу заметить, что фиксированое решение вероятно на коротких дистанциях, скажем до 100 км в прыжке. Дальше (более длинные векторы) не имеет смысла его (фиксированное решение) искать, float по двум частотам с моделями тропо и точными эфемеридами - лучшее. Вроде это связано с теоремой Котельникова-Найквиста.
С их сайта : В настоящее время СВОЭВП 2-го этапа находится в опытной эксплуатации. Да и это проходит по ФЦП ГЛОНАСС, сори, доверия выходным продуктам от этой отмывалки нет ...
