Зачётный баг в 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 над Индией то ли чем то иным.
2002_ivan, блин. Честно, был уверен, что вы всё поняли, но просто прикалываетесь… После вашего “патча” который исправляет “баг”, у одних пользователей будет согласно модели Клобучара вечная ночь, у других вечный день. Изначальная реализация в RTKLIB полностью правильная и ничего в ней править не нужно. Проверьте себя сами, возьмите свою функцию ionmodel_sim, заморозьте местоположение спутников и изменяйте только время. Вы, наверное, удивитесь, когда увидите, что значение ионосферы у вас не изменится :).
Тропосферные задержки пользователи SBAS рассчитывают по модели, модель может использоваться любая, есть лишь требование к точности модели. А вот ионосферные задержки передаются с шагом в 5 градусов и по сути являются локальными значениями.
столько раз уже повторил, Ok ! повторяю еще раз.
**На всех **логах снятых в различное время где принимается ваша SDCM неизменно наблюдаю типичную картину
**ion_sim и ion_sbas во всех логах чудно совпадают, тогда как ion_old врет **как троцкий
вы же утверждаете обратное, что ion_sim и ion_sbas во всех логах врут а истина в ion_old
Здесь как раз тот момент когда каждый в меру своей логики выбирает то что ему ближе, я выбрал ion_sim
ибо две случайные независимые величины (ion_sim и ion_sbas) чудно совпадают на случайных выборках (логах).
замороженные спутники это очень круто, фантастика
от времени и не должна задержка вызванная ионосферой изменяться в
величина задержки при этом не изменится ни на миллиметр а зависимость от времени исчезает вообще,
ибо ионосфера изменяется ТОЛЬКО тогда когда приходят в subframe 4, page 18 новые значения
в IS-GPS упоминается receiver computed system time, которое в данном случае полагаем что вычислили НОЛЬ
Это статья для врагов народа ?
Писатели этого алгоритма понятия не имеют о чём они пишут.
ICB зависит от групповых задержек приёмника и антенны.
Групповые задержеки приёмника в первом приближении можно отобразить в виде таблички,
а вот групповых задержки антенны зависят от многих факторов и могут быть представлены как МИНИМУМ только 3D поверхностью,
вместо нахождения этих 3D поверхностей авторы статьи первым делом предлагают все пригладить,
т.е. задача не решается вообще