На текущей стадии я не понимаю, что здесь интересного
Если в уловиях, приближённых к реальным, решения не даёт, то выходит, что rtklib мне не нужен. После такого вывода мне уже всё равно, что он выдаст на static.
А, вот оно что
Кстати, у SUR4 у самого есть NTRIP, почему бы его и не использовать? Осталось только понять, как
То, что надо зарегиться, это я понял. И дальше в rtknavi надо будет выбрать NTRIP Client… а в каком формате оно будет? Совместимом на этот раз с rtknavi? Или опять какие-то конвертеры втыкать?
SviMik
Проверил ваш файл port14.log - после rtkconv rtklab 2.4.1 и rtklib 2.4.2: измерения по L1 должны быть,
больше 100 000 000.000 и только положительными при WAVELENGTH FACT L1/2 = 1 . К сожелению все свои
данные по u-block ANTARIS я уже стер и не могу сделать вывод, кто же неправильно считает ваш u-block
или rtkconv.
Я в гараж заехал. Обрезать не стал, подумал что не мешает.
Мне было интересно решение самого приёмника тоже (иначе NMEA я бы вообще отключил). По поводу GGA не знаю, вдруг какой-то софт RMC использует, потом придётся ещё конвертить, чтобы его восстановить.
Можно последовательность действий для воспроизведения? У меня исключительно Single.
Попробовал вашу команду из командной строки, получилось. В начале есть даже 1% координат Fixed. Только почему-то они ничем не лучше float, гуляют точно также.
Я думал, что Fixed решение - это когда программа уверена в точности результата, но на деле - такая же ерунда, как float.
Также я думал, что float решение уж точно будет лучше, чем single. Но и здесь меня постигло разочарование - треки практически идентичны.
Ну и последний гвоздь в гроб: сравним float, сделанный с базовой станцией и поэтессами с решением самого приёмника, у которого никаких данных, кроме его собственных замеров, нет.
Синим - решение приёмника, жёлтым - float от rtklib.
Как видим, после поворота rtklib совсем потерялся, тогда как приёмник очень точно уложился на дорогу: