Спасибо, извиняюсь за задержку с ответом
Пытался сам выяснить что к чему и где основные глюки.
Самый главный глюк в RTKLIB это использование sbs->lcorr.iode в satpos_sbas,
для GPS это правильно.
Однако IODE от SDCM для GLONASS всегда бывает или 0 (типа не получили) или 252 :
1 satpos_sbas : time=2020/07/29 08:01:09.725 sat=35 iode= 0
1 satpos_sbas : time=2020/07/29 08:01:09.728 sat=36 iode= 0
1 satpos_sbas : time=2020/07/29 08:01:09.721 sat=37 iode=252
1 satpos_sbas : time=2020/07/29 08:01:09.727 sat=41 iode=252
1 satpos_sbas : time=2020/07/29 08:01:09.732 sat=42 iode=252
1 satpos_sbas : time=2020/07/29 08:01:09.726 sat=43 iode=252
1 satpos_sbas : time=2020/07/29 08:01:09.730 sat=51 iode=252
1 satpos_sbas : time=2020/07/29 08:01:09.735 sat=52 iode=252
1 satpos_sbas : time=2020/07/29 08:01:09.722 sat=53 iode=252
1 satpos_sbas : time=2020/07/29 08:01:09.925 sat=35 iode=252
1 satpos_sbas : time=2020/07/29 08:01:09.928 sat=36 iode=252
естественно от 0 или 252
if (!ephpos(time,teph,sat,nav,sbs->lcorr.iode,rs,dts,var,svh)) return 0;
всегда заканчивает return 0 т.е. режим SBAS для GLONASS не реализован.
Посмотрите страницу 41 в ИКД СДКМ, там приведён алгоритм. 252 это два под-поля (время действия и время запаздывания). Также для работы с поправками SBAS вам необходимо хранить текущие и предыдущие эфемериды для каждого НКА. При передачи спутниками новых эфемерид, системы SBAS продолжают использовать старые эфемериды для определения долгосрочных и быстрых поправок от 2 до 4 мин.
да смотрел я её много раз, алгоритма не увидел
Со спутников все время идет неизменно 252, т.е. два под-поля,
“время действия” ВСЕГДА максимально 960c и “время запаздывания” ВСЕГДА 0.
Специально посмотрел логи длиной более 3-х часов.
Как использовать константу 252 непонятно, вернее понятно что если отлична от нуля то идут данные и больше ничего
Ошибаетесь, вечного continue не будет :). continue будет если iode больше нуля (т.е. для данного спутника есть поправки к эфемеридам) и useglosbas вернёт 0 (т.е. не найдены эфемериды, к которым можно применить поправки).
if (iode>=0 && nav->geph[i].iode != iode) continue;
то вечное continue гарантировано
если убрать в общем то лишённую смысла эту строчку (непонятно зачем её вообще вставили)
то вечного continue нет и useglosbas работает
За что отдельное спасибо !
самому интересно какая в итоге будет точность
пока ничего особо интересного, по GLONASS поиски очередных глюков RTKLIB,
ибо SDCM c GLONASS у меня фактически не работает
вернее работает если закомментировать (убрать) в sbas.c
Да, кодовые измерения были сглажены фазовыми (т.е. уменьшен шум кодовых измерений и эффект многопутности). В результате мы видим более-менее реальную точность СДКМ. А так из-за кодовых шумов был бы круг с радиусом 1-1.5м.
В идеальных условиях выглядит красиво :), но на практике шумы в несколько раз выше.
Тут надо разбираться. В том файле, что вы предоставили, некоторые измерения псевдодальностей ГЛОНАСС явно были аномальными. Есть предположение, что этот приёмник некорректно работает с ГЛОНАСС + непонятно, что там с фазовым центром антенны. Во всяком случае, это смещение никак не связано с поправками СДКМ. На тех приёмниках, что есть в моём распоряжении, точность ГЛОНАСС+СДКМ ничем не хуже точности GPS+СДКМ.
Скорее всего это просто некорректная работа вашего приёмника и солнечный ветер тут не причём.
Про фазовый центр антенны имеет смысл говорить когда зайдет речь о невязках меньше 0.2 метра
Поскольку используется широкополосная полногабаритная антенна то в отличие от керамических (укороченных) этот параметр у антенны лучше не бывает
Похоже, смещение в 20 метров возникает из-за сильного разброса ICB, а не из-за солнечного ветра. Но центр ГЛОНАСС и GPS сильно смещен. Почему так непонятно, может все дело в антенне.