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

в Харькове 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.

Сегодня впервые поймал “Луч” на SirfStar III. Неплохо для прошивки 3.2.4 2006 года. С тех пор код SBAS в прошивке, судя по косвенным признакам, не менялся, а в v3.6.0 его вообще убрали для освобождения флеша под нужды Extended Ephemeris.

Пропатчил приёмник ещё неделю назад, “Луч” иногда выскакивал в переборе спутников с уровнем примерно 22-24 dBHz и сразу исчезал. Также иногда появлялса SBAS 126. А сегодня с удивлением обнаружил, что SV 140 принимается и используется в навигационном решении, уровень 40 dBHz.

Я всю неделю расшифровывал подряд все функции, которые хоть как-то связаны с декодированием SBAS, а, видимо, сигнала не было или очень слабый.

Учитывая возраст, в прошивке отведено место только для 8 спутнков SBAS, из них на сегодня полуживы три - японский 129, американский 138 (planned decommission in 2020) и европейский 126 (status: testing).

Планирую заменить эту таблицу на 8 живых спутников, которые хотя бы потенциально могут приниматься/тестироваться на территории России.

В сёрфе нет принудительного выбора конкретного спутника SBAS. В бинарном протоколе есть соответствующие команды, но код не реализован.

RTCM тоже не реализован, но вполне возможно он был в ранних прошивках.

в EGNOS сейчас реально работают 123 и 136
причем 136 частенько выключается на несколько часов