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

Как же все-таки достали эти волшебники

При подключении ZED-F9P к старому планшету с android4 rtkgps
он конечно правильно не заработал (кроме записи лога).
Поиск подходяшей версии из 149 форков оказался делом непростым.
Я собрал одну версию которая не сразу падает при нажатии кнопки “input stream”,
но пользоваться этим невозможно.
С arm64 дела обстоят лучше, но сразу проявились странности с galileo E5b,
который показыватся как L2, но это уже проблема в rtklib (так сделано специально для уменьшения
размера матриц ?).

Зря Вы так, скрипт работает, только нужно прогружать его каждый раз при включении питания (может у меня backup battery села, конечно).

Может быть кто-нибудь знает как командами управлять режимом TMODE3 на приемниках M8?
Т.е., нужен скрипт, в котором командами можно менять режим Survey-In на Fixed, и, в идеале, задавать опорные координаты)?

Если это можно задать через u-center, то он там пишет, какие байты нужно отправить.

Что-то не замечал, посмотрю, спасибо.
Или вообще, может быть, проще сразу готовую конфигурацию загрузить. Через u-center есть такая функция, а, например, через RTKLib/RTKGPS как это сделать? Просто указать файл конфигурации как загрузка скрипта при старте?

Так же есть примеры с отправкой команд, напиши по аналогии свою.

Заметил, что в примерах (скриптах) команды вида:

!UBX CFG-GNSS 0 32 32 1 6 16 16 0 0

А в конфигурациях вида:

CFG-TMODE3 - 06 71 28 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1E 00 00 00 90 D0 03 00 00 00 00 00 00 00 00 00

Надо разбираться как преобразовать одно в другое.

Если это не кейген с ублоксовскими ключами, добавьте в вики как для ublox6. not published == does not exist.
А если кейген, то так и напишите, как для !UBX CFG-LIC.

“в конфигурациях” перед цифрами надо добавить заголовок (университет Берн “u” “B”) B5 62
, а после цифр два байта контрольной суммы,
тогда это будет !BIN
!UBX поддерживает только ограниченный набор команд, по нынешним временам сильно недостаточный
а !BIN произвольные последовательности.

Товарищи волшебнеки, расскажите мне про волшебства с ZED-F9H.
Вроде нормальный приемник, а даже свои координаты не сообщает.
Я уж про RAWX вообще молчу.

ZED-F9H, вроде, только в паре с F9P может работать - https://www.ardusimple.com/freshly-baked-zed-f9h-now-available

товарищи волшебники с этим не камлают, это для избранных бла бла блошников :laughing:
можно намного дешевле поиграться :stuck_out_tongue:
покупаем пару BN-220 Beitian NEO-M8N в них меняем флеш на большую
и прошиваем FW от M8P, в один базу а в другой ровер.
К тому в котором FW базы припаиваем еще и USB разъем, по штатному COM проводом передаем коррекцию для ровера.
Применяем к каждому волшебство упомянутое раньше :slight_smile:

Если напрягает периодическая загрузка волшебства и reboot после длительного выключения питания
то заменяем малой емкости супер кондесатор на нормальный литиевый элемент.
И все :laughing:

Устанавливаем режим moving baseline а с ровера читаем UBX-NAV-RELPOSNED
где и будет так **желанный NED vector **которые собственно и выдает в десятки раз более дорогой ZED-F9H :roll_eyes:

Собственно я это проверял, надо сказать, что это решение для идеальных условий (дроны … яхты),
ибо в городских каньенах на авто большие переотражения сигналов GNSS и базу будет носить не подецки
а вместе с ним будет гулять и этот GPS компас, причем намного больше чем электронный :stuck_out_tongue:

Официально - да, так как у него очень урезанная прошивка. Прошивка от F9P на нем не работает,
вопрос как эту неприятность исправить. Отсутствие RAWX меня никoгда не смущало и не смущает, даже в
современном TRK-MEAS v8 можно при необходимости разобраться куда они там передвинули бит half-cycle.

первым делом узнать по чтению командой UBX-CFG-PT (продакт тест, значения eFuse ) 06 41 или в HEX B5 62 06 41 00 00 47 DB
в оригинальном F9P
если UBX-CFG-PT изъяли то воспользоваться командой чтения памяти, она то есть везде :smiley:

