Посмотрел при помощи M8N который магией превращен в M8Т СДКМ PRN 140 который над Азией
от меня он виден хотя и висит над горизонтом на 10 градусов,
PRN 125 должен был виден с углом ~20 градусов но был затенен зданиями
Исходя из приведенной выше карты покрытия Лучей мне без особой разницы на какой цеплятся,
хотя там сказано что PRN 140 Азия, Средняя Азия, Китай, Индия а PRN 125 Европа, Северная Африка, Ближний Восток
Все на M8Т с 3-м FW чудесно работает
Дивный “доплеровский сдвиг” Лучей пофиксили, теперь он как у всех
Сообщения шлет не пустые, заполнены инфой. что чисто GPS что чисто GLONASS
при включенной SBAS радостно сообщают что есть DGNSS
Осталось выехать во чисто поле и проверить есть ли толк от этого DGNSS
как на PRN 140 так и PRN 125
Ведь австралийцы не просто так делают отдельный приемник SBAS.
На сколько я понял (хотя могу и ошибаться), периодически читая статьи про ГНСС - Австралия пошла по простому пути, программное обеспечение для расчёта SBAS поправок было приобретено у испанской фирмы GMV (скорее всего без исходников), своих разработок там нет. Вроде и EGNOS в начале использовал софт от GMV, а может и сейчас использует. В общем не стоит приводить Австралию в качестве авторитета. А вот ребята из тихоокеанского региона молодцы, всё сделали сами, хотя и жалуются в статьях, что у них есть ряд нерешенных проблем, а Европейцы и Американцы редиски такие т.к. не делятся своими наработками
ROM у F9P и F9H одинаковый (CRC совпадают),
а вот при “простом” изменении байтов/битов приемник перезапускается,
так как у M9/F9 этот блок не 128, а 512 байт.
Вообще с остальными байтами/битами надо быть осторожным, чтобы с частотами не намудрить.
Сегодня удачный день !
С утра лежал сайт СДКМ где красивые картинки
непонятно как они их получают
Ибо без СДКМ у меня не хуже чем у них, даже лучше, а вот если включить SBAS в RTKLIB
то эффект не такой впечатляющий как на их картинках с включенным СДКМ Надо дорабатывать SBAS в RTKLIB, поскольку там
unsupported sbas message: type=27 Служебное сообщение СДКМ
unsupported sbas message: type=10 Параметры деградации (быстрых и долгосрочных поправок, задержек в ионосфере)
unsupported sbas message: type=12 Параметры сдвига “сетевое время СДКМ/UTC”
unsupported sbas message: type=17 Альманах спутников СДКМ
Режим SBAS в RTKLIB для GLONASS не реализован вообще впрочем как и в приемнике M8T
Поскольку сайт sbas.ru полег а на спутнике PRN 140 опять начал глючить опорный генератор и он то падает то подымается посему включили PRN 125
Заснял два лога каждый по 1 часу: PRN125+GPS+GLONASS PRN125+PRN140+GPS+GLONASS
первый поверхностный анализ показал что с обоих СДКМ спутников идет фактически идентичная инфа
это лог PRN125+PRN140+GPS+GLONASS
снятый на антенну которую я сделал и настроил сам и M8T за десять баксов
в u-center ничем не хуже картинок на sbas.ru
на sbas.ru снимали на много килобаксову антенну+приемник
отсутствуют Параметры деградации
Мдя.
Насколько далеко на восток имеются не-NODATA
значения ионосферных поправок ?
Я рисовал такую картинку для EGNOS в вики много лет назад.
Перепрошитый F9H отдыхает на полке до лучших времен,
так как успешно поправить биты PF пока не удалось:
$GNTXT,01,01,02,PF=FDBFF38
$GNTXT,01,01,02,PF=FFF7930
Спасибо, извиняюсь за задержку с ответом
Пытался сам выяснить что к чему и где основные глюки.
Самый главный глюк в 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 мин.