Попробовал, работает.
Это хорошо, что сам не сохраняет. Я уже терял связь с устройством, когда проверял, какую максимальную скорость порт поддерживает Если б он сохранял конфиг автоматом - не знаю, что бы делал.
Делал бы reset.
Хотя я бы тоже это предпочел, с батарейкой. На Antaris4 - 115200, этого достаточно для 10Hz сырых данных.
У меня по дефолту вообще 9600 стояло. Так что первым делом сменил на 115200. Ещё пробовал 230400, работает отлично. Только почему-то Ozi такую скорость не понимает Но это уже его личные проблемы, остальной софт ок.
А вот 460800 уже не прокатило.
Так что, возможно с него получить RXM-SFRB, или нет?
Это уж не ко мне
-1
-1
-1
Фраза достойна сочинения на тему “что хотел сказать автор” (и при чём тут вообще windows…)
Разве не вы писали, что ublox 6 уже успешно тестировали с rtklib? Или вместо RXM-SFRB был использован TRK-SFRB?
-1
Ну, по крайней мере, сообщения появились. Теперь осталось понять, что с ними делать
Подключил rtknavi в режиме чисто ровера (без базы). Решения не выдаёт… Или он так не работает?
Тип 1 использовался в двух случаях:
а) аппаратный приемник понимает только этот тип;
б) канал передачи данных имеет скорость 100-300 bps;
Поясню как формируется Type 1 и 2.
Type 1:
- Базовый приемник делает измерение дальностей;
- Корректирует измеренные дальности на ионосферные, тропосферные и прочие задержки по информации из broadcast data;
- Считает положение спутников по информации из broadcast ephemeris;
- Считает разность по каждому спутнику и её дрейф, формирует сообщение Type 1 PRC[m] и RRC[m/s];
Т.е. тип 1 подразумевает что эфемериды и модель атмосферы должны быть бродкастными на базовой станции и ровере. Номер эпохи navdata указывается отдельным полем в Type 1; использовать ultrarapid SP3 не получится (точнее можно, но это будет уже какой-то custom RTCM )))
Type 2:
Когда на спутник закачиваются новые navdata то может возникнуть короткое окно, когда базовый приемник уже обновился и формирует обновленные Type 1, а ровер всё ещё использует старые navdata (например слишком слабый сигнал, или спутник над горизонтом, или временно прерывался сигнал). Type 2 как раз и есть разница между двумя коррекциями Type 1 если они считаются по разным навигационным данным.
Message Type 2 contains the differences between the pseudorange and range rate corrections from a reference station to all satellites in view between two successive navigation messages. This message is used along with type 1 when the user has not decoded a new satellite ephemeris while the reference station has.
Кстати ровер тоже должен хранить два сета navdata на случай если обновился раньше базы.
В общем слишком сложно для базовой станции и требует хранить два массива navdata как на базе, так и на ровере.
Так что в ситуации realtime через скоростные каналы связи (9600+ bps) лучше использовать Type 19 - raw pseudorange, они обеспечат более качественный результат, не требуют нагрузки на базу, не требуют привязки к бродкастной модели атмосферы и эфемеридам.
-1
-1
Какие ширпотребные приeмники его поддерживают ?
Я думал речь идет о программном решении.
Если нужен именно RTCM 2.0 то RINEX точно не помощник, на базе надо обрабатывать сырые данные напрямую с приемника в реальном времени. Иначе зачем вообще нужен RTCM ))
(added)
Кажется понял о чем речь. Начиналось с того что есть реф.станция в 150км, дающая доступ к RINEX, что можно с этого поиметь. А поиметь можно только постобработку по коду. В реальном времени ничего не получится (если только они не дадут доступ по NTRIP).
Должен выдавать SINGLE решение. Но 3 спутника с ele >15° и cno < 30 dbHz ???
Кстати, тоже не понимаю, почему rtknavi видит 3 всего. Сам приёмник использует аж 16, если я правильно его понимаю.
Где это вообще меряется, покажите фото.
На окне, конечно же. Где ещё, если балкона нет.
Вобщем, что-то получилось. Единственное, прыгает как бешенный, тогда как сам приёмник выдаёт более адекватное решение (видимо, фильтры у него лучше). Интересно, можно ли от rtknavi добиться поведения, схожего с решением самого приёмника?. В идеале, не хуже. (Естественно, при условии одинаковых условий приёма, какие бы они ни были). Иначе, я не могу воспринимать этот софт всерьёз. Возможно где-то надо включить какие-то фильтры?
Если верить графику (частота обновления 5гц), моя скорость составляла до 25 м\с
Ну, для “на окне” результат абсолютно закономерный.
rtknavi имеет настройку elevation mask/SNR mask. Так что используются только “годные” спутники, хотя при таких уровнях это можно сказать о них с большой натяжкой.
Скачет совершенно правильно - учитывая положение антенны и ее саму. Дома можно экспериментировать только для освоения настроек и отладки связки железа.
Фильтры, очевидно, не делают определение координат “лучше”. Они только делают трек менее страшным. Та жуть, которую вы видите - это и есть самая настоящая правда о качестве приема в подобных условиях с подобными антеннами.
Похоже на эффект, который описан в фантастике у Станислава Лема, когда в будущем все находились под влиянием наркотических веществ, а потому не замечали, как ужасна реальность.
-1
rtknavi имеет настройку elevation mask/SNR mask. Так что используются только “годные” спутники, хотя при таких уровнях это можно сказать о них с большой натяжкой.
Выставил всё по нулям - всё равно в rtknavi решение переодически пропадает.
Хотя у самого приёмника никаких проблем, цифры весело скачут всё время, бодро рапортуя Fix mode: 3D, и 3D Acc. ~11m, что не так уж и плохо для single решения с подоконника. Почему rtknavi так не может?
Хм, уже 1001 раз говорили, что мерять надо на открытой местности, а не на подоконнике
А мне интересно потестировать софт и железо в крайних условиях, почему бы нет? И если rtknavi теряет решение гораздо раньше встроенной решалки приёмника, повод задуматься.
-1
-1