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

Зачётный баг в RTKLIB :smiley:
на базе этого бага несознательные опубликовали не один десяток публикаций :open_mouth:
типа этой, вот перл оттуда :laughing:
“модель Клобучара , которая в среднем компенсирует 50–60% ионосферной ошибки. Эта модель была предложена к практическому использованию около тридцати лет назад.”

от угла возвышения зависит длина пути в ионосфере и следовательно величина задержки
а вот какой механизм влияния азимута ? :wink:
особенно если спутник то один и тот же в одно и то же время

sat=29 el=16.4 -> ion_old=5.63 ion_sim=3.53 ion_sbas=3.61

Правильно ли я вас понял, что “БАГ” присутствует в стандартном алгоритме модели Клобучара? В том алгоритме, который приведён в ICD-GPS?

уже несколько раз повторил что бага в стандартном алгоритме модели Клобучара нет :slight_smile:

Есть баг в процедуре ionmodel RTKLIB которая compute ionospheric delay by broadcast ionosphere model (klobuchar model)
естественно реализуя стандартный алгоритм модели Клобучара, но неправильно :smiley:

Покажите уже патч его исправляющий, пока ваше поведение на протяжении страницы больше похоже на ёрничество.

очередное ваше весьма информативное сообщение :laughing:
больше не буду здесь появлятся, пользуйтесь RTKLIB с багами :smiley:

Где? Не запостил - не было! А запостил - было!

:roll_eyes: :slight_smile:

Проверили значения из вашей таблицы. Промоделировали ситуацию через стандартную ionmodel. Все значения ion_old являются истинными если по времени был “день”. Значения ion_sim являются истинными если по времени была “ночь”. Получается, что единственное расхождение между ionmodel и ionmodel_sim в вычислении локального времени. Но так как стандартная ionmodel отработала корректно при указании разных временных интервалов, то выводы делайте сами :).

чёзабред вы написали ? :smiley:

ясно же сказано что в одно и тоже время, причем значение ion_sim (по вашему “ночь” ) фактически в точности совпало с транслируемым СДКМ в это время ion_sbas, естественно лог смотрел тот что сделан в полден ибо ночью на дороге в поле не комфортно снимать :roll_eyes:

Удачи в борьбе с багами RTKLIB, у вас весьма извращенная логика, типа как у местного модера :stuck_out_tongue:

Смотрим приведённую вами статью:

Смотрим приведённую вами таблицу:


sat= 8 el= 5.2 -> ion_old=4.52 ion_sim=4.52 ion_sbas=3.56
sat=10 el=10.4 -> ion_old=5.54 ion_sim=4.02 ion_sbas=4.15
sat=27 el=12.8 -> ion_old=3.89 ion_sim=3.81 ion_sbas=3.05 
sat=13 el=15.5 -> ion_old=4.49 ion_sim=3.60 ion_sbas=3.60 
sat=29 el=16.4 -> ion_old=5.63 ion_sim=3.53 ion_sbas=3.61
sat=21 el=18.4 -> ion_old=3.89 ion_sim=3.38 ion_sbas=2.89 
sat=15 el=25.8 -> ion_old=4.06 ion_sim=2.89 ion_sbas=2.85 
sat=26 el=36.1 -> ion_old=3.23 ion_sim=2.36 ion_sbas=2.20 
sat=10 el=36.3 -> ion_old=3.34 ion_sim=2.35 ion_sbas=2.27 
sat=27 el=36.6 -> ion_old=2.80 ion_sim=2.34 ion_sbas=2.12 
sat=21 el=40.4 -> ion_old=2.77 ion_sim=2.18 ion_sbas=1.99 
sat=16 el=47.4 -> ion_old=2.49 ion_sim=1.95 ion_sbas=1.79
sat=26 el=53.2 -> ion_old=2.18 ion_sim=1.81 ion_sbas=1.55 
sat=18 el=63.8 -> ion_old=2.17 ion_sim=1.63 ion_sbas=1.60 
sat=20 el=67.1 -> ion_old=2.18 ion_sim=1.59 ion_sbas=1.55 
sat=18 el=88.5 -> ion_old=1.84 ion_sim=1.50 ion_sbas=1.25

Промоделируем “ночной режим” для спутников с такими же углами места по формуле, как указано в статье, на коленке за две минуты.


double elevs[] = {5.2, 10.4, 12.8, 15.5, 16.4, 18.4, 25.8, 36.1, 36.3, 36.6, 40.4, 47.4, 53.2, 63.8, 67.1, 88.5};
for (auto &el : elevs) {
	double E = el/180.;
	double f = 1.0+16.0*(0.53-E)*(0.53-E)*(0.53-E);
	double I = CLIGHT*f*5e-9;

	cout  << "el=" << el << ", ion_model=" << I << endl;
}

И значения один в один совпадут со значениями ion_sim:


