насколько я понимаю в этом нет резона
все покрыто сетями типа этой
приведенная сеть имеет две базовые, которые расположены в ~4 км от того места где я обычно тестирую девайсы,
SBAS с его точностью это прошлый век
Из за того что нет нигде базовой станции Полтавы в открытом доступе решил установить свою используя 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)
Сохранить выдачу str2str в файл, конвертировать с помощью convbin в RINEX,
и посмотреть будут ли во временных отметках ненулевые миллисекунды.
u-blox использует (на мой взгляд сознательно) разные методы для саботирования совместимости с другими
производителями.
Да, кстати что с этим делать на устройстве? Мой китайский клон F9P мне частенько выдаёт XX.995. Хотя в версии от rtkexplorer есть ключ для устранения этой проблемы
-TADJ возник давным давно не на пустом месте так как у antaris4 были отклонения и на 8 миллисекунд,
для 5,6,7,8 железо допускало только отклонение на 1 миллисекунду,
а вот 9 опять плывет до 5 миллисекунд.
sirf естественно тоже подвержен этой проблеме.
Программная реализация -TADJ довольно глупая (sscanf для каждого UBX пакета, большая радость на 20Hz).
Если RTCM пакеты генерируются чипсетом, то их надо править перед отсылкой,
также как это реализовано для TRK-MEAS.
Это нормально, у Сёрфа вообще 0.0 - 0.150 )))
Это всего-лишь внутренние часы. Есть два варианта сохранения ринекса - сырые данные, как их снял приёмник (ваш случай) и причёсанные, т.е. поправленные на уход часов.
При обработке бинарного потока можно вытащить dT из навигационного решения и поправить время, псевдодальности и фазу на это же значение перед записью в RINEX, естественно переведя в соответствующие единицы измерения - метры и фазы. Скорее всего в этом случае получится время, синхронизированное с GPS, т.е. с нулями в дробной части.
Период пропадания коррекций подозрительно похож на поведение сёрфа, что в своё время доставило мне кучу хлопот. Встроенные часы дрейфуют (и в uBlox, и в Тримбле), чтобы оставаться в заданных пределах регулярно поддёргиваются. Например я видел у некоторых плат Trimble от -0.5 мсек дрейфует в сторону 0.5 мсе, как только достигается это значение - дёргается обратно на -0.5. Это не страшно т.к. момент измерения всё-равно синхронизирован с GPS, но вот некоторым программам это не нравится, происходит срыв инициализации.
Посмотрите в своих ринексах не совпадает ли время сбоя коррекций с моментом перехода часов от +3 мсек обратно к -3 мсек.
Потому что геодезические приемники стараются синхронизировать свои внутренние часы
с GPS (VCO=VoltageControlledOscillator), у ублокс это умеет только LEA-M8F.
Trimble очевидно не любит отклонение меток от “стандартных” значений.
Поменяйте CFG-RATE с 1000 на простое число миллисекунд,
получите эпические практически псевдослучайные временные метки (в RXM-RAW, не смотрел в MSM7),
и увидите как реагирует Тримбл на такой поток данных.
Сегодня впервые поймал “Луч” на 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 тоже не реализован, но вполне возможно он был в ранних прошивках.
Задолбался я с нашими Лучами, PRN 140 вообще не ловится ни в какую уже неделю, а PRN 125 не берётся в обработку. Что-то у меня скепсис появился с этими SBAS-ами. В общем ловится всё что угодно - разные EGNOS, индийский GAGAN, но только не наши Лучи.
Сегодня тестировал в поле, в автономке 10-11 спутников, а когда цепляется к EGNOS 123 то остаётся 8-9 (разные созвездия), при этом позиция заметно ухудшается. Понятно что надо использовать свою региональную систему, а она не пойми в каком состоянии, то-ли работает, то-ли не работает. Информации по ним на сайте СДКМ нет вообще, словно не существуют.