10.06.2019 Отладка трансивера - лето 2019

Текущая версия на 19:16, 24 июля 2019

[править] Рекомендации по записи экспериментов

Результаты испытаний нужно записывать, чтобы сравнивать текущий результат с тем, что было когда-то и не повторять одинаковые эксперименты.

Желательно записывать следующие данные:

• дату испытания (в заголовке);
• номер ревизии PL;
• номер ревизии PS;
• экземпляр приемника;
• условия;
• цель;
• ожидаемые результаты;
• фактические результаты;
• выводы.

[править] 2019.06.10 - Отрабатываем на модели особые события в шкале времени

• хэш коммита 02b9d3c7650d84c5e9a9d9d102d348a924c0bc2d
• результаты получены на модели

[править] Переход псевдодальности через ноль из плюса в минус

Имитируем ситуацию, когда у нас резко уходит опорный генератор.

Время выставляется единожды по спутнику GPS + PPS от опорника.

Файл лога: SRNS_SIM.bin

0x0F5 PR  

[править] Смена leap second при синхронизации ШВП с GPS

Мы запустились после смены leap second с -18 на -20, но не знаем об этом.

Время выставляется единожды по спутнику GPS + PPS от опорника.

Файл лога: SRNS_SIM.bin

0x0F5 PR: в мире leap=-20, в приемнике leap=-18, синхронизация от GPS  

[править] Смена leap second при синхронизации ШВП с GLN (Фарватер)

Мы запустились после смены leap second с -18 на -20, но не знаем об этом.

Время выставляется единожды по спутнику GLN + PPS от опорника.

Файл лога: SRNS_SIM.bin

0x0F5 PR: в системе leap=-20, в приемнике leap=-18, синхронизация от ГЛН  

Если усугубить ситуацию и имитировать leap seconds = -218, то видно, что ось времени съезжает, т.е. параметр t в пакете F5 соответствует системному UTC. Когда берем время из GPS, то эффекта нет, то есть имеем смещение на 182 сек относительно UTC.

0x0F5 PR: в системе leap=-218, в приемнике leap=-18, синхронизация от ГЛН  

[править] 2019.07.24 - Разница эфемерид GlnL1OCd и GlnL1OF

• файл записан 04.07.2019, в сценарии 14.01.2018
• номер ревизии PL: n/a
• номер ревизии PS: f190a89b58a5c259b3b62ece701a9935e689c7eb
• экземпляр приемника: модель

Заложил в модель GlnL1OF ЦИ на то же время и с того же сценария, что у нас сейчас в L1OCd. Сравниваю вывод 0x222 (3 - GlnL1OCd, 1 - GlnL1OF):

 3  5 65700000.000   0 -2.40275976200103760e+07 -8.03384924030303955e+06 3.08990376472473145e+06 3.68244685232639313e-01 2.61957948096096516e-01 3.53226790949702263e+00 0.00000000000000000e+00 0.00000000000000000e+00 0.00000000000000000e+00 0.00000000000000000e+00 0.00000000000000000e+00 0
 1  5 65700000.000  -4 -2.40275976562500000e+07 -8.03384912109375000e+06 3.08990380859375000e+06 3.68245124816894531e-01 2.61958122253417969e-01 3.53226757049560547e+00 0.00000000000000000e+00 0.00000000000000000e+00 0.00000000000000000e+00 0.00000000000000000e+00 9.31322574615478516e-07 0

Качественное отличие только в предпоследнем параметре, это taun, выраженное в мс. То есть в L1OF идет 0, а в L1OCd около 1 нс. При этом в данном примере присутствуют как отрицательные, так и положительные значения.