05.06.2020 Отладка трансивера - лето 2020

Материал из SRNS
Перейти к: навигация, поиск
(2020.07.27 - Постоянство задержки от сериалайзера платы АЦП до десериалайзера платы Oryx)
(2020.07.28 - План по устранению проблем в платах АЦП и Oryx)
 
(не показаны 2 промежуточные версии 1 участника)
Строка 112: Строка 112:
 
* условия: Опора и PPS_In от SMBV100B, сигналы с крыши;
 
* условия: Опора и PPS_In от SMBV100B, сигналы с крыши;
  
Предыдущие эксперименты показали, что линия сериалайзер платы АЦП - десериалазер Oryx не вносит относительных задержек между разными банками АЦП от включения к включению прибора.
+
Предыдущие эксперименты показали, что линия сериалайзер платы АЦП - десериалазер Oryx не вносит относительных задержек между разными микросхемами АЦП от включения к включению прибора.
 
Возник вопрос: а как меняется общая задержка передачи данных "через Samtec" от включения к включению?
 
Возник вопрос: а как меняется общая задержка передачи данных "через Samtec" от включения к включению?
  
Строка 123: Строка 123:
  
 
[[file:Screenshot_2020-07-27_1_175704.png|600px]] [[file:Screenshot_2020-07-27_3_175834.png|600px]]
 
[[file:Screenshot_2020-07-27_1_175704.png|600px]] [[file:Screenshot_2020-07-27_3_175834.png|600px]]
 +
 +
 +
== 2020.07.28 - План по устранению проблем в платах АЦП и Oryx ==
 +
 +
Раз
 +
 +
* На плате АЦП прокинуть PPS_In с буфера через IDDR, и потом подать его на ЦАПы. Получим синхросигнал SYNC.
 +
* Поднять обратно 3-ю АЦП.
 +
* Завести синхросигнал SYNC с помощью делителей на 3 микросхемы АЦП.
 +
* Прокинуть их (SYNC) c трех микросхем АЦП и PPS_In с буффера по Samtec в ZynQ
 +
* Проверить их датаколлектором, убедиться в их адекватном внешнем виде, убедиться в наличии задержек между микросхемами АЦП.
 +
* Сделать в ZynQ схему выравнивания АЦП между собой: она должна принимать 3 сигнала SYNC, смотреть задержку между ними, и задерживать потоки данных от всех микросхем АЦП к самому задержанному. Также она должна оценивать задержку Delta между PPS_In с буфера платы АЦП и синалом SYNC (каким, выровненным к задержками или как?)
 +
* Учесть измеренную Delta в выдаче PPS_Out из ZynQ
 +
* Убираем в южном мосту Oryx схему с еще одним формированием PPS_Out  на счетчиках. Будем перещелкивать PPS_Out из ZynQ в клоки MCR - упрощаем монстра.
 +
 +
Два
 +
 +