Вообще-то 06 41 это UBX-CFG-OTP (от One-Time-Programmable).
Там естественно есть различия в дополнительных тэгах 81 и 82 (раньше показывались в MON-PATCH).
Кстати в самых первых версиях F9P их тоже не было, а в F9H они встречаются 2 раза!
Видимо более поздние “записи” в eFuse имеют приоритет.

это да. пока есть везде.

в одном очень древнем pdf 06 41 была обозвана UBX-CFG-PT :slight_smile:
а нынче 06 41 уже обзывают UBX-CFG-OTP

интересно, в F9P изменили алгоритм sha256 или нет ? :roll_eyes:
если не изменили то читаем в F9P содержимое eFuse при помощи UBX-CFG-OTP,
добавляем в конец контрольную сумму eFuses
и отправляем подписанной sha256 командой записи в память F9H, reboot,
т.е. будет как магия превращения M8N в M8T :smiley:

UBX-CFG-PT 06 45
UBX-CFG-PT2 06 59
никакого отношения к eFuse не имеют.

нигде ничего не меняли.

ну ежели наплевать на “уникальный” номер (и другие несущественные мелочи),
то можно конечно сразу все 128 байт вместе с контрольной суммой пихать :sunglasses:
по крайней мере на девайсах выпуска до 1 апреля 2020,
после этого чего-то ублоксовцы замутили на тему “tampering”.

не вижу смысла спорить :smiley:
я брал название из древнего pdf для 5 или 6 версии, уже точно не помню.

какие именно другие несущественные мелочи ? :expressionless:
“уникальный” номер важен только если по USB к компу будет цеплятся два и более девайса с магией :slight_smile:
поскольку UBX-CFG-OTP выдает без контрольной суммы то первые байты “уникального” номера всегда можно перебить при желании ручками, впрочем как и все остальные байты/биты.

Разобрался как менять параметры командами в модулях M8P (M8N c волшебством :)) - спасибо за наводку!
После изменения какого-либо параметра в u-center появляются необходимые команды в открытой HEX-консоли. Копируем команду и ставим перед ней !HEX - вот и всё.

Пример:

Survey-in off mode

!HEX B5 62 06 71 28 00 00 00 00 01 9B C7 F9 21 B0 C1 FC 23 D9 61 00 00 00 00 5A 00 20 A1 07 00 00 00 00 00 90 D0 03 00 00 00 00 00 00 00 00 00 6B 5C

Survey-in on mode

!HEX B5 62 06 71 28 00 00 00 01 01 9B C7 F9 21 B0 C1 FC 23 D9 61 00 00 00 00 5A 00 20 A1 07 00 00 00 00 00 90 D0 03 00 00 00 00 00 00 00 00 00 6C 82

Т.е., вышеуказанные параметры переводят TMODE-3 приёмника сначала в режим disable (начинает отслеживать и менять референцные координаты), а затем в режим Survey-In (определяет и фиксирует координаты для отправки их в 1005 RTCM3 сообщениях - необходимых для ровера).

А вот как задавать численные параметры (т.е, HEX-командами устанавливать координаты) - это ведь для каждой цыфры будут разные байты в строках?

(перенесено из другой темы)

Три Луча, может Тихоокеанский в тестовом режиме. На геодезист.ру один человек специально занимался тестированием геодезических приёмников с Лучами, написал что очень неплохие результаты, гарантированный субметр (1, 2).
Мне сначала надо найти место, где инициализируется PRN для разных спутников, даже если сообщения пустые - должен быть трекинг.

А пока попутно кажется нашел, где выставляется протокол и baudrate по-умолчанию. В разных наладонников были свои настройки, в блутус-приёмниках скорость порта должна быть залочена и т.д. Опять же отрубить этот дурацкий static navigation. Тогда можно будет прокачать любые устройства до самой последней 3.6.0, новее для GSW3 кажется не было.
И хочется наконец разобраться, остались ли хоть какие-то зачатки работы с RTCM или код выпилилен полностью.

Потенциал у прошивок есть - никаких тебе контрольных сумм, правь что хочешь, загрузчик неубиваемый, CPU распространённый ARM7TDMI, HexRays decompiler любит его как родного. Жаль только нет доков по портам ввода-вывода.

Судя по этой картинке сейчас работают два, S25 и S40:

http://mgex.igs.org/analysis/