Я в этом вопросе не очень разобрался. В том девайсе что мне достался, конфиг сохранялся сам собой без всяких батареек - там SPI Flash вроде имеется. Сохранялось вообще все, включая набор сообщений и прочее.
Есть в uCenter такая штука как Receiver->Action->Save config. Попробуйте.
Попробовал, работает.
Это хорошо, что сам не сохраняет. Я уже терял связь с устройством, когда проверял, какую максимальную скорость порт поддерживает Если б он сохранял конфиг автоматом - не знаю, что бы делал.
У меня по дефолту вообще 9600 стояло. Так что первым делом сменил на 115200. Ещё пробовал 230400, работает отлично. Только почему-то Ozi такую скорость не понимает Но это уже его личные проблемы, остальной софт ок.
А вот 460800 уже не прокатило.
Так что, возможно с него получить RXM-SFRB, или нет?
Ну, по крайней мере, сообщения появились. Теперь осталось понять, что с ними делать
Подключил 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 если они считаются по разным навигационным данным.
Кстати ровер тоже должен хранить два сета navdata на случай если обновился раньше базы.
В общем слишком сложно для базовой станции и требует хранить два массива navdata как на базе, так и на ровере.
Так что в ситуации realtime через скоростные каналы связи (9600+ bps) лучше использовать Type 19 - raw pseudorange, они обеспечат более качественный результат, не требуют нагрузки на базу, не требуют привязки к бродкастной модели атмосферы и эфемеридам.
Если нужен именно RTCM 2.0 то RINEX точно не помощник, на базе надо обрабатывать сырые данные напрямую с приемника в реальном времени. Иначе зачем вообще нужен RTCM ))
(added)
Кажется понял о чем речь. Начиналось с того что есть реф.станция в 150км, дающая доступ к RINEX, что можно с этого поиметь. А поиметь можно только постобработку по коду. В реальном времени ничего не получится (если только они не дадут доступ по NTRIP).
Кстати, тоже не понимаю, почему rtknavi видит 3 всего. Сам приёмник использует аж 16, если я правильно его понимаю.
На окне, конечно же. Где ещё, если балкона нет.
Вобщем, что-то получилось. Единственное, прыгает как бешенный, тогда как сам приёмник выдаёт более адекватное решение (видимо, фильтры у него лучше). Интересно, можно ли от rtknavi добиться поведения, схожего с решением самого приёмника?. В идеале, не хуже. (Естественно, при условии одинаковых условий приёма, какие бы они ни были). Иначе, я не могу воспринимать этот софт всерьёз. Возможно где-то надо включить какие-то фильтры?
Если верить графику (частота обновления 5гц), моя скорость составляла до 25 м\с
Ну, для “на окне” результат абсолютно закономерный.
rtknavi имеет настройку elevation mask/SNR mask. Так что используются только “годные” спутники, хотя при таких уровнях это можно сказать о них с большой натяжкой.
Скачет совершенно правильно - учитывая положение антенны и ее саму. Дома можно экспериментировать только для освоения настроек и отладки связки железа.
Фильтры, очевидно, не делают определение координат “лучше”. Они только делают трек менее страшным. Та жуть, которую вы видите - это и есть самая настоящая правда о качестве приема в подобных условиях с подобными антеннами.
Похоже на эффект, который описан в фантастике у Станислава Лема, когда в будущем все находились под влиянием наркотических веществ, а потому не замечали, как ужасна реальность.
Выставил всё по нулям - всё равно в rtknavi решение переодически пропадает.
Хотя у самого приёмника никаких проблем, цифры весело скачут всё время, бодро рапортуя Fix mode: 3D, и 3D Acc. ~11m, что не так уж и плохо для single решения с подоконника. Почему rtknavi так не может?
А мне интересно потестировать софт и железо в крайних условиях, почему бы нет? И если rtknavi теряет решение гораздо раньше встроенной решалки приёмника, повод задуматься.