* Оценить стабильность задержки от SER Samtec платы АЦП до DESER ZynQ в Oryx. Эксперимент проведен, [[#2020.07.27 - Постоянство задержки от сериалайзера платы АЦП до десериалайзера платы Oryx| результат чуть выше]]. Есть проблема со скачком на клок от включения к включению.
 +
 +
Три
 +
 +
* Чинить/освежать блоки Calibration и RefInterp в Oryx
 +
* Поднять UART из ZynQ для управления MCR, прокинуть его через южный мост к плате управления MCR. Там есть джамперы и  3х-пиновый разъем, можно переключаться между разъем на панели прибора / спец разъем.
 +
  
 
{{wl-publish: 2020-06-05 12:52:18 +0300 | Korogodin }}
 
{{wl-publish: 2020-06-05 12:52:18 +0300 | Korogodin }}

Текущая версия на 10:11, 28 июля 2020

Содержание

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

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

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

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


[править] 2020.06.05 - Интенсивность обмена данными по сети Ethernet по протоколу SRNS

  • номер ревизии PL: из bin, соответств. d948099bbd33557877428ce323ea3479a1f616c1
  • номер ревизии PS: из bin, соответств. d948099bbd33557877428ce323ea3479a1f616c1
  • номер рев conf: из bin, соответств. d948099bbd33557877428ce323ea3479a1f616c1
  • экземпляр приемника: старый (вероятно первой версии) Клоникус 115 на простой мама-борде, клок от SMC 10 MHz 0dBm
  • условия: SBMV, auto loc, 12 GPS;

К приемнику подключен srns2txt, который собирает лог от него. Данные снифятся wireshark.

Данные для 12 спутников, принимаются сигналы с низким темпом данных, для актуальной нагрузки надо умножать на 5-10.

[править] Общий поток от приемника

Саммари по обмену данными за 5 минут работы:

Screenshot 20200605 131702.png

Плотность отправки пакетов:

Screenshot 20200605 132120.png

Наибольшую плотность создает отправка эфемерид каждый 30 секунд, несколько десятков пакетов (сотня-две при полной нагрузке):

20200506 enp4s0 001.png

При этом достигается пиковая скорость 5кбайт/мс (50 при экстраполяции на полную нагрузку):

20200506 enp4s0 002.png


[править] Разбор по основным пакетам от приемника

Так как мы принимаем только один тип сигналов, то пакеты эфемеридных данных 0xF7 и 0x222 совпадают, раз в 30 секунд уходят порядка 2000 байт на 12 спутников:

Screenshot 20200605 143702.png

Измерения от 12 спутников отправляются раз в секунду в пакете 0xF5, 12 спутников занимают порядка 400 байт:

20200506 enp4s0 003.png

Секундный дамп цифровой информации в пакете 0х41 занимает порядка 100 байт на один сигнал. Но это для GPS LNAV, у которого самая низкая скорость передачи. Для SBAS это будут уже 600 байт.

20200506 enp4s0 004.png

Пакеты обмена целеуказаниями 0х12 улетают каждый 100 мс по одному от каждого спутника, 180 байт на пакет. У меня сейчас только один приемник, поэтому сниффится только один пакет.

20200506 enp4s0 012.png


[править] 2020.07.21 - Очередные мучения с PPS OUT в ККН

  • номер ревизии PL: 2c9bf757
  • номер ревизии PS: fc467aa0
  • номер ревизии PL южного моста: f695100d
  • номер ревизии PL платы АЦП: 0a001586
  • экземпляр приемника: наш MCR, Oryx IP 60 с новым линуксом
  • условия: Опора и PPS_In от SMBV100B, сигналы с крыши;

Можно сказать, что тестируется версия 5.7.5 на новом Линуксе.

Краткое резюме на 21.07.2020

АЦП

  • Клоки, сделанные из фрэймов 3 АЦП стоят в одной и той же фазе от включения к включению относительно клоков MCR. Есть там фидбэк в PLL или нет, не важно. Проверено в июле 2020.
  • Между разными головами АЦП могут появляться задержки на 1 клок. Проблема в десерах Спартана 6, их счетчики быстрых клоков не имеют сброса.
  • Если делать синхронизацию голов АЦП, подавая на них синхросигнал (с ЦАП, например), то тогда нужно делать аккуратно. Т.к. в плате АЦП есть блок mean-compens, который может сильно испортить прямоугольные сигналы, из-за своей инерционности. Я смотрел сиги/маги АЦП в Ориксе, после десера при помощи датаколлектора. Как-то его байпасить или настраивать для этих сигналов отдельно.
  • В плате АЦП был заложен мощный функционал по контроллеру SPI, который позволяет долбиться с Oryx по Samtec на плату АЦП и делать там всякое. В новом Линуксе Иван вывел системный UART с Oryx на линии SATMEC SPI. Таким образом, Oryx шлет системный вывод по SPI в плату АЦП, где это как-то может быть обработано контроллером SPI, и что-то сломать. Нужно выпиливать в плате АЦП прием SPI от Oryx.

MCR

  • Особенность работы синтезатора частот MCR -- каждый раз он стартует в новой фазе, относительно опорного сигнала 10 МГц (и входного PPS_IN соответственно, плюс клоки в АЦП джиттерят на размах около 2 нс относительно 10 МГц и/или PPS_IN). Таким образом, мы всегда от включения к включению можем оцифровать разный момент прихода PPS_IN в плату АЦП, соответственно, от включения к включению ящика у нас будет прыгать разность задержки между PPS_In и PPS_Out. Ну и из-за джиттера, если клок в плате АЦП встанет на фронте PPS_IN, будем еще и в процессе работы огребать (хотя тут врят ли, мы PPS_In пользуемся 1 раз по сути в софте).
  • На плате управления MCR есть джамперы, позволяющие переключить UART с разъема на панели, на обычный 3-пиновый разъем на плате. Это позволит заколхозить UART через Oryx и как-то подстраивать фазу клоков MCR из софта receiver.

Oryx

  • Эксперимент такой. Плата АЦП включена, все сигналы защелкнулись как-то и так и живут дальше. Дергаем питание Орикса отдельно, не выключая плату АЦП. И все равно можем получать разную задержку между PPS_In, PPS_Out. Возможные источники проблем:
    • плохо защелкиваем момент прихода PPS_In по ШВП в Ориксе
    • десериалайзеры Цинка
    • блок RefInterp, который неверно оценивает композитную метку времени по шкале ШВП
    • софт коррекции шкалы времени по PPS_In может лажать и неверно выставлять шкалу +- клок
  • Верилог выдачи PPS_Out в Цинке (общая шкала времени), содержит фиксированные задержки. Как минимум на 2 клока. Так что то, что записано в конф-файле в PPS_Out::offset как бы будет еще задержано на несколько клоков. Может как-то его пересмотреть?

[править] 2020.07.27 - Постоянство задержки от сериалайзера платы АЦП до десериалайзера платы Oryx

  • номер ревизии PL: 2c9bf757
  • номер ревизии PS: fc467aa0
  • номер ревизии PL южного моста: f695100d
  • номер ревизии PL платы АЦП: 0a001586
  • экземпляр приемника: наш MCR, Oryx IP 60 с новым линуксом
  • условия: Опора и PPS_In от SMBV100B, сигналы с крыши;

Предыдущие эксперименты показали, что линия сериалайзер платы АЦП - десериалазер Oryx не вносит относительных задержек между разными микросхемами АЦП от включения к включению прибора. Возник вопрос: а как меняется общая задержка передачи данных "через Samtec" от включения к включению?

Провели серию экспериментов, сравнивая задержку оцифрованного PPS IN, выведенного на GPIO 28 платы АЦП, и его же, выведенного через Zynq_GPIO_0 платы Oryx (кодовое название ППС ЫН Штрих). В качестве измерительного прибора использовали RTO.

На порядка 10 экспериментах в большинстве случаев получали задержку в 113 нс (12 клоков), пару раз получили задержку в 103 нс (11 клоков). Вывод: задержка по линии сериалайзер платы АЦП - десериалайзер Oryx вносит задержку, которая может изменяться на клок от включения к включению. Ивану требуется переработать FIFO.

Screenshot 2020-07-27 1 175704.png Screenshot 2020-07-27 3 175834.png


[править] 2020.07.28 - План по устранению проблем в платах АЦП и Oryx

Раз

  • На плате АЦП прокинуть PPS_In с буфера через IDDR, и потом подать его на ЦАПы. Получим синхросигнал SYNC.
  • Поднять обратно 3-ю АЦП.
  • Завести синхросигнал SYNC с помощью делителей на 3 микросхемы АЦП.
  • Прокинуть их (SYNC) c трех микросхем АЦП и PPS_In с буффера по Samtec в ZynQ
  • Проверить их датаколлектором, убедиться в их адекватном внешнем виде, убедиться в наличии задержек между микросхемами АЦП.
  • Сделать в ZynQ схему выравнивания АЦП между собой: она должна принимать 3 сигнала SYNC, смотреть задержку между ними, и задерживать потоки данных от всех микросхем АЦП к самому задержанному. Также она должна оценивать задержку Delta между PPS_In с буфера платы АЦП и синалом SYNC (каким, выровненным к задержками или как?)
  • Учесть измеренную Delta в выдаче PPS_Out из ZynQ
  • Убираем в южном мосту Oryx схему с еще одним формированием PPS_Out на счетчиках. Будем перещелкивать PPS_Out из ZynQ в клоки MCR - упрощаем монстра.

Два

  • Оценить стабильность задержки от SER Samtec платы АЦП до DESER ZynQ в Oryx. Эксперимент проведен, результат чуть выше. Есть проблема со скачком на клок от включения к включению.

Три

  • Чинить/освежать блоки Calibration и RefInterp в Oryx
  • Поднять UART из ZynQ для управления MCR, прокинуть его через южный мост к плате управления MCR. Там есть джамперы и 3х-пиновый разъем, можно переключаться между разъем на панели прибора / спец разъем.


[ Хронологический вид ]Комментарии

(нет элементов)

Войдите, чтобы комментировать.

Персональные инструменты
Пространства имён

Варианты
Действия
SRNS Wiki
Рабочие журналы
Приватный файлсервер
QNAP Сервер
Инструменты
Печать/экспорт