el=5.2,   ion_model=4.51692
el=10.4, ion_model=4.02448
el=12.8, ion_model=3.81653
el=15.5, ion_model=3.59661
el=16.4, ion_model=3.52653
el=18.4, ion_model=3.3764
el=25.8, ion_model=2.88547
el=36.1, ion_model=2.35651
el=36.3, ion_model=2.34786
el=36.6, ion_model=2.335
el=40.4, ion_model=2.18316
el=47.4, ion_model=1.95376
el=53.2, ion_model=1.80801
el=63.8, ion_model=1.62873
el=67.1, ion_model=1.59217
el=88.5, ion_model=1.50031

А теперь объясните где ваш полдень? :slight_smile:

чудная у вас логика :roll_eyes: снимал лог то я днем, в полдень :smiley:
и ion_sim чудно совпал с СДКМ ion_sbas :sunglasses: именно во время дневного съема

там написано
5. Find the local time at the IPP.
смотрим этот пункт в RTKLIB

//	tt=43200.0*lam+time2gpst(t,&week);

смотрим что такое time2gpst, это оказывается time of week (TOW) in gps time (s)
ржем :smiley: ибо вместо требуемых seconds в RTKLIB втулили TOW, патчим


//	tt=43200.0*lam+time2gpst(t,&week);
	tt=43200.0*lam+t.sec;

Серьёзно? Вы добавляете дробную часть секунды? Как я уже писал выше у вас ошибка в вычислении локального времени. Изначально всё было правильно…

дальше некуда :smiley:
именно так реализовано во всех серьезных GNSS в Мире :stuck_out_tongue: жаль, что вы этого не знаете :roll_eyes:

t.time - целая часть секунд, t.sec - дробная часть секунды, т.е 0.1 или 0.5. Вы правда не понимаете?

я уже все сказал и высказал сожаление что именно вы не понимаете :smiley:

каждый может теперь пропатчить свой RTKLIB и с радостью обнаружить что пятно от броадкаст ионо_поправки на том же месте что и
СДКМ ионо_поправки :smiley: а не в стороне на несколько метров как раньше :stuck_out_tongue:
Оглашение одного из многих багов RTKLIB закончено :slight_smile: вы проиграли …

Поскольку баг в ionmodel пофиксен добавим
в Ionosphere Correction дополнительно пункт SBAS or Broadcast в меню



	/* sbas-or-brdc ionospheric model option */
	
	if (ionoopt == IONOOPT_SBAS_OR_BRDC) {
		if ( !sbsioncorr(time, nav, pos, azel, ion, var) ) {
			*ion = ionmodel(time, nav->ion_gps, pos, azel);
			*var = SQR(*ion );
		}
		return 1;
	}



Выбор “SBAS or Broadcast” позволяет сравнивать различные SBAS системы, EGNOS GAGAN SDCM
Устанавливаем :

Ionosphere Correction → “SBAS or Broadcast”
Troposphere Correction → “SBAS”
Satelite Ephemeris/Clock → “Broadcast”

перебираем PRN спутников EGNOS GAGAN SDCM в SBAS Sat Selection
и не обнаруживаем ни малейших различий, т.е. SBAS локальные особенности
в Ionosphere Correction и Troposphere Correction не передает.

Устанавливаем:

Satelite Ephemeris/Clock → “Broadcast+SBAS”

перебираем PRN спутников EGNOS GAGAN SDCM в SBAS Sat Selection и только в этом случае наблюдаем различия

**SDCM vs EGNOS **
Хотя точка съема лога находится где EGNOS уже ничего не гарантирует получаем почти тоже что и от SDCM, т.е. суперточности SDCM по отношению к EGNOS не видать

**SDCM vs GAGAN **
Здесь преимущество SDCM перед индийским GAGAN налицо, осталось только понять чем вызван загадочный наклонный разброс от GAGAN. То ли особым TEC над Индией то ли чем то иным.


2002_ivan, блин. Честно, был уверен, что вы всё поняли, но просто прикалываетесь… После вашего “патча” который исправляет “баг”, у одних пользователей будет согласно модели Клобучара вечная ночь, у других вечный день. Изначальная реализация в RTKLIB полностью правильная и ничего в ней править не нужно. Проверьте себя сами, возьмите свою функцию ionmodel_sim, заморозьте местоположение спутников и изменяйте только время. Вы, наверное, удивитесь, когда увидите, что значение ионосферы у вас не изменится :).

Тропосферные задержки пользователи SBAS рассчитывают по модели, модель может использоваться любая, есть лишь требование к точности модели. А вот ионосферные задержки передаются с шагом в 5 градусов и по сути являются локальными значениями.

Посмотрите какую область покрывает ионосферная сетка GAGAN - https://sbas.ru/контроль-ионосфера/?uid=127. В ваших расчётах она ну ни как использоваться не может :).

