RTKlib/постпроцессинг

Добрый день!
Нашёл вот такое исследование
https://europepmc.org/article/PMC/6603672
Если я правильно понял вывод в п. 7,то итог такой:
1)смартфон при наличии спец. Программного обеспечения может добиться субметровой точности и в статике и в кинематике
2)при использовании ПО, встроенного в телефон можно добиться только мнтровой точности
У меня к вам просьба:прочтите вывод их(а может вам будет интересно все исследование, методика и т. Д.) и отпишите мне пожалуйста о ваших выводах!

Массив тоже таблица, но спасибо за нестандартное решение перебором G2, очень помогло. Нашёл в прошивке сёрфа инициализацию G2,там вписана таблица 1023 бита и инициализация выдёргивает нужное битовое окно.
Что я не понимаю до сих пор - почему в Москве спутники Луч висят ниже 11°, но радует, что российский Космос работает на регионы. В центральной России много сетей, а на ДВ не очень.

в Харькове 125 висит на 15° но работает редко, 140 висит на 10° но работает почти всегда,
оба спутника передают одно и тоже.

На бумаге - да. Mi8 - первая и последняя попытка использования потенциально нормального
GPS/GALILEO чипсета в телефоне (L1/L2/L5), но все остальное сделано через Ж:
антенна, LNA, недокументированный чипсет, жутко нестабильный трекинг и тд.

Встроенное ПО чудес из некачественных входных данных сделать не сможет,
никаких дифференциальных поправок (даже WAAS/EGNOS полностью игнорируется)
не использует, поэтому даже метровая точность это преувеличение.
Визуально качество треков с Mi8 лучше чем MAX-M8Q, но это скорее всего эффект
использования данных MEMS, а не GPS.
Вот если бы был телефон с чипом ZED-F9R (функциональный аналог BCM47755)
и разъемом для внешней антенны, то это было бы серьезно, а так Mi8 это баловство.

Потому что они геостационарные и находятся в Ж.
Их же не для людей делали.
В СПб спутники японские QZSS и то лучшую геометрию имеют,
но там и EGNOS нормально работает.

Давно уже бы пора интегрироваться в EGNOS, все украинские станции даже в EUREF имеются.

насколько я понимаю в этом нет резона :slight_smile:
все покрыто сетями типа этой
приведенная сеть имеет две базовые, которые расположены в ~4 км от того места где я обычно тестирую девайсы,
SBAS с его точностью это прошлый век :smiley:

Из за того что нет нигде базовой станции Полтавы в открытом доступе решил установить свою используя U-blox F9P + ESPRTK.

Результат таков:

  • Все заработало и поправки идут в RTCM 3.2.
  • Получилось инжектировать 1008.
  • Тримбл девайс начал работать с этой станцией.
  • Alpha RTK Также ловит фикс

Теперь о плохом:

  • Коррекция работает примерно 15-30 минут. После чего в Тримбл перестает работать коррекция (Alpha RTK не тестил).
    Отсутствие коррекции продолжается также около 20-30 минут, потом все начинает работать, и так по кругу. Либо нужно перезагрузить модуль U-blox F9P (могу удаленно ресетнуть по питанию) и коррекция восстанавливается сразу.

Расчет координат базы делал через OPUS с данными более суток.

Также данные с UART2 пробовал паралельно пропускать через strsvr. Все также работает на Trimble и коррекция пропадает одновременно с линией UART1 на ESPRTK.

Общий список сообщений 1005(1), 1008(5), 1077(1), 1087(1), 1097(1), 1127(1), 1230(5)

Прошу помощи знатоков по настройки базы.

Написал человек занимающийся припарками к глонассу :roll_eyes:

Ваша версия strsvr уравнивает сырые данные на целые секунды ?

Использую версию RTKLIB_bin demo5_b33c

Как это узнать?

Сохранить выдачу str2str в файл, конвертировать с помощью convbin в RINEX,
и посмотреть будут ли во временных отметках ненулевые миллисекунды.
u-blox использует (на мой взгляд сознательно) разные методы для саботирования совместимости с другими
производителями.

Да, кстати что с этим делать на устройстве? Мой китайский клон F9P мне частенько выдаёт XX.995. Хотя в версии от rtkexplorer есть ключ для устранения этой проблемы

-TADJ=0.005

-TADJ возник давным давно не на пустом месте так как у antaris4 были отклонения и на 8 миллисекунд,
для 5,6,7,8 железо допускало только отклонение на 1 миллисекунду,
а вот 9 опять плывет до 5 миллисекунд.
sirf естественно тоже подвержен этой проблеме.
Программная реализация -TADJ довольно глупая (sscanf для каждого UBX пакета, большая радость на 20Hz).
Если RTCM пакеты генерируются чипсетом, то их надо править перед отсылкой,
также как это реализовано для TRK-MEAS.

Прилагаю скрин файла

Прошу взглянуть.

Время плавает ± 0,003

Как с этим боротся?

У меня вроде оригинал. Покупал тут - https://www.gnss.store/gnss-gps-modules/99-ublox-zed-f9p-rtk-gnss-receiver-board-with-sma-base-or-rover.html

Это нормально, у Сёрфа вообще 0.0 - 0.150 )))
Это всего-лишь внутренние часы. Есть два варианта сохранения ринекса - сырые данные, как их снял приёмник (ваш случай) и причёсанные, т.е. поправленные на уход часов.

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

Спасибо за ответ.

Вернусь к своей изначальной проблеме о которой я писал ранее.

Почему пропадает коррекция на Trimble ровере от базы на F9P?

К чему такие симптомы?

Период пропадания коррекций подозрительно похож на поведение сёрфа, что в своё время доставило мне кучу хлопот. Встроенные часы дрейфуют (и в uBlox, и в Тримбле), чтобы оставаться в заданных пределах регулярно поддёргиваются. Например я видел у некоторых плат Trimble от -0.5 мсек дрейфует в сторону 0.5 мсе, как только достигается это значение - дёргается обратно на -0.5. Это не страшно т.к. момент измерения всё-равно синхронизирован с GPS, но вот некоторым программам это не нравится, происходит срыв инициализации.

Посмотрите в своих ринексах не совпадает ли время сбоя коррекций с моментом перехода часов от +3 мсек обратно к -3 мсек.

Потому что геодезические приемники стараются синхронизировать свои внутренние часы
с GPS (VCO=VoltageControlledOscillator), у ублокс это умеет только LEA-M8F.
Trimble очевидно не любит отклонение меток от “стандартных” значений.
Поменяйте CFG-RATE с 1000 на простое число миллисекунд,
получите эпические практически псевдослучайные временные метки (в RXM-RAW, не смотрел в MSM7),
и увидите как реагирует Тримбл на такой поток данных.

https://cddis.nasa.gov/Data_and_Derived_Products/GNSS/broadcast_ephemeris_data.html

Anonymous ftp service will be discontinued on October 31, 2020.

ftp это зло! Переходите на https. Кстати еще один action item для rtklib.