На бумаге - да. Mi8 - первая и последняя попытка использования потенциально нормального
GPS/GALILEO чипсета в телефоне (L1/L2/L5), но все остальное сделано через Ж:
антенна, LNA, недокументированный чипсет, жутко нестабильный трекинг и тд.
Встроенное ПО чудес из некачественных входных данных сделать не сможет,
никаких дифференциальных поправок (даже WAAS/EGNOS полностью игнорируется)
не использует, поэтому даже метровая точность это преувеличение.
Визуально качество треков с Mi8 лучше чем MAX-M8Q, но это скорее всего эффект
использования данных MEMS, а не GPS.
Вот если бы был телефон с чипом ZED-F9R (функциональный аналог BCM47755)
и разъемом для внешней антенны, то это было бы серьезно, а так Mi8 это баловство.
Потому что они геостационарные и находятся в Ж.
Их же не для людей делали.
В СПб спутники японские QZSS и то лучшую геометрию имеют,
но там и EGNOS нормально работает.
насколько я понимаю в этом нет резона
все покрыто сетями типа этой
приведенная сеть имеет две базовые, которые расположены в ~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 тоже не реализован, но вполне возможно он был в ранних прошивках.