:roll_eyes: :roll_eyes: столько раз уже повторил, Ok ! повторяю еще раз.
**На всех **логах снятых в различное время где принимается ваша SDCM неизменно наблюдаю типичную картину


1 sat= 5 azel= 38.5  4.2 ion_old=6.19 ion_sim=4.62 1  ion_sbas=3.54
1 sat=10 azel=194.3 23.6 ion_old=4.73 ion_sim=3.02 1  ion_sbas=3.30
1 sat=13 azel= 61.0 14.5 ion_old=5.75 ion_sim=3.68 1  ion_sbas=3.23
1 sat=15 azel= 97.9 20.9 ion_old=5.41 ion_sim=3.20 1  ion_sbas=3.09
1 sat=16 azel=280.0 49.6 ion_old=2.62 ion_sim=1.89 1  ion_sbas=1.89
1 sat=20 azel=183.8 49.5 ion_old=2.89 ion_sim=1.90 1  ion_sbas=1.96
1 sat=21 azel= 19.0 85.2 ion_old=2.20 ion_sim=1.50 1  ion_sbas=1.46
1 sat=26 azel=235.4 46.3 ion_old=2.86 ion_sim=1.99 1  ion_sbas=2.02
1 sat=27 azel=301.2 25.2 ion_old=3.63 ion_sim=2.92 1  ion_sbas=2.79
1 sat=29 azel=118.5 29.3 ion_old=4.45 ion_sim=2.69 1  ion_sbas=2.66


1 sat=16 azel=220.6 10.7 ion_old=7.36 ion_sim=4.00 1  ion_sbas=4.62
1 sat=18 azel=100.7 13.4 ion_old=6.73 ion_sim=3.76 1  ion_sbas=3.71
1 sat=20 azel= 64.7 42.2 ion_old=3.53 ion_sim=2.12 1  ion_sbas=1.92
1 sat=21 azel= 87.0 79.9 ion_old=2.56 ion_sim=1.51 1  ion_sbas=1.47
1 sat=24 azel= 69.2  5.7 ion_old=7.19 ion_sim=4.47 1  ion_sbas=3.69
1 sat=27 azel=215.3 64.7 ion_old=2.77 ion_sim=1.62 1  ion_sbas=1.67
1 sat=32 azel=158.9 30.4 ion_old=4.80 ion_sim=2.63 1  ion_sbas=2.78
1 sat= 8 azel=288.8 53.7 ion_old=2.95 ion_sim=1.80 1  ion_sbas=1.79
1 sat=10 azel= 73.5 78.3 ion_old=2.56 ion_sim=1.52 1  ion_sbas=1.47
1 sat=11 azel=298.7 26.8 ion_old=4.32 ion_sim=2.83 1  ion_sbas=2.70
1 sat=15 azel= 33.5  5.1 ion_old=6.10 ion_sim=4.53 1  ion_sbas=3.53
1 sat=16 azel=220.6 10.7 ion_old=7.36 ion_sim=4.00 1  ion_sbas=4.62

**ion_sim и ion_sbas во всех логах чудно совпадают, тогда как ion_old врет **как троцкий :laughing:
вы же утверждаете обратное, что ion_sim и ion_sbas во всех логах врут а истина в ion_old :sunglasses:

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

замороженные спутники это очень круто, фантастика :open_mouth:

от времени и не должна задержка вызванная ионосферой изменяться :smiley: в


//	tt=43200.0*lam+time2gpst(t,&week);
	tt=43200.0*lam+t.sec;

t.sec величина третьего порядка малости по сравнению с 43200.0*lam, по этой причине можно RTKLIB патчить дальше


//	tt=43200.0*lam+time2gpst(t,&week);
//	tt=43200.0*lam+t.sec;
	tt=43200.0*lam;

величина задержки при этом не изменится ни на миллиметр а зависимость от времени исчезает вообще,
ибо ионосфера изменяется ТОЛЬКО тогда когда приходят в subframe 4, page 18 новые значения
в IS-GPS упоминается receiver computed system time, которое в данном случае полагаем что вычислили НОЛЬ :roll_eyes:

Это статья для врагов народа ? :frowning:
Писатели этого алгоритма понятия не имеют о чём они пишут.
ICB зависит от групповых задержек приёмника и антенны.
Групповые задержеки приёмника в первом приближении можно отобразить в виде таблички,
а вот групповых задержки антенны зависят от многих факторов и могут быть представлены как МИНИМУМ только 3D поверхностью,
вместо нахождения этих 3D поверхностей авторы статьи первым делом предлагают все пригладить,
т.е. задача не решается вообще :smiley:

Извините за беспокойство.

Пресловутый 301 … cmd, нигде не нашел.

Это просто слух или он существует ??

(Переведено гуглом, извините если не хороший русский язык)