-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 (разные созвездия), при этом позиция заметно ухудшается. Понятно что надо использовать свою региональную систему, а она не пойми в каком состоянии, то-ли работает, то-ли не работает. Информации по ним на сайте СДКМ нет вообще, словно не существуют.
Некоторое время я проводил измерения с помощью sirf и увидел, что при преобразовании из Sirf в rinex Mid28 и Mid7 используются для расчета псевдодальности, фазы и других параметров. Но в Mid30 есть поправка на ионосферную задержку, которую я не вижу, чтобы она учитывалась.
Может ли это повлиять на обработку?
Хочу поделиться результатами испытаний такого дешевого приемника с алиэкспресса - китайского клона M8N.
Собрал на его базе простой логгер при помощи одноплатника Orange pi zero. Лог пишется с использованием str2str, пользовался при создании мануалом от rtklibexplorer.
Была выполнена поездка на машине продолжительностью около часа с несколькими длительными остановками. Приемник находился на торпедо под лобовым стеклом. Были участки с 5-этажной застройкой и полностью открытые.
Получаются такие результаты:
Видно по результатам, что фиксированное решение около 50% трека наблюдается только в местах остановки и в местах с замедленным движением. Результат не очень впечатлил, потому что ранее, на китайском старом одночастотном приемнике (типа геодезическом) S750, но с антенной-тарелкой - получал 100% фиксированного решения и двигался при этом с гораздо большими скоростями.
Вопрос: как улучшить качество принимаемого сигнала? Можно ли к нему приколхозить внешнюю антенну, если разъем для нее отсутствует и сам чип скрыт под экраном?
чудесный приемник всего за ~10 баксов
работает лучше чем приемники геодезического класса, многократно проверял
антенну, которая приклеена двухсторонним скотчем (даже не имеет второго контакта)
естественно надо убирать и подпаивать коакс. провод для внешней антенны.
к этому приемнику можно подключить и USB разъем