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

https://cnx-software.ru/2020/07/19/sparkfun-запускает-модуль-zed-f9r-gps-с-raspberry-pi-phat-для-точного-расчета-траектории-в-робототехнике/

На сколько я понял (хотя могу и ошибаться), периодически читая статьи про ГНСС - Австралия пошла по простому пути, программное обеспечение для расчёта SBAS поправок было приобретено у испанской фирмы GMV (скорее всего без исходников), своих разработок там нет. Вроде и EGNOS в начале использовал софт от GMV, а может и сейчас использует. В общем не стоит приводить Австралию в качестве авторитета. А вот ребята из тихоокеанского региона молодцы, всё сделали сами, хотя и жалуются в статьях, что у них есть ряд нерешенных проблем, а Европейцы и Американцы редиски такие т.к. не делятся своими наработками :slight_smile:

Он на прошлой неделе чего-то посылал, а потом выключился. Увидите снова, записывайте лог сообщений.

ROM у F9P и F9H одинаковый (CRC совпадают),
а вот при “простом” изменении байтов/битов приемник перезапускается,
так как у M9/F9 этот блок не 128, а 512 байт.
Вообще с остальными байтами/битами надо быть осторожным, чтобы с частотами не намудрить.

Сегодня удачный день ! :smiley:
С утра лежал сайт СДКМ где красивые картинки
непонятно как они их получают :expressionless:
Ибо без СДКМ у меня не хуже чем у них, даже лучше, а вот если включить SBAS в RTKLIB
то эффект не такой впечатляющий как на их картинках с включенным СДКМ :frowning:
Надо дорабатывать SBAS в RTKLIB, поскольку там

unsupported sbas message: type=27 Служебное сообщение СДКМ
unsupported sbas message: type=10 Параметры деградации (быстрых и долгосрочных поправок, задержек в ионосфере)
unsupported sbas message: type=12 Параметры сдвига “сетевое время СДКМ/UTC”
unsupported sbas message: type=17 Альманах спутников СДКМ

unsupported sbas message: type=27 SBAS Service message
unsupported sbas message: type=10 Degradation parameters
unsupported sbas message: type=12 SBAS Network time / UTC offset parameters
unsupported sbas message: type=17 Geo satellite almanacs

Режим SBAS в RTKLIB для GLONASS не реализован вообще впрочем как и в приемнике M8T

Поскольку сайт sbas.ru полег а на спутнике PRN 140 опять начал глючить опорный генератор и он то падает то подымается
посему включили PRN 125 :slight_smile:
Заснял два лога каждый по 1 часу:
PRN125+GPS+GLONASS
PRN125+PRN140+GPS+GLONASS

первый поверхностный анализ показал что с обоих СДКМ спутников идет фактически идентичная инфа :roll_eyes:

А СДКМ информацию для GPS спутников даёт?

естественно дает :smiley:
выше уже давал ссылку на sbas.ru
вот как там выглядит GPS + СДКМ

но у меня такой красоты GPS + СДКМ в RTKLIB получить не удалось :expressionless:
зато есть к чему стремиться :slight_smile:

EGNOS SDK Core в сырцах без малейших проблем
имея это уже можно копипастом править азиатскую RTKLIB :smiley:

если бы такое да для GLONASS + СДКМ :confused:

это лог PRN125+PRN140+GPS+GLONASS
снятый на антенну которую я сделал и настроил сам и M8T за десять баксов
в u-center ничем не хуже картинок на sbas.ru :smiley:
на sbas.ru снимали на много килобаксову антенну+приемник :wink:

отсутствуют Параметры деградации
Мдя.
Насколько далеко на восток имеются не-NODATA
значения ионосферных поправок ?
Я рисовал такую картинку для EGNOS в вики много лет назад.

Перепрошитый F9H отдыхает на полке до лучших времен,
так как успешно поправить биты PF пока не удалось:
$GNTXT,01,01,02,PF=FDBFF38
$GNTXT,01,01,02,PF=FFF79
30

я даже сейчас не могу использовать EGNOS :expressionless:
вот лог EGNOS PRN136
RTKLIB не может проглотить ionosphere correction от EGNOS :smiley:

собственно меня интересует применение SBAS применительно к ГЛОНАСС
где есть cIFB

которое даже в приемниках с закосом на крутость выглядит типично вот так

но, как видим, в СДКМ cIFB таинственным образом побеждают :smiley:
u-blox победить СДКМ + ГЛОНАСС не смог :stuck_out_tongue:

SBAS L1 maximum Doppler value [Hz], see SDCM ICD section 5.2.7
http://www.sdcm.ru/smglo/ICD_SDCM_1dot0_Eng.pdf

#define SBAS_L1_DOPPLER_MAX_HZ (+210.f)

(удалил, из пустого в порожнее)

Удивительно. Честно говоря, даже не вериться. Но если всё так, то очень круто.

На сайте sbas.ru используется обычный RTKLIB. Единственное файл sbas.c приведён в соответствие с ИКД СДКМ/DO-229, а сглаживание кодовых измерений фазовыми и автокалибровка ICB/cIFB реализована согласно статье - http://russianspacesystems.ru/wp-content/uploads/2019/10/1_p3_0603.pdf. Никакой магии :slight_smile:

https://sbas.ru/контроль-ионосфера/?uid=2

Буду очень Вам благодарен если Вы сбросите этот файл с модификацией под СДКМ мне на e-mail :slight_smile:
Именно sbas.c с той же целью я сейчас ковыряю.

К сожалению, выслать ничего не могу. Могу объяснить, по мере возможности, что и где в RTKLIB дописать/подправить для соответствия ИКД СДКМ/DO-229.

Спасибо, извиняюсь за задержку с ответом :slight_smile:
Пытался сам выяснить что к чему и где основные глюки.
Самый главный глюк в 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 не реализован.

Что необходимо использовать вместо 252, -1 или ?

Посмотрите страницу 41 в ИКД СДКМ, там приведён алгоритм. 252 это два под-поля (время действия и время запаздывания). Также для работы с поправками SBAS вам необходимо хранить текущие и предыдущие эфемериды для каждого НКА. При передачи спутниками новых эфемерид, системы SBAS продолжают использовать старые эфемериды для определения долгосрочных и быстрых поправок от 2 до 4 мин.

да смотрел я её много раз, алгоритма не увидел :roll_eyes:
Со спутников все время идет неизменно 252, т.е. два под-поля,
“время действия” ВСЕГДА максимально 960c и “время запаздывания” ВСЕГДА 0.
Специально посмотрел логи длиной более 3-х часов.

Как использовать константу 252 непонятно, вернее понятно что если отлична от нуля то идут данные и больше ничего :confused:


static int useglosbas(const int sat, const int iode, const sbssat_t *sbs, const geph_t* eph) {
   const sbssatp_t *p=NULL;
   for (p=sbs->sat; p<sbs->sat+sbs->nsat; p++) {
      if (p->sat!=sat || p->lcorr.t0.time==0) 
         continue;
      const int L=30*(iode&0x7);
      const int V=60*(iode>>3);
      return (p->lcorr.t0.time-L-V<=eph->tof.time && eph->tof.time<=p->lcorr.t0.time-L);
   } 
   return 0;
}

static geph_t *selgeph(gtime_t time, int sat, int iode, const nav_t *nav) {
...
   if (iode>=0 && !useglosbas(sat, iode, &nav->sbssat, &nav->geph[i])) 
       continue;
...
}