занятная у вас логика
если ion_sim (ionmodel_sim) фактически совпадает с ion_sbas а ion_old (ionmodel) врет типа el=16.4 → ion_old=5.63 тихий ужас и т.д.
то баг именно в ionmodel_sim
Почему сразу врёт и тихий ужас? Такие значения вполне имеют место быть. У вас же кроме угла возвышения есть ещё и азимут…Как вариант, точка прокола ионосферы для данного спутника оказалась в области более возмущённой ионосферы.
Зачётный баг в RTKLIB
на базе этого бага несознательные опубликовали не один десяток публикаций типа этой, вот перл оттуда
“модель Клобучара , которая в среднем компенсирует 50–60% ионосферной ошибки. Эта модель была предложена к практическому использованию около тридцати лет назад.”
от угла возвышения зависит длина пути в ионосфере и следовательно величина задержки
а вот какой механизм влияния азимута ?
особенно если спутник то один и тот же в одно и то же время
Есть баг в процедуре ionmodel RTKLIB которая compute ionospheric delay by broadcast ionosphere model (klobuchar model)
естественно реализуя стандартный алгоритм модели Клобучара, но неправильно
Проверили значения из вашей таблицы. Промоделировали ситуацию через стандартную ionmodel. Все значения ion_old являются истинными если по времени был “день”. Значения ion_sim являются истинными если по времени была “ночь”. Получается, что единственное расхождение между ionmodel и ionmodel_sim в вычислении локального времени. Но так как стандартная ionmodel отработала корректно при указании разных временных интервалов, то выводы делайте сами :).
ясно же сказано что в одно и тоже время, причем значение ion_sim (по вашему “ночь” ) фактически в точности совпало с транслируемым СДКМ в это время ion_sbas, естественно лог смотрел тот что сделан в полден ибо ночью на дороге в поле не комфортно снимать
Удачи в борьбе с багами RTKLIB, у вас весьма извращенная логика, типа как у местного модера
я уже все сказал и высказал сожаление что именно вы не понимаете
каждый может теперь пропатчить свой RTKLIB и с радостью обнаружить что пятно от броадкаст ионо_поправки на том же месте что и
СДКМ ионо_поправки а не в стороне на несколько метров как раньше Оглашение одного из многих багов RTKLIB закончено вы проиграли …
перебираем 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 над Индией то ли чем то иным.