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

Я в этом вопросе не очень разобрался. В том девайсе что мне достался, конфиг сохранялся сам собой без всяких батареек - там SPI Flash вроде имеется. Сохранялось вообще все, включая набор сообщений и прочее.

Есть в uCenter такая штука как Receiver->Action->Save config. Попробуйте.

Попробовал, работает.
Это хорошо, что сам не сохраняет. Я уже терял связь с устройством, когда проверял, какую максимальную скорость порт поддерживает :slight_smile: Если б он сохранял конфиг автоматом - не знаю, что бы делал.

Делал бы reset.
Хотя я бы тоже это предпочел, с батарейкой. На Antaris4 - 115200, этого достаточно для 10Hz сырых данных.

У меня по дефолту вообще 9600 стояло. Так что первым делом сменил на 115200. Ещё пробовал 230400, работает отлично. Только почему-то Ozi такую скорость не понимает :slight_smile: Но это уже его личные проблемы, остальной софт ок.
А вот 460800 уже не прокатило.

Так что, возможно с него получить RXM-SFRB, или нет?

Это уж не ко мне :slight_smile:

-1

-1

-1

Фраза достойна сочинения на тему “что хотел сказать автор” :smiley: (и при чём тут вообще windows…)

Разве не вы писали, что ublox 6 уже успешно тестировали с rtklib? Или вместо RXM-SFRB был использован TRK-SFRB?

-1

Ну, по крайней мере, сообщения появились. Теперь осталось понять, что с ними делать :slight_smile:
Подключил rtknavi в режиме чисто ровера (без базы). Решения не выдаёт… Или он так не работает?

Тип 1 использовался в двух случаях:
а) аппаратный приемник понимает только этот тип;
б) канал передачи данных имеет скорость 100-300 bps;

Поясню как формируется Type 1 и 2.

Type 1:

  1. Базовый приемник делает измерение дальностей;
  2. Корректирует измеренные дальности на ионосферные, тропосферные и прочие задержки по информации из broadcast data;
  3. Считает положение спутников по информации из broadcast ephemeris;
  4. Считает разность по каждому спутнику и её дрейф, формирует сообщение 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, они обеспечат более качественный результат, не требуют нагрузки на базу, не требуют привязки к бродкастной модели атмосферы и эфемеридам.

-1

-1

Я думал речь идет о программном решении.

Если нужен именно RTCM 2.0 то RINEX точно не помощник, на базе надо обрабатывать сырые данные напрямую с приемника в реальном времени. Иначе зачем вообще нужен RTCM ))

(added)
Кажется понял о чем речь. Начиналось с того что есть реф.станция в 150км, дающая доступ к RINEX, что можно с этого поиметь. А поиметь можно только постобработку по коду. В реальном времени ничего не получится (если только они не дадут доступ по NTRIP).

Кстати, тоже не понимаю, почему rtknavi видит 3 всего. Сам приёмник использует аж 16, если я правильно его понимаю.

На окне, конечно же. Где ещё, если балкона нет.

Вобщем, что-то получилось. Единственное, прыгает как бешенный, тогда как сам приёмник выдаёт более адекватное решение (видимо, фильтры у него лучше). Интересно, можно ли от rtknavi добиться поведения, схожего с решением самого приёмника?. В идеале, не хуже. (Естественно, при условии одинаковых условий приёма, какие бы они ни были). Иначе, я не могу воспринимать этот софт всерьёз. Возможно где-то надо включить какие-то фильтры?

Если верить графику (частота обновления 5гц), моя скорость составляла до 25 м\с :slight_smile:

Ну, для “на окне” результат абсолютно закономерный.
rtknavi имеет настройку elevation mask/SNR mask. Так что используются только “годные” спутники, хотя при таких уровнях это можно сказать о них с большой натяжкой.
Скачет совершенно правильно - учитывая положение антенны и ее саму. Дома можно экспериментировать только для освоения настроек и отладки связки железа.

Фильтры, очевидно, не делают определение координат “лучше”. Они только делают трек менее страшным. Та жуть, которую вы видите - это и есть самая настоящая правда о качестве приема в подобных условиях с подобными антеннами.
Похоже на эффект, который описан в фантастике у Станислава Лема, когда в будущем все находились под влиянием наркотических веществ, а потому не замечали, как ужасна реальность. :slight_smile:

-1

Выставил всё по нулям - всё равно в rtknavi решение переодически пропадает.

Хотя у самого приёмника никаких проблем, цифры весело скачут всё время, бодро рапортуя Fix mode: 3D, и 3D Acc. ~11m, что не так уж и плохо для single решения с подоконника. Почему rtknavi так не может?

А мне интересно потестировать софт и железо в крайних условиях, почему бы нет? :slight_smile: И если rtknavi теряет решение гораздо раньше встроенной решалки приёмника, повод задуматься.

-1