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

Ничего не понятно :). Что за баг? Что означает “выверенную в GPS симуляторе klobuchar model”?

ionmodel имеет баг в реализации klobuchar model который расписан весьма детально :smiley:
Алгоритм есть так что сами ищите где именно баг в ionmodel :sunglasses:

В GPS симуляторе реализация klobuchar model проверяется вессьма просто :slight_smile:
Два неподвижных приемника u-blox принимают в одно и то же время один реальные спутники а второй
сигнал от симулятора который иммитирует эти спутники в реальном масштабе времени.

Посмотрел, бага не нашёл, может плохо искал :slight_smile:

Понятнее не стало. Как вычисляется ion_sim? Каким-то образом вычисляете разницу между сигналом от симулятора и реальным измерением?

баг там знатный :smiley: с первого и даже пятого взгляда кажется что все OK !
поэтому** все и пользуются с багом**


extern int ionocorr(gtime_t time, const nav_t *nav, int sat, const double *pos,
					const double *azel, int ionoopt, double *ion, double *var)
{
.....
	/* broadcast model */
//	if (ionoopt==IONOOPT_BRDC)
	{
		double ion2 ;
		ion2 = ionmodel_sim( time,nav->ion_gps,pos,azel);
		*ion=ionmodel(time,nav->ion_gps,pos,azel);
		trace(2," ion_old=%2.2f ion_sim=%2.2f ",*ion, ion2 );
		*ion = ion2;
		*var=SQR(*ion);
//		return 1;
	}
	/* sbas ionosphere model */
	if (ionoopt==IONOOPT_SBAS)
	{
		sbsioncorr(time,nav,pos,azel,ion,var);
		trace(2," ion_sbas=%2.2f \n",*ion);
		return  1;
	}

.....
}

ionmodel_sim и ionmodel реализуют один и тот же алгоритм klobuchar model
только в ionmodel_sim нет бага :slight_smile:

вот в реализации тропосферной задержки нет багов


SDCM

2 sat=25 azel= 2.9 -> 2  trp_saas=47.16 2  trp_sbas=36.04 
2 sat= 8 azel= 5.2 -> 2  trp_saas=26.44 2  trp_sbas=24.18
2 sat=13 azel= 7.5 -> 2  trp_saas=18.33 2  trp_sbas=17.69
2 sat=10 azel= 8.0 -> 2  trp_saas=17.10 2  trp_sbas=16.62
2 sat=27 azel=10.7 -> 2  trp_saas=12.78 2  trp_sbas=12.69
2 sat=15 azel=11.8 -> 2  trp_saas=11.66 2  trp_sbas=11.63
2 sat=13 azel=15.5 -> 2  trp_saas= 8.95 2  trp_sbas= 9.01
2 sat= 5 azel=15.0 -> 2  trp_saas= 9.23 2  trp_sbas= 9.28
2 sat=21 azel=16.2 -> 2  trp_saas= 8.54 2  trp_sbas= 8.61
2 sat=29 azel=16.4 -> 2  trp_saas= 8.48 2  trp_sbas= 8.55
2 sat=15 azel=25.8 -> 2  trp_saas= 5.48 2  trp_sbas= 5.57
2 sat=16 azel=35.0 -> 2  trp_saas= 4.16 2  trp_sbas= 4.23
2 sat=26 azel=36.1 -> 2  trp_saas= 4.05 2  trp_sbas= 4.13
2 sat=10 azel=36.3 -> 2  trp_saas= 4.03 2  trp_sbas= 4.10
2 sat=27 azel=36.6 -> 2  trp_saas= 4.01 2  trp_sbas= 4.08
2 sat=20 azel=38.0 -> 2  trp_saas= 3.87 2  trp_sbas= 3.94
2 sat=21 azel=40.4 -> 2  trp_saas= 3.68 2  trp_sbas= 3.75
2 sat=29 azel=42.0 -> 2  trp_saas= 3.56 2  trp_sbas= 3.63
2 sat=16 azel=47.4 -> 2  trp_saas= 3.24 2  trp_sbas= 3.30
2 sat=26 azel=53.9 -> 2  trp_saas= 2.95 2  trp_sbas= 3.00
2 sat=18 azel=63.8 -> 2  trp_saas= 2.66 2  trp_sbas= 2.71
2 sat=20 azel=67.1 -> 2  trp_saas= 2.59 2  trp_sbas= 2.64
2 sat=18 azel=86.7 -> 2  trp_saas= 2.39 2  trp_sbas= 2.43


наглядно видать что тропосферная задержка больше чем ионосферная.

Ещё раз проверил ionmodel, ошибок нет, всё правильно реализовано. Сдаётся мне, что баг всё-таки в ionmodel_sim :slight_smile:

Уже ж сказал что** баг там знатный** :smiley:
Причем видать его любому если смотреть в эту табличку


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

занятная у вас логика :laughing:
если ion_sim (ionmodel_sim) фактически совпадает с ion_sbas а ion_old (ionmodel) врет типа el=16.4 → ion_old=5.63 тихий ужас :open_mouth: и т.д.
то баг именно в ionmodel_sim :sunglasses:

Невидимый :).

Почему сразу врёт и тихий ужас? Такие значения вполне имеют место быть. У вас же кроме угла возвышения есть ещё и азимут…Как вариант, точка прокола ионосферы для данного спутника оказалась в области более возмущённой ионосферы.

Зачётный баг в 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. Вы правда не понимаете?