SRNS - Вклад участника [ru]

Blog:Roslyakov/13.12.2021 Формирование навигационного сигнала GPS CA с помощью gps-sdr-sim и HackRF

2025-12-12T06:19:45Z

Dneprov:

<summary [ hidden ]>
<center>[[File:JsPFkaOzCOA.jpg|400px]]</center>
Имитатор за копейки
</summary>

== Формирование навигационного сигнала GPS L1 C/A c помощью GPS-SDR-SIM и HackRF One ==

''' GPS-SDR-SIM ''' — программа, позволяющая выводить двоичный файл сигналов в соответствии с указанным файлом спутниковой информации, информацией о координатах, частоте дискретизации и другими параметрами.

''' HackRF One ''' — программно-определяемое радио, способное передавать / принимать радиосигналы на частотах от 1МГц до 6 ГГц.
Использует технологию, позволяющую с помощью программного обеспечения устанавливать / изменять рабочие радиочастотные параметры.

== Введение ==

Данная статья является инструкцией по формированию навигационного сигналы GPS L1 C/A для неподвижного потребителя.
Для имитации GPS сигнала будет использоваться программа GPS-SDR-SIM, которая позволяет формировать выборку навигационного сигнала (НС) в соответствии с указанным файлом спутниковой информации.
Полученный файл будет импортироваться в радиочастотное устройство для трансляции НС в эфир.

В качестве приемопередатчика будет выступать программно-определяемое радио (англ. SDR - software defined radio) HackRF One.
Основные характеристики устройства: диапазон частот от 1 МГц до 6 ГГц, полоса пропускания 20 МГц, 8-разрядный АЦП/ЦАП.

Рассматривается конфигурация HackRF One c расширяющей платой Portapack H2, которая позволяет работать HackRF One автономно, т.е. без подключения к компьютеру.

В сборе HackRf One + Portapack H2 + металлический корпус, SDR выглядит следующим образом:

[[File:photo_2021-12-13_17-08-01.jpg||240px|center]]

На изображении ниже можно увидеть два SMA разъема CLKIN (ближний) и CLKOUT – вход и выход для синхронизации.
На этой же стороне присутствует разъем micro-USB для подключения платы к компьютеру.

[[File:photo_2021-12-13_16-51-13.jpg||400px|center]]

С противоположной стороны плата имеет антенный разъем SMA и две кнопки: Reset – для перезагрузки HackRF по питанию и DFU – для восстановления заводской прошивки.
Над кнопками разъем для карты памяти.

[[File:photo_2021-12-13_16-48-52 (2).jpg||400px|center]]

== Последовательность действий для формирования сигнала ==

''' Шаг 1. Подключение '''

* Подключите антенну к SMA разъему на плате.
* Подключите плату к ПК (micro-USB/USB кабель).

''' Шаг 2. Установка драйверов и пакетов на ПК (ОС: Linux) '''

*Команды в консоль:

sudo apt update; sudo apt upgrade

sudo apt install hackrf libhackrf-dev libhackrf0 gnuradio gnuradio-dev gr-osmosdr gqrx-sdr

''' Шаг 3. Отклик HackRF '''

* Включить плату, в открывшемся меню выбрать и нажать кнопку HackRF.

[[file:photo_2021-12-13_16-49-51.jpg|thumb|Меню HackRF]]

* Соглашаемся на HackRF mode для управления платой через ПК.

*Команда в консоль:

hackrf_info

*Ожидаемый ответ:

hackrf_info version: unknown
libhackrf version: unknown (0.5)
Found HackRF
Index: 0
Serial number: 0000000000000000048866dc348258c3
Board ID Number: 2 (HackRF One)
Firmware Version: local-57ed3eb (API:1.04)
Part ID Number: 0xa000cb3c 0x00614368

''' Шаг 4. Загрузить и скомпилировать код GPS-SDR-SIM '''

*Команды в консоль:

git clone https://github.com/osqzss/gps-sdr-sim.git

cd gps-sdr-sim && gcc gpssim.c -lm -O3 -o gps-sdr-sim

''' Шаг 5. Формированию выборки сигнала GPS '''

* Открыть консоль внутри скомпилированной программы.

* Консольная команда для формирования 8-разрядного бинарный файла сигнала по эфемеридному файлу brdc3540.14n:

./gps-sdr-sim -e brdc3540.14n -l 31.603202,120.466576,100 -b 8 -d 300

где

brdc3540.14 — файл эфемерид 32-х спутников GPS;

-e — файл является общим форматом ГНСС-данных RINEX;

-l 31.603202,120.466576,100 — координаты позиции приемника;

-b 8 — разрядность чисел в выходном файле;

-d 300 — длительность в секундах (1с = 5Мбайт).

''' Шаг 6. Формирование радиосигнала '''

На предыдущем шаге по эфемеридному файлу был создан 8-разрядный бинарный файл «gpssim.bin».

* Консольная команда для отправки сформированного файла на HackRF:
<sub>Убедитесь, что антенна подключена к антенному порту HackRF</sub>

hackrf_transfer -t gpssim.bin -f 1575.42e6 -s 2.6e6 -a 1 -x 30 -b 5e6

где

hackrf_transfer – команда, с помощью которой можно отправлять и получать сигналы, используя HackRF;

-t – пересылать данные из файла <имя файла>;

-f – несущая сигнала 1575.42 МГц;

-s – частота дискретизации 2.6 МГц;

-a – RF усилитель (1=Включен);

-x – усиление TX 30 dB;

-b – 5e6 полоса пропускания ФНЧ.

''' Шаг 7. Оценка параметров сигнала смартфоном '''

[[file:photo_2021-12-13_17-07-30.jpg|thumb|Ожижаемый результат]]

* Установить приложение GPS Test.

* Включить геолакацию.

* Включить на телефоне режим полета

== Дополнительный материал ==

Ссылки:

https://github.com/osqzss/gps-sdr-sim.git — GPS-SDR-SIM

https://russianblogs.com/article/2381493862/ — более широкая инструкция по флагам gps-sdr-sim

https://hackware.ru/?p=8249 — инструкция на русском для HackRF
{{wl-publish: 2021-12-24 09:22:02 +0400 | Roslyakov }}

Blog:DneprovD/17.06.2024 Clonicus 2.0

2025-12-12T06:18:58Z

Dneprov:

<summary hidden=true>
<center>[[File:IMG_20240621_134919.jpg|400px]]</center>
</summary>
{{Форма2}}
__TOC__

== Косяки ==
=== DDR ===
На плате установлен 1 чип DDR3L MT41K128M16-107 на 256 МБ. В проекте вивадо достаточно было выбрать похожее устройство, тайминги были выставлены автоматически. Задержки по дорогам берутся из альтиума.

Память сначала отказывалась работать, повисала на калибровке WL. Потыкались осцилографом - проблема была в некачественной пайке.

[https://static.chipdip.ru/lib/911/DOC012911114.pdf Даташит на DDR]

[https://www.youtube.com/watch?v=W3Jt_y6PHjA&ab_channel=Phil%E2%80%99sLab Видео, какие тайминги откуда брать]

[https://docs.amd.com/v/u/en-US/ds191-XC7Z030-XC7Z045-data-sheet#page=17 Таблица20: максимальная скорость DDR в цинках]

=== SD Card ===
Были проблемы с подмонтированием разделов и ошибки чтения секторов. Проблема схемотехническая в обвязке и непонятном левелшифтере PI4ULS5V106.

=== Nomada ===
Припаян не тот кварц (выбран не с тем номиналом напряжения). Подтянут к нужному номиналу резистором.

== Заметки ==
=== Ethernet ===
(!) Для корректной работы желательно пересобирать u-boot при изменении девайстри, и boot.bin командой
<source lang="bash">
petalinux-package --boot --format BIN --fsbl ./zynq_fsbl.elf --u-boot --force
</source>
На плате есть 2 физика:
* К GEM0 подключен Realtek RTL8211E-VL-CG.
* К GEM1 подключен Texas Instruments DP83867.
* Шина MDIO общая, на пинах 52-53.

В Vivado включал отдельно только Ethernet0, только Ethernet1, оба сразу с MDIO на нулевом.

Каждый физик отдельно видится на мдио независимо от того, к Ethernet0 или Ethernet1 она подключена. В стандалоне тестах в sdk автосогласование проходят оба физика, тест их находит.

U-boot версии 2017.4 видит оба физика на мдио, но драйвер прикручивает только к первому по порядку в девайстри. Два сразу старый U-boot не умеет до версии 2018.1 (гуглится обсуждение).

При работе с двумя физиками рекомендуют накатить на ядро патч драйвера macb, чтобы он видел два физика. При этом раздел mdio {} в девайстри заработал только при помещении его в общую часть, там где {aliases, chosen}.

[https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841740/Macb+Driver Заметка на хиливики про Common MDIO DT Macb Driver]

[https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842475/PetaLinux+Yocto+Tips#PetaLinuxYoctoTips-PatchingtheLinuxKernelofaPetaLinuxProject Как патчить ядро]

[https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841740/Macb+Driver Пример девайстри с вики для двух PHY]

[https://support.xilinx.com/s/article/69132?language=en_US Оффициальный AR xilinx для dual PHY с патчами]

[https://support.xilinx.com/s/question/0D52E00006hpe3DSAQ/dual-ethernet-still-not-working-after-patching-macb-driver-petalinux-20172?language=en_US AR#1]

[https://support.xilinx.com/s/question/0D52E00007AMwsGSAT/how-to-fix-zynq7000-dual-ethernet-phy-on-single-mdio-bus-in-xilinxv20191-and-newer?language=en_US AR#2]

[https://support.xilinx.com/s/question/0D52E00006iHu9HSAS/dual-phys-on-mdioemio?language=en_US AR#3]

[https://support.xilinx.com/s/question/0D52E00007AMwsGSAT/how-to-fix-zynq7000-dual-ethernet-phy-on-single-mdio-bus-in-xilinxv20191-and-newer?language=en_US AR#4]

[https://support.xilinx.com/s/question/0D52E00006iHlW2SAK/zynq-dual-ethernet-question?language=en_US AR#5]

==== Один PHY ====
Рабочий devicetree для ядра без патча, один PHY (на выбор):

'''<projectname>/project-spec/meta-user/recipes-bsp/device-tree/files/system-user.dtsi''':
<source lang = bash>
/* RTL8211E */
&gem0{
status = "okay";
phy-handle = <&phy1>;
phy-mode = "rgmii-id";
local-mac-address = [00 0a 35 00 22 01];

mdio {
status = "okay";
#address-cells = <1>;
#size-cells = <0>;

phy0: phy@1 {
status = "okay";
device_type = "ethernet-phy";
reg = <1>;
};
};
};

/*TI dp83867 */
&gem1{
status = "okay";
phy-handle = <&phy1>;
phy-mode = "rgmii-id";
local-mac-address = [00 0a 35 00 22 02];

xlnx,eth-mode = <0x1>;

mdio {
status = "okay";
#address-cells = <1>;
#size-cells = <0>;

phy1: phy@12 {
status = "okay";
compatible = "ethernet-phy-ieee802.3-c22";
device_type = "ethernet-phy";

reg = <12>;
ti,rx-internal-delay = <0x7>;
ti,tx-internal-delay = <0x7>;
ti,fifo-depth = <0x01>;
ti,min-output-impedance;
ti,dp83867-rxctrl-strap-quirk;
};
};
};

</source>

==== Два PHY ====
Пропатчено ядро для общей mdio. Mdio на Ethernet0 в Vivado, пины 52-53. Первый физик поднимается автоматически. Второй жив, пожнимается через:
<source lang = bash>
ifconfig eth1 192.168.0.231 netmask 255.255.255.0 up
</source>

'''<projectname>/project-spec/meta-user/recipes-bsp/device-tree/files/system-user.dtsi''':
<source lang = bash>
/ {
aliases {...}

chosen {...}

mdio {
compatible = "cdns,macb-mdio";
reg = <0xe000b000 0x1000>;
status = "okay";
clocks = <&clkc 30>, <&clkc 30>, <&clkc 13>;
clock-names = "pclk", "hclk", "tx_clk";
#address-cells = <1>;
#size-cells = <0>;

phy0: phy@1 {
compatible = "ethernet-phy-ieee802.3-c22";
device_type = "ethernet-phy";
reg = <1>;
status = "okay";
};

phy1: phy@12 {
compatible = "ethernet-phy-ieee802.3-c22";
device_type = "ethernet-phy";
reg = <12>;
status = "okay";
ti,rx-internal-delay = <0x7>;
ti,tx-internal-delay = <0x7>;
ti,fifo-depth = <0x01>;
ti,min-output-impedance;
ti,dp83867-rxctrl-strap-quirk;
};
};
};

&gem0{
status = "okay";
phy-handle = <&phy0>;
phy-mode = "rgmii-id";
local-mac-address = [00 0a 35 00 22 01];
};

&gem1{
status = "okay";
phy-handle = <&phy1>;
phy-mode = "rgmii";
local-mac-address = [00 0a 35 00 22 02];

xlnx,eth-mode = <0x1>;
};
</source>

=== QSPI Flash ===
На плате установлена не поддерживаемая (нету) по табличке W25Q512JVEIQ.

Флешка поднялась, причина - отсутствие резистора на QSPI_SCK_MODE4 - была закоротка на землю.

Пропатчил юбут, добавив в файл <projectname>/components/ext_sources/MY-U-BOOT/u-boot-xlnx/drivers/mtd/spi/spi_flash_ids.c флешку, и наложив патч:

'''0001-add-spi-support-for-w25q512jv.patch'''
<source lang = bash>
From 17ebfc83d3929446288d1143d33d8fbd156360d0 Mon Sep 17 00:00:00 2001
From: DneprovD <dneprov_dv@mail.ru>
Date: Thu, 20 Jun 2024 12:27:45 +0300
Subject: [PATCH] add spi support for w25q512jv

---
drivers/mtd/spi/spi_flash_ids.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/spi/spi_flash_ids.c b/drivers/mtd/spi/spi_flash_ids.c
index cb27c88..c3e725a 100644
--- a/drivers/mtd/spi/spi_flash_ids.c
+++ b/drivers/mtd/spi/spi_flash_ids.c
@@ -167,6 +167,7 @@ const struct spi_flash_info spi_flash_ids[] = {
{"w25q32dw", INFO(0xef6016, 0x0, 64 * 1024, 64, RD_FULL | WR_QPP | SECT_4K) },
{"w25q64dw", INFO(0xef6017, 0x0, 64 * 1024, 128, RD_FULL | WR_QPP | SECT_4K) },
{"w25q128fw", INFO(0xef6018, 0x0, 64 * 1024, 256, RD_FULL | WR_QPP | SECT_4K) },
+ {"w25q512jv", INFO(0xef4020, 0x0, 64 * 1024, 1024, RD_FULL | WR_QPP | SECT_4K) },
#endif
{}, /* Empty entry to terminate the list */
/*
--
1.9.1

</source>

В project-spec/meta-user/recipes-bsp/u-boot/files/platform-top.h добавил
<source lang=bash>
#define CONFIG_SPI_FLASH_WINBOND Y
</source>

[https://support.xilinx.com/s/article/50991?language=en_US Список поддерживаемых Zynq 7000 флешек и гайд что делать с неподдерживаемыми]

[https://support.xilinx.com/s/article/62743?language=en_US Гайд для неподдерживаемых]

[https://srns.ru/wiki/%D0%A4%D0%B0%D0%B9%D0%BB:QSPI_FLASH_support_guide_rev1.0.pdf Гайд по добавлению правок в U-boot]

[https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842262/Zynq+QSPI+Driver Zynq QSPI Driver на хилипедии]

==== Разметка QSPI ====

Делал так:

1) Идем в petalinux-config -> Subsystem AUTO Hardware Settings -> '''Flash Settings'''

Там задаем разделы флешки:
[[Файл:Qspi-partitions-KibiBytes.PNG|500px|right|thumb]]
<source lang=bash>
Primary Flash (ps7_qspi_0) --->
[ ] Advanced Flash Auto Configuration
*** partition 0 ***
(boot) name
(0x100000) size
*** partition 1 ***
(bootenv) name
(0x20000) size
*** partition 2 ***
(kernel) name
(0x1400000) size
*** partition 3 ***
(dtb) name
(0x20000) size
*** partition 4 ***
(rootfs) name
(0xA00000) size
*** partition 5 ***
(bitstream) name
(0x600000) size
*** partition 6 ***
(spare) name
(0x1AC0000) size
*** partition 7 ***
() name
</source>

Для наглядности накидал [https://openipc.org/tools/firmware-partitions-calculation?locale=ru на сайтике картинку]

2) Там же в petalinux-config -> Subsystem AUTO Hardware Settings -> '''Advanced bootable images storage Settings''' заходим в каждый пункт и выставляем
<source lang = bash>
image storage media
(X) primary flash

# в пункте для DTB на пробу поставил
(X) from boot image
</source>

После этого U-boot будет искать указанные файлы по указанным адресам на QSPI флешке при включенном режиме загрузки с QSPI флешки. Также это отразится на генерируемом файле юбута Petalinux/qspi/project-spec/meta-plnx-generated/recipes-bsp/u-boot/configs/platform-auto.h. Этот файл обновляется при вызове petalinux-config -c u-boot (вроде).

==== Прошивка QSPI ====

QSPI флешка прошивается из U-boot через sf probe, sf write.
Это же делает SDK, когда прошивается флешка через JTAG. SDK собирает свой юбут внутри себя, и им прошивает. Недостатком было то, что юбут из SDK не пропатчен на поддержку новой флешки, и он валится на обнаружении. Возможно, его можно пропатчить внутри SDK, я не пробовал.

Как прошивал:
# Собрал проект через petalinux-build.
# Положил все нужные файлы на sd-карту.
# Загрузился с sd-карты, зашел в u-boot.
# Из консоли U-boot выполнил:
<source lang=bash>
# подключаемся
> sf probe 0

# стираем области перед записью. Стирать можно маленькими разделами или всю флешку разом
> sf erase 0 0x1AC0000

# загружаем файлы в DDR и пишем их на флешку. Переменная filesize заполняется сама.
> fatload mmc 0 0x00100000 BOOT.bin
> sf write 0x00100000 0x0 ${filesize} #(DDR_address offset image_size)

> fatload mmc 0 0x00100000 image.ub
> sf write 0x00100000 0x120000 ${filesize}

и так далее
</source>

==== Работа с MTD ====

В операционке работать с разделами флешки можно через /proc/mtd. Для того, чтобы mtd драйвер увидел флешку, пришлось накатить на него патч.

<source lang=bash>
From 6a51554240c03a0dc0676fac0ab273bd7cf0c77f Mon Sep 17 00:00:00 2001
From: DneprovD <dneprov_dv@mail.ru>
Date: Tue, 12 Nov 2024 14:31:49 +0300
Subject: [PATCH] Add w25q512jvq support in mtd-spi-nor

---
drivers/mtd/spi-nor/spi-nor.c | 2 ++
1 file changed, 2 insertions(+)

diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 79194ec..91d6996 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -1336,6 +1336,8 @@ static int spi_nor_is_locked(struct mtd_info *mtd, loff_t ofs, uint64_t len)
{ "w25q128", INFO(0xef4018, 0, 64 * 1024, 256, SECT_4K| SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
{ "w25q256", INFO(0xef4019, 0, 64 * 1024, 512, SECT_4K| SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },

+ { "w25q512jvq", INFO(0xef4020, 0, 64 * 1024, 1024, SECT_4K| SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
+
/* Catalyst / On Semiconductor -- non-JEDEC */
{ "cat25c11", CAT25_INFO( 16, 8, 16, 1, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
{ "cat25c03", CAT25_INFO( 32, 8, 16, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
--
1.9.1

</source>

Изначально поддержки конкретно нашей флешки там нет вплоть до v2021.1. Простое добавление строки позволило mtd драйверу обнаруживать флешку, но запись в нее через flashcp работает с ошибками. Пока остановился на этом.

=== U-boot ===
==== Env ====
uEnv.txt - только для sd boot (захардкожено в u-boot-xlnx/include/configs/zynq-common.h).

Вроде бы можно [https://community.intel.com/t5/FPGA-SoC-And-CPLD-Boards-And/Unable-to-read-file-u-boot-scr/td-p/219580 обернуть юбутом (mkImage)] тектовый файл, и зашить в qspi. Не пробовал, вдруг не нужно.

{{Начало скрытого блока|Выравнивание_заголовка = left| Ссылка = left|Заголовок = Код стандартной env из zynq-common.h:}}
<source lang=bash>
/* Default environment */
#ifndef CONFIG_EXTRA_ENV_SETTINGS
#define CONFIG_EXTRA_ENV_SETTINGS \
"ethaddr=00:0a:35:00:01:22\0" \
"kernel_image=uImage\0" \
"kernel_load_address=0x2080000\0" \
"ramdisk_image=uramdisk.image.gz\0" \
"ramdisk_load_address=0x4000000\0" \
"devicetree_image=devicetree.dtb\0" \
"devicetree_load_address=0x2000000\0" \
"bitstream_image=system.bit.bin\0" \
"boot_image=BOOT.bin\0" \
"loadbit_addr=0x100000\0" \
"loadbootenv_addr=0x2000000\0" \
"kernel_size=0x500000\0" \
"devicetree_size=0x20000\0" \
"ramdisk_size=0x5E0000\0" \
"boot_size=0xF00000\0" \
"fdt_high=0x20000000\0" \
"initrd_high=0x20000000\0" \
"bootenv=uEnv.txt\0" \
"loadbootenv=load mmc 0 ${loadbootenv_addr} ${bootenv}\0" \
"importbootenv=echo Importing environment from SD ...; " \
"env import -t ${loadbootenv_addr} $filesize\0" \
"sd_uEnvtxt_existence_test=test -e mmc 0 /uEnv.txt\0" \
"preboot=if test $modeboot = sdboot && env run sd_uEnvtxt_existence_test; " \
"then if env run loadbootenv; " \
"then env run importbootenv; " \
"fi; " \
"fi; \0" \
"mmc_loadbit=echo Loading bitstream from SD/MMC/eMMC to RAM.. && " \
"mmcinfo && " \
"load mmc 0 ${loadbit_addr} ${bitstream_image} && " \
"fpga load 0 ${loadbit_addr} ${filesize}\0" \
"norboot=echo Copying Linux from NOR flash to RAM... && " \
"cp.b 0xE2100000 ${kernel_load_address} ${kernel_size} && " \
"cp.b 0xE2600000 ${devicetree_load_address} ${devicetree_size} && " \
"echo Copying ramdisk... && " \
"cp.b 0xE2620000 ${ramdisk_load_address} ${ramdisk_size} && " \
"bootm ${kernel_load_address} ${ramdisk_load_address} ${devicetree_load_address}\0" \
"qspiboot=echo Copying Linux from QSPI flash to RAM... && " \
"sf probe 0 0 0 && " \
"sf read ${kernel_load_address} 0x100000 ${kernel_size} && " \
"sf read ${devicetree_load_address} 0x600000 ${devicetree_size} && " \
"echo Copying ramdisk... && " \
"sf read ${ramdisk_load_address} 0x620000 ${ramdisk_size} && " \
"bootm ${kernel_load_address} ${ramdisk_load_address} ${devicetree_load_address}\0" \
"uenvboot=" \
"if run loadbootenv; then " \
"echo Loaded environment from ${bootenv}; " \
"run importbootenv; " \
"fi; " \
"if test -n $uenvcmd; then " \
"echo Running uenvcmd ...; " \
"run uenvcmd; " \
"fi\0" \
"sdboot=if mmcinfo; then " \
"run uenvboot; " \
"echo Copying Linux from SD to RAM... && " \
"load mmc 0 ${kernel_load_address} ${kernel_image} && " \
"load mmc 0 ${devicetree_load_address} ${devicetree_image} && " \
"load mmc 0 ${ramdisk_load_address} ${ramdisk_image} && " \
"bootm ${kernel_load_address} ${ramdisk_load_address} ${devicetree_load_address}; " \
"fi\0" \
"usbboot=if usb start; then " \
"run uenvboot; " \
"echo Copying Linux from USB to RAM... && " \
"load usb 0 ${kernel_load_address} ${kernel_image} && " \
"load usb 0 ${devicetree_load_address} ${devicetree_image} && " \
"load usb 0 ${ramdisk_load_address} ${ramdisk_image} && " \
"bootm ${kernel_load_address} ${ramdisk_load_address} ${devicetree_load_address}; " \
"fi\0" \
"nandboot=echo Copying Linux from NAND flash to RAM... && " \
"nand read ${kernel_load_address} 0x100000 ${kernel_size} && " \
"nand read ${devicetree_load_address} 0x600000 ${devicetree_size} && " \
"echo Copying ramdisk... && " \
"nand read ${ramdisk_load_address} 0x620000 ${ramdisk_size} && " \
"bootm ${kernel_load_address} ${ramdisk_load_address} ${devicetree_load_address}\0" \
"jtagboot=echo TFTPing Linux to RAM... && " \
"tftpboot ${kernel_load_address} ${kernel_image} && " \
"tftpboot ${devicetree_load_address} ${devicetree_image} && " \
"tftpboot ${ramdisk_load_address} ${ramdisk_image} && " \
"bootm ${kernel_load_address} ${ramdisk_load_address} ${devicetree_load_address}\0" \
"rsa_norboot=echo Copying Image from NOR flash to RAM... && " \
"cp.b 0xE2100000 0x100000 ${boot_size} && " \
"zynqrsa 0x100000 && " \
"bootm ${kernel_load_address} ${ramdisk_load_address} ${devicetree_load_address}\0" \
"rsa_nandboot=echo Copying Image from NAND flash to RAM... && " \
"nand read 0x100000 0x0 ${boot_size} && " \
"zynqrsa 0x100000 && " \
"bootm ${kernel_load_address} ${ramdisk_load_address} ${devicetree_load_address}\0" \
"rsa_qspiboot=echo Copying Image from QSPI flash to RAM... && " \
"sf probe 0 0 0 && " \
"sf read 0x100000 0x0 ${boot_size} && " \
"zynqrsa 0x100000 && " \
"bootm ${kernel_load_address} ${ramdisk_load_address} ${devicetree_load_address}\0" \
"rsa_sdboot=echo Copying Image from SD to RAM... && " \
"load mmc 0 0x100000 ${boot_image} && " \
"zynqrsa 0x100000 && " \
"bootm ${kernel_load_address} ${ramdisk_load_address} ${devicetree_load_address}\0" \
"rsa_jtagboot=echo TFTPing Image to RAM... && " \
"tftpboot 0x100000 ${boot_image} && " \
"zynqrsa 0x100000 && " \
"bootm ${kernel_load_address} ${ramdisk_load_address} ${devicetree_load_address}\0" \
DFU_ALT_INFO
#endif
</source>
{{Конец скрытого блока}}

Иван загружал clonicus.bit юбутом через Uboot.env. Вроде как можно вместо Uboot.env сделать uEnv.txt - на схожесть не проверял.

'''Иванова Uboot.env''' в текстовом редакторе после приведения в читаемый вид:
<source lang = bash>
<TіQautoload=yes
boot_dtb=fatload mmc 0 0x9000000 system.dtb
boot_image=fatload mmc 0 0xA000000 image.ub
bootcmd=run swdt_set && run fpga_config && run boot_image && run boot_dtb && bootm 0xA000000 0xA000000 0x9000000
bootdelay=1
ethaddr=00:0a:35:00:21:70
fdtcontroladdr=ffa91b0
fileaddr=100000
filesize=5b3f74
swdt_set=run swdt_ccr && run swdt_rst && run swdt_zmr
swdt_ccr=mw 0xf8005004 0x92063b
swdt_rst=mw 0xf8005008 0x1999
swdt_zmr=mw 0xf8005000 0xabc043
fpga_config=run load_bit && run pl_load
ipaddr=192.168.0.110
kernel_img=image.ub
load_bit=fatload mmc 0 0x100000 clonicus.bit
netmask=255.255.255.0
pl_load=fpga loadb 0 0x100000 0x1400000
serverip=192.168.0.1
</source>

==== Env to binary ====
В исходниках U-boot давно лежит утилита mkenvimage.c.
Пока что так и не попользовался ей.
https://bootlin.com/blog/mkenvimage-uboot-binary-env-generator/

Код Андрея по переводу текстового uEnv.txt в бинарный:
<source lang=python>
import zlib
import sys

if len(sys.argv) != 4:
sys.exit('args error!')

inputFilename = str(sys.argv[1])
outputFilename = str(sys.argv[2])
write_size = int(sys.argv[3])

with open(inputFilename, "r") as fid:
lines = [line for line in fid]

lines_zero = (''.join(lines)).replace('\n', '\0')
lines_zero = lines_zero + (write_size - len(lines_zero)) * '\0'
fbytes = lines_zero.encode()
fid.close()

crc = (zlib.crc32(fbytes)).to_bytes(4, byteorder='little')

file_contents = crc + fbytes

fid = open(outputFilename,"wb")
fid.write(file_contents)
fid.close()
</source>

==== U-boot patch ====

(!) При внесении изменений в юбут не забываем добавить коммент к версии в
<source lang=bash>
$ petalinux-config -c u-boot

General setup ->
Local version - append to U-Boot release
дописываем отличия версии, например, qspi
</source>

Попробовал пропатчить u-boot для добавления поддержки qspi флешки, которая не поддерживалась.

[https://docs.amd.com/v/u/2019.1-English/ug1144-petalinux-tools-reference-guide#page=107 Как сделать внешние исходники u-boot в проекте]

[https://devconnected.com/how-to-create-and-apply-git-patch-files/ Как делать git patch]

Методология создания патча для U-boot:
* Куда-то рядом или внутрь проекта в <projectname>/components/ext_sources/MY-U-BOOT/ скачивается [https://github.com/Xilinx/u-boot-xlnx/tree/xilinx-v2017.4 гит юбута].
* Переходим на ветку xilinx-v2017.4
<source lang = bash>
git checkout xilinx-v2017.4
</source>
* Создаем новую ветку mytest
<source lang = bash>
git checkout -b mytest
</source>
* Находим в исходниках файлик(и), в который хотим внести изменения. Вносим изменения. Коммитим в ветку mytest.
* Делаем файл патча относительно ветки xilinx-v2017.4, находясь в ветке mytest. В той папке, в которой вызываем команду, появится файл '''0001-<commit-mesg>.patch'''
<source lang = bash>
git format-patch xilinx-v2017.4
</source>
* Копируем файл 0001-<commit-mesg>.patch в <projectname>/project-spec/meta-user/recipes-bsp/u-boot/files/
* Добавляем в файл '''<projectname>/project-spec/meta-user/recipes-bsp/u-boot/u-boot-xlnx_%.bbappend''' строку с именем патча:
<source lang = bash>
SRC_URI_append = " file://0001-add-spi-support-for-w25q512jv.patch"
</source>
* Собираем
<source lang = bash>
petalinux-build -c u-boot
</source>

Для изменения стартового сообщения U-Boot 2017.01 (Jun 07...) идем в <projectname>/components/ext_sources/MY-U-BOOT/u-boot-xlnx/Makefile. В строке 5 есть VERSION, в строке 1280 сам вывод.
То же можно сделать где-то в petalinux конфигах / юбут конфигах, не залезая в исходники.

[[Категория:Zynq]]
[[Категория:EmbeddedLinux]]
[[Category:Clonicus]]

{{wl-publish: 2024-06-17 07:27:00 +00:00 | Dneprov D }}

Blog:DneprovD/17.06.2024 Clonicus 2.0

2025-12-12T06:08:56Z

Dneprov:

<summary hidden=true>
<center>[[File:IMG_20240621_134919.jpg|400px]]</center>
</summary>

__TOC__

== Косяки ==
=== DDR ===
На плате установлен 1 чип DDR3L MT41K128M16-107 на 256 МБ. В проекте вивадо достаточно было выбрать похожее устройство, тайминги были выставлены автоматически. Задержки по дорогам берутся из альтиума.

Память сначала отказывалась работать, повисала на калибровке WL. Потыкались осцилографом - проблема была в некачественной пайке.

[https://static.chipdip.ru/lib/911/DOC012911114.pdf Даташит на DDR]

[https://www.youtube.com/watch?v=W3Jt_y6PHjA&ab_channel=Phil%E2%80%99sLab Видео, какие тайминги откуда брать]

[https://docs.amd.com/v/u/en-US/ds191-XC7Z030-XC7Z045-data-sheet#page=17 Таблица20: максимальная скорость DDR в цинках]

=== SD Card ===
Были проблемы с подмонтированием разделов и ошибки чтения секторов. Проблема схемотехническая в обвязке и непонятном левелшифтере PI4ULS5V106.

=== Nomada ===
Припаян не тот кварц (выбран не с тем номиналом напряжения). Подтянут к нужному номиналу резистором.

== Заметки ==
=== Ethernet ===
(!) Для корректной работы желательно пересобирать u-boot при изменении девайстри, и boot.bin командой
<source lang="bash">
petalinux-package --boot --format BIN --fsbl ./zynq_fsbl.elf --u-boot --force
</source>
На плате есть 2 физика:
* К GEM0 подключен Realtek RTL8211E-VL-CG.
* К GEM1 подключен Texas Instruments DP83867.
* Шина MDIO общая, на пинах 52-53.

В Vivado включал отдельно только Ethernet0, только Ethernet1, оба сразу с MDIO на нулевом.

Каждый физик отдельно видится на мдио независимо от того, к Ethernet0 или Ethernet1 она подключена. В стандалоне тестах в sdk автосогласование проходят оба физика, тест их находит.

U-boot версии 2017.4 видит оба физика на мдио, но драйвер прикручивает только к первому по порядку в девайстри. Два сразу старый U-boot не умеет до версии 2018.1 (гуглится обсуждение).

При работе с двумя физиками рекомендуют накатить на ядро патч драйвера macb, чтобы он видел два физика. При этом раздел mdio {} в девайстри заработал только при помещении его в общую часть, там где {aliases, chosen}.

[https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841740/Macb+Driver Заметка на хиливики про Common MDIO DT Macb Driver]

[https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842475/PetaLinux+Yocto+Tips#PetaLinuxYoctoTips-PatchingtheLinuxKernelofaPetaLinuxProject Как патчить ядро]

[https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841740/Macb+Driver Пример девайстри с вики для двух PHY]

[https://support.xilinx.com/s/article/69132?language=en_US Оффициальный AR xilinx для dual PHY с патчами]

[https://support.xilinx.com/s/question/0D52E00006hpe3DSAQ/dual-ethernet-still-not-working-after-patching-macb-driver-petalinux-20172?language=en_US AR#1]

[https://support.xilinx.com/s/question/0D52E00007AMwsGSAT/how-to-fix-zynq7000-dual-ethernet-phy-on-single-mdio-bus-in-xilinxv20191-and-newer?language=en_US AR#2]

[https://support.xilinx.com/s/question/0D52E00006iHu9HSAS/dual-phys-on-mdioemio?language=en_US AR#3]

[https://support.xilinx.com/s/question/0D52E00007AMwsGSAT/how-to-fix-zynq7000-dual-ethernet-phy-on-single-mdio-bus-in-xilinxv20191-and-newer?language=en_US AR#4]

[https://support.xilinx.com/s/question/0D52E00006iHlW2SAK/zynq-dual-ethernet-question?language=en_US AR#5]

==== Один PHY ====
Рабочий devicetree для ядра без патча, один PHY (на выбор):

'''<projectname>/project-spec/meta-user/recipes-bsp/device-tree/files/system-user.dtsi''':
<source lang = bash>
/* RTL8211E */
&gem0{
status = "okay";
phy-handle = <&phy1>;
phy-mode = "rgmii-id";
local-mac-address = [00 0a 35 00 22 01];

mdio {
status = "okay";
#address-cells = <1>;
#size-cells = <0>;

phy0: phy@1 {
status = "okay";
device_type = "ethernet-phy";
reg = <1>;
};
};
};

/*TI dp83867 */
&gem1{
status = "okay";
phy-handle = <&phy1>;
phy-mode = "rgmii-id";
local-mac-address = [00 0a 35 00 22 02];

xlnx,eth-mode = <0x1>;

mdio {
status = "okay";
#address-cells = <1>;
#size-cells = <0>;

phy1: phy@12 {
status = "okay";
compatible = "ethernet-phy-ieee802.3-c22";
device_type = "ethernet-phy";

reg = <12>;
ti,rx-internal-delay = <0x7>;
ti,tx-internal-delay = <0x7>;
ti,fifo-depth = <0x01>;
ti,min-output-impedance;
ti,dp83867-rxctrl-strap-quirk;
};
};
};

</source>

==== Два PHY ====
Пропатчено ядро для общей mdio. Mdio на Ethernet0 в Vivado, пины 52-53. Первый физик поднимается автоматически. Второй жив, пожнимается через:
<source lang = bash>
ifconfig eth1 192.168.0.231 netmask 255.255.255.0 up
</source>

'''<projectname>/project-spec/meta-user/recipes-bsp/device-tree/files/system-user.dtsi''':
<source lang = bash>
/ {
aliases {...}

chosen {...}

mdio {
compatible = "cdns,macb-mdio";
reg = <0xe000b000 0x1000>;
status = "okay";
clocks = <&clkc 30>, <&clkc 30>, <&clkc 13>;
clock-names = "pclk", "hclk", "tx_clk";
#address-cells = <1>;
#size-cells = <0>;

phy0: phy@1 {
compatible = "ethernet-phy-ieee802.3-c22";
device_type = "ethernet-phy";
reg = <1>;
status = "okay";
};

phy1: phy@12 {
compatible = "ethernet-phy-ieee802.3-c22";
device_type = "ethernet-phy";
reg = <12>;
status = "okay";
ti,rx-internal-delay = <0x7>;
ti,tx-internal-delay = <0x7>;
ti,fifo-depth = <0x01>;
ti,min-output-impedance;
ti,dp83867-rxctrl-strap-quirk;
};
};
};

&gem0{
status = "okay";
phy-handle = <&phy0>;
phy-mode = "rgmii-id";
local-mac-address = [00 0a 35 00 22 01];
};

&gem1{
status = "okay";
phy-handle = <&phy1>;
phy-mode = "rgmii";
local-mac-address = [00 0a 35 00 22 02];

xlnx,eth-mode = <0x1>;
};
</source>

=== QSPI Flash ===
На плате установлена не поддерживаемая (нету) по табличке W25Q512JVEIQ.

Флешка поднялась, причина - отсутствие резистора на QSPI_SCK_MODE4 - была закоротка на землю.

Пропатчил юбут, добавив в файл <projectname>/components/ext_sources/MY-U-BOOT/u-boot-xlnx/drivers/mtd/spi/spi_flash_ids.c флешку, и наложив патч:

'''0001-add-spi-support-for-w25q512jv.patch'''
<source lang = bash>
From 17ebfc83d3929446288d1143d33d8fbd156360d0 Mon Sep 17 00:00:00 2001
From: DneprovD <dneprov_dv@mail.ru>
Date: Thu, 20 Jun 2024 12:27:45 +0300
Subject: [PATCH] add spi support for w25q512jv

---
drivers/mtd/spi/spi_flash_ids.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/spi/spi_flash_ids.c b/drivers/mtd/spi/spi_flash_ids.c
index cb27c88..c3e725a 100644
--- a/drivers/mtd/spi/spi_flash_ids.c
+++ b/drivers/mtd/spi/spi_flash_ids.c
@@ -167,6 +167,7 @@ const struct spi_flash_info spi_flash_ids[] = {
{"w25q32dw", INFO(0xef6016, 0x0, 64 * 1024, 64, RD_FULL | WR_QPP | SECT_4K) },
{"w25q64dw", INFO(0xef6017, 0x0, 64 * 1024, 128, RD_FULL | WR_QPP | SECT_4K) },
{"w25q128fw", INFO(0xef6018, 0x0, 64 * 1024, 256, RD_FULL | WR_QPP | SECT_4K) },
+ {"w25q512jv", INFO(0xef4020, 0x0, 64 * 1024, 1024, RD_FULL | WR_QPP | SECT_4K) },
#endif
{}, /* Empty entry to terminate the list */
/*
--
1.9.1

</source>

В project-spec/meta-user/recipes-bsp/u-boot/files/platform-top.h добавил
<source lang=bash>
#define CONFIG_SPI_FLASH_WINBOND Y
</source>

[https://support.xilinx.com/s/article/50991?language=en_US Список поддерживаемых Zynq 7000 флешек и гайд что делать с неподдерживаемыми]

[https://support.xilinx.com/s/article/62743?language=en_US Гайд для неподдерживаемых]

[https://srns.ru/wiki/%D0%A4%D0%B0%D0%B9%D0%BB:QSPI_FLASH_support_guide_rev1.0.pdf Гайд по добавлению правок в U-boot]

[https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842262/Zynq+QSPI+Driver Zynq QSPI Driver на хилипедии]

==== Разметка QSPI ====

Делал так:

1) Идем в petalinux-config -> Subsystem AUTO Hardware Settings -> '''Flash Settings'''

Там задаем разделы флешки:
[[Файл:Qspi-partitions-KibiBytes.PNG|500px|right|thumb]]
<source lang=bash>
Primary Flash (ps7_qspi_0) --->
[ ] Advanced Flash Auto Configuration
*** partition 0 ***
(boot) name
(0x100000) size
*** partition 1 ***
(bootenv) name
(0x20000) size
*** partition 2 ***
(kernel) name
(0x1400000) size
*** partition 3 ***
(dtb) name
(0x20000) size
*** partition 4 ***
(rootfs) name
(0xA00000) size
*** partition 5 ***
(bitstream) name
(0x600000) size
*** partition 6 ***
(spare) name
(0x1AC0000) size
*** partition 7 ***
() name
</source>

Для наглядности накидал [https://openipc.org/tools/firmware-partitions-calculation?locale=ru на сайтике картинку]

2) Там же в petalinux-config -> Subsystem AUTO Hardware Settings -> '''Advanced bootable images storage Settings''' заходим в каждый пункт и выставляем
<source lang = bash>
image storage media
(X) primary flash

# в пункте для DTB на пробу поставил
(X) from boot image
</source>

После этого U-boot будет искать указанные файлы по указанным адресам на QSPI флешке при включенном режиме загрузки с QSPI флешки. Также это отразится на генерируемом файле юбута Petalinux/qspi/project-spec/meta-plnx-generated/recipes-bsp/u-boot/configs/platform-auto.h. Этот файл обновляется при вызове petalinux-config -c u-boot (вроде).

==== Прошивка QSPI ====

QSPI флешка прошивается из U-boot через sf probe, sf write.
Это же делает SDK, когда прошивается флешка через JTAG. SDK собирает свой юбут внутри себя, и им прошивает. Недостатком было то, что юбут из SDK не пропатчен на поддержку новой флешки, и он валится на обнаружении. Возможно, его можно пропатчить внутри SDK, я не пробовал.

Как прошивал:
# Собрал проект через petalinux-build.
# Положил все нужные файлы на sd-карту.
# Загрузился с sd-карты, зашел в u-boot.
# Из консоли U-boot выполнил:
<source lang=bash>
# подключаемся
> sf probe 0

# стираем области перед записью. Стирать можно маленькими разделами или всю флешку разом
> sf erase 0 0x1AC0000

# загружаем файлы в DDR и пишем их на флешку. Переменная filesize заполняется сама.
> fatload mmc 0 0x00100000 BOOT.bin
> sf write 0x00100000 0x0 ${filesize} #(DDR_address offset image_size)

> fatload mmc 0 0x00100000 image.ub
> sf write 0x00100000 0x120000 ${filesize}

и так далее
</source>

==== Работа с MTD ====

В операционке работать с разделами флешки можно через /proc/mtd. Для того, чтобы mtd драйвер увидел флешку, пришлось накатить на него патч.

<source lang=bash>
From 6a51554240c03a0dc0676fac0ab273bd7cf0c77f Mon Sep 17 00:00:00 2001
From: DneprovD <dneprov_dv@mail.ru>
Date: Tue, 12 Nov 2024 14:31:49 +0300
Subject: [PATCH] Add w25q512jvq support in mtd-spi-nor

---
drivers/mtd/spi-nor/spi-nor.c | 2 ++
1 file changed, 2 insertions(+)

diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 79194ec..91d6996 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -1336,6 +1336,8 @@ static int spi_nor_is_locked(struct mtd_info *mtd, loff_t ofs, uint64_t len)
{ "w25q128", INFO(0xef4018, 0, 64 * 1024, 256, SECT_4K| SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
{ "w25q256", INFO(0xef4019, 0, 64 * 1024, 512, SECT_4K| SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },

+ { "w25q512jvq", INFO(0xef4020, 0, 64 * 1024, 1024, SECT_4K| SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
+
/* Catalyst / On Semiconductor -- non-JEDEC */
{ "cat25c11", CAT25_INFO( 16, 8, 16, 1, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
{ "cat25c03", CAT25_INFO( 32, 8, 16, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
--
1.9.1

</source>

Изначально поддержки конкретно нашей флешки там нет вплоть до v2021.1. Простое добавление строки позволило mtd драйверу обнаруживать флешку, но запись в нее через flashcp работает с ошибками. Пока остановился на этом.

=== U-boot ===
==== Env ====
uEnv.txt - только для sd boot (захардкожено в u-boot-xlnx/include/configs/zynq-common.h).

Вроде бы можно [https://community.intel.com/t5/FPGA-SoC-And-CPLD-Boards-And/Unable-to-read-file-u-boot-scr/td-p/219580 обернуть юбутом (mkImage)] тектовый файл, и зашить в qspi. Не пробовал, вдруг не нужно.

{{Начало скрытого блока|Выравнивание_заголовка = left| Ссылка = left|Заголовок = Код стандартной env из zynq-common.h:}}
<source lang=bash>
/* Default environment */
#ifndef CONFIG_EXTRA_ENV_SETTINGS
#define CONFIG_EXTRA_ENV_SETTINGS \
"ethaddr=00:0a:35:00:01:22\0" \
"kernel_image=uImage\0" \
"kernel_load_address=0x2080000\0" \
"ramdisk_image=uramdisk.image.gz\0" \
"ramdisk_load_address=0x4000000\0" \
"devicetree_image=devicetree.dtb\0" \
"devicetree_load_address=0x2000000\0" \
"bitstream_image=system.bit.bin\0" \
"boot_image=BOOT.bin\0" \
"loadbit_addr=0x100000\0" \
"loadbootenv_addr=0x2000000\0" \
"kernel_size=0x500000\0" \
"devicetree_size=0x20000\0" \
"ramdisk_size=0x5E0000\0" \
"boot_size=0xF00000\0" \
"fdt_high=0x20000000\0" \
"initrd_high=0x20000000\0" \
"bootenv=uEnv.txt\0" \
"loadbootenv=load mmc 0 ${loadbootenv_addr} ${bootenv}\0" \
"importbootenv=echo Importing environment from SD ...; " \
"env import -t ${loadbootenv_addr} $filesize\0" \
"sd_uEnvtxt_existence_test=test -e mmc 0 /uEnv.txt\0" \
"preboot=if test $modeboot = sdboot && env run sd_uEnvtxt_existence_test; " \
"then if env run loadbootenv; " \
"then env run importbootenv; " \
"fi; " \
"fi; \0" \
"mmc_loadbit=echo Loading bitstream from SD/MMC/eMMC to RAM.. && " \
"mmcinfo && " \
"load mmc 0 ${loadbit_addr} ${bitstream_image} && " \
"fpga load 0 ${loadbit_addr} ${filesize}\0" \
"norboot=echo Copying Linux from NOR flash to RAM... && " \
"cp.b 0xE2100000 ${kernel_load_address} ${kernel_size} && " \
"cp.b 0xE2600000 ${devicetree_load_address} ${devicetree_size} && " \
"echo Copying ramdisk... && " \
"cp.b 0xE2620000 ${ramdisk_load_address} ${ramdisk_size} && " \
"bootm ${kernel_load_address} ${ramdisk_load_address} ${devicetree_load_address}\0" \
"qspiboot=echo Copying Linux from QSPI flash to RAM... && " \
"sf probe 0 0 0 && " \
"sf read ${kernel_load_address} 0x100000 ${kernel_size} && " \
"sf read ${devicetree_load_address} 0x600000 ${devicetree_size} && " \
"echo Copying ramdisk... && " \
"sf read ${ramdisk_load_address} 0x620000 ${ramdisk_size} && " \
"bootm ${kernel_load_address} ${ramdisk_load_address} ${devicetree_load_address}\0" \
"uenvboot=" \
"if run loadbootenv; then " \
"echo Loaded environment from ${bootenv}; " \
"run importbootenv; " \
"fi; " \
"if test -n $uenvcmd; then " \
"echo Running uenvcmd ...; " \
"run uenvcmd; " \
"fi\0" \
"sdboot=if mmcinfo; then " \
"run uenvboot; " \
"echo Copying Linux from SD to RAM... && " \
"load mmc 0 ${kernel_load_address} ${kernel_image} && " \
"load mmc 0 ${devicetree_load_address} ${devicetree_image} && " \
"load mmc 0 ${ramdisk_load_address} ${ramdisk_image} && " \
"bootm ${kernel_load_address} ${ramdisk_load_address} ${devicetree_load_address}; " \
"fi\0" \
"usbboot=if usb start; then " \
"run uenvboot; " \
"echo Copying Linux from USB to RAM... && " \
"load usb 0 ${kernel_load_address} ${kernel_image} && " \
"load usb 0 ${devicetree_load_address} ${devicetree_image} && " \
"load usb 0 ${ramdisk_load_address} ${ramdisk_image} && " \
"bootm ${kernel_load_address} ${ramdisk_load_address} ${devicetree_load_address}; " \
"fi\0" \
"nandboot=echo Copying Linux from NAND flash to RAM... && " \
"nand read ${kernel_load_address} 0x100000 ${kernel_size} && " \
"nand read ${devicetree_load_address} 0x600000 ${devicetree_size} && " \
"echo Copying ramdisk... && " \
"nand read ${ramdisk_load_address} 0x620000 ${ramdisk_size} && " \
"bootm ${kernel_load_address} ${ramdisk_load_address} ${devicetree_load_address}\0" \
"jtagboot=echo TFTPing Linux to RAM... && " \
"tftpboot ${kernel_load_address} ${kernel_image} && " \
"tftpboot ${devicetree_load_address} ${devicetree_image} && " \
"tftpboot ${ramdisk_load_address} ${ramdisk_image} && " \
"bootm ${kernel_load_address} ${ramdisk_load_address} ${devicetree_load_address}\0" \
"rsa_norboot=echo Copying Image from NOR flash to RAM... && " \
"cp.b 0xE2100000 0x100000 ${boot_size} && " \
"zynqrsa 0x100000 && " \
"bootm ${kernel_load_address} ${ramdisk_load_address} ${devicetree_load_address}\0" \
"rsa_nandboot=echo Copying Image from NAND flash to RAM... && " \
"nand read 0x100000 0x0 ${boot_size} && " \
"zynqrsa 0x100000 && " \
"bootm ${kernel_load_address} ${ramdisk_load_address} ${devicetree_load_address}\0" \
"rsa_qspiboot=echo Copying Image from QSPI flash to RAM... && " \
"sf probe 0 0 0 && " \
"sf read 0x100000 0x0 ${boot_size} && " \
"zynqrsa 0x100000 && " \
"bootm ${kernel_load_address} ${ramdisk_load_address} ${devicetree_load_address}\0" \
"rsa_sdboot=echo Copying Image from SD to RAM... && " \
"load mmc 0 0x100000 ${boot_image} && " \
"zynqrsa 0x100000 && " \
"bootm ${kernel_load_address} ${ramdisk_load_address} ${devicetree_load_address}\0" \
"rsa_jtagboot=echo TFTPing Image to RAM... && " \
"tftpboot 0x100000 ${boot_image} && " \
"zynqrsa 0x100000 && " \
"bootm ${kernel_load_address} ${ramdisk_load_address} ${devicetree_load_address}\0" \
DFU_ALT_INFO
#endif
</source>
{{Конец скрытого блока}}

Иван загружал clonicus.bit юбутом через Uboot.env. Вроде как можно вместо Uboot.env сделать uEnv.txt - на схожесть не проверял.

'''Иванова Uboot.env''' в текстовом редакторе после приведения в читаемый вид:
<source lang = bash>
<TіQautoload=yes
boot_dtb=fatload mmc 0 0x9000000 system.dtb
boot_image=fatload mmc 0 0xA000000 image.ub
bootcmd=run swdt_set && run fpga_config && run boot_image && run boot_dtb && bootm 0xA000000 0xA000000 0x9000000
bootdelay=1
ethaddr=00:0a:35:00:21:70
fdtcontroladdr=ffa91b0
fileaddr=100000
filesize=5b3f74
swdt_set=run swdt_ccr && run swdt_rst && run swdt_zmr
swdt_ccr=mw 0xf8005004 0x92063b
swdt_rst=mw 0xf8005008 0x1999
swdt_zmr=mw 0xf8005000 0xabc043
fpga_config=run load_bit && run pl_load
ipaddr=192.168.0.110
kernel_img=image.ub
load_bit=fatload mmc 0 0x100000 clonicus.bit
netmask=255.255.255.0
pl_load=fpga loadb 0 0x100000 0x1400000
serverip=192.168.0.1
</source>

==== Env to binary ====
В исходниках U-boot давно лежит утилита mkenvimage.c.
Пока что так и не попользовался ей.
https://bootlin.com/blog/mkenvimage-uboot-binary-env-generator/

Код Андрея по переводу текстового uEnv.txt в бинарный:
<source lang=python>
import zlib
import sys

if len(sys.argv) != 4:
sys.exit('args error!')

inputFilename = str(sys.argv[1])
outputFilename = str(sys.argv[2])
write_size = int(sys.argv[3])

with open(inputFilename, "r") as fid:
lines = [line for line in fid]

lines_zero = (''.join(lines)).replace('\n', '\0')
lines_zero = lines_zero + (write_size - len(lines_zero)) * '\0'
fbytes = lines_zero.encode()
fid.close()

crc = (zlib.crc32(fbytes)).to_bytes(4, byteorder='little')

file_contents = crc + fbytes

fid = open(outputFilename,"wb")
fid.write(file_contents)
fid.close()
</source>

==== U-boot patch ====

(!) При внесении изменений в юбут не забываем добавить коммент к версии в
<source lang=bash>
$ petalinux-config -c u-boot

General setup ->
Local version - append to U-Boot release
дописываем отличия версии, например, qspi
</source>

Попробовал пропатчить u-boot для добавления поддержки qspi флешки, которая не поддерживалась.

[https://docs.amd.com/v/u/2019.1-English/ug1144-petalinux-tools-reference-guide#page=107 Как сделать внешние исходники u-boot в проекте]

[https://devconnected.com/how-to-create-and-apply-git-patch-files/ Как делать git patch]

Методология создания патча для U-boot:
* Куда-то рядом или внутрь проекта в <projectname>/components/ext_sources/MY-U-BOOT/ скачивается [https://github.com/Xilinx/u-boot-xlnx/tree/xilinx-v2017.4 гит юбута].
* Переходим на ветку xilinx-v2017.4
<source lang = bash>
git checkout xilinx-v2017.4
</source>
* Создаем новую ветку mytest
<source lang = bash>
git checkout -b mytest
</source>
* Находим в исходниках файлик(и), в который хотим внести изменения. Вносим изменения. Коммитим в ветку mytest.
* Делаем файл патча относительно ветки xilinx-v2017.4, находясь в ветке mytest. В той папке, в которой вызываем команду, появится файл '''0001-<commit-mesg>.patch'''
<source lang = bash>
git format-patch xilinx-v2017.4
</source>
* Копируем файл 0001-<commit-mesg>.patch в <projectname>/project-spec/meta-user/recipes-bsp/u-boot/files/
* Добавляем в файл '''<projectname>/project-spec/meta-user/recipes-bsp/u-boot/u-boot-xlnx_%.bbappend''' строку с именем патча:
<source lang = bash>
SRC_URI_append = " file://0001-add-spi-support-for-w25q512jv.patch"
</source>
* Собираем
<source lang = bash>
petalinux-build -c u-boot
</source>

Для изменения стартового сообщения U-Boot 2017.01 (Jun 07...) идем в <projectname>/components/ext_sources/MY-U-BOOT/u-boot-xlnx/Makefile. В строке 5 есть VERSION, в строке 1280 сам вывод.
То же можно сделать где-то в petalinux конфигах / юбут конфигах, не залезая в исходники.

[[Категория:Zynq]]
[[Категория:EmbeddedLinux]]
[[Category:Clonicus]]

{{wl-publish: 2024-06-17 07:27:00 +00:00 | Dneprov D }}

Blog:DneprovD/17.06.2024 Clonicus 2.0

2025-12-12T06:08:42Z

Dneprov:

<summary hidden=true>
<center>[[File:IMG_20240621_134919.jpg|400px]]</center>
</summary>
//{{Форма2}}
__TOC__

== Косяки ==
=== DDR ===
На плате установлен 1 чип DDR3L MT41K128M16-107 на 256 МБ. В проекте вивадо достаточно было выбрать похожее устройство, тайминги были выставлены автоматически. Задержки по дорогам берутся из альтиума.

Память сначала отказывалась работать, повисала на калибровке WL. Потыкались осцилографом - проблема была в некачественной пайке.

[https://static.chipdip.ru/lib/911/DOC012911114.pdf Даташит на DDR]

[https://www.youtube.com/watch?v=W3Jt_y6PHjA&ab_channel=Phil%E2%80%99sLab Видео, какие тайминги откуда брать]

[https://docs.amd.com/v/u/en-US/ds191-XC7Z030-XC7Z045-data-sheet#page=17 Таблица20: максимальная скорость DDR в цинках]

=== SD Card ===
Были проблемы с подмонтированием разделов и ошибки чтения секторов. Проблема схемотехническая в обвязке и непонятном левелшифтере PI4ULS5V106.

=== Nomada ===
Припаян не тот кварц (выбран не с тем номиналом напряжения). Подтянут к нужному номиналу резистором.

== Заметки ==
=== Ethernet ===
(!) Для корректной работы желательно пересобирать u-boot при изменении девайстри, и boot.bin командой
<source lang="bash">
petalinux-package --boot --format BIN --fsbl ./zynq_fsbl.elf --u-boot --force
</source>
На плате есть 2 физика:
* К GEM0 подключен Realtek RTL8211E-VL-CG.
* К GEM1 подключен Texas Instruments DP83867.
* Шина MDIO общая, на пинах 52-53.

В Vivado включал отдельно только Ethernet0, только Ethernet1, оба сразу с MDIO на нулевом.

Каждый физик отдельно видится на мдио независимо от того, к Ethernet0 или Ethernet1 она подключена. В стандалоне тестах в sdk автосогласование проходят оба физика, тест их находит.

U-boot версии 2017.4 видит оба физика на мдио, но драйвер прикручивает только к первому по порядку в девайстри. Два сразу старый U-boot не умеет до версии 2018.1 (гуглится обсуждение).

При работе с двумя физиками рекомендуют накатить на ядро патч драйвера macb, чтобы он видел два физика. При этом раздел mdio {} в девайстри заработал только при помещении его в общую часть, там где {aliases, chosen}.

[https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841740/Macb+Driver Заметка на хиливики про Common MDIO DT Macb Driver]

[https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842475/PetaLinux+Yocto+Tips#PetaLinuxYoctoTips-PatchingtheLinuxKernelofaPetaLinuxProject Как патчить ядро]

[https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841740/Macb+Driver Пример девайстри с вики для двух PHY]

[https://support.xilinx.com/s/article/69132?language=en_US Оффициальный AR xilinx для dual PHY с патчами]

[https://support.xilinx.com/s/question/0D52E00006hpe3DSAQ/dual-ethernet-still-not-working-after-patching-macb-driver-petalinux-20172?language=en_US AR#1]

[https://support.xilinx.com/s/question/0D52E00007AMwsGSAT/how-to-fix-zynq7000-dual-ethernet-phy-on-single-mdio-bus-in-xilinxv20191-and-newer?language=en_US AR#2]

[https://support.xilinx.com/s/question/0D52E00006iHu9HSAS/dual-phys-on-mdioemio?language=en_US AR#3]

[https://support.xilinx.com/s/question/0D52E00007AMwsGSAT/how-to-fix-zynq7000-dual-ethernet-phy-on-single-mdio-bus-in-xilinxv20191-and-newer?language=en_US AR#4]

[https://support.xilinx.com/s/question/0D52E00006iHlW2SAK/zynq-dual-ethernet-question?language=en_US AR#5]

==== Один PHY ====
Рабочий devicetree для ядра без патча, один PHY (на выбор):

'''<projectname>/project-spec/meta-user/recipes-bsp/device-tree/files/system-user.dtsi''':
<source lang = bash>
/* RTL8211E */
&gem0{
status = "okay";
phy-handle = <&phy1>;
phy-mode = "rgmii-id";
local-mac-address = [00 0a 35 00 22 01];

mdio {
status = "okay";
#address-cells = <1>;
#size-cells = <0>;

phy0: phy@1 {
status = "okay";
device_type = "ethernet-phy";
reg = <1>;
};
};
};

/*TI dp83867 */
&gem1{
status = "okay";
phy-handle = <&phy1>;
phy-mode = "rgmii-id";
local-mac-address = [00 0a 35 00 22 02];

xlnx,eth-mode = <0x1>;

mdio {
status = "okay";
#address-cells = <1>;
#size-cells = <0>;

phy1: phy@12 {
status = "okay";
compatible = "ethernet-phy-ieee802.3-c22";
device_type = "ethernet-phy";

reg = <12>;
ti,rx-internal-delay = <0x7>;
ti,tx-internal-delay = <0x7>;
ti,fifo-depth = <0x01>;
ti,min-output-impedance;
ti,dp83867-rxctrl-strap-quirk;
};
};
};

</source>

==== Два PHY ====
Пропатчено ядро для общей mdio. Mdio на Ethernet0 в Vivado, пины 52-53. Первый физик поднимается автоматически. Второй жив, пожнимается через:
<source lang = bash>
ifconfig eth1 192.168.0.231 netmask 255.255.255.0 up
</source>

'''<projectname>/project-spec/meta-user/recipes-bsp/device-tree/files/system-user.dtsi''':
<source lang = bash>
/ {
aliases {...}

chosen {...}

mdio {
compatible = "cdns,macb-mdio";
reg = <0xe000b000 0x1000>;
status = "okay";
clocks = <&clkc 30>, <&clkc 30>, <&clkc 13>;
clock-names = "pclk", "hclk", "tx_clk";
#address-cells = <1>;
#size-cells = <0>;

phy0: phy@1 {
compatible = "ethernet-phy-ieee802.3-c22";
device_type = "ethernet-phy";
reg = <1>;
status = "okay";
};

phy1: phy@12 {
compatible = "ethernet-phy-ieee802.3-c22";
device_type = "ethernet-phy";
reg = <12>;
status = "okay";
ti,rx-internal-delay = <0x7>;
ti,tx-internal-delay = <0x7>;
ti,fifo-depth = <0x01>;
ti,min-output-impedance;
ti,dp83867-rxctrl-strap-quirk;
};
};
};

&gem0{
status = "okay";
phy-handle = <&phy0>;
phy-mode = "rgmii-id";
local-mac-address = [00 0a 35 00 22 01];
};

&gem1{
status = "okay";
phy-handle = <&phy1>;
phy-mode = "rgmii";
local-mac-address = [00 0a 35 00 22 02];

xlnx,eth-mode = <0x1>;
};
</source>

=== QSPI Flash ===
На плате установлена не поддерживаемая (нету) по табличке W25Q512JVEIQ.

Флешка поднялась, причина - отсутствие резистора на QSPI_SCK_MODE4 - была закоротка на землю.

Пропатчил юбут, добавив в файл <projectname>/components/ext_sources/MY-U-BOOT/u-boot-xlnx/drivers/mtd/spi/spi_flash_ids.c флешку, и наложив патч:

'''0001-add-spi-support-for-w25q512jv.patch'''
<source lang = bash>
From 17ebfc83d3929446288d1143d33d8fbd156360d0 Mon Sep 17 00:00:00 2001
From: DneprovD <dneprov_dv@mail.ru>
Date: Thu, 20 Jun 2024 12:27:45 +0300
Subject: [PATCH] add spi support for w25q512jv

---
drivers/mtd/spi/spi_flash_ids.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/spi/spi_flash_ids.c b/drivers/mtd/spi/spi_flash_ids.c
index cb27c88..c3e725a 100644
--- a/drivers/mtd/spi/spi_flash_ids.c
+++ b/drivers/mtd/spi/spi_flash_ids.c
@@ -167,6 +167,7 @@ const struct spi_flash_info spi_flash_ids[] = {
{"w25q32dw", INFO(0xef6016, 0x0, 64 * 1024, 64, RD_FULL | WR_QPP | SECT_4K) },
{"w25q64dw", INFO(0xef6017, 0x0, 64 * 1024, 128, RD_FULL | WR_QPP | SECT_4K) },
{"w25q128fw", INFO(0xef6018, 0x0, 64 * 1024, 256, RD_FULL | WR_QPP | SECT_4K) },
+ {"w25q512jv", INFO(0xef4020, 0x0, 64 * 1024, 1024, RD_FULL | WR_QPP | SECT_4K) },
#endif
{}, /* Empty entry to terminate the list */
/*
--
1.9.1

</source>

В project-spec/meta-user/recipes-bsp/u-boot/files/platform-top.h добавил
<source lang=bash>
#define CONFIG_SPI_FLASH_WINBOND Y
</source>

[https://support.xilinx.com/s/article/50991?language=en_US Список поддерживаемых Zynq 7000 флешек и гайд что делать с неподдерживаемыми]

[https://support.xilinx.com/s/article/62743?language=en_US Гайд для неподдерживаемых]

[https://srns.ru/wiki/%D0%A4%D0%B0%D0%B9%D0%BB:QSPI_FLASH_support_guide_rev1.0.pdf Гайд по добавлению правок в U-boot]

[https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842262/Zynq+QSPI+Driver Zynq QSPI Driver на хилипедии]

==== Разметка QSPI ====

Делал так:

1) Идем в petalinux-config -> Subsystem AUTO Hardware Settings -> '''Flash Settings'''

Там задаем разделы флешки:
[[Файл:Qspi-partitions-KibiBytes.PNG|500px|right|thumb]]
<source lang=bash>
Primary Flash (ps7_qspi_0) --->
[ ] Advanced Flash Auto Configuration
*** partition 0 ***
(boot) name
(0x100000) size
*** partition 1 ***
(bootenv) name
(0x20000) size
*** partition 2 ***
(kernel) name
(0x1400000) size
*** partition 3 ***
(dtb) name
(0x20000) size
*** partition 4 ***
(rootfs) name
(0xA00000) size
*** partition 5 ***
(bitstream) name
(0x600000) size
*** partition 6 ***
(spare) name
(0x1AC0000) size
*** partition 7 ***
() name
</source>

Для наглядности накидал [https://openipc.org/tools/firmware-partitions-calculation?locale=ru на сайтике картинку]

2) Там же в petalinux-config -> Subsystem AUTO Hardware Settings -> '''Advanced bootable images storage Settings''' заходим в каждый пункт и выставляем
<source lang = bash>
image storage media
(X) primary flash

# в пункте для DTB на пробу поставил
(X) from boot image
</source>

После этого U-boot будет искать указанные файлы по указанным адресам на QSPI флешке при включенном режиме загрузки с QSPI флешки. Также это отразится на генерируемом файле юбута Petalinux/qspi/project-spec/meta-plnx-generated/recipes-bsp/u-boot/configs/platform-auto.h. Этот файл обновляется при вызове petalinux-config -c u-boot (вроде).

==== Прошивка QSPI ====

QSPI флешка прошивается из U-boot через sf probe, sf write.
Это же делает SDK, когда прошивается флешка через JTAG. SDK собирает свой юбут внутри себя, и им прошивает. Недостатком было то, что юбут из SDK не пропатчен на поддержку новой флешки, и он валится на обнаружении. Возможно, его можно пропатчить внутри SDK, я не пробовал.

Как прошивал:
# Собрал проект через petalinux-build.
# Положил все нужные файлы на sd-карту.
# Загрузился с sd-карты, зашел в u-boot.
# Из консоли U-boot выполнил:
<source lang=bash>
# подключаемся
> sf probe 0

# стираем области перед записью. Стирать можно маленькими разделами или всю флешку разом
> sf erase 0 0x1AC0000

# загружаем файлы в DDR и пишем их на флешку. Переменная filesize заполняется сама.
> fatload mmc 0 0x00100000 BOOT.bin
> sf write 0x00100000 0x0 ${filesize} #(DDR_address offset image_size)

> fatload mmc 0 0x00100000 image.ub
> sf write 0x00100000 0x120000 ${filesize}

и так далее
</source>

==== Работа с MTD ====

В операционке работать с разделами флешки можно через /proc/mtd. Для того, чтобы mtd драйвер увидел флешку, пришлось накатить на него патч.

<source lang=bash>
From 6a51554240c03a0dc0676fac0ab273bd7cf0c77f Mon Sep 17 00:00:00 2001
From: DneprovD <dneprov_dv@mail.ru>
Date: Tue, 12 Nov 2024 14:31:49 +0300
Subject: [PATCH] Add w25q512jvq support in mtd-spi-nor

---
drivers/mtd/spi-nor/spi-nor.c | 2 ++
1 file changed, 2 insertions(+)

diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 79194ec..91d6996 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -1336,6 +1336,8 @@ static int spi_nor_is_locked(struct mtd_info *mtd, loff_t ofs, uint64_t len)
{ "w25q128", INFO(0xef4018, 0, 64 * 1024, 256, SECT_4K| SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
{ "w25q256", INFO(0xef4019, 0, 64 * 1024, 512, SECT_4K| SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },

+ { "w25q512jvq", INFO(0xef4020, 0, 64 * 1024, 1024, SECT_4K| SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
+
/* Catalyst / On Semiconductor -- non-JEDEC */
{ "cat25c11", CAT25_INFO( 16, 8, 16, 1, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
{ "cat25c03", CAT25_INFO( 32, 8, 16, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
--
1.9.1

</source>

Изначально поддержки конкретно нашей флешки там нет вплоть до v2021.1. Простое добавление строки позволило mtd драйверу обнаруживать флешку, но запись в нее через flashcp работает с ошибками. Пока остановился на этом.

=== U-boot ===
==== Env ====
uEnv.txt - только для sd boot (захардкожено в u-boot-xlnx/include/configs/zynq-common.h).

Вроде бы можно [https://community.intel.com/t5/FPGA-SoC-And-CPLD-Boards-And/Unable-to-read-file-u-boot-scr/td-p/219580 обернуть юбутом (mkImage)] тектовый файл, и зашить в qspi. Не пробовал, вдруг не нужно.

{{Начало скрытого блока|Выравнивание_заголовка = left| Ссылка = left|Заголовок = Код стандартной env из zynq-common.h:}}
<source lang=bash>
/* Default environment */
#ifndef CONFIG_EXTRA_ENV_SETTINGS
#define CONFIG_EXTRA_ENV_SETTINGS \
"ethaddr=00:0a:35:00:01:22\0" \
"kernel_image=uImage\0" \
"kernel_load_address=0x2080000\0" \
"ramdisk_image=uramdisk.image.gz\0" \
"ramdisk_load_address=0x4000000\0" \
"devicetree_image=devicetree.dtb\0" \
"devicetree_load_address=0x2000000\0" \
"bitstream_image=system.bit.bin\0" \
"boot_image=BOOT.bin\0" \
"loadbit_addr=0x100000\0" \
"loadbootenv_addr=0x2000000\0" \
"kernel_size=0x500000\0" \
"devicetree_size=0x20000\0" \
"ramdisk_size=0x5E0000\0" \
"boot_size=0xF00000\0" \
"fdt_high=0x20000000\0" \
"initrd_high=0x20000000\0" \
"bootenv=uEnv.txt\0" \
"loadbootenv=load mmc 0 ${loadbootenv_addr} ${bootenv}\0" \
"importbootenv=echo Importing environment from SD ...; " \
"env import -t ${loadbootenv_addr} $filesize\0" \
"sd_uEnvtxt_existence_test=test -e mmc 0 /uEnv.txt\0" \
"preboot=if test $modeboot = sdboot && env run sd_uEnvtxt_existence_test; " \
"then if env run loadbootenv; " \
"then env run importbootenv; " \
"fi; " \
"fi; \0" \
"mmc_loadbit=echo Loading bitstream from SD/MMC/eMMC to RAM.. && " \
"mmcinfo && " \
"load mmc 0 ${loadbit_addr} ${bitstream_image} && " \
"fpga load 0 ${loadbit_addr} ${filesize}\0" \
"norboot=echo Copying Linux from NOR flash to RAM... && " \
"cp.b 0xE2100000 ${kernel_load_address} ${kernel_size} && " \
"cp.b 0xE2600000 ${devicetree_load_address} ${devicetree_size} && " \
"echo Copying ramdisk... && " \
"cp.b 0xE2620000 ${ramdisk_load_address} ${ramdisk_size} && " \
"bootm ${kernel_load_address} ${ramdisk_load_address} ${devicetree_load_address}\0" \
"qspiboot=echo Copying Linux from QSPI flash to RAM... && " \
"sf probe 0 0 0 && " \
"sf read ${kernel_load_address} 0x100000 ${kernel_size} && " \
"sf read ${devicetree_load_address} 0x600000 ${devicetree_size} && " \
"echo Copying ramdisk... && " \
"sf read ${ramdisk_load_address} 0x620000 ${ramdisk_size} && " \
"bootm ${kernel_load_address} ${ramdisk_load_address} ${devicetree_load_address}\0" \
"uenvboot=" \
"if run loadbootenv; then " \
"echo Loaded environment from ${bootenv}; " \
"run importbootenv; " \
"fi; " \
"if test -n $uenvcmd; then " \
"echo Running uenvcmd ...; " \
"run uenvcmd; " \
"fi\0" \
"sdboot=if mmcinfo; then " \
"run uenvboot; " \
"echo Copying Linux from SD to RAM... && " \
"load mmc 0 ${kernel_load_address} ${kernel_image} && " \
"load mmc 0 ${devicetree_load_address} ${devicetree_image} && " \
"load mmc 0 ${ramdisk_load_address} ${ramdisk_image} && " \
"bootm ${kernel_load_address} ${ramdisk_load_address} ${devicetree_load_address}; " \
"fi\0" \
"usbboot=if usb start; then " \
"run uenvboot; " \
"echo Copying Linux from USB to RAM... && " \
"load usb 0 ${kernel_load_address} ${kernel_image} && " \
"load usb 0 ${devicetree_load_address} ${devicetree_image} && " \
"load usb 0 ${ramdisk_load_address} ${ramdisk_image} && " \
"bootm ${kernel_load_address} ${ramdisk_load_address} ${devicetree_load_address}; " \
"fi\0" \
"nandboot=echo Copying Linux from NAND flash to RAM... && " \
"nand read ${kernel_load_address} 0x100000 ${kernel_size} && " \
"nand read ${devicetree_load_address} 0x600000 ${devicetree_size} && " \
"echo Copying ramdisk... && " \
"nand read ${ramdisk_load_address} 0x620000 ${ramdisk_size} && " \
"bootm ${kernel_load_address} ${ramdisk_load_address} ${devicetree_load_address}\0" \
"jtagboot=echo TFTPing Linux to RAM... && " \
"tftpboot ${kernel_load_address} ${kernel_image} && " \
"tftpboot ${devicetree_load_address} ${devicetree_image} && " \
"tftpboot ${ramdisk_load_address} ${ramdisk_image} && " \
"bootm ${kernel_load_address} ${ramdisk_load_address} ${devicetree_load_address}\0" \
"rsa_norboot=echo Copying Image from NOR flash to RAM... && " \
"cp.b 0xE2100000 0x100000 ${boot_size} && " \
"zynqrsa 0x100000 && " \
"bootm ${kernel_load_address} ${ramdisk_load_address} ${devicetree_load_address}\0" \
"rsa_nandboot=echo Copying Image from NAND flash to RAM... && " \
"nand read 0x100000 0x0 ${boot_size} && " \
"zynqrsa 0x100000 && " \
"bootm ${kernel_load_address} ${ramdisk_load_address} ${devicetree_load_address}\0" \
"rsa_qspiboot=echo Copying Image from QSPI flash to RAM... && " \
"sf probe 0 0 0 && " \
"sf read 0x100000 0x0 ${boot_size} && " \
"zynqrsa 0x100000 && " \
"bootm ${kernel_load_address} ${ramdisk_load_address} ${devicetree_load_address}\0" \
"rsa_sdboot=echo Copying Image from SD to RAM... && " \
"load mmc 0 0x100000 ${boot_image} && " \
"zynqrsa 0x100000 && " \
"bootm ${kernel_load_address} ${ramdisk_load_address} ${devicetree_load_address}\0" \
"rsa_jtagboot=echo TFTPing Image to RAM... && " \
"tftpboot 0x100000 ${boot_image} && " \
"zynqrsa 0x100000 && " \
"bootm ${kernel_load_address} ${ramdisk_load_address} ${devicetree_load_address}\0" \
DFU_ALT_INFO
#endif
</source>
{{Конец скрытого блока}}

Иван загружал clonicus.bit юбутом через Uboot.env. Вроде как можно вместо Uboot.env сделать uEnv.txt - на схожесть не проверял.

'''Иванова Uboot.env''' в текстовом редакторе после приведения в читаемый вид:
<source lang = bash>
<TіQautoload=yes
boot_dtb=fatload mmc 0 0x9000000 system.dtb
boot_image=fatload mmc 0 0xA000000 image.ub
bootcmd=run swdt_set && run fpga_config && run boot_image && run boot_dtb && bootm 0xA000000 0xA000000 0x9000000
bootdelay=1
ethaddr=00:0a:35:00:21:70
fdtcontroladdr=ffa91b0
fileaddr=100000
filesize=5b3f74
swdt_set=run swdt_ccr && run swdt_rst && run swdt_zmr
swdt_ccr=mw 0xf8005004 0x92063b
swdt_rst=mw 0xf8005008 0x1999
swdt_zmr=mw 0xf8005000 0xabc043
fpga_config=run load_bit && run pl_load
ipaddr=192.168.0.110
kernel_img=image.ub
load_bit=fatload mmc 0 0x100000 clonicus.bit
netmask=255.255.255.0
pl_load=fpga loadb 0 0x100000 0x1400000
serverip=192.168.0.1
</source>

==== Env to binary ====
В исходниках U-boot давно лежит утилита mkenvimage.c.
Пока что так и не попользовался ей.
https://bootlin.com/blog/mkenvimage-uboot-binary-env-generator/

Код Андрея по переводу текстового uEnv.txt в бинарный:
<source lang=python>
import zlib
import sys

if len(sys.argv) != 4:
sys.exit('args error!')

inputFilename = str(sys.argv[1])
outputFilename = str(sys.argv[2])
write_size = int(sys.argv[3])

with open(inputFilename, "r") as fid:
lines = [line for line in fid]

lines_zero = (''.join(lines)).replace('\n', '\0')
lines_zero = lines_zero + (write_size - len(lines_zero)) * '\0'
fbytes = lines_zero.encode()
fid.close()

crc = (zlib.crc32(fbytes)).to_bytes(4, byteorder='little')

file_contents = crc + fbytes

fid = open(outputFilename,"wb")
fid.write(file_contents)
fid.close()
</source>

==== U-boot patch ====

(!) При внесении изменений в юбут не забываем добавить коммент к версии в
<source lang=bash>
$ petalinux-config -c u-boot

General setup ->
Local version - append to U-Boot release
дописываем отличия версии, например, qspi
</source>

Попробовал пропатчить u-boot для добавления поддержки qspi флешки, которая не поддерживалась.

[https://docs.amd.com/v/u/2019.1-English/ug1144-petalinux-tools-reference-guide#page=107 Как сделать внешние исходники u-boot в проекте]

[https://devconnected.com/how-to-create-and-apply-git-patch-files/ Как делать git patch]

Методология создания патча для U-boot:
* Куда-то рядом или внутрь проекта в <projectname>/components/ext_sources/MY-U-BOOT/ скачивается [https://github.com/Xilinx/u-boot-xlnx/tree/xilinx-v2017.4 гит юбута].
* Переходим на ветку xilinx-v2017.4
<source lang = bash>
git checkout xilinx-v2017.4
</source>
* Создаем новую ветку mytest
<source lang = bash>
git checkout -b mytest
</source>
* Находим в исходниках файлик(и), в который хотим внести изменения. Вносим изменения. Коммитим в ветку mytest.
* Делаем файл патча относительно ветки xilinx-v2017.4, находясь в ветке mytest. В той папке, в которой вызываем команду, появится файл '''0001-<commit-mesg>.patch'''
<source lang = bash>
git format-patch xilinx-v2017.4
</source>
* Копируем файл 0001-<commit-mesg>.patch в <projectname>/project-spec/meta-user/recipes-bsp/u-boot/files/
* Добавляем в файл '''<projectname>/project-spec/meta-user/recipes-bsp/u-boot/u-boot-xlnx_%.bbappend''' строку с именем патча:
<source lang = bash>
SRC_URI_append = " file://0001-add-spi-support-for-w25q512jv.patch"
</source>
* Собираем
<source lang = bash>
petalinux-build -c u-boot
</source>

Для изменения стартового сообщения U-Boot 2017.01 (Jun 07...) идем в <projectname>/components/ext_sources/MY-U-BOOT/u-boot-xlnx/Makefile. В строке 5 есть VERSION, в строке 1280 сам вывод.
То же можно сделать где-то в petalinux конфигах / юбут конфигах, не залезая в исходники.

[[Категория:Zynq]]
[[Категория:EmbeddedLinux]]
[[Category:Clonicus]]

{{wl-publish: 2024-06-17 07:27:00 +00:00 | Dneprov D }}

R&S SMBV100B S/N 100917 (прибор)

2025-05-16T07:33:08Z

Dneprov:

{{Форма3}}

<noinclude>Векторный генератор сигналов [[SMBV_(серия приборов)|SMBV]]100B.

{{Карточка Инвентарная единица
|название = SMBV 100B
|серийный номер = 100917
|инвентарный номер = -
|изображение = Файл:100917_SMBV.jpg
|подпись =
|тип = Векторный генератор сигналов
|производитель = Rohde & Schwarz
|серия = [[SMBV]]
|год производства =
|год приобретения =
|аудитория приписки = -
|фактическое местоположение = Е-615
|входит де-юре =
|входит де-факто =
|ссылки =
}}

[[file:QRCode RS SMBV100B SN 100917.jpg|thumb|Ссылка на эту страницу]]

<gallery>
Image:100917_SMBV100B_front.jpeg
Image:100917_SMBV100B_back.jpeg
</gallery>
</noinclude>{|table class="wikitable collapsible collapsed"
! colspan ="3"| [[R&S SMBV100B S/N 100917 (прибор)|R&S SMBV100B S/N 100917]]  
|-
! Индекс опции
! Наименование
! Примечание

|-
| SMBVB-K31
| '''High output power'''
| Высокая выходная мощность

|-
| SMBVB-K511
| '''Memory extension''' for ARB(up to 512 MS) for R&S®SMBV100B (software license)
| Расширение памяти

|-
| SMBVB-K520
| '''Baseband realtime extension''' for R&S®SMBV100B
| Расширение полосы частот в реальном времени

|-
| SMBVB-K62
| '''Additional white Gaussian noise''' for R&S®SMBV100B(software license)
| Аддитивный белый Гауссовский шум

|-
| SMBVB-K136
| '''Add 6 GNSS channels'''(increase the number of available GNSS channels by 6), at least one of the following options required: K44, K66, K94, K97, K98, K107, K132 (software license)
| Добавляет 6 ГНСС каналов

|-
| SMBVB-K137
| '''Add 12 GNSS channels'''(increase the number of available GNSS channels by 12), at least one of the following options required: K44, K66, K94, K97, K98, K107, K132 (software license)
| Добавляет 12 ГНСС каналов

|-
| SMBVB-K44
| '''GPS''' (6 SVs) for R&S®SMBV100B R&S®SMBVB-K520
| -

|-
| SMBVB-K66
| '''GALILEO''' (6 SVs) for R&S®SMBV100B R&S®SMBVB-K520 required (software license)
| -

|-
| SMBVB-K94
| '''GLONASS''' (6 SVs) for R&S®SMBV100B R&S®SMBVB-K520 required (software license)
| -

|-
| SMBVB-K98
| '''Modernized GPS''' (6 SVs) for R&S®SMBV100B R&S®SMBVB-K520
| Модернизированный GPS

|-
| SMBVB-K106
| '''SBAS/QZSS''' for R&S®SMBV100B R&S®SMBV-K44 required (software license)
| -

|-
| SMBVB-K107
| '''BeiDou''' (6 SVs) for R&S®SMBV100B R&S®SMBVB-K520 required (software license)
| -

|-
| SMBVB-K134
| '''Upgrade to dual-frequency GNSS''' (at least one of the GNSS base options K44,K66,K94,K98, K107
| Обновление до двухчастотной ГНСС

|-
| SMBVB-K135
| '''Upgrade to triple-frequency GNSS''' (K134 required)(software license)
| Обновление до трехчастотной ГНСС
|}<noinclude>
[[Категория:Экземпляры приборов]]</noinclude>

MCR

2023-09-20T13:39:11Z

Dneprov: /* Руководство по эксплуатации */

{{Форма3}}
{{НАП
|Модель = MultiChannel Receiver
|Сущность = [[фронтенд]], многочастотный приемник
|Фотография = [[Файл:MCR_raw.png|300px]]
|Назначение = линейный фронтенд
|Навигационные сигналы =
GPS L1, L2<br>
ГЛОНАСС L1, L2
|Первые образцы = 2014 г в рамках СЧ ОКР "Сантиметр-М"
|Начало продаж =
|Разработчик = [[Advantex]] (каф. РПУ МЭИ) + УИЦ СРТТ (в цифровой части)
|Производитель = Корпус фирмы [https://schroff.pentair.com/en/schroff-apac/Ratiopac-PRO Schroff]


|Родственные модели =
|Модификации =


|Энергопотребление =
|Номинал напряжения питания =


|Размеры =
|Масса =


|Чувствительность coldstart =
|Чувствительность navigation =
|Время coldstart =
|Время warmstart =
|Время hotstart =
|Перезахват =


|Точность плановых координат =
|Точность высоты =
|Точность скорости =
|Точность времени =


|Рекомендуемый антенный модуль =
|Дополнительно об антмодуле =
|Антенный элемент =
|Диапазон частот антмодуля =
|Ку антенны =
|Кэ антенны =
|Питание антенного модуля =
|Ку МШУ =
|Кш МШУ =
|Выходной импеданс антмодуля =
|КСВН выхода антмодуля =
|Интерфейс антмодуля =


|Динамический диапазон = [[Измерение_SINAD_ящика_AVDNов|39-55 дБ]]
|Кш фронтенда = 11 дБ
|Число промежуточных частот = 2
|АРУ =
|Нижняя промежуточная частота =


|Разрядность АЦП =
|Частота дискретизации =


|Машина быстрого поиска =
|Число эквивалентных корреляторов=


|Исполнение коррелятора =
|Число каналов коррелятора =
|Коррелятор и многолучевость =
|Темп работы =


|Этапность алгоритмов слежения =
|Слежение за частотой =
|Оценка задержки =
|Оценка частоты =
|Оценка фазы =
|Оценка амплитуды =
|Оценка шума =
|Выделение НИ =


|Темп решения навзадачи =
|Описание решения навзадачи =
|Расчет скорости потребителя =
|Расчет времени потребителя =
|Расчет ориентации потребителя =
|Разрешение неоднозначности =
}}

'''MCR''' (''MultiChannel Receiver'') - макетный образец прецизионного навигационного приемника или его аналого-коробочная часть.

== Интерфейс ==

== Основные рабочие характеристики ==

=== Степень линейности ===

=== Потребление ===

=== Усиление ===

=== Полоса ===

=== Опорный генератор ===

== Интересные факты ==

== Настройка ==
=== Через RealTerm ===
* Настройка каналов фронтенда (по Profilic COM, командами SCPI).
** Параметры порта: 115200, 8 bit, no parity.
** *IDN? - проверка подключения, возвращает ID прибора.
** Если MCR не отвечает на команды, следует проверить посылку в конце команд EOL (End of Line), данная опция может быть отключена у терминала.
** Команды управления частотой, усилением и пр., а также различные данные о приборе содержатся в руководстве по эксплуатации (см. далее).
[[File:20160824_realterm_send_options_for_MCR.png|400px]]
* Истинное значение параметра DEM: GAIN (коэффициент усиления) при записанном 63 дБ равно 41 дБ ! Требуется проверять для каждого фронтенда.

=== Через MATLAB ===

Устали мы через Realterm настраивать. Сделали свою программу настройки. Работает из Windows. Как и для Realterm, нужно подключить usb-rs преобразователь.

[[File:MCR_gui.PNG|400px]]

Программа умеет:
* Соединять с прибором автоматически по нажатию любой большой кнопки.
* Узнать, что там у MCR сейчас настроено. Кнопка '''Check MCR'''.
* Настроить MCR на частотные планы под кодовыми названиями SPP и SRTT. Кнопки '''SPP''' и '''SRTT''' соответственно.
* Сделать сброс (команда *RST). Кнопка '''RESET'''.
* Сохранить текущие настройки (команда SAVE:CURRENT). Кнопка '''SAVE'''.
* Вручную настроить некоторые параметры соответствующими кнопками.

== Прошивка ==

Есть возможность прошивать MCR в части блока управления. Нужно это для точной установки кода частоты (FTW) в DDS синтезатора тактового сигнала. Подробнее см. [[Blog:Korogodin/28.07.16 Очередная смена частотного плана|тут]].

Файлы и инструкции по прошивке лежат в архиве [[Media:MCR_MCU.zip|MCR_MCU]].

== Частотный план ==

'''UPD 04.03.2020.'''

Просто абы-какой частотный план ставить низя. Нужно учесть некоторые ограничения и по клокам и по значениям гетеродинов. Изначально о них написано [[Blog:Korogodin/28.07.16 Очередная смена частотного плана|тут]]. Чуть позже проведена дополнительная доработка матлаб-скрипта и рассмотрен вариант приема L2+L3 на один и тот же канал демодулятора, там наиболее актуальное состояние вопроса с частотным планом и там же свежий матлаб-скрипт с учетом L3. [[Blog:DneprovV/04.03.2020_Отладка_трансивера_-_весна_2020#Частотный план в MCR|Об этом здесь.]]

'''OLD'''

Иногда приходится настраивать в MCR и fpga.cpp новые промежуточные частоты. Для их удобного расчета сделан матлаб-скрипт. Ему надо рассказать, какая у нас тактовая частота. Он сам проверит, сможет ли синтезатор сделать такую частоту. Частоты гетеродинов рассчитываются по формуле для дробно-переменного делителя частоты ([[Blog:Korogodin/28.07.16 Очередная смена частотного плана|как тут]]). Но можно и ручками задать.

Скачать [[Media:20161115_MCR_IF_freq.rar|матлаб-скрипт]].

== Протоколы испытаний ==
При передаче изделий были проведены измерения основных парметров РЧБ. Чтобы не потерять, вот протоколы:

1. [[Media:Протокол 1 MCR.pdf|Протокол испытаний одного из опытных образцов MCR]]

2. [[Media:Протокол 2 MCR.pdf|Пока не установлено чей протокол + парочка страниц потеряна]]

== Руководство по эксплуатации ==

[[Media:20160729_РЭ_рчб_ред2.pdf|Руководство PDF.]]

[[Media:20150112 РЭ рчб_ред2.doc|Руководство DOC.]]

[[Media:DSG3_Manual.pdf|Руководство по синтезатору частот DSG3 PDF.]]

[[Media:MCR_DEM.jpeg| Схема приемного модуля (где I, где Q). Прислал Петр Бобкович.]]

'''Как подключать шлейфы питания / управления на плате управления MCR.'''

Счет разъемов начинается от линий питания (коннекторы с одного из торцов платы)

#define SPI_MUX_SYN 0x10 - синтезатор разъем 1 (XP6)
#define SPI_MUX_DEM1 0x16- дем 1600 разъем 6 (XP9)
#define SPI_MUX_DEM2 0x15- дем 1200 разъем 7 (XP11)
#define SPI_MUX_DEM3 0x13- дем 1200 разъем 4 (XP14)

[[Категория: RF]]
[[Категория: Фронтенд]]

R&S BBA150-D30 S/N 103501 (прибор)

2023-06-09T14:35:12Z

Dneprov:

<noinclude>Широкополосный усилитель R&S BBA

{{Карточка Инвентарная единица
|название = BBA150-D30
|серийный номер = 103501
|инвентарный номер = 210124000315
|изображение = Файл:photo_2022-02-04_12-18-41.jpg
|подпись =
|тип = Широкополосный усилитель
|производитель = Rohde & Schwarz
|серия = [[BBA]]
|год производства =
|год приобретения = 2019
|числится за = [[УИЦ СРТТ]]
|аудитория приписки = З-408-1
|фактическое местоположение = E-615
|входит де-юре =
|входит де-факто =
|ссылки =
}}

[[file:QRCode R&S BBA150-D30 103501.jpg|thumb|Ссылка на эту страницу]]
<gallery>
Image:210124000315_BBA.jpg
Image:210124000315_BBA_2.jpg
</gallery>

[[Media:BBA150_man_v6_rus.pdf | МАНУАЛ на прибор]]

[[Категория:Экземпляры приборов]]</noinclude>

R&S BBA150-D30 S/N 103501 (прибор)

2023-06-09T14:34:36Z

Dneprov:

<noinclude>Широкополосный усилитель R&S BBA

{{Карточка Инвентарная единица
|название = BBA150-D30
|серийный номер = 103501
|инвентарный номер = 210124000315
|изображение = Файл:photo_2022-02-04_12-18-41.jpg
|подпись =
|тип = Широкополосный усилитель
|производитель = Rohde & Schwarz
|серия = [[BBA]]
|год производства =
|год приобретения = 2019
|числится за = [[УИЦ СРТТ]]
|аудитория приписки = З-408-1
|фактическое местоположение = E-615
|входит де-юре =
|входит де-факто =
|ссылки =
}}

[[file:QRCode R&S BBA150-D30 103501.jpg|thumb|Ссылка на эту страницу]]
<gallery>
Image:210124000315_BBA.jpg
Image:210124000315_BBA_2.jpg
</gallery>

[[File:BBA150_man_v6_rus.pdf | МАНУАЛ на прибор]]

[[Категория:Экземпляры приборов]]</noinclude>

R&S BBA150-D30 S/N 103501 (прибор)

2023-06-09T14:34:19Z

Dneprov:

R&S BBA150-D30 S/N 103501 (прибор)

2023-06-09T14:33:34Z

Dneprov:

<noinclude>Широкополосный усилитель R&S BBA

{{Карточка Инвентарная единица
|название = BBA150-D30
|серийный номер = 103501
|инвентарный номер = 210124000315
|изображение = Файл:photo_2022-02-04_12-18-41.jpg
|подпись =
|тип = Широкополосный усилитель
|производитель = Rohde & Schwarz
|серия = [[BBA]]
|год производства =
|год приобретения = 2019
|числится за = [[УИЦ СРТТ]]
|аудитория приписки = З-408-1
|фактическое местоположение = E-615
|входит де-юре =
|входит де-факто =
|ссылки =
}}

[[file:QRCode R&S BBA150-D30 103501.jpg|thumb|Ссылка на эту страницу]]
<gallery>
Image:210124000315_BBA.jpg
Image:210124000315_BBA_2.jpg
</gallery>

МАНУАЛ на прибор [[File:BBA150_man_v6_rus.pdf]]

[[Категория:Экземпляры приборов]]</noinclude>

Файл:BBA150 man v6 rus.pdf

2023-06-09T14:32:11Z

Dneprov: MsUpload

MsUpload

MCR

2022-11-10T08:02:13Z

Dneprov: /* Руководство по эксплуатации */

{{Форма3}}
{{НАП
|Модель = MultiChannel Receiver
|Сущность = [[фронтенд]], многочастотный приемник
|Фотография = [[Файл:MCR_raw.png|300px]]
|Назначение = линейный фронтенд
|Навигационные сигналы =
GPS L1, L2<br>
ГЛОНАСС L1, L2
|Первые образцы = 2014 г в рамках СЧ ОКР "Сантиметр-М"
|Начало продаж =
|Разработчик = [[Advantex]] (каф. РПУ МЭИ) + УИЦ СРТТ (в цифровой части)
|Производитель = Корпус фирмы [https://schroff.pentair.com/en/schroff-apac/Ratiopac-PRO Schroff]


|Родственные модели =
|Модификации =


|Энергопотребление =
|Номинал напряжения питания =


|Размеры =
|Масса =


|Чувствительность coldstart =
|Чувствительность navigation =
|Время coldstart =
|Время warmstart =
|Время hotstart =
|Перезахват =


|Точность плановых координат =
|Точность высоты =
|Точность скорости =
|Точность времени =


|Рекомендуемый антенный модуль =
|Дополнительно об антмодуле =
|Антенный элемент =
|Диапазон частот антмодуля =
|Ку антенны =
|Кэ антенны =
|Питание антенного модуля =
|Ку МШУ =
|Кш МШУ =
|Выходной импеданс антмодуля =
|КСВН выхода антмодуля =
|Интерфейс антмодуля =


|Динамический диапазон = [[Измерение_SINAD_ящика_AVDNов|39-55 дБ]]
|Кш фронтенда = 11 дБ
|Число промежуточных частот = 2
|АРУ =
|Нижняя промежуточная частота =


|Разрядность АЦП =
|Частота дискретизации =


|Машина быстрого поиска =
|Число эквивалентных корреляторов=


|Исполнение коррелятора =
|Число каналов коррелятора =
|Коррелятор и многолучевость =
|Темп работы =


|Этапность алгоритмов слежения =
|Слежение за частотой =
|Оценка задержки =
|Оценка частоты =
|Оценка фазы =
|Оценка амплитуды =
|Оценка шума =
|Выделение НИ =


|Темп решения навзадачи =
|Описание решения навзадачи =
|Расчет скорости потребителя =
|Расчет времени потребителя =
|Расчет ориентации потребителя =
|Разрешение неоднозначности =
}}

'''MCR''' (''MultiChannel Receiver'') - макетный образец прецизионного навигационного приемника или его аналого-коробочная часть.

== Интерфейс ==

== Основные рабочие характеристики ==

=== Степень линейности ===

=== Потребление ===

=== Усиление ===

=== Полоса ===

=== Опорный генератор ===

== Интересные факты ==

== Настройка ==
=== Через RealTerm ===
* Настройка каналов фронтенда (по Profilic COM, командами SCPI).
** Параметры порта: 115200, 8 bit, no parity.
** *IDN? - проверка подключения, возвращает ID прибора.
** Если MCR не отвечает на команды, следует проверить посылку в конце команд EOL (End of Line), данная опция может быть отключена у терминала.
** Команды управления частотой, усилением и пр., а также различные данные о приборе содержатся в руководстве по эксплуатации (см. далее).
[[File:20160824_realterm_send_options_for_MCR.png|400px]]
* Истинное значение параметра DEM: GAIN (коэффициент усиления) при записанном 63 дБ равно 41 дБ ! Требуется проверять для каждого фронтенда.

=== Через MATLAB ===

Устали мы через Realterm настраивать. Сделали свою программу настройки. Работает из Windows. Как и для Realterm, нужно подключить usb-rs преобразователь.

[[File:MCR_gui.PNG|400px]]

Программа умеет:
* Соединять с прибором автоматически по нажатию любой большой кнопки.
* Узнать, что там у MCR сейчас настроено. Кнопка '''Check MCR'''.
* Настроить MCR на частотные планы под кодовыми названиями SPP и SRTT. Кнопки '''SPP''' и '''SRTT''' соответственно.
* Сделать сброс (команда *RST). Кнопка '''RESET'''.
* Сохранить текущие настройки (команда SAVE:CURRENT). Кнопка '''SAVE'''.
* Вручную настроить некоторые параметры соответствующими кнопками.

== Прошивка ==

Есть возможность прошивать MCR в части блока управления. Нужно это для точной установки кода частоты (FTW) в DDS синтезатора тактового сигнала. Подробнее см. [[Blog:Korogodin/28.07.16 Очередная смена частотного плана|тут]].

Файлы и инструкции по прошивке лежат в архиве [[Media:MCR_MCU.zip|MCR_MCU]].

== Частотный план ==

'''UPD 04.03.2020.'''

Просто абы-какой частотный план ставить низя. Нужно учесть некоторые ограничения и по клокам и по значениям гетеродинов. Изначально о них написано [[Blog:Korogodin/28.07.16 Очередная смена частотного плана|тут]]. Чуть позже проведена дополнительная доработка матлаб-скрипта и рассмотрен вариант приема L2+L3 на один и тот же канал демодулятора, там наиболее актуальное состояние вопроса с частотным планом и там же свежий матлаб-скрипт с учетом L3. [[Blog:DneprovV/04.03.2020_Отладка_трансивера_-_весна_2020#Частотный план в MCR|Об этом здесь.]]

'''OLD'''

Иногда приходится настраивать в MCR и fpga.cpp новые промежуточные частоты. Для их удобного расчета сделан матлаб-скрипт. Ему надо рассказать, какая у нас тактовая частота. Он сам проверит, сможет ли синтезатор сделать такую частоту. Частоты гетеродинов рассчитываются по формуле для дробно-переменного делителя частоты ([[Blog:Korogodin/28.07.16 Очередная смена частотного плана|как тут]]). Но можно и ручками задать.

Скачать [[Media:20161115_MCR_IF_freq.rar|матлаб-скрипт]].

== Протоколы испытаний ==
При передаче изделий были проведены измерения основных парметров РЧБ. Чтобы не потерять, вот протоколы:

1. [[Media:Протокол 1 MCR.pdf|Протокол испытаний одного из опытных образцов MCR]]

2. [[Media:Протокол 2 MCR.pdf|Пока не установлено чей протокол + парочка страниц потеряна]]

== Руководство по эксплуатации ==

[[Media:20160729_РЭ_рчб_ред2.pdf|Руководство PDF.]]

[[Media:20150112 РЭ рчб_ред2.doc|Руководство DOC.]]

[[Media:DSG3_Manual.pdf|Руководство по синтезатору частот DSG3 PDF.]]

[[Media:MCR_DEM.jpeg| Схема приемного модуля (где I, где Q). Прислал Петр Бобкович.]]

Как подключать шлейфы питания / управления на плате управления MCR.

Счет разъемов начинается от линий питания (коннекторы с одного из торцов платы)

#define SPI_MUX_SYN 0x10 - синтезатор разъем 1 (XP6)
#define SPI_MUX_DEM1 0x16- дем 1600 разъем 6 (XP9)
#define SPI_MUX_DEM2 0x15- дем 1200 разъем 7 (XP11)
#define SPI_MUX_DEM3 0x13- дем 1200 разъем 4 (XP14)

[[Категория: RF]]
[[Категория: Фронтенд]]

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

2022-07-20T13:06:24Z

Dneprov: /* 2020.07.28 - План по устранению проблем в платах АЦП и Oryx */

<summary [ hidden ]>

Записи о текущих испытаниях Орикса, Клоникуса и т.п.
</summary>

{{Форма3}}

{{TOCright}}

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

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

Желательно записывать следующие данные:
* дату испытания (в заголовке);
* номер ревизии 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 минут работы:
[[image:Screenshot_20200605_131702.png|center]]

Плотность отправки пакетов:
[[image:Screenshot_20200605_132120.png|center]]

Наибольшую плотность создает отправка эфемерид каждый 30 секунд, несколько десятков пакетов (сотня-две при полной нагрузке):
[[image:20200506_enp4s0_001.png|center]]

При этом достигается пиковая скорость 5кбайт/мс (50 при экстраполяции на полную нагрузку):
[[image:20200506_enp4s0_002.png|center]]



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

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

Измерения от 12 спутников отправляются раз в секунду в пакете 0xF5, 12 спутников занимают порядка 400 байт:
[[image:20200506_enp4s0_003.png|center]]

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

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

== 2020.07.21 - Очередные мучения с PPS OUT в ККН ==

* номер ревизии PL: [https://gitlab.srns.ru:8080/git/src/commit/2c9bf757016cb7796a6188fce514a494d92cdad8 | 2c9bf757]
* номер ревизии PS: [https://gitlab.srns.ru:8080/git/src/commit/fc467aa0d30a6d5f54445cc8153944d2d3d9dd0e | fc467aa0]
* номер ревизии PL южного моста: [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/f695100df9f88f713932f8daeabf75aa352c1d1c | f695100d]
* номер ревизии PL платы АЦП: [https://gitlab.srns.ru:8080/git/adc_rev3/commit/0a0015868fb8a8914e0abed88c4ec5603d6eeb7b | 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: [https://gitlab.srns.ru:8080/git/src/commit/2c9bf757016cb7796a6188fce514a494d92cdad8 | 2c9bf757]
* номер ревизии PS: [https://gitlab.srns.ru:8080/git/src/commit/fc467aa0d30a6d5f54445cc8153944d2d3d9dd0e | fc467aa0]
* номер ревизии PL южного моста: [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/f695100df9f88f713932f8daeabf75aa352c1d1c | f695100d]
* номер ревизии PL платы АЦП: [https://gitlab.srns.ru:8080/git/adc_rev3/commit/0a0015868fb8a8914e0abed88c4ec5603d6eeb7b | 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.

[[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.
** сделано в коммите [https://gitlab.srns.ru:8080/git/adc_rev3/commit/558992d20fd15d5e92f8031fcea4fbed1cd9d225 | 558992d2]
* Поднять обратно 3-ю АЦП.
** сделано в коммите [https://gitlab.srns.ru:8080/git/adc_rev3/commit/2c6556f0588640dd321f68038dc4066e37c2f80f | 2c6556f0]
** UPD 20.07.2022 в качестве gclk по-прежнему используется фрэйм 3 АЦП. Т.к. фрэймы для синхронизации 3 АЦП отжали, она синхронизируется в microblaze при помощи встроенных в АЦП паттернов.
* Завести синхросигнал SYNC с помощью делителей на 3 микросхемы АЦП.
** сделано в коммите [https://gitlab.srns.ru:8080/git/adc_rev3/commit/2c6556f0588640dd321f68038dc4066e37c2f80f | 2c6556f0]
** UPD 20.07.2022 синхросигнал SYNC подаем каждой АЦП на последний, 4 SMA разъем. Сигнал 10 МГц подаем на 3 SMA разъем АЦП 2.
* Прокинуть их (SYNC) c трех микросхем АЦП и PPS_In с буффера по Samtec в ZynQ
** сделано в коммите [https://gitlab.srns.ru:8080/git/adc_rev3/commit/2c6556f0588640dd321f68038dc4066e37c2f80f | 2c6556f0]
** UPD 20.07.2022 Прокинуто, в samtec идут минуя блок mean-compense
* Проверить их датаколлектором, убедиться в их адекватном внешнем виде, убедиться в наличии задержек между микросхемами АЦП.
** Проверяли на компе у Сереги. Увидели прямоугольные импульсы SYNC и PPS_IN (с буффера платы АЦП). Почему-то PPS_IN опаздывает относительно сигналов SYNC, хотя должно быть наоборот. Проблема может быть как в отображении самой программы датаколлектора, так и в реализации датаколлектора в ПЛИС (как он пишет по времени и вычитывает по времени).
* Сделать в ZynQ схему выравнивания АЦП между собой: она должна принимать 3 сигнала SYNC, смотреть задержку между ними, и задерживать потоки данных от всех микросхем АЦП к самому задержанному. Также она должна оценивать задержку Delta между PPS_In с буфера платы АЦП и синалом SYNC (каким, выровненным к задержками или как?)
** Иван сделал в коммите [https://gitlab.srns.ru:8080/git/src/commit/05c5e5fc250c7b2663003214f43fab26b5f61532 | 05c5e5fc] (на самом деле в 5cc547ee, по ссылке лишь обновленный тикль). Пока никто не проверял это кроме него и в с++ не встраивал.
* Учесть измеренную Delta в выдаче PPS_Out из ZynQ
* Убираем в южном мосту Oryx схему с еще одним формированием PPS_Out на счетчиках. Будем перещелкивать PPS_Out из ZynQ в клоки MCR - упрощаем монстра.
** сделано в коммите [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/3ecc30ce1dedb84c636e05821723add06d97217a | 3ecc30ce]

Два

* Оценить стабильность задержки от SER Samtec платы АЦП до DESER ZynQ в Oryx.
** Эксперимент проведен, [[#2020.07.27 - Постоянство задержки от сериалайзера платы АЦП до десериалайзера платы Oryx| результат чуть выше]]. Есть проблема со скачком на клок от включения к включению.
** Иван начал перепиливать плату АЦП, выкинул SER в ней и DESER в ZynQ. Данные от АЦП кладет просто в ODDR в дифф.линии Samtec в расчете на режим DDR. Провели эксперимент, как и в предыдущем пункте. PPS_IN между АЦП и Oryx больше не прыгает. Также посмотрели дата-коллектором в линии от АЦП - увидели там гармоники, т.е. как будто бы передача данных по Samtec между платой АЦП и Oryx работает без SER-DES цепочки. '''Важный ньюанс''' - т.к. хотим данные передавать в режиме DDR, для их защелкивания в ZynQ нужен клок, который был бы по середине бита данных. Оказалось, что на плате Oryx есть буфер, который делает из дифф-сингл клоки, и вносит задержку в клоки от АЦП порядка 2.5 нс на 100 МГц, т.е. 90 градусов, что нам и нужно. Поэтому просто берем и защелкиваем данные из АЦП в Цинке клоками, которые кинули из АЦП и они добрались до Цинка.

Три

* Чинить/освежать блоки Calibration и RefInterp в Oryx
** Calibration переделан тут (см. два мердженных коммита) [https://gitlab.srns.ru:8080/git/src/commit/1f59ed4248d6d644a31e3fa8171bf60cdedf7194 | 1f59ed42].
** RefInterp переделан тут (PL [https://gitlab.srns.ru:8080/git/src/commit/8d93c996a488ab41515b36121aae84b20cec9fce | 8d93c996], PS [https://gitlab.srns.ru:8080/git/src/commit/d873d357c66d5c9a0d192748a141d76eef8735a5 | d873d357]).
* Поднять UART из ZynQ для управления MCR, прокинуть его через южный мост к плате управления MCR. Там есть джамперы и 3х-пиновый разъем, можно переключаться между разъем на панели прибора / спец разъем.
** Сделано, работает. Коммит src [https://gitlab.srns.ru:8080/git/src/commit/33be60030193279208fa79a1bebb615673422794 | 33be6003]. Коммит южного моста [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/67ed0dbe96634ae136db85261b2c763aed7b31d5 | 67ed0dbe].

{{wl-publish: 2020-06-05 12:52:18 +0300 | Korogodin }}

MCR

2022-03-03T07:35:56Z

Dneprov: /* Расчет промежуточных частот */

{{Форма3}}
{{НАП
|Модель = MultiChannel Receiver
|Сущность = [[фронтенд]], многочастотный приемник
|Фотография = [[Файл:MCR_raw.png|300px]]
|Назначение = линейный фронтенд
|Навигационные сигналы =
GPS L1, L2<br>
ГЛОНАСС L1, L2
|Первые образцы = 2014 г в рамках СЧ ОКР "Сантиметр-М"
|Начало продаж =
|Разработчик = [[Advantex]] (каф. РПУ МЭИ) + УИЦ СРТТ (в цифровой части)
|Производитель = Корпус фирмы [https://schroff.pentair.com/en/schroff-apac/Ratiopac-PRO Schroff]


|Родственные модели =
|Модификации =


|Энергопотребление =
|Номинал напряжения питания =


|Размеры =
|Масса =


|Чувствительность coldstart =
|Чувствительность navigation =
|Время coldstart =
|Время warmstart =
|Время hotstart =
|Перезахват =


|Точность плановых координат =
|Точность высоты =
|Точность скорости =
|Точность времени =


|Рекомендуемый антенный модуль =
|Дополнительно об антмодуле =
|Антенный элемент =
|Диапазон частот антмодуля =
|Ку антенны =
|Кэ антенны =
|Питание антенного модуля =
|Ку МШУ =
|Кш МШУ =
|Выходной импеданс антмодуля =
|КСВН выхода антмодуля =
|Интерфейс антмодуля =


|Динамический диапазон = [[Измерение_SINAD_ящика_AVDNов|39-55 дБ]]
|Кш фронтенда = 11 дБ
|Число промежуточных частот = 2
|АРУ =
|Нижняя промежуточная частота =


|Разрядность АЦП =
|Частота дискретизации =


|Машина быстрого поиска =
|Число эквивалентных корреляторов=


|Исполнение коррелятора =
|Число каналов коррелятора =
|Коррелятор и многолучевость =
|Темп работы =


|Этапность алгоритмов слежения =
|Слежение за частотой =
|Оценка задержки =
|Оценка частоты =
|Оценка фазы =
|Оценка амплитуды =
|Оценка шума =
|Выделение НИ =


|Темп решения навзадачи =
|Описание решения навзадачи =
|Расчет скорости потребителя =
|Расчет времени потребителя =
|Расчет ориентации потребителя =
|Разрешение неоднозначности =
}}

'''MCR''' (''MultiChannel Receiver'') - макетный образец прецизионного навигационного приемника или его аналого-коробочная часть.

== Интерфейс ==

== Основные рабочие характеристики ==

=== Степень линейности ===

=== Потребление ===

=== Усиление ===

=== Полоса ===

=== Опорный генератор ===

== Интересные факты ==

== Настройка ==
=== Через RealTerm ===
* Настройка каналов фронтенда (по Profilic COM, командами SCPI).
** Параметры порта: 115200, 8 bit, no parity.
** *IDN? - проверка подключения, возвращает ID прибора.
** Если MCR не отвечает на команды, следует проверить посылку в конце команд EOL (End of Line), данная опция может быть отключена у терминала.
** Команды управления частотой, усилением и пр., а также различные данные о приборе содержатся в руководстве по эксплуатации (см. далее).
[[File:20160824_realterm_send_options_for_MCR.png|400px]]
* Истинное значение параметра DEM: GAIN (коэффициент усиления) при записанном 63 дБ равно 41 дБ ! Требуется проверять для каждого фронтенда.

=== Через MATLAB ===

Устали мы через Realterm настраивать. Сделали свою программу настройки. Работает из Windows. Как и для Realterm, нужно подключить usb-rs преобразователь.

[[File:MCR_gui.PNG|400px]]

Программа умеет:
* Соединять с прибором автоматически по нажатию любой большой кнопки.
* Узнать, что там у MCR сейчас настроено. Кнопка '''Check MCR'''.
* Настроить MCR на частотные планы под кодовыми названиями SPP и SRTT. Кнопки '''SPP''' и '''SRTT''' соответственно.
* Сделать сброс (команда *RST). Кнопка '''RESET'''.
* Сохранить текущие настройки (команда SAVE:CURRENT). Кнопка '''SAVE'''.
* Вручную настроить некоторые параметры соответствующими кнопками.

== Прошивка ==

Есть возможность прошивать MCR в части блока управления. Нужно это для точной установки кода частоты (FTW) в DDS синтезатора тактового сигнала. Подробнее см. [[Blog:Korogodin/28.07.16 Очередная смена частотного плана|тут]].

Файлы и инструкции по прошивке лежат в архиве [[Media:MCR_MCU.zip|MCR_MCU]].

== Частотный план ==

'''UPD 04.03.2020.'''

Просто абы-какой частотный план ставить низя. Нужно учесть некоторые ограничения и по клокам и по значениям гетеродинов. Изначально о них написано [[Blog:Korogodin/28.07.16 Очередная смена частотного плана|тут]]. Чуть позже проведена дополнительная доработка матлаб-скрипта и рассмотрен вариант приема L2+L3 на один и тот же канал демодулятора, там наиболее актуальное состояние вопроса с частотным планом и там же свежий матлаб-скрипт с учетом L3. [[Blog:DneprovV/04.03.2020_Отладка_трансивера_-_весна_2020#Частотный план в MCR|Об этом здесь.]]

'''OLD'''

Иногда приходится настраивать в MCR и fpga.cpp новые промежуточные частоты. Для их удобного расчета сделан матлаб-скрипт. Ему надо рассказать, какая у нас тактовая частота. Он сам проверит, сможет ли синтезатор сделать такую частоту. Частоты гетеродинов рассчитываются по формуле для дробно-переменного делителя частоты ([[Blog:Korogodin/28.07.16 Очередная смена частотного плана|как тут]]). Но можно и ручками задать.

Скачать [[Media:20161115_MCR_IF_freq.rar|матлаб-скрипт]].

== Протоколы испытаний ==
При передаче изделий были проведены измерения основных парметров РЧБ. Чтобы не потерять, вот протоколы:

1. [[Media:Протокол 1 MCR.pdf|Протокол испытаний одного из опытных образцов MCR]]

2. [[Media:Протокол 2 MCR.pdf|Пока не установлено чей протокол + парочка страниц потеряна]]

== Руководство по эксплуатации ==

[[Media:20160729_РЭ_рчб_ред2.pdf|Руководство PDF.]]

[[Media:20150112 РЭ рчб_ред2.doc|Руководство DOC.]]

[[Media:DSG3_Manual.pdf|Руководство по синтезатору частот DSG3 PDF.]]

[[Media:MCR_DEM.jpeg| Схема приемного модуля (где I, где Q). Прислал Петр Бобкович.]]

[[Категория: RF]]
[[Категория: Фронтенд]]

Список IP

2021-07-30T12:59:28Z

Dneprov:

{{Форма2}}

Список IP-адресов УИЦ СРТТ

{| class="wikitable" border="1"
|-align="center"
! IP
! Название
! Принадлежность
! Примечания
|-
| 192.168.0.1
|
| Внешний маршрутизатор
|
|-
| 192.168.0.2
| [http://192.168.0.2 server]
| Хранилище QNAP
|-
| 192.168.0.3
| [http://192.168.0.3 HP MFP479fdn]
| Сетевой принтер/сканер (цветной)
|
|-
| 192.168.0.4
| [http://192.168.0.4 HP M1412nfh]
| Сетевой принтер/сканер
|
|-
| 192.168.0.5
| [http://192.168.0.5 Diesel-power]
| Сетевой пилот
| Ethernet-пилот EnerGenie
|-
| 192.168.0.6
| [http://192.168.0.6 HP M443nda]
| МФУ А3 принтер/сканер
|
|-
| 192.168.0.10
| AI
| Устинов
|
|-
| 192.168.0.11
| Ivan-PC
| Липа
|
|-
| 192.168.0.12
| raspberry
| ivan
|
|-
| 192.168.0.60
| Oryx S/N 1.008
| Наш MCR
| Новый Орикс с новой печатной платой и модулем
|-
| 192.168.0.61
| Oryx S/N 1.009
| Наш MCR
| Новый Орикс с новой печатной платой и модулем
|-
| 192.168.0.62
| Oryx S/N 1.010
| Ящик ГЛОНАСС-ККН
| Новый Орикс с новой печатной платой и модулем
|-
| 192.168.0.63
| Oryx S/N 1.011
| ГЛОНАСС-ККН №2 с буферами
| Новый Орикс с новой печатной платой и модулем
|-
| 192.168.0.64
| Oryx S/N 1.012
| ГЛОНАСС-ККН №2 с буферами
| Новый Орикс с новой печатной платой и модулем
|-
| 192.168.0.65
| Oryx S/N 1.013
| ОО Сантиметр с выводами PPS'/PPSout
| Новый Орикс с новой печатной платой и модулем
|-
| 192.168.0.66
| Oryx S/N 1.014
| Забрали в июне 2017 от Филатова, у Ивана на столе
| Новый Орикс с новой печатной платой и модулем
|-
| 192.168.0.67
| Oryx S/N 1.015
| Забрали в июне 2017 от Филатова, ОО Сантиметр с выводами PPS'/PPSout
| Новый Орикс с новой печатной платой и модулем
|-
| 192.168.0.68
| Oryx S/N 1.016
| Oryx Potrable. Забрали в июне 2017 от Филатова.
| Новый Орикс с новой печатной платой и модулем. Заменил плату S/N: 1.003 (IP 163) в portable.
|-
| 192.168.0.69
| Oryx S/N 1.017
| Забрали в июне 2017 от Филатова. Лежит в коробочке.
| Новый Орикс с новой печатной платой и модулем. Наблюдаются проблемы со стартом Ethernet.
|-
| 192.168.0.80
| TP-LINK
|
| Маршрутизатор, используемый, как хаб (2014.05.15)
|-
| 192.168.0.83
| srns.ru
| Сервер
| Внешний IP 193.233.71.244
|-
| 192.168.0.92
| object-d
| Болденков
|
|-
| 192.168.0.93
| spirent
|
| Спайрент, что стоит в А-401
|-
| 192.168.0.94
| Evaluator
|
| Сервер тестирования
|-
| 192.168.0.95
| USRP E312
|
|
|-
| 192.168.0.96
| Neptune-1
| Шатилов
|
|-
| 192.168.0.99
| KorPC
| Корогодин
|
|-
| 192.168.0.110
| ZCU104
|
|MAC 00:0A:35:00:23:00
|-
| 192.168.0.111
| Clonicus 1
|
|MAC 00:0A:35:00:23:01
|-
| 192.168.0.112
| Clonicus 2
|
|MAC 00:0A:35:00:23:02
|-
| 192.168.0.117 '''...'''
| Clonicus v1.2
| Работы по псевдоспутникам
| '''Диапазон IP с 117 по 128''' занят под 12 Clonicus'ов v1.2
|-
| '''...''' 192.168.0.128
| Clonicus v1.2
| Работы по псевдоспутникам
|
|-
| 192.168.0.130
| Фарватер ЦМПО-М
| GPS L1 L2
| MAC 00:0A:35:00:01:00, с проводами, радиатор от ЗУ
|-
| 192.168.0.131
| Фарватер ЦМПО-М
| GLN L3, GPS L5
| MAC 00:0A:35:00:01:01, радиатор Gigabyte
|-
| 192.168.0.132
| Фарватер ЦМПО-М
| GLN L1 ОД
| MAC 00:0A:35:00:01:02
|-
| 192.168.0.133
| Фарватер ЦМПО-М
| GLN L1 СД
| MAC 00:0A:35:00:01:03
|-
| 192.168.0.134
| Фарватер ЦМПО-М
| GLN L2 ОД
| MAC 00:0A:35:00:01:04
|-
| 192.168.0.135
| Фарватер ЦМПО-М
| GLN L2 СД
| MAC 00:0A:35:00:01:05
|-
| 192.168.0.136
| Фарватер МПВО-М
| GLN L1
| MAC 00:0A:35:00:01:06
|-
| 192.168.0.137
| Фарватер МПВО-М
| GLN L2
| MAC 00:0A:35:00:01:07
|-
| 192.168.0.151
| Impala1
| Импала, экземпляр 1
| У Ивана
|-
| 192.168.0.152
| Impala2
| Модуль в тестовой плате
| Плата поиска в макете "Сантиметр"
|-
| 192.168.0.153
| Impala3
| Импала, экземпляр 3
| Плата коррелятора в макете "НИИ КП"
|-
| 192.168.0.154
| Impala4
| Импала, экземпляр 4 (c МАКС'а - у Андрея)
| Плата коррелятора в макете "Сантиметр"
|-
| 192.168.0.155
| Impala5
| Импала, экземпляр 5
| Плата поиска в макете "НИИ КП"
|-
| 192.168.0.156
| PLDA starter kit
|
|
|-
| 192.168.0.160
| MCR экземпляр 1
| Маршрутизатор "Сантиметра"
| Макет "Сантиметр", отдан Быханову. IP свободен
|-
| 192.168.0.161
| Oryx Экземпляр 1
| ОО Сантиметр №1, у Быханова, SN 1.001
|
|-
| 192.168.0.162
| Oryx Экземпляр 2
| Лежит без дела в коробочке, SN 1.002
|
|-
| 192.168.0.163
| Oryx Экземпляр 3
| Был Oryx portable, сломался разъем Ethernet, заменен. Лежит в коробочке.
| MAC 00:0A:35:00:01:63
|-
| 192.168.0.164
| Oryx Экземпляр 4
| Black Box, предположительно SN 1.004
| MAC 00:0A:35:00:01:64
|-
| 192.168.0.165
| Oryx Экземпляр 5
| Неизвестно, где она, SN 1.005
|
|-
| 192.168.0.166
| Oryx Экземпляр 6
| ОО Сантиметр №1, у Быханова, SN 1.006
|
|-
| 192.168.0.167
| Oryx Экземпляр 7
| Ящик ГЛОНАСС-ККН, предположительно SN 1.007
| '''ВАЖНО! Ранее этот IP был Маршрутизатор "Сантиметра" - 2'''
|-
| 192.168.0.168
| MCR экземпляр 3
| Маршрутизатор "Сантиметра" - 3
| Стоит на столе СПРАВА
|-
| 192.168.0.169
| Наш MCR с экраном
| Компьютер Тион-ПРО 2
|
|-
| 192.168.0.171
| Наш MCR с экраном
| Маршрутизатор MCR с экраном
|
|-
| 192.168.0.174
| R&S BBA150
| Усилитель R&S 30Вт
|
|-
| 192.168.0.175
|
| [[R&S SMBV100A S/N 257717 (прибор)|R&S SMBV100A S/N 257717]]
|
|-
| 192.168.0.176
|
| [[R&S SMBV100A S/N 257718 (прибор)|R&S SMBV100A S/N 257718]]
|
|-
| 192.168.0.177
|
| [[R&S SMBV100A S/N 256978 (прибор)|R&S SMBV100A S/N 256978]]
| Инв. номер 4186
|-
| 192.168.0.178
|
| [[R&S SMBV100A S/N 257721 (прибор)|R&S SMBV100A S/N 257721]]
|
|-
| 192.168.0.179
|
| [[R&S SMBV100A S/N 257716 (прибор)|R&S SMBV100A S/N 257716]]
|
|-
| 192.168.0.180
|
| [[Spirent_GSS6737-3_S/N_1201383_(прибор) | Spirent GSS6737-3]]
| его нет
|-
| 192.168.0.181
|
| R&S SMC 100A S/N 103005
| В стенде для тестирования
|-
| 192.168.0.182
|
| R&S RTM S/N 102119
| В стенде для тестирования
|-
| 192.168.0.186
| ZYNQ z702
|
| ТЕКУЩИЙ IP = 0.186
При изменении uImage сбивается. Настройка: vi /etc/network/interfaces
|-
| 192.168.0.187
| ZYNQ z706
|
| Наша первая плата Z-706
|-
| 192.168.0.188
| ZYNQ z706/2
|
| Вторая плата Z-706, которую дали для фарватера на время(MAC 00:0A:35:00:F1:88)
|-
| 192.168.0.189
| Lenovo Q180 #1 Aka Wirelessdude
|
| Неттоп с ви-фи (передатчик)
|-
| 192.168.0.190
| Lenovo Q180 #2 Aka Wirelessdude2
|
| Неттоп с ви-фи (приемник)
|-
| >= 192.168.0.200
|
|
| Область динамических адресов
|}

[[Категория:SRNS.ru]]

Список плат

2021-03-17T13:08:34Z

Dneprov: /* Список где/что/зачем */

{{Форма2}}

Данная страница содержит перепись выпускаемых нами изделий. В дальнейшем пополнится серийными номерами.

== Oryx ==

[[Blog:Boldenkov/15.10.2014 Встречайте - Oryx!|Oryx]] (плата + модуль c ZYNQ) - наиболее массовое на данный момент изделие. Всего их будет сделано 33 (!!!) штуки (+ 2 платы без модулей).

=== Немного истории ===

'''Первая закупка'''

Сделали 6 плат v1.0, купили 6 Somz-7045 к ним. В процессе беспощадной эксплуатации испортилось 2 Somz-7045.

Итог первой закупки - 4 рабочих Oryx v1.0, 2 печатных платы v1.0 без Somz-7045 (на которых перепаяли спартаны).

'''Вторая закупка'''

Шло время... Была разработана вторая версия печатной платы v2.0 с защитой по питанию.
Сделали 3 платы v2.0, купили 3 Somz-7045 к ним. Два новых Somz-7045 ушли в Oryx v1.0 в замен сгоревших. Одна новая плата Oryx v2.0 была запущена (потребовалось немного ручной пайки) и введена в строй. Оставшиеся две ждут своих Somz-7045 в коробке.

Итог второй закупки - 7 рабочих Oryx. Из них 1 Oryx v2.0, 6 Oryx v1.0 (два восстановлено за счет второй закупки). Осталось 2 пустых платы v2.0 в резерве.

'''Третья закупка'''

Внезапно все работает более-менее хорошо =). Сделан заказ на 10 плат v2.0 и 10 модулей Somz-7045. Их судьба следующая. 6 Oryx уходит в ГЛОНАСС-ККН (по 2 в ящики, 2 запасные). 4 Oryx вроде как свободные для дальнейших работ. Отметим, что 2 модуля Somz из 10 сразу ушли в платы v2.0, что были в резерве после второй закупки. Посему 2 платы этой закупки остаются без модулей.

'''Четвертая закупка'''

В ноябре-декабре 2017 года созрел заказ еще аж на 16 Oryx. Соответственно запустили процесс закупки деталей (кое-какие детали к тому моменту уже вышли из продажи). Подробности по заказу деталей в моем Evernote. Параллельно запустили процесс изготовления печатных плат (просто повторив заказ, см. личный кабинет Ивана в Резоните). Также купили 16 модулей Somz-7045. Чуть позже (летом 2018), выяснилось, что их снимают с производства, потому заказали запас еще 10 модулей Somz-7045. Примерно в конце марта отдали Виктору Александровичу Филатову на монтаж (ценник там же, в Evernote). Ориентировочно в октябре 2018 монтаж будет закончен. Все 16 штук уходят в ГЛОНАСС-ККН-сеть.

'''Пятая закупка'''

В конце 2018 года прошла инфа, что модули SOMZ снимаются с производства. Решено было приобрести 10 штучек. В начале весны 2019 года модули были получены, проверены в ките. Все рабочие. Примерно тогда же были закуплены разъемы SAMTEC для Oryx, платы АЦП (и под провода и под модули) в достаточном количестве, чтобы обеспечить 10 последних Oryx и под них 5 плат АЦП. '''Таким образом, разъемы SAMTEC для данных плат больше не нужно покупать.'''

При подготовке плат к установке в MCR (работа ККН-сеть) был обнаружен ряд косяков печатной платы Oryx v2.0 (та, что с защитой по питанию). Подробности сведены в статье [[Blog:Boldenkov/25.11.2014 Oryx-косяки]]. Также из-за неразберихи с количеством плат/комплектов/полукомплектов было решено таки сделать ЗИП для ККН-сеть в количестве 4 Oryx, 4 АЦП. Резюмируя, мы решили таки переразвести печатную плату Oryx для устранения косяков.

Всего отходит Быханову 12 БЦОНС, каждый из которых состоит из 2 плат Oryx и 1 ADC. 8 БЦОНС уходит в ящики, 4 типа ЗИП.

=== Итого в наличии ===

'''P.S. не посчитаны платы с четвертой закупки, ибо лень, да и все они уходят под ноль заказчику.'''

Согласно переписи, у нас сейчас есть 7 рабочих Oryx. Из них Быханову отходит точно 4 в опытные образцы Сантиметра, макет с 1 Oryx он также вряд ли отдаст, 1 Oryx поселился в blackbox, еще 1 в Oryx Portable. Из новых закупок предполагается 6 из 10 отдать Быханову, 4 свободны. '''Таким образом, можем рассчитывать на 6 Oryx, 2 из которых уже запиханы в коробочки.''' Также, судя по всему, в резерве две пустые печатные платы v2.0, т. к. модули под них не заказаны.

Это все сложно читать, проще так:

Всего должно быть - 17 Oryx

Отдадим Быханову - 11 Oryx (4(?) в ОО №1 и №2 Сантиметр, 1 в макет Сантиметр, 6 в ГЛОНАСС-ККН)

Останется нам - 6 Oryx (из них уже 2 засунуты в blackbox и в Oryx portable, посему '''"на столах" должно остаться 4''') + 2 пп v2.0 без модулей

== ADC Board ==

=== Немного истории ===

Давным-давно плата [[Blog:Lipa/02.04.15 ADC Board|АЦП]] была синяя. Свет увидели две таких платы, v1.0. Одну китайцы погнули в пропеллер. Другой повезло меньше, ей китайцы порядок слоев поменяли. Дебаги и прочие мучения с платами показали, что лучше их отправить на пенсию и сделать еще.

В новой редакции v2.0 цвет платы сменился на белый. Выпустили парочку таких белых плат АЦП. Платы рабочие, распиханы по ящикам.

На данный момент выпустили еще одну редакцию v3.0. Она также рабочая и живет в ящиках MCR.

Вместе с 10 Oryx заказано еще 4 платы АЦП v3.0.

'''Также зимой 2017''' к 16 Oryx запустили изготовление 8 плат АЦП v3.0. Подробности см. в разделе Oryx и моем Evernote. Все платы также уходят в ГЛОНАСС-ККН-сеть.

=== Итого в наличии ===

'''P.S. Последние 8 плат не учтены. Все уходят заказчику.'''

Согласно переписи, у нас сейчас есть 4 платы АЦП. Предположительно две v2.0, две v3.0. Из них 2 точно уйдут Быханову в опытные образцы, 1 уйдет в макет. Значит 1 плата условно свободна. Из новых закупок 3 платы уходят Быханову, 1 свободна. '''Итого можем рассчитывать на 2 платы АЦП.'''

Это все сложно читать, проще так:

Всего должно быть - 8 ADC board

Отдадим Быханову - 6 ADC board (2 в ОО №1 и №2 Сантиметр, 1 в макет Сантиметр, 3 в ГЛОНАСС-ККН)

Останется нам - 2 ADC board (из них уже 1 стоит в нашем MCR, посему '''"на столах" должна остаться 1''')

== Список где/что/зачем ==

Прежде всего, пару примечаний. Отказались выдавать отдельные SN на плату/модуль/Oryx в сборе. Считаем, что ничего не разбираем, один Oryx - один серийник. Чтобы много не переклеивать, оставили SN 1.XXX. Номер 3.XXX свободен.

{|table class="wikitable" style="text-align:center"
! colspan ="4"| Серийные номера изделий
|-
!Серийный номер||Что это||Где стоит/какая работа||Примечание

|-class="highlight"
|1.001||Oryx||Сантиметр Макет (или ОО №1), у Быханова||IP 161, наклеить наклейку

|-class="highlight"
|1.002||Oryx||Лежит в коробочке||IP 162

|-
|-class="highlight"
|1.003||Oryx||Лежит в коробочке, был Oryx portable||IP 163, сломался разъем Ethernet, заменен на плату SN 1.016 (IP 68)

|-
|-class="highlight"
|1.004||Oryx||великий и ужасный blackbox, стоит у нас||IP 164, наклеить наклейку

|-
|-class="highlight"
|1.005||Oryx||Неизвестно||Выяснить IP (165?), где реально стоит, наклеить наклейку

|-
|-class="highlight"
|1.006||Oryx||Сантиметр Макет (или ОО №1), у Быханова||IP 166, наклеить наклейку

|-
|-class="highlight"
|1.007||Oryx||Ревизия 2.0, ящик ГЛОНАСС-ККН||IP 167

|-
|-class="highlight"
|1.008||Oryx||Ревизия 2.0, снабжена Somz из 10-ти новых, наш MCR, стоит у нас||IP 60

|-
|-class="highlight"
|1.009||Oryx||Ревизия 2.0, снабжена Somz из 10-ти новых, наш MCR, стоит у нас||IP 61

|-
|-class="highlight"
|1.010||Oryx||Ревизия 2.0, снабжена Somz из 10-ти новых, ящик ГЛОНАСС-ККН||IP 62

|-
|-class="highlight"
|1.011||Oryx||Ревизия 2.0, снабжена Somz из 10-ти новых, ящик ГЛОНАСС-ККН №2 (с буфферами)||IP 63

|-
|-class="highlight"
|1.012||Oryx||Ревизия 2.0, снабжена Somz из 10-ти новых, ящик ГЛОНАСС-ККН №2 (с буфферами)||IP 64, заменил печатную плату на одну из последних (июнь 2017), родная плата глючила (см. SN 1.018)

|-
|-class="highlight"
|1.013||Oryx||Ревизия 2.0, снабжена Somz из 10-ти новых, ОО Сантиметр с выводами PPS||IP 65

|-
|-class="highlight"
|1.014||Oryx||Ревизия 2.0, последний монтаж (июль 2017), ККН-сеть|| IP 30, Ушел в MCR S/N: 46048-8071-005 вместо платы №30.

|-
|-class="highlight"
|1.015||Oryx||Ревизия 2.0, последний монтаж (июль 2017), запустили, ОО Сантиметр с выводами PPS||IP 67, 25.06.2019 внезапно сдох модуль SOMZ. Оказалось - отвалились ключи после DC-DC из-за брака пайки. Фил починил.
|-
|-class="highlight"
|1.016||Oryx||Ревизия 2.0, последний монтаж (июль 2017), запустили, Oryx portable||IP 68, заменили плату SN 1.003 в Oryx portable, там сломался разъем Ethernet.

|-
|-class="highlight"
|1.017||Oryx||Ревизия 2.0, последний монтаж (июль 2017), запустили, лежит в коробочке||IP 69, плохо стартует Ethernet.

|-
|-class="highlight"
|1.018||motherboard Oryx||Нет модуля, лежит в коробочке||не работают DAC, молчит Microblaze

|-
|-class="highlight"
|1.019||motherboard Oryx||Нет модуля, лежит в коробочке||<s>глюки в DC-DC 5В</s> впаян новый DC-DC, работает. В процессе жесткого дебуга проблемы с загрузкой процессора, данная плата была сильно резана/паяна. см. подробности у меня в evernote. Что-то вернули обратно, что-то нет.

|-
|-class="highlight"
|1.020||Oryx||Rev 2.0, монтаж 2018, предназначен в ККН-сеть || IP 20, стоит в MCR S/N: 46048-8071-008

|-
|-class="highlight"
|1.021||Oryx||Rev 2.0, монтаж 2018, предназначен в ККН-сеть || IP 21, стоит в MCR S/N: 46048-8071-008

|-
|-class="highlight"
|1.022||Oryx||Rev 2.0, монтаж 2018, предназначен в ККН-сеть || IP 22, стоит в MCR S/N: 46048-8071-001

|-
|-class="highlight"
|1.023||Oryx||Rev 2.0, монтаж 2018, предназначен в ККН-сеть || IP 23, стоит в MCR S/N: 46048-8071-001

|-
|-class="highlight"
|1.024||Oryx||Rev 2.0, монтаж 2018, предназначен в ККН-сеть || IP 24, стоит в MCR S/N: 46048-8071-002 <s> Дебуг проведен, вроде победили. Не грузился проц, не было видно его по JTAG.</s>

|-
|-class="highlight"
|1.025||Oryx||Rev 2.0, монтаж 2018, предназначен в ККН-сеть || IP 25, стоит в MCR S/N: 46048-8071-002

|-
|-class="highlight"
|1.026||Oryx||Rev 2.0, монтаж 2018, предназначен в ККН-сеть || IP 26, стоит в MCR S/N: 46048-8071-003 <s> Дебуг проведен, вроде победили. Не грузился проц, не было видно его по JTAG.</s>

|-
|-class="highlight"
|1.027||Oryx||Rev 2.0, монтаж 2018, предназначен в ККН-сеть || IP 27, стоит в MCR S/N: 46048-8071-003

|-
|-class="highlight"
|1.028||Oryx||Rev 2.0, монтаж 2018, предназначен в ККН-сеть || IP 28, стоит в MCR S/N: 46048-8071-004 <s> Дебуг проведен, вроде победили. Не грузился проц, не было видно его по JTAG.</s>

|-
|-class="highlight"
|1.029||Oryx||Rev 2.0, монтаж 2018, предназначен в ККН-сеть || IP 29, стоит в MCR S/N: 46048-8071-004 <s> Спартан горел, заменили спартан на новый</s>

|-
|-class="highlight"
|1.030||Oryx||Rev 2.0, монтаж 2018, предназначен в ККН-сеть, пока лежит в коробочке || IP 66. На процессорном модуле оказался битый транзистор Т1, он же ключ на 3.3 В, модуль включался нестабильно. Перепаяли с дохлой платы, завелось. Пришлось вставить в ящик MCR S/N: 46048-8071-005 плату №14. Флэшки соответственно поменял местами.
|-
|-class="highlight"
|1.031||Oryx||Rev 2.0, монтаж 2018, предназначен в ККН-сеть || IP 31, стоит в MCR S/N: 46048-8071-005 <s>ридбэк прошел нормально, но импакт сказал, что доне не поднялся (это в режиме 4 бита). Иван сварил отдельный битник в режиме 1 бит и он нормально прошился. Хз, греть спартан или нет. - возможно в ЗИП ее отдать. UPD: ПЛИС погрели с флюсом, и по 4 линиям флэшка зашилась.</s>

|-
|-class="highlight"
|1.032||Oryx||Rev 2.0, монтаж 2018, предназначен в ККН-сеть || IP 32, стоит в MCR S/N: 46048-8071-006

|-
|-class="highlight"
|1.033||Oryx||Rev 2.0, монтаж 2018, предназначен в ККН-сеть || IP 33, стоит в MCR S/N: 46048-8071-006. Отмечен глюк Ethernet: при загрузке может долго инициализироваться, но вроде после небольшого ожидания работает.

|-
|-class="highlight"
|1.034||Oryx||Rev 2.0, монтаж 2018, предназначен в ККН-сеть || IP 34, стоит в MCR S/N: 46048-8071-007. <s>Вставил модуль, не грузится процессорная часть. Был реболлинг спартана - по итогу имеем КЗ по выходам ключей DC-DC. Возможно спартан мертвый, надо менять.</s><s> Заменили спартан на новый. Вроде пока без модуля с перемычкой по JTAG спартан видно, флэшку прошил.</s>

|-
|-class="highlight"
|1.035||Oryx||Rev 2.0, монтаж 2018, предназначен в ККН-сеть || IP 35, стоит в MCR S/N: 46048-8071-007. <s>Вставил модуль, не грузится процессорная часть. Был реболлинг спартана - по итогу имеем КЗ по выходам ключей DC-DC. Возможно спартан мертвый, надо менять.</s><s> Заменили спартан на новый. Вроде пока без модуля с перемычкой по JTAG спартан видно, флэшку прошил.</s>

|-
|-class="highlight"
|1.036||Oryx||Rev 3.0, монтаж 2019, предназначен в ККН-сеть || IP 36, будет ЗИПом

|-
|-class="highlight"
|1.037||Oryx||Rev 3.0, монтаж 2019, предназначен в ККН-сеть || IP 37, <s>Ошибка в установке одного из буферов 50 Ом под разъемом mmcx XW1</s>, будет ЗИПом

|-
|-class="highlight"
|1.038||Oryx||Rev 3.0, монтаж 2019, предназначен в ККН-сеть || IP 38, будет ЗИПом

|-
|-class="highlight"
|1.039||Oryx||Rev 3.0, монтаж 2019, предназначен в ККН-сеть || IP 39, будет ЗИПом

|-
|-class="highlight"
|1.040||Oryx||Rev 3.0, монтаж 2019, предназначен в ККН-сеть || IP 40, будет ЗИПом

|-
|-class="highlight"
|1.041||Oryx||Rev 3.0, монтаж 2019, предназначен в ККН-сеть || IP 41, Отмечены проблемы с прошивкой флэшки спартана. То не вычитывает ID по SPI, то на ридбэке валится. Поменяли флэшку, прогрели заново спартан. После этого чудом раза с 3го прошилась, вроде работает. Будет ЗИПом.

|-
|-class="highlight"
|1.042||Oryx||Rev 3.0, монтаж 2019, предназначен в ККН-сеть || IP 42, не завелась в нашем ящике MCR при тесте. Отключил синий кабель Samtec - завелась, так и живем. Будет ЗИПом.

|-
|-class="highlight"
|1.043||Oryx||Rev 3.0, монтаж 2019, предназначен в ККН-сеть || IP 43, будет ЗИПом

|-class="bright"
|2.001||Clonicus 1.1||||IP 111, наклеить серийник

|-class="bright"
|2.002||Clonicus 1.1||||IP 112, наклеить серийник

|-class="bright"
|2.003||Clonicus 1.1||||IP 113, наклеить серийник

|-class="bright"
|2.004||Clonicus 1.1||||IP 114, наклеить серийник

|-class="bright"
|2.005||Clonicus 1.1||||IP 115, наклеить серийник

|-class="bright"
|2.006||Clonicus 1.1||||IP 116, наклеить серийник

|-class="bright"
|2.007||Clonicus 1.2|| в псевдоспутники ||IP 117, ГРУЗИТСЯ, есть сеть, номады есть лок

|-class="bright"
|2.008||Clonicus 1.2|| в псевдоспутники ||IP 118, ГРУЗИТСЯ, есть сеть, номады есть лок

|-class="bright"
|2.009||Clonicus 1.2|| в псевдоспутники ||IP 119, ГРУЗИТСЯ, есть сеть, номады есть лок

|-class="bright"
|2.010||Clonicus 1.2|| в псевдоспутники ||IP 120, ГРУЗИТСЯ, номады есть лок

|-class="bright"
|2.011||Clonicus 1.2|| в псевдоспутники ||IP 121, ГРУЗИТСЯ, номады есть лок

|-class="bright"
|2.012||Clonicus 1.2|| в псевдоспутники ||IP 122, ГРУЗИТСЯ, номады есть лок

|-class="bright"
|2.013||Clonicus 1.2|| в псевдоспутники ||IP 123, ГРУЗИТСЯ, номады есть лок

|-class="bright"
|2.014||Clonicus 1.2|| в псевдоспутники ||IP 124, ГРУЗИТСЯ, номады есть лок

|-class="bright"
|2.015||Clonicus 1.2|| в псевдоспутники ||IP 125, ГРУЗИТСЯ, номады есть лок

|-class="bright"
|2.016||Clonicus 1.2|| в псевдоспутники ||IP 126, ГРУЗИТСЯ, номады есть лок

|-class="bright"
|2.017||Clonicus 1.2|| в псевдоспутники ||IP 127, ZYNQ 45, ГРУЗИТСЯ, номады есть лок

|-class="bright"
|2.018||Clonicus 1.2|| в псевдоспутники ||IP 128, ZYNQ 45, РАБОТАЕТ SSH, номады есть лок

|-class="highlight"
|4.001||ADC board||макет Сантиметр, у Быханова||узнать Rev ???, наклеить наклейку

|-class="highlight"
|4.002||ADC board||Rev 2.0, лежит в коробке||вход pps не подключен к ПЛИС физически (касается всех Rev 2.0)

|-
|-class="highlight"
|4.003||ADC board||макет (или опытный образец №1, хз) Сантиметр, у Быханова||узнать Rev ???, наклеить наклейку

|-
|-class="highlight"
|4.004||ADC board||Rev 3.0, наш MCR, стоит у нас||

|-
|-class="highlight"
|4.005||ADC board||Rev 3.0, последняя закупка, опытный образец Сантиметр с выводами PPS||

|-
|-class="highlight"
|4.006||ADC board||Rev 3.0, последняя закупка, отдыхает в коробке||На производстве получила пропеллер, работает так себе

|-
|-class="highlight"
|4.007||ADC board||Rev 3.0, последняя закупка, ящик ГЛОНАСС-ККН №2 (с буфферами)||

|-
|-class="highlight"
|4.008||ADC board||Rev 3.0, последняя закупка, ящик ГЛОНАСС-ККН||

|-
|-class="highlight"
|4.009||ADC board||Rev 3.0, в работу ККН-сеть|| стоит в MCR S/N: 46048-8071-008, прошивка сварена из ветки ADC3_GCLK, коммит 61628c02.

|-
|-class="highlight"
|4.010||ADC board||Rev 3.0, в работу ККН-сеть|| стоит в MCR S/N: 46048-8071-001, прошивка сварена из ветки ADC3_GCLK, коммит 61628c02.

|-
|-class="highlight"
|4.011||ADC board||Rev 3.0, в работу ККН-сеть|| стоит в MCR S/N: 46048-8071-002, прошивка сварена из ветки ADC3_GCLK, коммит 61628c02.

|-
|-class="highlight"
|4.012||ADC board||Rev 3.0, в работу ККН-сеть|| стоит в MCR S/N: 46048-8071-003, прошивка сварена из ветки ADC3_GCLK, коммит 61628c02.

|-
|-class="highlight"
|4.013||ADC board||Rev 3.0, в работу ККН-сеть|| стоит в MCR S/N: 46048-8071-004, прошивка сварена из ветки ADC3_GCLK, коммит 61628c02. LED1 не горит (возможно сгорел/не так запаян)

|-
|-class="highlight"
|4.014||ADC board||Rev 3.0, в работу ККН-сеть|| стоит в MCR S/N: 46048-8071-005, прошивка сварена из ветки ADC3_GCLK, коммит 61628c02.

|-
|-class="highlight"
|4.015||ADC board||Rev 3.0, в работу ККН-сеть|| стоит в MCR S/N: 46048-8071-006, прошивка сварена из ветки ADC3_GCLK, коммит 61628c02.

|-
|-class="highlight"
|4.016||ADC board||Rev 3.0, в работу ККН-сеть|| стоит в MCR S/N: 46048-8071-007, прошивка сварена из ветки ADC3_GCLK, коммит 61628c02. Прошилась раза с третьего.

|-
|-class="highlight"
|4.017||ADC board||Rev 3.0, в работу ККН-сеть|| прошивка сварена из ветки ADC3_GCLK, коммит 61628c02, новый стеклотекстолит TG170, будет ЗИПом

|-
|-class="highlight"
|4.018||ADC board||Rev 3.0, в работу ККН-сеть|| прошивка сварена из ветки ADC3_GCLK, коммит 61628c02, новый стеклотекстолит TG170, будет ЗИПом

|-
|-class="highlight"
|4.019||ADC board||Rev 3.0, в работу ККН-сеть|| прошивка сварена из ветки ADC3_GCLK, коммит 61628c02, новый стеклотекстолит TG170, будет ЗИПом

|-
|-class="highlight"
|4.020||ADC board||Rev 3.0, в работу ККН-сеть|| прошивка сварена из ветки ADC3_GCLK, коммит 61628c02, АЦПшка в позиции D11 - б/у с старой синей платы, новый стеклотекстолит TG170, будет ЗИПом

|-
|-class="highlight"
|4.021||ADC board||Rev 3.0, нам про запас, лежит в коробочке|| прошивка сварена из ветки ADC3_GCLK, коммит 61628c02, все АЦПшки - б/у с старой синей платы, новый стеклотекстолит TG170
|}
[[Категория:Oryx]]
[[Category:Clonicus]]

Список плат

2021-03-17T13:05:30Z

Dneprov: /* Список где/что/зачем */

{{Форма2}}

Данная страница содержит перепись выпускаемых нами изделий. В дальнейшем пополнится серийными номерами.

== Oryx ==

[[Blog:Boldenkov/15.10.2014 Встречайте - Oryx!|Oryx]] (плата + модуль c ZYNQ) - наиболее массовое на данный момент изделие. Всего их будет сделано 33 (!!!) штуки (+ 2 платы без модулей).

=== Немного истории ===

'''Первая закупка'''

Сделали 6 плат v1.0, купили 6 Somz-7045 к ним. В процессе беспощадной эксплуатации испортилось 2 Somz-7045.

Итог первой закупки - 4 рабочих Oryx v1.0, 2 печатных платы v1.0 без Somz-7045 (на которых перепаяли спартаны).

'''Вторая закупка'''

Шло время... Была разработана вторая версия печатной платы v2.0 с защитой по питанию.
Сделали 3 платы v2.0, купили 3 Somz-7045 к ним. Два новых Somz-7045 ушли в Oryx v1.0 в замен сгоревших. Одна новая плата Oryx v2.0 была запущена (потребовалось немного ручной пайки) и введена в строй. Оставшиеся две ждут своих Somz-7045 в коробке.

Итог второй закупки - 7 рабочих Oryx. Из них 1 Oryx v2.0, 6 Oryx v1.0 (два восстановлено за счет второй закупки). Осталось 2 пустых платы v2.0 в резерве.

'''Третья закупка'''

Внезапно все работает более-менее хорошо =). Сделан заказ на 10 плат v2.0 и 10 модулей Somz-7045. Их судьба следующая. 6 Oryx уходит в ГЛОНАСС-ККН (по 2 в ящики, 2 запасные). 4 Oryx вроде как свободные для дальнейших работ. Отметим, что 2 модуля Somz из 10 сразу ушли в платы v2.0, что были в резерве после второй закупки. Посему 2 платы этой закупки остаются без модулей.

'''Четвертая закупка'''

В ноябре-декабре 2017 года созрел заказ еще аж на 16 Oryx. Соответственно запустили процесс закупки деталей (кое-какие детали к тому моменту уже вышли из продажи). Подробности по заказу деталей в моем Evernote. Параллельно запустили процесс изготовления печатных плат (просто повторив заказ, см. личный кабинет Ивана в Резоните). Также купили 16 модулей Somz-7045. Чуть позже (летом 2018), выяснилось, что их снимают с производства, потому заказали запас еще 10 модулей Somz-7045. Примерно в конце марта отдали Виктору Александровичу Филатову на монтаж (ценник там же, в Evernote). Ориентировочно в октябре 2018 монтаж будет закончен. Все 16 штук уходят в ГЛОНАСС-ККН-сеть.

'''Пятая закупка'''

В конце 2018 года прошла инфа, что модули SOMZ снимаются с производства. Решено было приобрести 10 штучек. В начале весны 2019 года модули были получены, проверены в ките. Все рабочие. Примерно тогда же были закуплены разъемы SAMTEC для Oryx, платы АЦП (и под провода и под модули) в достаточном количестве, чтобы обеспечить 10 последних Oryx и под них 5 плат АЦП. '''Таким образом, разъемы SAMTEC для данных плат больше не нужно покупать.'''

При подготовке плат к установке в MCR (работа ККН-сеть) был обнаружен ряд косяков печатной платы Oryx v2.0 (та, что с защитой по питанию). Подробности сведены в статье [[Blog:Boldenkov/25.11.2014 Oryx-косяки]]. Также из-за неразберихи с количеством плат/комплектов/полукомплектов было решено таки сделать ЗИП для ККН-сеть в количестве 4 Oryx, 4 АЦП. Резюмируя, мы решили таки переразвести печатную плату Oryx для устранения косяков.

Всего отходит Быханову 12 БЦОНС, каждый из которых состоит из 2 плат Oryx и 1 ADC. 8 БЦОНС уходит в ящики, 4 типа ЗИП.

=== Итого в наличии ===

'''P.S. не посчитаны платы с четвертой закупки, ибо лень, да и все они уходят под ноль заказчику.'''

Согласно переписи, у нас сейчас есть 7 рабочих Oryx. Из них Быханову отходит точно 4 в опытные образцы Сантиметра, макет с 1 Oryx он также вряд ли отдаст, 1 Oryx поселился в blackbox, еще 1 в Oryx Portable. Из новых закупок предполагается 6 из 10 отдать Быханову, 4 свободны. '''Таким образом, можем рассчитывать на 6 Oryx, 2 из которых уже запиханы в коробочки.''' Также, судя по всему, в резерве две пустые печатные платы v2.0, т. к. модули под них не заказаны.

Это все сложно читать, проще так:

Всего должно быть - 17 Oryx

Отдадим Быханову - 11 Oryx (4(?) в ОО №1 и №2 Сантиметр, 1 в макет Сантиметр, 6 в ГЛОНАСС-ККН)

Останется нам - 6 Oryx (из них уже 2 засунуты в blackbox и в Oryx portable, посему '''"на столах" должно остаться 4''') + 2 пп v2.0 без модулей

== ADC Board ==

=== Немного истории ===

Давным-давно плата [[Blog:Lipa/02.04.15 ADC Board|АЦП]] была синяя. Свет увидели две таких платы, v1.0. Одну китайцы погнули в пропеллер. Другой повезло меньше, ей китайцы порядок слоев поменяли. Дебаги и прочие мучения с платами показали, что лучше их отправить на пенсию и сделать еще.

В новой редакции v2.0 цвет платы сменился на белый. Выпустили парочку таких белых плат АЦП. Платы рабочие, распиханы по ящикам.

На данный момент выпустили еще одну редакцию v3.0. Она также рабочая и живет в ящиках MCR.

Вместе с 10 Oryx заказано еще 4 платы АЦП v3.0.

'''Также зимой 2017''' к 16 Oryx запустили изготовление 8 плат АЦП v3.0. Подробности см. в разделе Oryx и моем Evernote. Все платы также уходят в ГЛОНАСС-ККН-сеть.

=== Итого в наличии ===

'''P.S. Последние 8 плат не учтены. Все уходят заказчику.'''

Согласно переписи, у нас сейчас есть 4 платы АЦП. Предположительно две v2.0, две v3.0. Из них 2 точно уйдут Быханову в опытные образцы, 1 уйдет в макет. Значит 1 плата условно свободна. Из новых закупок 3 платы уходят Быханову, 1 свободна. '''Итого можем рассчитывать на 2 платы АЦП.'''

Это все сложно читать, проще так:

Всего должно быть - 8 ADC board

Отдадим Быханову - 6 ADC board (2 в ОО №1 и №2 Сантиметр, 1 в макет Сантиметр, 3 в ГЛОНАСС-ККН)

Останется нам - 2 ADC board (из них уже 1 стоит в нашем MCR, посему '''"на столах" должна остаться 1''')

== Список где/что/зачем ==

Прежде всего, пару примечаний. Отказались выдавать отдельные SN на плату/модуль/Oryx в сборе. Считаем, что ничего не разбираем, один Oryx - один серийник. Чтобы много не переклеивать, оставили SN 1.XXX. Номер 3.XXX свободен.

{|table class="wikitable" style="text-align:center"
! colspan ="4"| Серийные номера изделий
|-
!Серийный номер||Что это||Где стоит/какая работа||Примечание

|-class="highlight"
|1.001||Oryx||Сантиметр Макет (или ОО №1), у Быханова||IP 161, наклеить наклейку

|-class="highlight"
|1.002||Oryx||Лежит в коробочке||IP 162

|-
|-class="highlight"
|1.003||Oryx||Лежит в коробочке, был Oryx portable||IP 163, сломался разъем Ethernet, заменен на плату SN 1.016 (IP 68)

|-
|-class="highlight"
|1.004||Oryx||великий и ужасный blackbox, стоит у нас||IP 164, наклеить наклейку

|-
|-class="highlight"
|1.005||Oryx||Неизвестно||Выяснить IP (165?), где реально стоит, наклеить наклейку

|-
|-class="highlight"
|1.006||Oryx||Сантиметр Макет (или ОО №1), у Быханова||IP 166, наклеить наклейку

|-
|-class="highlight"
|1.007||Oryx||Ревизия 2.0, ящик ГЛОНАСС-ККН||IP 167

|-
|-class="highlight"
|1.008||Oryx||Ревизия 2.0, снабжена Somz из 10-ти новых, наш MCR, стоит у нас||IP 60

|-
|-class="highlight"
|1.009||Oryx||Ревизия 2.0, снабжена Somz из 10-ти новых, наш MCR, стоит у нас||IP 61

|-
|-class="highlight"
|1.010||Oryx||Ревизия 2.0, снабжена Somz из 10-ти новых, ящик ГЛОНАСС-ККН||IP 62

|-
|-class="highlight"
|1.011||Oryx||Ревизия 2.0, снабжена Somz из 10-ти новых, ящик ГЛОНАСС-ККН №2 (с буфферами)||IP 63

|-
|-class="highlight"
|1.012||Oryx||Ревизия 2.0, снабжена Somz из 10-ти новых, ящик ГЛОНАСС-ККН №2 (с буфферами)||IP 64, заменил печатную плату на одну из последних (июнь 2017), родная плата глючила (см. SN 1.018)

|-
|-class="highlight"
|1.013||Oryx||Ревизия 2.0, снабжена Somz из 10-ти новых, ОО Сантиметр с выводами PPS||IP 65

|-
|-class="highlight"
|1.014||Oryx||Ревизия 2.0, последний монтаж (июль 2017), ККН-сеть|| IP 30, Ушел в MCR S/N: 46048-8071-005 вместо платы №30.

|-
|-class="highlight"
|1.015||Oryx||Ревизия 2.0, последний монтаж (июль 2017), запустили, ОО Сантиметр с выводами PPS||IP 67, 25.06.2019 внезапно сдох модуль SOMZ. Оказалось - отвалились ключи после DC-DC из-за брака пайки. Фил починил.
|-
|-class="highlight"
|1.016||Oryx||Ревизия 2.0, последний монтаж (июль 2017), запустили, Oryx portable||IP 68, заменили плату SN 1.003 в Oryx portable, там сломался разъем Ethernet.

|-
|-class="highlight"
|1.017||Oryx||Ревизия 2.0, последний монтаж (июль 2017), запустили, лежит в коробочке||IP 69, плохо стартует Ethernet.

|-
|-class="highlight"
|1.018||motherboard Oryx||Нет модуля, лежит в коробочке||не работают DAC, молчит Microblaze

|-
|-class="highlight"
|1.019||motherboard Oryx||Нет модуля, лежит в коробочке||<s>глюки в DC-DC 5В</s> впаян новый DC-DC, работает. В процессе жесткого дебуга проблемы с загрузкой процессора, данная плата была сильно резана/паяна. см. подробности у меня в evernote. Что-то вернули обратно, что-то нет.

|-
|-class="highlight"
|1.020||Oryx||Rev 2.0, монтаж 2018, предназначен в ККН-сеть || IP 20, стоит в MCR S/N: 46048-8071-008

|-
|-class="highlight"
|1.021||Oryx||Rev 2.0, монтаж 2018, предназначен в ККН-сеть || IP 21, стоит в MCR S/N: 46048-8071-008

|-
|-class="highlight"
|1.022||Oryx||Rev 2.0, монтаж 2018, предназначен в ККН-сеть || IP 22, стоит в MCR S/N: 46048-8071-001

|-
|-class="highlight"
|1.023||Oryx||Rev 2.0, монтаж 2018, предназначен в ККН-сеть || IP 23, стоит в MCR S/N: 46048-8071-001

|-
|-class="highlight"
|1.024||Oryx||Rev 2.0, монтаж 2018, предназначен в ККН-сеть || IP 24, стоит в MCR S/N: 46048-8071-002 <s> Дебуг проведен, вроде победили. Не грузился проц, не было видно его по JTAG.</s>

|-
|-class="highlight"
|1.025||Oryx||Rev 2.0, монтаж 2018, предназначен в ККН-сеть || IP 25, стоит в MCR S/N: 46048-8071-002

|-
|-class="highlight"
|1.026||Oryx||Rev 2.0, монтаж 2018, предназначен в ККН-сеть || IP 26, стоит в MCR S/N: 46048-8071-003 <s> Дебуг проведен, вроде победили. Не грузился проц, не было видно его по JTAG.</s>

|-
|-class="highlight"
|1.027||Oryx||Rev 2.0, монтаж 2018, предназначен в ККН-сеть || IP 27, стоит в MCR S/N: 46048-8071-003

|-
|-class="highlight"
|1.028||Oryx||Rev 2.0, монтаж 2018, предназначен в ККН-сеть || IP 28, стоит в MCR S/N: 46048-8071-004 <s> Дебуг проведен, вроде победили. Не грузился проц, не было видно его по JTAG.</s>

|-
|-class="highlight"
|1.029||Oryx||Rev 2.0, монтаж 2018, предназначен в ККН-сеть || IP 29, стоит в MCR S/N: 46048-8071-004 <s> Спартан горел, заменили спартан на новый</s>

|-
|-class="highlight"
|1.030||Oryx||Rev 2.0, монтаж 2018, предназначен в ККН-сеть, пока лежит в коробочке || IP 66. На процессорном модуле оказался битый транзистор Т1, он же ключ на 3.3 В, модуль включался нестабильно. Перепаяли с дохлой платы, завелось. Пришлось вставить в ящик MCR S/N: 46048-8071-005 плату №14. Флэшки соответственно поменял местами.
|-
|-class="highlight"
|1.031||Oryx||Rev 2.0, монтаж 2018, предназначен в ККН-сеть || IP 31, стоит в MCR S/N: 46048-8071-005 <s>ридбэк прошел нормально, но импакт сказал, что доне не поднялся (это в режиме 4 бита). Иван сварил отдельный битник в режиме 1 бит и он нормально прошился. Хз, греть спартан или нет. - возможно в ЗИП ее отдать. UPD: ПЛИС погрели с флюсом, и по 4 линиям флэшка зашилась.</s>

|-
|-class="highlight"
|1.032||Oryx||Rev 2.0, монтаж 2018, предназначен в ККН-сеть || IP 32, стоит в MCR S/N: 46048-8071-006

|-
|-class="highlight"
|1.033||Oryx||Rev 2.0, монтаж 2018, предназначен в ККН-сеть || IP 33, стоит в MCR S/N: 46048-8071-006. Отмечен глюк Ethernet: при загрузке может долго инициализироваться, но вроде после небольшого ожидания работает.

|-
|-class="highlight"
|1.034||Oryx||Rev 2.0, монтаж 2018, предназначен в ККН-сеть || IP 34, стоит в MCR S/N: 46048-8071-007. <s>Вставил модуль, не грузится процессорная часть. Был реболлинг спартана - по итогу имеем КЗ по выходам ключей DC-DC. Возможно спартан мертвый, надо менять.</s><s> Заменили спартан на новый. Вроде пока без модуля с перемычкой по JTAG спартан видно, флэшку прошил.</s>

|-
|-class="highlight"
|1.035||Oryx||Rev 2.0, монтаж 2018, предназначен в ККН-сеть || IP 35, стоит в MCR S/N: 46048-8071-007. <s>Вставил модуль, не грузится процессорная часть. Был реболлинг спартана - по итогу имеем КЗ по выходам ключей DC-DC. Возможно спартан мертвый, надо менять.</s><s> Заменили спартан на новый. Вроде пока без модуля с перемычкой по JTAG спартан видно, флэшку прошил.</s>

|-
|-class="highlight"
|1.036||Oryx||Rev 3.0, монтаж 2019, предназначен в ККН-сеть || IP 36, будет ЗИПом

|-
|-class="highlight"
|1.037||Oryx||Rev 3.0, монтаж 2019, предназначен в ККН-сеть || IP 37, <s>Ошибка в установке одного из буферов 50 Ом под разъемом mmcx XW1</s>, будет ЗИПом

|-
|-class="highlight"
|1.038||Oryx||Rev 3.0, монтаж 2019, предназначен в ККН-сеть || IP 38, будет ЗИПом

|-
|-class="highlight"
|1.039||Oryx||Rev 3.0, монтаж 2019, предназначен в ККН-сеть || IP 39, будет ЗИПом

|-
|-class="highlight"
|1.040||Oryx||Rev 3.0, монтаж 2019, предназначен в ККН-сеть || IP 40, будет ЗИПом

|-
|-class="highlight"
|1.041||Oryx||Rev 3.0, монтаж 2019, предназначен в ККН-сеть || IP 41, Отмечены проблемы с прошивкой флэшки спартана. То не вычитывает ID по SPI, то на ридбэке валится. Поменяли флэшку, прогрели заново спартан. После этого чудом раза с 3го прошилась, вроде работает. Будет ЗИПом.

|-
|-class="highlight"
|1.042||Oryx||Rev 3.0, монтаж 2019, предназначен в ККН-сеть || IP 42, не завелась в нашем ящике MCR при тесте. Отключил синий кабель Samtec - завелась, так и живем. Будет ЗИПом.

|-
|-class="highlight"
|1.043||Oryx||Rev 3.0, монтаж 2019, предназначен в ККН-сеть || IP 43, будет ЗИПом

|-class="bright"
|2.001||Clonicus 1.1||||IP 111, наклеить серийник

|-class="bright"
|2.002||Clonicus 1.1||||IP 112, наклеить серийник

|-class="bright"
|2.003||Clonicus 1.1||||IP 113, наклеить серийник

|-class="bright"
|2.004||Clonicus 1.1||||IP 114, наклеить серийник

|-class="bright"
|2.005||Clonicus 1.1||||IP 115, наклеить серийник

|-class="bright"
|2.006||Clonicus 1.1||||IP 116, наклеить серийник

|-class="bright"
|2.007||Clonicus 1.2|| в псевдоспутники ||IP 117, ГРУЗИТСЯ, есть сеть, номады есть лок

|-class="bright"
|2.008||Clonicus 1.2|| в псевдоспутники ||IP 118, ГРУЗИТСЯ, есть сеть, номады есть лок

|-class="bright"
|2.009||Clonicus 1.2|| в псевдоспутники ||IP 119, ГРУЗИТСЯ, есть сеть, номады есть лок

|-class="bright"
|2.010||Clonicus 1.2|| в псевдоспутники ||IP 120, ГРУЗИТСЯ, номады есть лок

|-class="bright"
|2.011||Clonicus 1.2|| в псевдоспутники ||IP 121, ГРУЗИТСЯ, номады есть лок

|-class="bright"
|2.012||Clonicus 1.2|| в псевдоспутники ||IP 122, ГРУЗИТСЯ, номады есть лок

|-class="bright"
|2.013||Clonicus 1.2|| в псевдоспутники ||IP 123, ГРУЗИТСЯ, номады есть лок

|-class="bright"
|2.014||Clonicus 1.2|| в псевдоспутники ||IP 124, ГРУЗИТСЯ, номады есть лок

|-class="bright"
|2.015||Clonicus 1.2|| в псевдоспутники ||IP 125, ГРУЗИТСЯ, номады есть лок

|-class="bright"
|2.016||Clonicus 1.2|| в псевдоспутники ||IP 126, ГРУЗИТСЯ, номады есть лок

|-class="bright"
|2.017||Clonicus 1.2|| в псевдоспутники ||IP 127, ZYNQ 45, ГРУЗИТСЯ, номады есть лок

|-class="bright"
|2.018||Clonicus 1.2|| в псевдоспутники ||IP 128, ZYNQ 45, РАБОТАЕТ SSH, номады есть лок

|-class="highlight"
|4.001||ADC board||макет Сантиметр, у Быханова||узнать Rev ???, наклеить наклейку

|-class="highlight"
|4.002||ADC board||Rev 2.0, лежит в коробке||вход pps не подключен к ПЛИС физически (касается всех Rev 2.0)

|-
|-class="highlight"
|4.003||ADC board||опытный образец №1 Сантиметр, у Быханова||узнать Rev ???, наклеить наклейку

|-
|-class="highlight"
|4.004||ADC board||Rev 3.0, наш MCR, стоит у нас||

|-
|-class="highlight"
|4.005||ADC board||Rev 3.0, последняя закупка, опытный образец №2 Сантиметр с выводами PPS||

|-
|-class="highlight"
|4.006||ADC board||Rev 3.0, последняя закупка, отдыхает в коробке||На производстве получила пропеллер, работает так себе

|-
|-class="highlight"
|4.007||ADC board||Rev 3.0, последняя закупка, ящик ГЛОНАСС-ККН №2 (с буфферами)||

|-
|-class="highlight"
|4.008||ADC board||Rev 3.0, последняя закупка, ящик ГЛОНАСС-ККН||

|-
|-class="highlight"
|4.009||ADC board||Rev 3.0, в работу ККН-сеть|| стоит в MCR S/N: 46048-8071-008, прошивка сварена из ветки ADC3_GCLK, коммит 61628c02.

|-
|-class="highlight"
|4.010||ADC board||Rev 3.0, в работу ККН-сеть|| стоит в MCR S/N: 46048-8071-001, прошивка сварена из ветки ADC3_GCLK, коммит 61628c02.

|-
|-class="highlight"
|4.011||ADC board||Rev 3.0, в работу ККН-сеть|| стоит в MCR S/N: 46048-8071-002, прошивка сварена из ветки ADC3_GCLK, коммит 61628c02.

|-
|-class="highlight"
|4.012||ADC board||Rev 3.0, в работу ККН-сеть|| стоит в MCR S/N: 46048-8071-003, прошивка сварена из ветки ADC3_GCLK, коммит 61628c02.

|-
|-class="highlight"
|4.013||ADC board||Rev 3.0, в работу ККН-сеть|| стоит в MCR S/N: 46048-8071-004, прошивка сварена из ветки ADC3_GCLK, коммит 61628c02. LED1 не горит (возможно сгорел/не так запаян)

|-
|-class="highlight"
|4.014||ADC board||Rev 3.0, в работу ККН-сеть|| стоит в MCR S/N: 46048-8071-005, прошивка сварена из ветки ADC3_GCLK, коммит 61628c02.

|-
|-class="highlight"
|4.015||ADC board||Rev 3.0, в работу ККН-сеть|| стоит в MCR S/N: 46048-8071-006, прошивка сварена из ветки ADC3_GCLK, коммит 61628c02.

|-
|-class="highlight"
|4.016||ADC board||Rev 3.0, в работу ККН-сеть|| стоит в MCR S/N: 46048-8071-007, прошивка сварена из ветки ADC3_GCLK, коммит 61628c02. Прошилась раза с третьего.

|-
|-class="highlight"
|4.017||ADC board||Rev 3.0, в работу ККН-сеть|| прошивка сварена из ветки ADC3_GCLK, коммит 61628c02, новый стеклотекстолит TG170, будет ЗИПом

|-
|-class="highlight"
|4.018||ADC board||Rev 3.0, в работу ККН-сеть|| прошивка сварена из ветки ADC3_GCLK, коммит 61628c02, новый стеклотекстолит TG170, будет ЗИПом

|-
|-class="highlight"
|4.019||ADC board||Rev 3.0, в работу ККН-сеть|| прошивка сварена из ветки ADC3_GCLK, коммит 61628c02, новый стеклотекстолит TG170, будет ЗИПом

|-
|-class="highlight"
|4.020||ADC board||Rev 3.0, в работу ККН-сеть|| прошивка сварена из ветки ADC3_GCLK, коммит 61628c02, АЦПшка в позиции D11 - б/у с старой синей платы, новый стеклотекстолит TG170, будет ЗИПом

|-
|-class="highlight"
|4.021||ADC board||Rev 3.0, нам про запас, лежит в коробочке|| прошивка сварена из ветки ADC3_GCLK, коммит 61628c02, все АЦПшки - б/у с старой синей платы, новый стеклотекстолит TG170
|}
[[Категория:Oryx]]
[[Category:Clonicus]]

Список IP

2021-02-19T10:28:17Z

Dneprov:

{{Форма2}}

Список IP-адресов УИЦ СРТТ

{| class="wikitable" border="1"
|-align="center"
! IP
! Название
! Принадлежность
! Примечания
|-
| 192.168.0.1
|
| Внешний маршрутизатор
|
|-
| 192.168.0.2
| [http://192.168.0.2 server]
| Хранилище QNAP
|-
| 192.168.0.3
| [http://192.168.0.3 HP MFP479fdn]
| Сетевой принтер/сканер (цветной)
|
|-
| 192.168.0.4
| [http://192.168.0.4 HP M1412nfh]
| Сетевой принтер/сканер
|
|-
| 192.168.0.5
| [http://192.168.0.5 Diesel-power]
| Сетевой пилот
| Ethernet-пилот EnerGenie
|-
| 192.168.0.6
| [http://192.168.0.6 HP M443nda]
| МФУ А3 принтер/сканер
|
|-
| 192.168.0.10
| AI
| Устинов
|
|-
| 192.168.0.11
| Ivan-PC
| Липа
|
|-
| 192.168.0.12
| raspberry
| ivan
|
|-
| 192.168.0.60
| Oryx S/N 1.008
| Наш MCR
| Новый Орикс с новой печатной платой и модулем
|-
| 192.168.0.61
| Oryx S/N 1.009
| Наш MCR
| Новый Орикс с новой печатной платой и модулем
|-
| 192.168.0.62
| Oryx S/N 1.010
| Ящик ГЛОНАСС-ККН
| Новый Орикс с новой печатной платой и модулем
|-
| 192.168.0.63
| Oryx S/N 1.011
| ГЛОНАСС-ККН №2 с буферами
| Новый Орикс с новой печатной платой и модулем
|-
| 192.168.0.64
| Oryx S/N 1.012
| ГЛОНАСС-ККН №2 с буферами
| Новый Орикс с новой печатной платой и модулем
|-
| 192.168.0.65
| Oryx S/N 1.013
| ОО Сантиметр с выводами PPS'/PPSout
| Новый Орикс с новой печатной платой и модулем
|-
| 192.168.0.66
| Oryx S/N 1.014
| Забрали в июне 2017 от Филатова, у Ивана на столе
| Новый Орикс с новой печатной платой и модулем
|-
| 192.168.0.67
| Oryx S/N 1.015
| Забрали в июне 2017 от Филатова, ОО Сантиметр с выводами PPS'/PPSout
| Новый Орикс с новой печатной платой и модулем
|-
| 192.168.0.68
| Oryx S/N 1.016
| Oryx Potrable. Забрали в июне 2017 от Филатова.
| Новый Орикс с новой печатной платой и модулем. Заменил плату S/N: 1.003 (IP 163) в portable.
|-
| 192.168.0.69
| Oryx S/N 1.017
| Забрали в июне 2017 от Филатова. Лежит в коробочке.
| Новый Орикс с новой печатной платой и модулем. Наблюдаются проблемы со стартом Ethernet.
|-
| 192.168.0.80
| TP-LINK
|
| Маршрутизатор, используемый, как хаб (2014.05.15)
|-
| 192.168.0.83
| srns.ru
| Сервер
| Внешний IP 193.233.71.244
|-
| 192.168.0.92
| object-d
| Болденков
|
|-
| 192.168.0.93
| spirent
|
| Спайрент, что стоит в А-401
|-
| 192.168.0.94
| Evaluator
|
| Сервер тестирования
|-
| 192.168.0.95
| USRP E312
|
|
|-
| 192.168.0.96
| Neptune-1
| Шатилов
|
|-
| 192.168.0.99
| KorPC
| Корогодин
|
|-
| 192.168.0.110
| ZCU104
|
|MAC 00:0A:35:00:23:00
|-
| 192.168.0.111
| Clonicus 1
|
|MAC 00:0A:35:00:23:01
|-
| 192.168.0.112
| Clonicus 2
|
|MAC 00:0A:35:00:23:02
|-
| 192.168.0.117 '''...'''
| Clonicus v1.2
| Работы по псевдоспутникам
| '''Диапазон IP с 117 по 128''' занят под 12 Clonicus'ов v1.2
|-
| '''...''' 192.168.0.128
| Clonicus v1.2
| Работы по псевдоспутникам
|
|-
| 192.168.0.130
| Фарватер ЦМПО-М
| GPS L1 L2
| MAC 00:0A:35:00:01:00, с проводами, радиатор от ЗУ
|-
| 192.168.0.131
| Фарватер ЦМПО-М
| GLN L3, GPS L5
| MAC 00:0A:35:00:01:01, радиатор Gigabyte
|-
| 192.168.0.132
| Фарватер ЦМПО-М
| GLN L1 ОД
| MAC 00:0A:35:00:01:02
|-
| 192.168.0.133
| Фарватер ЦМПО-М
| GLN L1 СД
| MAC 00:0A:35:00:01:03
|-
| 192.168.0.134
| Фарватер ЦМПО-М
| GLN L2 ОД
| MAC 00:0A:35:00:01:04
|-
| 192.168.0.135
| Фарватер ЦМПО-М
| GLN L2 СД
| MAC 00:0A:35:00:01:05
|-
| 192.168.0.136
| Фарватер МПВО-М
| GLN L1
| MAC 00:0A:35:00:01:06
|-
| 192.168.0.137
| Фарватер МПВО-М
| GLN L2
| MAC 00:0A:35:00:01:07
|-
| 192.168.0.151
| Impala1
| Импала, экземпляр 1
| У Ивана
|-
| 192.168.0.152
| Impala2
| Модуль в тестовой плате
| Плата поиска в макете "Сантиметр"
|-
| 192.168.0.153
| Impala3
| Импала, экземпляр 3
| Плата коррелятора в макете "НИИ КП"
|-
| 192.168.0.154
| Impala4
| Импала, экземпляр 4 (c МАКС'а - у Андрея)
| Плата коррелятора в макете "Сантиметр"
|-
| 192.168.0.155
| Impala5
| Импала, экземпляр 5
| Плата поиска в макете "НИИ КП"
|-
| 192.168.0.156
| PLDA starter kit
|
|
|-
| 192.168.0.160
| MCR экземпляр 1
| Маршрутизатор "Сантиметра"
| Макет "Сантиметр", отдан Быханову. IP свободен
|-
| 192.168.0.161
| Oryx Экземпляр 1
| ОО Сантиметр №1, у Быханова, SN 1.001
|
|-
| 192.168.0.162
| Oryx Экземпляр 2
| Лежит без дела в коробочке, SN 1.002
|
|-
| 192.168.0.163
| Oryx Экземпляр 3
| Был Oryx portable, сломался разъем Ethernet, заменен. Лежит в коробочке.
| MAC 00:0A:35:00:01:63
|-
| 192.168.0.164
| Oryx Экземпляр 4
| Black Box, предположительно SN 1.004
| MAC 00:0A:35:00:01:64
|-
| 192.168.0.165
| Oryx Экземпляр 5
| Неизвестно, где она, SN 1.005
|
|-
| 192.168.0.166
| Oryx Экземпляр 6
| ОО Сантиметр №1, у Быханова, SN 1.006
|
|-
| 192.168.0.167
| Oryx Экземпляр 7
| Ящик ГЛОНАСС-ККН, предположительно SN 1.007
| '''ВАЖНО! Ранее этот IP был Маршрутизатор "Сантиметра" - 2'''
|-
| 192.168.0.168
| MCR экземпляр 3
| Маршрутизатор "Сантиметра" - 3
| Стоит на столе СПРАВА
|-
| 192.168.0.169
| Наш MCR с экраном
| Компьютер Тион-ПРО 2
|
|-
| 192.168.0.171
| Наш MCR с экраном
| Маршрутизатор MCR с экраном
|
|-
| 192.168.0.174
| R&S BBA150
| Усилитель R&S 30Вт
|
|-
| 192.168.0.175
|
| [[R&S SMBV100A S/N 257717 (прибор)|R&S SMBV100A S/N 257717]]
|
|-
| 192.168.0.176
|
| [[R&S SMBV100A S/N 257718 (прибор)|R&S SMBV100A S/N 257718]]
|
|-
| 192.168.0.177
|
| [[R&S SMBV100A S/N 256978 (прибор)|R&S SMBV100A S/N 256978]]
| Инв. номер 4186
|-
| 192.168.0.178
|
| [[R&S SMBV100A S/N 257721 (прибор)|R&S SMBV100A S/N 257721]]
|
|-
| 192.168.0.179
|
| [[R&S SMBV100A S/N 257716 (прибор)|R&S SMBV100A S/N 257716]]
|
|-
| 192.168.0.180
|
| [[Spirent_GSS6737-3_S/N_1201383_(прибор) | Spirent GSS6737-3]]
| его нет
|-
| 192.168.0.186
| ZYNQ z702
|
| ТЕКУЩИЙ IP = 0.186
При изменении uImage сбивается. Настройка: vi /etc/network/interfaces
|-
| 192.168.0.187
| ZYNQ z706
|
| Наша первая плата Z-706
|-
| 192.168.0.188
| ZYNQ z706/2
|
| Вторая плата Z-706, которую дали для фарватера на время(MAC 00:0A:35:00:F1:88)
|-
| 192.168.0.189
| Lenovo Q180 #1 Aka Wirelessdude
|
| Неттоп с ви-фи (передатчик)
|-
| 192.168.0.190
| Lenovo Q180 #2 Aka Wirelessdude2
|
| Неттоп с ви-фи (приемник)
|-
| >= 192.168.0.200
|
|
| Область динамических адресов
|}

[[Категория:SRNS.ru]]

Список IP

2021-02-19T06:29:56Z

Dneprov:

{{Форма2}}

Список IP-адресов УИЦ СРТТ

{| class="wikitable" border="1"
|-align="center"
! IP
! Название
! Принадлежность
! Примечания
|-
| 192.168.0.1
|
| Внешний маршрутизатор
|
|-
| 192.168.0.2
| [http://192.168.0.2 server]
| Хранилище QNAP
|-
| 192.168.0.3
| [http://192.168.0.3 HP MFP479fdn]
| Сетевой принтер/сканер (цветной)
|
|-
| 192.168.0.4
| [http://192.168.0.4 HP M1412nfh]
| Сетевой принтер/сканер
|
|-
| 192.168.0.5
| [http://192.168.0.5 Diesel-power]
| Сетевой пилот
| Ethernet-пилот EnerGenie
|-
| 192.168.0.10
| AI
| Устинов
|
|-
| 192.168.0.11
| Ivan-PC
| Липа
|
|-
| 192.168.0.12
| raspberry
| ivan
|
|-
| 192.168.0.60
| Oryx S/N 1.008
| Наш MCR
| Новый Орикс с новой печатной платой и модулем
|-
| 192.168.0.61
| Oryx S/N 1.009
| Наш MCR
| Новый Орикс с новой печатной платой и модулем
|-
| 192.168.0.62
| Oryx S/N 1.010
| Ящик ГЛОНАСС-ККН
| Новый Орикс с новой печатной платой и модулем
|-
| 192.168.0.63
| Oryx S/N 1.011
| ГЛОНАСС-ККН №2 с буферами
| Новый Орикс с новой печатной платой и модулем
|-
| 192.168.0.64
| Oryx S/N 1.012
| ГЛОНАСС-ККН №2 с буферами
| Новый Орикс с новой печатной платой и модулем
|-
| 192.168.0.65
| Oryx S/N 1.013
| ОО Сантиметр с выводами PPS'/PPSout
| Новый Орикс с новой печатной платой и модулем
|-
| 192.168.0.66
| Oryx S/N 1.014
| Забрали в июне 2017 от Филатова, у Ивана на столе
| Новый Орикс с новой печатной платой и модулем
|-
| 192.168.0.67
| Oryx S/N 1.015
| Забрали в июне 2017 от Филатова, ОО Сантиметр с выводами PPS'/PPSout
| Новый Орикс с новой печатной платой и модулем
|-
| 192.168.0.68
| Oryx S/N 1.016
| Oryx Potrable. Забрали в июне 2017 от Филатова.
| Новый Орикс с новой печатной платой и модулем. Заменил плату S/N: 1.003 (IP 163) в portable.
|-
| 192.168.0.69
| Oryx S/N 1.017
| Забрали в июне 2017 от Филатова. Лежит в коробочке.
| Новый Орикс с новой печатной платой и модулем. Наблюдаются проблемы со стартом Ethernet.
|-
| 192.168.0.80
| TP-LINK
|
| Маршрутизатор, используемый, как хаб (2014.05.15)
|-
| 192.168.0.83
| srns.ru
| Сервер
| Внешний IP 193.233.71.244
|-
| 192.168.0.92
| object-d
| Болденков
|
|-
| 192.168.0.93
| spirent
|
| Спайрент, что стоит в А-401
|-
| 192.168.0.94
| Evaluator
|
| Сервер тестирования
|-
| 192.168.0.95
| USRP E312
|
|
|-
| 192.168.0.96
| Neptune-1
| Шатилов
|
|-
| 192.168.0.99
| KorPC
| Корогодин
|
|-
| 192.168.0.110
| ZCU104
|
|MAC 00:0A:35:00:23:00
|-
| 192.168.0.111
| Clonicus 1
|
|MAC 00:0A:35:00:23:01
|-
| 192.168.0.112
| Clonicus 2
|
|MAC 00:0A:35:00:23:02
|-
| 192.168.0.117 '''...'''
| Clonicus v1.2
| Работы по псевдоспутникам
| '''Диапазон IP с 117 по 128''' занят под 12 Clonicus'ов v1.2
|-
| '''...''' 192.168.0.128
| Clonicus v1.2
| Работы по псевдоспутникам
|
|-
| 192.168.0.130
| Фарватер ЦМПО-М
| GPS L1 L2
| MAC 00:0A:35:00:01:00, с проводами, радиатор от ЗУ
|-
| 192.168.0.131
| Фарватер ЦМПО-М
| GLN L3, GPS L5
| MAC 00:0A:35:00:01:01, радиатор Gigabyte
|-
| 192.168.0.132
| Фарватер ЦМПО-М
| GLN L1 ОД
| MAC 00:0A:35:00:01:02
|-
| 192.168.0.133
| Фарватер ЦМПО-М
| GLN L1 СД
| MAC 00:0A:35:00:01:03
|-
| 192.168.0.134
| Фарватер ЦМПО-М
| GLN L2 ОД
| MAC 00:0A:35:00:01:04
|-
| 192.168.0.135
| Фарватер ЦМПО-М
| GLN L2 СД
| MAC 00:0A:35:00:01:05
|-
| 192.168.0.136
| Фарватер МПВО-М
| GLN L1
| MAC 00:0A:35:00:01:06
|-
| 192.168.0.137
| Фарватер МПВО-М
| GLN L2
| MAC 00:0A:35:00:01:07
|-
| 192.168.0.151
| Impala1
| Импала, экземпляр 1
| У Ивана
|-
| 192.168.0.152
| Impala2
| Модуль в тестовой плате
| Плата поиска в макете "Сантиметр"
|-
| 192.168.0.153
| Impala3
| Импала, экземпляр 3
| Плата коррелятора в макете "НИИ КП"
|-
| 192.168.0.154
| Impala4
| Импала, экземпляр 4 (c МАКС'а - у Андрея)
| Плата коррелятора в макете "Сантиметр"
|-
| 192.168.0.155
| Impala5
| Импала, экземпляр 5
| Плата поиска в макете "НИИ КП"
|-
| 192.168.0.156
| PLDA starter kit
|
|
|-
| 192.168.0.160
| MCR экземпляр 1
| Маршрутизатор "Сантиметра"
| Макет "Сантиметр", отдан Быханову. IP свободен
|-
| 192.168.0.161
| Oryx Экземпляр 1
| ОО Сантиметр №1, у Быханова, SN 1.001
|
|-
| 192.168.0.162
| Oryx Экземпляр 2
| Лежит без дела в коробочке, SN 1.002
|
|-
| 192.168.0.163
| Oryx Экземпляр 3
| Был Oryx portable, сломался разъем Ethernet, заменен. Лежит в коробочке.
| MAC 00:0A:35:00:01:63
|-
| 192.168.0.164
| Oryx Экземпляр 4
| Black Box, предположительно SN 1.004
| MAC 00:0A:35:00:01:64
|-
| 192.168.0.165
| Oryx Экземпляр 5
| Неизвестно, где она, SN 1.005
|
|-
| 192.168.0.166
| Oryx Экземпляр 6
| ОО Сантиметр №1, у Быханова, SN 1.006
|
|-
| 192.168.0.167
| Oryx Экземпляр 7
| Ящик ГЛОНАСС-ККН, предположительно SN 1.007
| '''ВАЖНО! Ранее этот IP был Маршрутизатор "Сантиметра" - 2'''
|-
| 192.168.0.168
| MCR экземпляр 3
| Маршрутизатор "Сантиметра" - 3
| Стоит на столе СПРАВА
|-
| 192.168.0.169
| Наш MCR с экраном
| Компьютер Тион-ПРО 2
|
|-
| 192.168.0.171
| Наш MCR с экраном
| Маршрутизатор MCR с экраном
|
|-
| 192.168.0.174
| R&S BBA150
| Усилитель R&S 30Вт
|
|-
| 192.168.0.175
|
| [[R&S SMBV100A S/N 257717 (прибор)|R&S SMBV100A S/N 257717]]
|
|-
| 192.168.0.176
|
| [[R&S SMBV100A S/N 257718 (прибор)|R&S SMBV100A S/N 257718]]
|
|-
| 192.168.0.177
|
| [[R&S SMBV100A S/N 256978 (прибор)|R&S SMBV100A S/N 256978]]
| Инв. номер 4186
|-
| 192.168.0.178
|
| [[R&S SMBV100A S/N 257721 (прибор)|R&S SMBV100A S/N 257721]]
|
|-
| 192.168.0.179
|
| [[R&S SMBV100A S/N 257716 (прибор)|R&S SMBV100A S/N 257716]]
|
|-
| 192.168.0.180
|
| [[Spirent_GSS6737-3_S/N_1201383_(прибор) | Spirent GSS6737-3]]
| его нет
|-
| 192.168.0.186
| ZYNQ z702
|
| ТЕКУЩИЙ IP = 0.186
При изменении uImage сбивается. Настройка: vi /etc/network/interfaces
|-
| 192.168.0.187
| ZYNQ z706
|
| Наша первая плата Z-706
|-
| 192.168.0.188
| ZYNQ z706/2
|
| Вторая плата Z-706, которую дали для фарватера на время(MAC 00:0A:35:00:F1:88)
|-
| 192.168.0.189
| Lenovo Q180 #1 Aka Wirelessdude
|
| Неттоп с ви-фи (передатчик)
|-
| 192.168.0.190
| Lenovo Q180 #2 Aka Wirelessdude2
|
| Неттоп с ви-фи (приемник)
|-
| >= 192.168.0.200
|
|
| Область динамических адресов
|}

[[Категория:SRNS.ru]]

MCR

2021-01-27T10:49:44Z

Dneprov: /* Руководство по эксплуатации */

{{Форма3}}
{{НАП
|Модель = MultiChannel Receiver
|Сущность = [[фронтенд]], многочастотный приемник
|Фотография = [[Файл:MCR_raw.png|300px]]
|Назначение = линейный фронтенд
|Навигационные сигналы =
GPS L1, L2<br>
ГЛОНАСС L1, L2
|Первые образцы = 2014 г в рамках СЧ ОКР "Сантиметр-М"
|Начало продаж =
|Разработчик = [[Advantex]] (каф. РПУ МЭИ) + УИЦ СРТТ (в цифровой части)
|Производитель = Корпус фирмы [https://schroff.pentair.com/en/schroff-apac/Ratiopac-PRO Schroff]


|Родственные модели =
|Модификации =


|Энергопотребление =
|Номинал напряжения питания =


|Размеры =
|Масса =


|Чувствительность coldstart =
|Чувствительность navigation =
|Время coldstart =
|Время warmstart =
|Время hotstart =
|Перезахват =


|Точность плановых координат =
|Точность высоты =
|Точность скорости =
|Точность времени =


|Рекомендуемый антенный модуль =
|Дополнительно об антмодуле =
|Антенный элемент =
|Диапазон частот антмодуля =
|Ку антенны =
|Кэ антенны =
|Питание антенного модуля =
|Ку МШУ =
|Кш МШУ =
|Выходной импеданс антмодуля =
|КСВН выхода антмодуля =
|Интерфейс антмодуля =


|Динамический диапазон = [[Измерение_SINAD_ящика_AVDNов|39-55 дБ]]
|Кш фронтенда = 11 дБ
|Число промежуточных частот = 2
|АРУ =
|Нижняя промежуточная частота =


|Разрядность АЦП =
|Частота дискретизации =


|Машина быстрого поиска =
|Число эквивалентных корреляторов=


|Исполнение коррелятора =
|Число каналов коррелятора =
|Коррелятор и многолучевость =
|Темп работы =


|Этапность алгоритмов слежения =
|Слежение за частотой =
|Оценка задержки =
|Оценка частоты =
|Оценка фазы =
|Оценка амплитуды =
|Оценка шума =
|Выделение НИ =


|Темп решения навзадачи =
|Описание решения навзадачи =
|Расчет скорости потребителя =
|Расчет времени потребителя =
|Расчет ориентации потребителя =
|Разрешение неоднозначности =
}}

'''MCR''' (''MultiChannel Receiver'') - макетный образец прецизионного навигационного приемника или его аналого-коробочная часть.

== Интерфейс ==

== Основные рабочие характеристики ==

=== Степень линейности ===

=== Потребление ===

=== Усиление ===

=== Полоса ===

=== Опорный генератор ===

== Интересные факты ==

== Настройка ==
=== Через RealTerm ===
* Настройка каналов фронтенда (по Profilic COM, командами SCPI).
** Параметры порта: 115200, 8 bit, no parity.
** *IDN? - проверка подключения, возвращает ID прибора.
** Если MCR не отвечает на команды, следует проверить посылку в конце команд EOL (End of Line), данная опция может быть отключена у терминала.
** Команды управления частотой, усилением и пр., а также различные данные о приборе содержатся в руководстве по эксплуатации (см. далее).
[[File:20160824_realterm_send_options_for_MCR.png|400px]]
* Истинное значение параметра DEM: GAIN (коэффициент усиления) при записанном 63 дБ равно 41 дБ ! Требуется проверять для каждого фронтенда.

=== Через MATLAB ===

Устали мы через Realterm настраивать. Сделали свою программу настройки. Работает из Windows. Как и для Realterm, нужно подключить usb-rs преобразователь.

[[File:MCR_gui.PNG|400px]]

Программа умеет:
* Соединять с прибором автоматически по нажатию любой большой кнопки.
* Узнать, что там у MCR сейчас настроено. Кнопка '''Check MCR'''.
* Настроить MCR на частотные планы под кодовыми названиями SPP и SRTT. Кнопки '''SPP''' и '''SRTT''' соответственно.
* Сделать сброс (команда *RST). Кнопка '''RESET'''.
* Сохранить текущие настройки (команда SAVE:CURRENT). Кнопка '''SAVE'''.
* Вручную настроить некоторые параметры соответствующими кнопками.

== Прошивка ==

Есть возможность прошивать MCR в части блока управления. Нужно это для точной установки кода частоты (FTW) в DDS синтезатора тактового сигнала. Подробнее см. [[Blog:Korogodin/28.07.16 Очередная смена частотного плана|тут]].

Файлы и инструкции по прошивке лежат в архиве [[Media:MCR_MCU.zip|MCR_MCU]].

== Расчет промежуточных частот ==

Иногда приходится настраивать в MCR и fpga.cpp новые промежуточные частоты. Для их удобного расчета сделан матлаб-скрипт. Ему надо рассказать, какая у нас тактовая частота. Он сам проверит, сможет ли синтезатор сделать такую частоту. Частоты гетеродинов рассчитываются по формуле для дробно-переменного делителя частоты ([[Blog:Korogodin/28.07.16 Очередная смена частотного плана|как тут]]). Но можно и ручками задать.

Скачать [[Media:20161115_MCR_IF_freq.rar|матлаб-скрипт]].

== Протоколы испытаний ==
При передаче изделий были проведены измерения основных парметров РЧБ. Чтобы не потерять, вот протоколы:

1. [[Media:Протокол 1 MCR.pdf|Протокол испытаний одного из опытных образцов MCR]]

2. [[Media:Протокол 2 MCR.pdf|Пока не установлено чей протокол + парочка страниц потеряна]]

== Руководство по эксплуатации ==

[[Media:20160729_РЭ_рчб_ред2.pdf|Руководство PDF.]]

[[Media:20150112 РЭ рчб_ред2.doc|Руководство DOC.]]

[[Media:DSG3_Manual.pdf|Руководство по синтезатору частот DSG3 PDF.]]

[[Media:MCR_DEM.jpeg| Схема приемного модуля (где I, где Q). Прислал Петр Бобкович.]]

[[Категория: RF]]
[[Категория: Фронтенд]]

MCR

2021-01-27T10:49:31Z

Dneprov: /* Руководство по эксплуатации */

{{Форма3}}
{{НАП
|Модель = MultiChannel Receiver
|Сущность = [[фронтенд]], многочастотный приемник
|Фотография = [[Файл:MCR_raw.png|300px]]
|Назначение = линейный фронтенд
|Навигационные сигналы =
GPS L1, L2<br>
ГЛОНАСС L1, L2
|Первые образцы = 2014 г в рамках СЧ ОКР "Сантиметр-М"
|Начало продаж =
|Разработчик = [[Advantex]] (каф. РПУ МЭИ) + УИЦ СРТТ (в цифровой части)
|Производитель = Корпус фирмы [https://schroff.pentair.com/en/schroff-apac/Ratiopac-PRO Schroff]


|Родственные модели =
|Модификации =


|Энергопотребление =
|Номинал напряжения питания =


|Размеры =
|Масса =


|Чувствительность coldstart =
|Чувствительность navigation =
|Время coldstart =
|Время warmstart =
|Время hotstart =
|Перезахват =


|Точность плановых координат =
|Точность высоты =
|Точность скорости =
|Точность времени =


|Рекомендуемый антенный модуль =
|Дополнительно об антмодуле =
|Антенный элемент =
|Диапазон частот антмодуля =
|Ку антенны =
|Кэ антенны =
|Питание антенного модуля =
|Ку МШУ =
|Кш МШУ =
|Выходной импеданс антмодуля =
|КСВН выхода антмодуля =
|Интерфейс антмодуля =


|Динамический диапазон = [[Измерение_SINAD_ящика_AVDNов|39-55 дБ]]
|Кш фронтенда = 11 дБ
|Число промежуточных частот = 2
|АРУ =
|Нижняя промежуточная частота =


|Разрядность АЦП =
|Частота дискретизации =


|Машина быстрого поиска =
|Число эквивалентных корреляторов=


|Исполнение коррелятора =
|Число каналов коррелятора =
|Коррелятор и многолучевость =
|Темп работы =


|Этапность алгоритмов слежения =
|Слежение за частотой =
|Оценка задержки =
|Оценка частоты =
|Оценка фазы =
|Оценка амплитуды =
|Оценка шума =
|Выделение НИ =


|Темп решения навзадачи =
|Описание решения навзадачи =
|Расчет скорости потребителя =
|Расчет времени потребителя =
|Расчет ориентации потребителя =
|Разрешение неоднозначности =
}}

'''MCR''' (''MultiChannel Receiver'') - макетный образец прецизионного навигационного приемника или его аналого-коробочная часть.

== Интерфейс ==

== Основные рабочие характеристики ==

=== Степень линейности ===

=== Потребление ===

=== Усиление ===

=== Полоса ===

=== Опорный генератор ===

== Интересные факты ==

== Настройка ==
=== Через RealTerm ===
* Настройка каналов фронтенда (по Profilic COM, командами SCPI).
** Параметры порта: 115200, 8 bit, no parity.
** *IDN? - проверка подключения, возвращает ID прибора.
** Если MCR не отвечает на команды, следует проверить посылку в конце команд EOL (End of Line), данная опция может быть отключена у терминала.
** Команды управления частотой, усилением и пр., а также различные данные о приборе содержатся в руководстве по эксплуатации (см. далее).
[[File:20160824_realterm_send_options_for_MCR.png|400px]]
* Истинное значение параметра DEM: GAIN (коэффициент усиления) при записанном 63 дБ равно 41 дБ ! Требуется проверять для каждого фронтенда.

=== Через MATLAB ===

Устали мы через Realterm настраивать. Сделали свою программу настройки. Работает из Windows. Как и для Realterm, нужно подключить usb-rs преобразователь.

[[File:MCR_gui.PNG|400px]]

Программа умеет:
* Соединять с прибором автоматически по нажатию любой большой кнопки.
* Узнать, что там у MCR сейчас настроено. Кнопка '''Check MCR'''.
* Настроить MCR на частотные планы под кодовыми названиями SPP и SRTT. Кнопки '''SPP''' и '''SRTT''' соответственно.
* Сделать сброс (команда *RST). Кнопка '''RESET'''.
* Сохранить текущие настройки (команда SAVE:CURRENT). Кнопка '''SAVE'''.
* Вручную настроить некоторые параметры соответствующими кнопками.

== Прошивка ==

Есть возможность прошивать MCR в части блока управления. Нужно это для точной установки кода частоты (FTW) в DDS синтезатора тактового сигнала. Подробнее см. [[Blog:Korogodin/28.07.16 Очередная смена частотного плана|тут]].

Файлы и инструкции по прошивке лежат в архиве [[Media:MCR_MCU.zip|MCR_MCU]].

== Расчет промежуточных частот ==

Иногда приходится настраивать в MCR и fpga.cpp новые промежуточные частоты. Для их удобного расчета сделан матлаб-скрипт. Ему надо рассказать, какая у нас тактовая частота. Он сам проверит, сможет ли синтезатор сделать такую частоту. Частоты гетеродинов рассчитываются по формуле для дробно-переменного делителя частоты ([[Blog:Korogodin/28.07.16 Очередная смена частотного плана|как тут]]). Но можно и ручками задать.

Скачать [[Media:20161115_MCR_IF_freq.rar|матлаб-скрипт]].

== Протоколы испытаний ==
При передаче изделий были проведены измерения основных парметров РЧБ. Чтобы не потерять, вот протоколы:

1. [[Media:Протокол 1 MCR.pdf|Протокол испытаний одного из опытных образцов MCR]]

2. [[Media:Протокол 2 MCR.pdf|Пока не установлено чей протокол + парочка страниц потеряна]]

== Руководство по эксплуатации ==

[[Media:20160729_РЭ_рчб_ред2.pdf|Руководство PDF.]]

[[Media:20150112 РЭ рчб_ред2.doc|Руководство DOC.]]

[[Media:DSG3_Manual.pdf|Руководство по синтезатору частот DSG3 PDF.]]

[[Media:MCR_DEM.jpeg| Схема приемного модуля (где I, где Q) Прислал Петр Бобкович]]

[[Категория: RF]]
[[Категория: Фронтенд]]

Файл:MCR DEM.jpeg

2021-01-27T10:48:57Z

Dneprov: MsUpload

MsUpload

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

2020-12-14T06:34:32Z

Dneprov: /* 2020.07.21 - Очередные мучения с PPS OUT в ККН */

<summary [ hidden ]>

Записи о текущих испытаниях Орикса, Клоникуса и т.п.
</summary>

{{Форма3}}

{{TOCright}}

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

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

Желательно записывать следующие данные:
* дату испытания (в заголовке);
* номер ревизии 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 минут работы:
[[image:Screenshot_20200605_131702.png|center]]

Плотность отправки пакетов:
[[image:Screenshot_20200605_132120.png|center]]

Наибольшую плотность создает отправка эфемерид каждый 30 секунд, несколько десятков пакетов (сотня-две при полной нагрузке):
[[image:20200506_enp4s0_001.png|center]]

При этом достигается пиковая скорость 5кбайт/мс (50 при экстраполяции на полную нагрузку):
[[image:20200506_enp4s0_002.png|center]]



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

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

Измерения от 12 спутников отправляются раз в секунду в пакете 0xF5, 12 спутников занимают порядка 400 байт:
[[image:20200506_enp4s0_003.png|center]]

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

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

== 2020.07.21 - Очередные мучения с PPS OUT в ККН ==

* номер ревизии PL: [https://gitlab.srns.ru:8080/git/src/commit/2c9bf757016cb7796a6188fce514a494d92cdad8 | 2c9bf757]
* номер ревизии PS: [https://gitlab.srns.ru:8080/git/src/commit/fc467aa0d30a6d5f54445cc8153944d2d3d9dd0e | fc467aa0]
* номер ревизии PL южного моста: [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/f695100df9f88f713932f8daeabf75aa352c1d1c | f695100d]
* номер ревизии PL платы АЦП: [https://gitlab.srns.ru:8080/git/adc_rev3/commit/0a0015868fb8a8914e0abed88c4ec5603d6eeb7b | 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: [https://gitlab.srns.ru:8080/git/src/commit/2c9bf757016cb7796a6188fce514a494d92cdad8 | 2c9bf757]
* номер ревизии PS: [https://gitlab.srns.ru:8080/git/src/commit/fc467aa0d30a6d5f54445cc8153944d2d3d9dd0e | fc467aa0]
* номер ревизии PL южного моста: [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/f695100df9f88f713932f8daeabf75aa352c1d1c | f695100d]
* номер ревизии PL платы АЦП: [https://gitlab.srns.ru:8080/git/adc_rev3/commit/0a0015868fb8a8914e0abed88c4ec5603d6eeb7b | 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.

[[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.
** сделано в коммите [https://gitlab.srns.ru:8080/git/adc_rev3/commit/558992d20fd15d5e92f8031fcea4fbed1cd9d225 | 558992d2]
* Поднять обратно 3-ю АЦП.
** сделано в коммите [https://gitlab.srns.ru:8080/git/adc_rev3/commit/2c6556f0588640dd321f68038dc4066e37c2f80f | 2c6556f0]
* Завести синхросигнал SYNC с помощью делителей на 3 микросхемы АЦП.
** сделано в коммите [https://gitlab.srns.ru:8080/git/adc_rev3/commit/2c6556f0588640dd321f68038dc4066e37c2f80f | 2c6556f0]
* Прокинуть их (SYNC) c трех микросхем АЦП и PPS_In с буффера по Samtec в ZynQ
** сделано в коммите [https://gitlab.srns.ru:8080/git/adc_rev3/commit/2c6556f0588640dd321f68038dc4066e37c2f80f | 2c6556f0]
* Проверить их датаколлектором, убедиться в их адекватном внешнем виде, убедиться в наличии задержек между микросхемами АЦП.
** Проверяли на компе у Сереги. Увидели прямоугольные импульсы SYNC и PPS_IN (с буффера платы АЦП). Почему-то PPS_IN опаздывает относительно сигналов SYNC, хотя должно быть наоборот. Проблема может быть как в отображении самой программы датаколлектора, так и в реализации датаколлектора в ПЛИС (как он пишет по времени и вычитывает по времени).
* Сделать в ZynQ схему выравнивания АЦП между собой: она должна принимать 3 сигнала SYNC, смотреть задержку между ними, и задерживать потоки данных от всех микросхем АЦП к самому задержанному. Также она должна оценивать задержку Delta между PPS_In с буфера платы АЦП и синалом SYNC (каким, выровненным к задержками или как?)
** Иван сделал в коммите [https://gitlab.srns.ru:8080/git/src/commit/05c5e5fc250c7b2663003214f43fab26b5f61532 | 05c5e5fc] (на самом деле в 5cc547ee, по ссылке лишь обновленный тикль). Пока никто не проверял это кроме него и в с++ не встраивал.
* Учесть измеренную Delta в выдаче PPS_Out из ZynQ
* Убираем в южном мосту Oryx схему с еще одним формированием PPS_Out на счетчиках. Будем перещелкивать PPS_Out из ZynQ в клоки MCR - упрощаем монстра.
** сделано в коммите [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/3ecc30ce1dedb84c636e05821723add06d97217a | 3ecc30ce]

Два

* Оценить стабильность задержки от SER Samtec платы АЦП до DESER ZynQ в Oryx.
** Эксперимент проведен, [[#2020.07.27 - Постоянство задержки от сериалайзера платы АЦП до десериалайзера платы Oryx| результат чуть выше]]. Есть проблема со скачком на клок от включения к включению.
** Иван начал перепиливать плату АЦП, выкинул SER в ней и DESER в ZynQ. Данные от АЦП кладет просто в ODDR в дифф.линии Samtec в расчете на режим DDR. Провели эксперимент, как и в предыдущем пункте. PPS_IN между АЦП и Oryx больше не прыгает. Также посмотрели дата-коллектором в линии от АЦП - увидели там гармоники, т.е. как будто бы передача данных по Samtec между платой АЦП и Oryx работает без SER-DES цепочки. '''Важный ньюанс''' - т.к. хотим данные передавать в режиме DDR, для их защелкивания в ZynQ нужен клок, который был бы по середине бита данных. Оказалось, что на плате Oryx есть буфер, который делает из дифф-сингл клоки, и вносит задержку в клоки от АЦП порядка 2.5 нс на 100 МГц, т.е. 90 градусов, что нам и нужно. Поэтому просто берем и защелкиваем данные из АЦП в Цинке клоками, которые кинули из АЦП и они добрались до Цинка.

Три

* Чинить/освежать блоки Calibration и RefInterp в Oryx
** Calibration переделан тут (см. два мердженных коммита) [https://gitlab.srns.ru:8080/git/src/commit/1f59ed4248d6d644a31e3fa8171bf60cdedf7194 | 1f59ed42].
** RefInterp переделан тут (PL [https://gitlab.srns.ru:8080/git/src/commit/8d93c996a488ab41515b36121aae84b20cec9fce | 8d93c996], PS [https://gitlab.srns.ru:8080/git/src/commit/d873d357c66d5c9a0d192748a141d76eef8735a5 | d873d357]).
* Поднять UART из ZynQ для управления MCR, прокинуть его через южный мост к плате управления MCR. Там есть джамперы и 3х-пиновый разъем, можно переключаться между разъем на панели прибора / спец разъем.
** Сделано, работает. Коммит src [https://gitlab.srns.ru:8080/git/src/commit/33be60030193279208fa79a1bebb615673422794 | 33be6003]. Коммит южного моста [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/67ed0dbe96634ae136db85261b2c763aed7b31d5 | 67ed0dbe].

{{wl-publish: 2020-06-05 12:52:18 +0300 | Korogodin }}

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

2020-12-14T06:33:53Z

Dneprov: /* 2020.07.27 - Постоянство задержки от сериалайзера платы АЦП до десериалайзера платы Oryx */

<summary [ hidden ]>

Записи о текущих испытаниях Орикса, Клоникуса и т.п.
</summary>

{{Форма3}}

{{TOCright}}

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

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

Желательно записывать следующие данные:
* дату испытания (в заголовке);
* номер ревизии 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 минут работы:
[[image:Screenshot_20200605_131702.png|center]]

Плотность отправки пакетов:
[[image:Screenshot_20200605_132120.png|center]]

Наибольшую плотность создает отправка эфемерид каждый 30 секунд, несколько десятков пакетов (сотня-две при полной нагрузке):
[[image:20200506_enp4s0_001.png|center]]

При этом достигается пиковая скорость 5кбайт/мс (50 при экстраполяции на полную нагрузку):
[[image:20200506_enp4s0_002.png|center]]



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

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

Измерения от 12 спутников отправляются раз в секунду в пакете 0xF5, 12 спутников занимают порядка 400 байт:
[[image:20200506_enp4s0_003.png|center]]

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

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

== 2020.07.21 - Очередные мучения с PPS OUT в ККН ==

* номер ревизии PL: [https://gitlab.srns.ru:8080/git/src/commit/2c9bf757016cb7796a6188fce514a494d92cdad8| 2c9bf757]
* номер ревизии PS: [https://gitlab.srns.ru:8080/git/src/commit/fc467aa0d30a6d5f54445cc8153944d2d3d9dd0e| fc467aa0]
* номер ревизии PL южного моста: [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/f695100df9f88f713932f8daeabf75aa352c1d1c| f695100d]
* номер ревизии PL платы АЦП: [https://gitlab.srns.ru:8080/git/adc_rev3/commit/0a0015868fb8a8914e0abed88c4ec5603d6eeb7b| 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: [https://gitlab.srns.ru:8080/git/src/commit/2c9bf757016cb7796a6188fce514a494d92cdad8 | 2c9bf757]
* номер ревизии PS: [https://gitlab.srns.ru:8080/git/src/commit/fc467aa0d30a6d5f54445cc8153944d2d3d9dd0e | fc467aa0]
* номер ревизии PL южного моста: [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/f695100df9f88f713932f8daeabf75aa352c1d1c | f695100d]
* номер ревизии PL платы АЦП: [https://gitlab.srns.ru:8080/git/adc_rev3/commit/0a0015868fb8a8914e0abed88c4ec5603d6eeb7b | 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.

[[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.
** сделано в коммите [https://gitlab.srns.ru:8080/git/adc_rev3/commit/558992d20fd15d5e92f8031fcea4fbed1cd9d225 | 558992d2]
* Поднять обратно 3-ю АЦП.
** сделано в коммите [https://gitlab.srns.ru:8080/git/adc_rev3/commit/2c6556f0588640dd321f68038dc4066e37c2f80f | 2c6556f0]
* Завести синхросигнал SYNC с помощью делителей на 3 микросхемы АЦП.
** сделано в коммите [https://gitlab.srns.ru:8080/git/adc_rev3/commit/2c6556f0588640dd321f68038dc4066e37c2f80f | 2c6556f0]
* Прокинуть их (SYNC) c трех микросхем АЦП и PPS_In с буффера по Samtec в ZynQ
** сделано в коммите [https://gitlab.srns.ru:8080/git/adc_rev3/commit/2c6556f0588640dd321f68038dc4066e37c2f80f | 2c6556f0]
* Проверить их датаколлектором, убедиться в их адекватном внешнем виде, убедиться в наличии задержек между микросхемами АЦП.
** Проверяли на компе у Сереги. Увидели прямоугольные импульсы SYNC и PPS_IN (с буффера платы АЦП). Почему-то PPS_IN опаздывает относительно сигналов SYNC, хотя должно быть наоборот. Проблема может быть как в отображении самой программы датаколлектора, так и в реализации датаколлектора в ПЛИС (как он пишет по времени и вычитывает по времени).
* Сделать в ZynQ схему выравнивания АЦП между собой: она должна принимать 3 сигнала SYNC, смотреть задержку между ними, и задерживать потоки данных от всех микросхем АЦП к самому задержанному. Также она должна оценивать задержку Delta между PPS_In с буфера платы АЦП и синалом SYNC (каким, выровненным к задержками или как?)
** Иван сделал в коммите [https://gitlab.srns.ru:8080/git/src/commit/05c5e5fc250c7b2663003214f43fab26b5f61532 | 05c5e5fc] (на самом деле в 5cc547ee, по ссылке лишь обновленный тикль). Пока никто не проверял это кроме него и в с++ не встраивал.
* Учесть измеренную Delta в выдаче PPS_Out из ZynQ
* Убираем в южном мосту Oryx схему с еще одним формированием PPS_Out на счетчиках. Будем перещелкивать PPS_Out из ZynQ в клоки MCR - упрощаем монстра.
** сделано в коммите [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/3ecc30ce1dedb84c636e05821723add06d97217a | 3ecc30ce]

Два

* Оценить стабильность задержки от SER Samtec платы АЦП до DESER ZynQ в Oryx.
** Эксперимент проведен, [[#2020.07.27 - Постоянство задержки от сериалайзера платы АЦП до десериалайзера платы Oryx| результат чуть выше]]. Есть проблема со скачком на клок от включения к включению.
** Иван начал перепиливать плату АЦП, выкинул SER в ней и DESER в ZynQ. Данные от АЦП кладет просто в ODDR в дифф.линии Samtec в расчете на режим DDR. Провели эксперимент, как и в предыдущем пункте. PPS_IN между АЦП и Oryx больше не прыгает. Также посмотрели дата-коллектором в линии от АЦП - увидели там гармоники, т.е. как будто бы передача данных по Samtec между платой АЦП и Oryx работает без SER-DES цепочки. '''Важный ньюанс''' - т.к. хотим данные передавать в режиме DDR, для их защелкивания в ZynQ нужен клок, который был бы по середине бита данных. Оказалось, что на плате Oryx есть буфер, который делает из дифф-сингл клоки, и вносит задержку в клоки от АЦП порядка 2.5 нс на 100 МГц, т.е. 90 градусов, что нам и нужно. Поэтому просто берем и защелкиваем данные из АЦП в Цинке клоками, которые кинули из АЦП и они добрались до Цинка.

Три

* Чинить/освежать блоки Calibration и RefInterp в Oryx
** Calibration переделан тут (см. два мердженных коммита) [https://gitlab.srns.ru:8080/git/src/commit/1f59ed4248d6d644a31e3fa8171bf60cdedf7194 | 1f59ed42].
** RefInterp переделан тут (PL [https://gitlab.srns.ru:8080/git/src/commit/8d93c996a488ab41515b36121aae84b20cec9fce | 8d93c996], PS [https://gitlab.srns.ru:8080/git/src/commit/d873d357c66d5c9a0d192748a141d76eef8735a5 | d873d357]).
* Поднять UART из ZynQ для управления MCR, прокинуть его через южный мост к плате управления MCR. Там есть джамперы и 3х-пиновый разъем, можно переключаться между разъем на панели прибора / спец разъем.
** Сделано, работает. Коммит src [https://gitlab.srns.ru:8080/git/src/commit/33be60030193279208fa79a1bebb615673422794 | 33be6003]. Коммит южного моста [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/67ed0dbe96634ae136db85261b2c763aed7b31d5 | 67ed0dbe].

{{wl-publish: 2020-06-05 12:52:18 +0300 | Korogodin }}

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

2020-11-09T10:09:31Z

Dneprov: /* 2020.07.28 - План по устранению проблем в платах АЦП и Oryx */

<summary [ hidden ]>

Записи о текущих испытаниях Орикса, Клоникуса и т.п.
</summary>

{{Форма3}}

{{TOCright}}

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

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

Желательно записывать следующие данные:
* дату испытания (в заголовке);
* номер ревизии 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 минут работы:
[[image:Screenshot_20200605_131702.png|center]]

Плотность отправки пакетов:
[[image:Screenshot_20200605_132120.png|center]]

Наибольшую плотность создает отправка эфемерид каждый 30 секунд, несколько десятков пакетов (сотня-две при полной нагрузке):
[[image:20200506_enp4s0_001.png|center]]

При этом достигается пиковая скорость 5кбайт/мс (50 при экстраполяции на полную нагрузку):
[[image:20200506_enp4s0_002.png|center]]



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

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

Измерения от 12 спутников отправляются раз в секунду в пакете 0xF5, 12 спутников занимают порядка 400 байт:
[[image:20200506_enp4s0_003.png|center]]

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

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

== 2020.07.21 - Очередные мучения с PPS OUT в ККН ==

* номер ревизии PL: [https://gitlab.srns.ru:8080/git/src/commit/2c9bf757016cb7796a6188fce514a494d92cdad8| 2c9bf757]
* номер ревизии PS: [https://gitlab.srns.ru:8080/git/src/commit/fc467aa0d30a6d5f54445cc8153944d2d3d9dd0e| fc467aa0]
* номер ревизии PL южного моста: [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/f695100df9f88f713932f8daeabf75aa352c1d1c| f695100d]
* номер ревизии PL платы АЦП: [https://gitlab.srns.ru:8080/git/adc_rev3/commit/0a0015868fb8a8914e0abed88c4ec5603d6eeb7b| 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: [https://gitlab.srns.ru:8080/git/src/commit/2c9bf757016cb7796a6188fce514a494d92cdad8| 2c9bf757]
* номер ревизии PS: [https://gitlab.srns.ru:8080/git/src/commit/fc467aa0d30a6d5f54445cc8153944d2d3d9dd0e| fc467aa0]
* номер ревизии PL южного моста: [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/f695100df9f88f713932f8daeabf75aa352c1d1c| f695100d]
* номер ревизии PL платы АЦП: [https://gitlab.srns.ru:8080/git/adc_rev3/commit/0a0015868fb8a8914e0abed88c4ec5603d6eeb7b| 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.

[[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.
** сделано в коммите [https://gitlab.srns.ru:8080/git/adc_rev3/commit/558992d20fd15d5e92f8031fcea4fbed1cd9d225 | 558992d2]
* Поднять обратно 3-ю АЦП.
** сделано в коммите [https://gitlab.srns.ru:8080/git/adc_rev3/commit/2c6556f0588640dd321f68038dc4066e37c2f80f | 2c6556f0]
* Завести синхросигнал SYNC с помощью делителей на 3 микросхемы АЦП.
** сделано в коммите [https://gitlab.srns.ru:8080/git/adc_rev3/commit/2c6556f0588640dd321f68038dc4066e37c2f80f | 2c6556f0]
* Прокинуть их (SYNC) c трех микросхем АЦП и PPS_In с буффера по Samtec в ZynQ
** сделано в коммите [https://gitlab.srns.ru:8080/git/adc_rev3/commit/2c6556f0588640dd321f68038dc4066e37c2f80f | 2c6556f0]
* Проверить их датаколлектором, убедиться в их адекватном внешнем виде, убедиться в наличии задержек между микросхемами АЦП.
** Проверяли на компе у Сереги. Увидели прямоугольные импульсы SYNC и PPS_IN (с буффера платы АЦП). Почему-то PPS_IN опаздывает относительно сигналов SYNC, хотя должно быть наоборот. Проблема может быть как в отображении самой программы датаколлектора, так и в реализации датаколлектора в ПЛИС (как он пишет по времени и вычитывает по времени).
* Сделать в ZynQ схему выравнивания АЦП между собой: она должна принимать 3 сигнала SYNC, смотреть задержку между ними, и задерживать потоки данных от всех микросхем АЦП к самому задержанному. Также она должна оценивать задержку Delta между PPS_In с буфера платы АЦП и синалом SYNC (каким, выровненным к задержками или как?)
** Иван сделал в коммите [https://gitlab.srns.ru:8080/git/src/commit/05c5e5fc250c7b2663003214f43fab26b5f61532 | 05c5e5fc] (на самом деле в 5cc547ee, по ссылке лишь обновленный тикль). Пока никто не проверял это кроме него и в с++ не встраивал.
* Учесть измеренную Delta в выдаче PPS_Out из ZynQ
* Убираем в южном мосту Oryx схему с еще одним формированием PPS_Out на счетчиках. Будем перещелкивать PPS_Out из ZynQ в клоки MCR - упрощаем монстра.
** сделано в коммите [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/3ecc30ce1dedb84c636e05821723add06d97217a | 3ecc30ce]

Два

* Оценить стабильность задержки от SER Samtec платы АЦП до DESER ZynQ в Oryx.
** Эксперимент проведен, [[#2020.07.27 - Постоянство задержки от сериалайзера платы АЦП до десериалайзера платы Oryx| результат чуть выше]]. Есть проблема со скачком на клок от включения к включению.
** Иван начал перепиливать плату АЦП, выкинул SER в ней и DESER в ZynQ. Данные от АЦП кладет просто в ODDR в дифф.линии Samtec в расчете на режим DDR. Провели эксперимент, как и в предыдущем пункте. PPS_IN между АЦП и Oryx больше не прыгает. Также посмотрели дата-коллектором в линии от АЦП - увидели там гармоники, т.е. как будто бы передача данных по Samtec между платой АЦП и Oryx работает без SER-DES цепочки. '''Важный ньюанс''' - т.к. хотим данные передавать в режиме DDR, для их защелкивания в ZynQ нужен клок, который был бы по середине бита данных. Оказалось, что на плате Oryx есть буфер, который делает из дифф-сингл клоки, и вносит задержку в клоки от АЦП порядка 2.5 нс на 100 МГц, т.е. 90 градусов, что нам и нужно. Поэтому просто берем и защелкиваем данные из АЦП в Цинке клоками, которые кинули из АЦП и они добрались до Цинка.

Три

* Чинить/освежать блоки Calibration и RefInterp в Oryx
** Calibration переделан тут (см. два мердженных коммита) [https://gitlab.srns.ru:8080/git/src/commit/1f59ed4248d6d644a31e3fa8171bf60cdedf7194 | 1f59ed42].
** RefInterp переделан тут (PL [https://gitlab.srns.ru:8080/git/src/commit/8d93c996a488ab41515b36121aae84b20cec9fce | 8d93c996], PS [https://gitlab.srns.ru:8080/git/src/commit/d873d357c66d5c9a0d192748a141d76eef8735a5 | d873d357]).
* Поднять UART из ZynQ для управления MCR, прокинуть его через южный мост к плате управления MCR. Там есть джамперы и 3х-пиновый разъем, можно переключаться между разъем на панели прибора / спец разъем.
** Сделано, работает. Коммит src [https://gitlab.srns.ru:8080/git/src/commit/33be60030193279208fa79a1bebb615673422794 | 33be6003]. Коммит южного моста [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/67ed0dbe96634ae136db85261b2c763aed7b31d5 | 67ed0dbe].

{{wl-publish: 2020-06-05 12:52:18 +0300 | Korogodin }}

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

2020-11-09T10:08:58Z

Dneprov: /* 2020.07.28 - План по устранению проблем в платах АЦП и Oryx */

<summary [ hidden ]>

Записи о текущих испытаниях Орикса, Клоникуса и т.п.
</summary>

{{Форма3}}

{{TOCright}}

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

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

Желательно записывать следующие данные:
* дату испытания (в заголовке);
* номер ревизии 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 минут работы:
[[image:Screenshot_20200605_131702.png|center]]

Плотность отправки пакетов:
[[image:Screenshot_20200605_132120.png|center]]

Наибольшую плотность создает отправка эфемерид каждый 30 секунд, несколько десятков пакетов (сотня-две при полной нагрузке):
[[image:20200506_enp4s0_001.png|center]]

При этом достигается пиковая скорость 5кбайт/мс (50 при экстраполяции на полную нагрузку):
[[image:20200506_enp4s0_002.png|center]]



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

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

Измерения от 12 спутников отправляются раз в секунду в пакете 0xF5, 12 спутников занимают порядка 400 байт:
[[image:20200506_enp4s0_003.png|center]]

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

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

== 2020.07.21 - Очередные мучения с PPS OUT в ККН ==

* номер ревизии PL: [https://gitlab.srns.ru:8080/git/src/commit/2c9bf757016cb7796a6188fce514a494d92cdad8| 2c9bf757]
* номер ревизии PS: [https://gitlab.srns.ru:8080/git/src/commit/fc467aa0d30a6d5f54445cc8153944d2d3d9dd0e| fc467aa0]
* номер ревизии PL южного моста: [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/f695100df9f88f713932f8daeabf75aa352c1d1c| f695100d]
* номер ревизии PL платы АЦП: [https://gitlab.srns.ru:8080/git/adc_rev3/commit/0a0015868fb8a8914e0abed88c4ec5603d6eeb7b| 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: [https://gitlab.srns.ru:8080/git/src/commit/2c9bf757016cb7796a6188fce514a494d92cdad8| 2c9bf757]
* номер ревизии PS: [https://gitlab.srns.ru:8080/git/src/commit/fc467aa0d30a6d5f54445cc8153944d2d3d9dd0e| fc467aa0]
* номер ревизии PL южного моста: [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/f695100df9f88f713932f8daeabf75aa352c1d1c| f695100d]
* номер ревизии PL платы АЦП: [https://gitlab.srns.ru:8080/git/adc_rev3/commit/0a0015868fb8a8914e0abed88c4ec5603d6eeb7b| 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.

[[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.
** сделано в коммите [https://gitlab.srns.ru:8080/git/adc_rev3/commit/558992d20fd15d5e92f8031fcea4fbed1cd9d225 | 558992d2]
* Поднять обратно 3-ю АЦП.
** сделано в коммите [https://gitlab.srns.ru:8080/git/adc_rev3/commit/2c6556f0588640dd321f68038dc4066e37c2f80f | 2c6556f0]
* Завести синхросигнал SYNC с помощью делителей на 3 микросхемы АЦП.
** сделано в коммите [https://gitlab.srns.ru:8080/git/adc_rev3/commit/2c6556f0588640dd321f68038dc4066e37c2f80f | 2c6556f0]
* Прокинуть их (SYNC) c трех микросхем АЦП и PPS_In с буффера по Samtec в ZynQ
** сделано в коммите [https://gitlab.srns.ru:8080/git/adc_rev3/commit/2c6556f0588640dd321f68038dc4066e37c2f80f | 2c6556f0]
* Проверить их датаколлектором, убедиться в их адекватном внешнем виде, убедиться в наличии задержек между микросхемами АЦП.
** Проверяли на компе у Сереги. Увидели прямоугольные импульсы SYNC и PPS_IN (с буффера платы АЦП). Почему-то PPS_IN опаздывает относительно сигналов SYNC, хотя должно быть наоборот. Проблема может быть как в отображении самой программы датаколлектора, так и в реализации датаколлектора в ПЛИС (как он пишет по времени и вычитывает по времени).
* Сделать в ZynQ схему выравнивания АЦП между собой: она должна принимать 3 сигнала SYNC, смотреть задержку между ними, и задерживать потоки данных от всех микросхем АЦП к самому задержанному. Также она должна оценивать задержку Delta между PPS_In с буфера платы АЦП и синалом SYNC (каким, выровненным к задержками или как?)
** Иван сделал в коммите [https://gitlab.srns.ru:8080/git/src/commit/05c5e5fc250c7b2663003214f43fab26b5f61532 | 05c5e5fc] (на самом деле в 5cc547ee, по ссылке лишь обновленный тикль). Пока никто не проверял это кроме него и в с++ не встраивал.
* Учесть измеренную Delta в выдаче PPS_Out из ZynQ
* Убираем в южном мосту Oryx схему с еще одним формированием PPS_Out на счетчиках. Будем перещелкивать PPS_Out из ZynQ в клоки MCR - упрощаем монстра.
** сделано в коммите [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/3ecc30ce1dedb84c636e05821723add06d97217a | 3ecc30ce]

Два

* Оценить стабильность задержки от SER Samtec платы АЦП до DESER ZynQ в Oryx.
** Эксперимент проведен, [[#2020.07.27 - Постоянство задержки от сериалайзера платы АЦП до десериалайзера платы Oryx| результат чуть выше]]. Есть проблема со скачком на клок от включения к включению.
** Иван начал перепиливать плату АЦП, выкинул SER в ней и DESER в ZynQ. Данные от АЦП кладет просто в ODDR в дифф.линии Samtec в расчете на режим DDR. Провели эксперимент, как и в предыдущем пункте. PPS_IN между АЦП и Oryx больше не прыгает. Также посмотрели дата-коллектором в линии от АЦП - увидели там гармоники, т.е. как будто бы передача данных по Samtec между платой АЦП и Oryx работает без SER-DES цепочки. '''Важный ньюанс''' - т.к. хотим данные передавать в режиме DDR, для их защелкивания в ZynQ нужен клок, который был бы по середине бита данных. Оказалось, что на плате Oryx есть буфер, который делает из дифф-сингл клоки, и вносит задержку в клоки от АЦП порядка 2.5 нс на 100 МГц, т.е. 90 градусов, что нам и нужно. Поэтому просто берем и защелкиваем данные из АЦП в Цинке клоками, которые кинули из АЦП и они добрались до Цинка.

Три

* Чинить/освежать блоки Calibration и RefInterp в Oryx
** Calibration переделан тут (см. два мердженных коммита) [https://gitlab.srns.ru:8080/git/src/commit/1f59ed4248d6d644a31e3fa8171bf60cdedf7194 | 1f59ed42].
** RefInterp переделан тут (в PL [https://gitlab.srns.ru:8080/git/src/commit/8d93c996a488ab41515b36121aae84b20cec9fce | 8d93c996], PS [https://gitlab.srns.ru:8080/git/src/commit/d873d357c66d5c9a0d192748a141d76eef8735a5 | d873d357].
* Поднять UART из ZynQ для управления MCR, прокинуть его через южный мост к плате управления MCR. Там есть джамперы и 3х-пиновый разъем, можно переключаться между разъем на панели прибора / спец разъем.
** Сделано, работает. Коммит src [https://gitlab.srns.ru:8080/git/src/commit/33be60030193279208fa79a1bebb615673422794 | 33be6003]. Коммит южного моста [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/67ed0dbe96634ae136db85261b2c763aed7b31d5 | 67ed0dbe].

{{wl-publish: 2020-06-05 12:52:18 +0300 | Korogodin }}

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

2020-09-21T12:16:05Z

Dneprov: /* 2020.07.28 - План по устранению проблем в платах АЦП и Oryx */

<summary [ hidden ]>

Записи о текущих испытаниях Орикса, Клоникуса и т.п.
</summary>

{{Форма3}}

{{TOCright}}

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

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

Желательно записывать следующие данные:
* дату испытания (в заголовке);
* номер ревизии 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 минут работы:
[[image:Screenshot_20200605_131702.png|center]]

Плотность отправки пакетов:
[[image:Screenshot_20200605_132120.png|center]]

Наибольшую плотность создает отправка эфемерид каждый 30 секунд, несколько десятков пакетов (сотня-две при полной нагрузке):
[[image:20200506_enp4s0_001.png|center]]

При этом достигается пиковая скорость 5кбайт/мс (50 при экстраполяции на полную нагрузку):
[[image:20200506_enp4s0_002.png|center]]



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

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

Измерения от 12 спутников отправляются раз в секунду в пакете 0xF5, 12 спутников занимают порядка 400 байт:
[[image:20200506_enp4s0_003.png|center]]

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

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

== 2020.07.21 - Очередные мучения с PPS OUT в ККН ==

* номер ревизии PL: [https://gitlab.srns.ru:8080/git/src/commit/2c9bf757016cb7796a6188fce514a494d92cdad8| 2c9bf757]
* номер ревизии PS: [https://gitlab.srns.ru:8080/git/src/commit/fc467aa0d30a6d5f54445cc8153944d2d3d9dd0e| fc467aa0]
* номер ревизии PL южного моста: [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/f695100df9f88f713932f8daeabf75aa352c1d1c| f695100d]
* номер ревизии PL платы АЦП: [https://gitlab.srns.ru:8080/git/adc_rev3/commit/0a0015868fb8a8914e0abed88c4ec5603d6eeb7b| 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: [https://gitlab.srns.ru:8080/git/src/commit/2c9bf757016cb7796a6188fce514a494d92cdad8| 2c9bf757]
* номер ревизии PS: [https://gitlab.srns.ru:8080/git/src/commit/fc467aa0d30a6d5f54445cc8153944d2d3d9dd0e| fc467aa0]
* номер ревизии PL южного моста: [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/f695100df9f88f713932f8daeabf75aa352c1d1c| f695100d]
* номер ревизии PL платы АЦП: [https://gitlab.srns.ru:8080/git/adc_rev3/commit/0a0015868fb8a8914e0abed88c4ec5603d6eeb7b| 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.

[[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.
** сделано в коммите [https://gitlab.srns.ru:8080/git/adc_rev3/commit/558992d20fd15d5e92f8031fcea4fbed1cd9d225 | 558992d2]
* Поднять обратно 3-ю АЦП.
** сделано в коммите [https://gitlab.srns.ru:8080/git/adc_rev3/commit/2c6556f0588640dd321f68038dc4066e37c2f80f | 2c6556f0]
* Завести синхросигнал SYNC с помощью делителей на 3 микросхемы АЦП.
** сделано в коммите [https://gitlab.srns.ru:8080/git/adc_rev3/commit/2c6556f0588640dd321f68038dc4066e37c2f80f | 2c6556f0]
* Прокинуть их (SYNC) c трех микросхем АЦП и PPS_In с буффера по Samtec в ZynQ
** сделано в коммите [https://gitlab.srns.ru:8080/git/adc_rev3/commit/2c6556f0588640dd321f68038dc4066e37c2f80f | 2c6556f0]
* Проверить их датаколлектором, убедиться в их адекватном внешнем виде, убедиться в наличии задержек между микросхемами АЦП.
** Проверяли на компе у Сереги. Увидели прямоугольные импульсы SYNC и PPS_IN (с буффера платы АЦП). Почему-то PPS_IN опаздывает относительно сигналов SYNC, хотя должно быть наоборот. Проблема может быть как в отображении самой программы датаколлектора, так и в реализации датаколлектора в ПЛИС (как он пишет по времени и вычитывает по времени).
* Сделать в ZynQ схему выравнивания АЦП между собой: она должна принимать 3 сигнала SYNC, смотреть задержку между ними, и задерживать потоки данных от всех микросхем АЦП к самому задержанному. Также она должна оценивать задержку Delta между PPS_In с буфера платы АЦП и синалом SYNC (каким, выровненным к задержками или как?)
** Иван сделал в коммите [https://gitlab.srns.ru:8080/git/src/commit/05c5e5fc250c7b2663003214f43fab26b5f61532 | 05c5e5fc] (на самом деле в 5cc547ee, по ссылке лишь обновленный тикль). Пока никто не проверял это кроме него и в с++ не встраивал.
* Учесть измеренную Delta в выдаче PPS_Out из ZynQ
* Убираем в южном мосту Oryx схему с еще одним формированием PPS_Out на счетчиках. Будем перещелкивать PPS_Out из ZynQ в клоки MCR - упрощаем монстра.
** сделано в коммите [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/3ecc30ce1dedb84c636e05821723add06d97217a | 3ecc30ce]

Два

* Оценить стабильность задержки от SER Samtec платы АЦП до DESER ZynQ в Oryx.
** Эксперимент проведен, [[#2020.07.27 - Постоянство задержки от сериалайзера платы АЦП до десериалайзера платы Oryx| результат чуть выше]]. Есть проблема со скачком на клок от включения к включению.
** Иван начал перепиливать плату АЦП, выкинул SER в ней и DESER в ZynQ. Данные от АЦП кладет просто в ODDR в дифф.линии Samtec в расчете на режим DDR. Провели эксперимент, как и в предыдущем пункте. PPS_IN между АЦП и Oryx больше не прыгает. Также посмотрели дата-коллектором в линии от АЦП - увидели там гармоники, т.е. как будто бы передача данных по Samtec между платой АЦП и Oryx работает без SER-DES цепочки. '''Важный ньюанс''' - т.к. хотим данные передавать в режиме DDR, для их защелкивания в ZynQ нужен клок, который был бы по середине бита данных. Оказалось, что на плате Oryx есть буфер, который делает из дифф-сингл клоки, и вносит задержку в клоки от АЦП порядка 2.5 нс на 100 МГц, т.е. 90 градусов, что нам и нужно. Поэтому просто берем и защелкиваем данные из АЦП в Цинке клоками, которые кинули из АЦП и они добрались до Цинка.

Три

* Чинить/освежать блоки Calibration и RefInterp в Oryx
** Calibration переделан тут (см. два мердженных коммита) [https://gitlab.srns.ru:8080/git/src/commit/1f59ed4248d6d644a31e3fa8171bf60cdedf7194 | 1f59ed42].
* Поднять UART из ZynQ для управления MCR, прокинуть его через южный мост к плате управления MCR. Там есть джамперы и 3х-пиновый разъем, можно переключаться между разъем на панели прибора / спец разъем.
** Сделано, работает. Коммит src [https://gitlab.srns.ru:8080/git/src/commit/33be60030193279208fa79a1bebb615673422794 | 33be6003]. Коммит южного моста [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/67ed0dbe96634ae136db85261b2c763aed7b31d5 | 67ed0dbe].

{{wl-publish: 2020-06-05 12:52:18 +0300 | Korogodin }}

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

2020-08-28T12:04:04Z

Dneprov: /* 2020.07.28 - План по устранению проблем в платах АЦП и Oryx */

<summary [ hidden ]>

Записи о текущих испытаниях Орикса, Клоникуса и т.п.
</summary>

{{Форма3}}

{{TOCright}}

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

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

Желательно записывать следующие данные:
* дату испытания (в заголовке);
* номер ревизии 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 минут работы:
[[image:Screenshot_20200605_131702.png|center]]

Плотность отправки пакетов:
[[image:Screenshot_20200605_132120.png|center]]

Наибольшую плотность создает отправка эфемерид каждый 30 секунд, несколько десятков пакетов (сотня-две при полной нагрузке):
[[image:20200506_enp4s0_001.png|center]]

При этом достигается пиковая скорость 5кбайт/мс (50 при экстраполяции на полную нагрузку):
[[image:20200506_enp4s0_002.png|center]]



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

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

Измерения от 12 спутников отправляются раз в секунду в пакете 0xF5, 12 спутников занимают порядка 400 байт:
[[image:20200506_enp4s0_003.png|center]]

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

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

== 2020.07.21 - Очередные мучения с PPS OUT в ККН ==

* номер ревизии PL: [https://gitlab.srns.ru:8080/git/src/commit/2c9bf757016cb7796a6188fce514a494d92cdad8| 2c9bf757]
* номер ревизии PS: [https://gitlab.srns.ru:8080/git/src/commit/fc467aa0d30a6d5f54445cc8153944d2d3d9dd0e| fc467aa0]
* номер ревизии PL южного моста: [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/f695100df9f88f713932f8daeabf75aa352c1d1c| f695100d]
* номер ревизии PL платы АЦП: [https://gitlab.srns.ru:8080/git/adc_rev3/commit/0a0015868fb8a8914e0abed88c4ec5603d6eeb7b| 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: [https://gitlab.srns.ru:8080/git/src/commit/2c9bf757016cb7796a6188fce514a494d92cdad8| 2c9bf757]
* номер ревизии PS: [https://gitlab.srns.ru:8080/git/src/commit/fc467aa0d30a6d5f54445cc8153944d2d3d9dd0e| fc467aa0]
* номер ревизии PL южного моста: [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/f695100df9f88f713932f8daeabf75aa352c1d1c| f695100d]
* номер ревизии PL платы АЦП: [https://gitlab.srns.ru:8080/git/adc_rev3/commit/0a0015868fb8a8914e0abed88c4ec5603d6eeb7b| 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.

[[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.
** сделано в коммите [https://gitlab.srns.ru:8080/git/adc_rev3/commit/558992d20fd15d5e92f8031fcea4fbed1cd9d225 | 558992d2]
* Поднять обратно 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 - упрощаем монстра.
** сделано в коммите [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/3ecc30ce1dedb84c636e05821723add06d97217a | 3ecc30ce]

Два

* Оценить стабильность задержки от SER Samtec платы АЦП до DESER ZynQ в Oryx.
** Эксперимент проведен, [[#2020.07.27 - Постоянство задержки от сериалайзера платы АЦП до десериалайзера платы Oryx| результат чуть выше]]. Есть проблема со скачком на клок от включения к включению.
** Иван начал перепиливать плату АЦП, выкинул SER в ней и DESER в ZynQ. Данные от АЦП кладет просто в ODDR в дифф.линии Samtec в расчете на режим DDR. Провели эксперимент, как и в предыдущем пункте. PPS_IN между АЦП и Oryx больше не прыгает. Также посмотрели дата-коллектором в линии от АЦП - увидели там гармоники, т.е. как будто бы передача данных по Samtec между платой АЦП и Oryx работает без SER-DES цепочки. '''Важный ньюанс''' - т.к. хотим данные передавать в режиме DDR, для их защелкивания в ZynQ нужен клок, который был бы по середине бита данных. Оказалось, что на плате Oryx есть буфер, который делает из дифф-сингл клоки, и вносит задержку в клоки от АЦП порядка 2.5 нс на 100 МГц, т.е. 90 градусов, что нам и нужно. Поэтому просто берем и защелкиваем данные из АЦП в Цинке клоками, которые кинули из АЦП и они добрались до Цинка.

Три

* Чинить/освежать блоки Calibration и RefInterp в Oryx
** Calibration переделан тут (см. два мердженных коммита) [https://gitlab.srns.ru:8080/git/src/commit/1f59ed4248d6d644a31e3fa8171bf60cdedf7194 | 1f59ed42].
* Поднять UART из ZynQ для управления MCR, прокинуть его через южный мост к плате управления MCR. Там есть джамперы и 3х-пиновый разъем, можно переключаться между разъем на панели прибора / спец разъем.
** Сделано, работает. Коммит src [https://gitlab.srns.ru:8080/git/src/commit/33be60030193279208fa79a1bebb615673422794 | 33be6003]. Коммит южного моста [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/67ed0dbe96634ae136db85261b2c763aed7b31d5 | 67ed0dbe].

{{wl-publish: 2020-06-05 12:52:18 +0300 | Korogodin }}

Список децимальных номеров

2020-08-25T13:11:39Z

Dneprov: /* Список децимальников на ПО выданное по ЕСПД */

{{Форма2}}

== Список МИФТов выданных в рамках ЕСКД ==
Обрати внимание на смещение на 128, в номерах, выданных на БЦО для Сантиметра и ГЛОНАСС-ККН. В будущих работах либо делать 130, либо продолжить Сантиметр.
{| class="wikitable sortable" border="1"
|-align="center"
! НИОКР !! Децимальный номер !! Название !! class="unsortable" | Примечания

|-align="center"
| Сантиметр
| МИФТ.461513.001
| Прецизионный навигационный приемник
|

|-align="center"
| Сантиметр
| МИФТ.464345.001
| Радиочастотный блок
| MCR

|-align="center"
| Сантиметр
| МИФТ.464347.001
| Блок цифровой обработки
| Снежинка + N Oryx'ов

|-align="center"
| Сантиметр
| МИФТ.468157.001
| Плата АЦП
| Снежинка

|-align="center"
| Сантиметр
| МИФТ.467449.001
| Плата коррелятора
| Oryx

|-align="center"
| Сантиметр
| МИФТ.687263.101
| Плата печатная многослойная
| ПП Снежинка

|-align="center"
| Сантиметр
| МИФТ.687263.102
| Плата печатная многослойная
| ПП Oryx

|-align="center"
| ГЛОНАСС-ККН
| МИФТ.464347.129
| БЦО НС
|

|-align="center"
| ГЛОНАСС-ККН
| МИФТ.468157.002
| Плата АЦП
| Снежинка

|-align="center"
| ГЛОНАСС-ККН
| МИФТ.467449.002
| Плата корреляционной обработки
| Oryx

|-align="center"
| ГЛОНАСС-ККН
| МИФТ.468173.002
| Плата ФШВ
| Плата формирования шкалы времени, входит в БФШВ, по сути сейчас это PPS-gun

|-align="center"
| ГЛОНАСС-ККН
| МИФТ.687263.103
| Плата печатная многослойная
| ПП АЦП

|-align="center"
| ГЛОНАСС-ККН
| МИФТ.687263.104
| Плата печатная многослойная
| ПП Oryx

|-align="center"
| ГЛОНАСС-ККН
| МИФТ.468157.129
| БФШВ
|

|-align="center"
| ГЛОНАСС-ККН
| МИФТ.464340.129
| БФИ
|

|-align="center"
| Имитация
| МИФТ.464421.001
| АПОФС
|

|-align="center"
| Имитация ТП
| МИФТ.464421.002
| ФИС
|

|-align="center"
| Имитация ТП
| МИФТ.464421.004
| БПОФС
| В составе ФИС

|-align="center"
| Флагман
| МИФТ.464659.001
| Антенна приемная
| Под вопросом

|-align="center"
| Имитация
| МИФТ.461513.002
| АПНС
|

|-align="center"
| Имитация
| МИФТ.461513.003
| БОС
| Ящик приемника

|-align="center"
| Имитация
| МИФТ.323366.001
| Упаковка
| В АПОФС

|-align="center"
| Имитация
| МИФТ.323366.002
| Кейс транспортировочный
| В ФИС

|-align="center"
| Имитация ТП
| МИФТ.323366.003
| Кейс транспортировочный
| В АПНС

|-align="center"
| Имитация
| МИФТ.464933.101
| Комплект ЗИП-О
| В АПОФС

|-align="center"
| Имитация
| МИФТ.464939.103
| Комплект кабелей
| В АПОФС

|-align="center"
| Имитация
| МИФТ.464939.101
| Комплект кабелей радиочастотных
| В ФИС

|-align="center"
| Имитация ТП
| МИФТ.757448.001
| Сборка кабельная
| Кабель питания адикусов

|-align="center"
| Имитация ТП
| МИФТ.757448.002
| Сборка кабельная
| Кабель радиочастотный от адикусов до сплиттера

|-align="center"
| Имитация ТП
| МИФТ.757448.003
| Сборка кабельная
| Кабель радиочастотный от адикусов до комбайнера

|-align="center"
| Имитация ТП
| МИФТ.757448.004
| Сборка кабельная
| Кабель радиочастотный от адикусов до синхронизатора

|-align="center"
| Имитация ТП
| МИФТ.757448.005
| Сборка кабельная
| Кабель радиочастотный от синхронизатора до панели

|-align="center"
| Имитация ТП
| МИФТ.757448.006
| Сборка кабельная
| Кабель радиочастотный от комбайнера/сплиттера до панели

|-align="center"
| Имитация ТП
| МИФТ.757448.007
| Сборка кабельная
| Кабель Ethernet

|-align="center"
| Имитация ТП
| МИФТ.757448.008
| Сборка кабельная
| Кабель Ethernet к передней панели

|-align="center"
| Имитация ТП
| МИФТ.464939.102
| Комплект кабелей питания
| В ФИС

|-align="center"
| Имитация
| МИФТ.464939.104
| Комплект кабелей Ethernet
| Пока в схеме деления без децимального номера

|-align="center"
| Имитация
| МИФТ.464939.105
| Комплект кабелей
| К БПОФС в составе ФИС

|-align="center"
| Имитация ТП
| МИФТ.464939.106
| Комплект кабелей
| К БОС в составе АПНС

|-align="center"
| Имитация ТП
| МИФТ.464421.003
| Приемопередатчик диапазонный
| Адикус

|-align="center"
| Имитация ТП
| МИФТ.468526.001
| Синхронизатор
|

|-align="center"
| Имитация ТП
| МИФТ.468526.002
| Плата синхронизатора
|

|-align="center"
| Имитация ТП
| МИФТ.687263.107
| Плата печатная многослойная
| ПП синхронизатора

|-align="center"
| Имитация ТП
| МИФТ.468522.001
| Комбайнер
|

|-align="center"
| Имитация ТП
| МИФТ.468522.002
| Плата комбайнера
|

|-align="center"
| Имитация ТП
| МИФТ.687263.108
| Плата печатная многослойная
| ПП комбайнера

|-align="center"
| Имитация ТП
| МИФТ.469673.001
| Корпус
| БПОФС

|-align="center"
| Имитация ТП
| МИФТ.469673.002
| Корпус
| БОС

|-align="center"
| Имитация
| МИФТ.461513.021
| Плата приемника
|

|-align="center"
| Имитация ТП
| МИФТ.687263.105
| Плата печатная многослойная
| ПП Clonicus

|-align="center"
| Имитация ТП
| МИФТ.687263.106
| Плата печатная многослойная
| ПП AD9361Kit

|-align="center"
| Имитация ТП
| МИФТ.434933.001
| Плата передатчика
| AD9361Kit

|-align="center"
| Имитация ТП
| МИФТ.301415.075
| Радиатор
| Железка + крепеж

|-align="center"
| Имитация ТП
| МИФТ.301415.076
| Излучатель радиатора
| Сама железная болванка

|-align="center"
| Имитация ТП
| МИФТ.301129.001
| Корпус
| для синхронизатора

|-align="center"
| Имитация ТП
| МИФТ.301129.002
| Корпус
| для комбайнера

|-align="center"
| Площадка
| МИФТ.464945.001
| Макет ЛРНС
|

|-align="center"
| Площадка
| МИФТ.468577.051
| Антенна клеверная
|

|}

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

Пока не поступило новых вводных, я решил выдавать такие номера: XXXXXX-ММГГ-YYY, где
*XXXXXX - код из классификатора ЕСКД на изделие (тот же, что и в КД на изделие);
*ММГГ - месяц и год выпуска (по сути, ставится исходя из требований ТЗ, сроков и т.п.)
*YYY - просто порядковый номер. Пока не решил, делать просто сквозную нумерацию через века, или начинать с начала в пределах каждого нового месяца/года.

{| class="wikitable" border="1"
|-align="center"
! НИОКР
! Изделие
! Заводской номер
! Примечания

|-align="center"
|rowspan ="3"| '''ГЛОНАСС-ККН'''
|БЦОНС
|464347-0617-001, 464347-0617-002
|

|-align="center"
|БФШВ
|468157-0617-001, 468157-0617-002
|

|-align="center"
|БФИ
|464340-0617-001, 464340-0617-002
|

|-align="center"
|rowspan ="3"| '''ГЛОНАСС-ККН-СЕТЬ'''
|БЦОНС
|с 464347-0319-001 по -012. На 2 ящика приходится 1 БЦОНС в ЗИП, т.е. 8 БЦОНС в ящики, 4 в ЗИП
|

|-align="center"
|БФШВ
|с 468157-0319-001 по -008
|

|-align="center"
|БФИ
|с 464340-0319-001 по -008
|
|}

== Список децимальников на ПО выданное по ЕСПД ==
{| class="wikitable sortable" border="1"
|-align="center"
! НИОКР
! Децимальный номер
! Название
! Примечания

|-align="center"
|rowspan ="1"| '''Сантиметр'''
| 643.МИФТ.13867-02
| ПМО БЦО
|

|-align="center"
| rowspan ="6"| '''Фарватер-МЭИ (стационарный)'''
| 643.МИФТ.00121-01
| СПМО ЦМПО ОД
| в новой редакции решили слить в одно (см 00134) - не прокатило, в апреле 2019г. вернулся к этим номерам, пришлось клепать 3 копии

|-align="center"
| 643.МИФТ.00122-01
| СПМО ЦМПО МОД
| в новой редакции решили слить в одно (см 00134) - не прокатило, в апреле 2019г. вернулся к этим номерам, пришлось клепать 3 копии

|-align="center"
| 643.МИФТ.00123-01
| СПМО ЦМПО МСД
| в новой редакции решили слить в одно (см 00134) - не прокатило, в апреле 2019г. вернулся к этим номерам, пришлось клепать 3 копии

|-align="center"
| 643.МИФТ.00134-01
| СПМО ЦМПО
| В Дополнении №1 ТЗ все три варианта (ОД, МОД, МСД) сделаны как 3 исполнения одного СПМО ЦМПО - не прокатило, в апреле 2019г. пришлось клепать 3 копии

|-align="center"
| 643.МИФТ.00135-01
| СПМО МПВО L1(L2)
| В Дополнении №1 ТЗ теперь мы еще и МПВО делаем, под него бумажки

|-align="center"
| 643.МИФТ.00138-01
| Технологическое ПО ЦМ
| Так получилось, что его реально сделал под Возимый, а пришлось подсовывать еще и в обычный фарватер.

|-align="center"
| rowspan ="4"| '''Фарватер-МЭИ-ВДПС (возимый)'''
| 643.МИФТ.00133-01 (02)
| СПМО Фарватер Возимый
| Основное изделие (СПМО ЦМ ККС). Все-таки потребовали делать два копмлекта на морской и на наземный. Решил сделать 2 "редакции-исполнения", что отражено в последней цифре децимальника. Соответственно -01 это СПМО ЦМ-ВМ, -02 это СПМО ЦМ-ВН. В состав входит поз. 136, 137, 138. По сути - просто спецификация с включением туда 136, 137, 138 и описание программ.

|-align="center"
| 643.МИФТ.00136-01 (02)
| ПО ЦСПП ЦМ
| Программное обеспечение цифровой схемы подавления помех

|-align="center"
| 643.МИФТ.00137-01 (02)
| ПО ЦСПО ЦМ
| Программное обеспечение цифровой схемы первичной обработки

|-align="center"
| 643.МИФТ.00139-01
| Технологическое ПО ЦМ
| Так получилось, сначала я выпустил его под номером 138 и засунул и в обычный фарватер и в ВДПС один и тот же (не было времени и нужно было к ГИ фарватера в апереле 2019 все подшаманить). Это плохо, и в НИИКП есть теперь ПД по Фарватеру с литерой О, где есть техн. ПО №138, а также ПД по Фарватеру-ВДПС, где тоже техн. ПО №138. В октябре 2019г. при формировании ПД с литерой О по Фарватеру-ВДПС, я решил все-таки номерок заменить и формально иметь два разных техн. ПО на два разных фарватера.

|-align="center"
| rowspan ="1"| '''Пока не ясно'''
| 643.МИФТ.00124-01
| Некоторое СПМО
| Шеф попросил в какую-то работу номерок

|-align="center"
|rowspan ="4"| '''ГЛОНАСС-ККН'''
| 643.МИФТ.00125-01
| ПО БЦОНС в ГЛОНАСС ККН
|

|-align="center"
| 643.МИФТ.00126-01
| СПО БФИ в ГЛОНАСС ККН
|

|-align="center"
| 643.МИФТ.00127-01
| СПО БФШВ в ГЛОНАСС ККН
|

|-align="center"
| 643.МИФТ.00132-01
| СПО БИСКОС в ГЛОНАСС ККН
| 20.09.2017 звонил Быханов, сказал нужно делать СПО БИСКОС

|-align="center"
| rowspan ="1"| '''Спин-Интеграция'''
| 643.МИФТ.00128-01
| ПМО
| ПМО в Спин-интеграцию

|-align="center"
| rowspan ="1"| '''Высотка'''
| 643.МИФТ.00129-01
| ПМО
| ПМО в Высотку

|-align="center"
| rowspan ="2"| '''Что-то в РКС'''
| 643.МИФТ.00130-01
| Компонент программы МК реализующей алгоритм ММРЛ
| программа?

|-align="center"
| 643.МИФТ.00131-01
| Компонент программы ПЛИС реализующей структуру сигнала ММРЛ
| программа?

|-align="center"
| rowspan ="5"| '''РКС-Независимость'''
| 643.МИФТ.00145-01
| Резерв на новую работу
| «Разработка программных модулей для цифровых формирователей и измерительных приемников навигационных радиосигналов системы ГЛОНАСС и сигналов межспутниковой радиолинии» Шифр «ГЛОНАСС-КК-В-Независимость-БИНК-К2-М-ЦФРС-МЭИ

|-align="center"
| 643.МИФТ.00146-01
| Резерв на новую работу
| см. 145

|-align="center"
| 643.МИФТ.00147-01
| Резерв на новую работу
| см. 145

|-align="center"
| 643.МИФТ.00148-01
| Резерв на новую работу
| см. 145

|-align="center"
| 643.МИФТ.00149-01
| Резерв на новую работу
| см. 145

|-align="center"
| rowspan ="5"| '''Флагман'''
| 643.МИФТ.00140-01
| СПМО ПП
| самая большая программа, в неё входят остальные компоненты

|-align="center"
| 643.МИФТ.00141-01
| Конфигурация ОС
| входит в 00140

|-align="center"
| 643.МИФТ.00142-01
| Прошивка программируемой логики ПП
| входит в 00140, описание Zynq PL

|-align="center"
| 643.МИФТ.00143-01
| Программа процессорной системы ПП
| входит в 00140, описание Zynq PS

|-align="center"
| 643.МИФТ.00144-01
| Технологическое ПО
| входит в 00140, srns2txt, sendsrns, imipointer и т.п.

|}
[[Категория:SRNS.ru]]

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

2020-08-21T06:30:15Z

Dneprov: /* 2020.07.28 - План по устранению проблем в платах АЦП и Oryx */

<summary [ hidden ]>

Записи о текущих испытаниях Орикса, Клоникуса и т.п.
</summary>

{{Форма3}}

{{TOCright}}

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

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

Желательно записывать следующие данные:
* дату испытания (в заголовке);
* номер ревизии 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 минут работы:
[[image:Screenshot_20200605_131702.png|center]]

Плотность отправки пакетов:
[[image:Screenshot_20200605_132120.png|center]]

Наибольшую плотность создает отправка эфемерид каждый 30 секунд, несколько десятков пакетов (сотня-две при полной нагрузке):
[[image:20200506_enp4s0_001.png|center]]

При этом достигается пиковая скорость 5кбайт/мс (50 при экстраполяции на полную нагрузку):
[[image:20200506_enp4s0_002.png|center]]



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

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

Измерения от 12 спутников отправляются раз в секунду в пакете 0xF5, 12 спутников занимают порядка 400 байт:
[[image:20200506_enp4s0_003.png|center]]

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

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

== 2020.07.21 - Очередные мучения с PPS OUT в ККН ==

* номер ревизии PL: [https://gitlab.srns.ru:8080/git/src/commit/2c9bf757016cb7796a6188fce514a494d92cdad8| 2c9bf757]
* номер ревизии PS: [https://gitlab.srns.ru:8080/git/src/commit/fc467aa0d30a6d5f54445cc8153944d2d3d9dd0e| fc467aa0]
* номер ревизии PL южного моста: [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/f695100df9f88f713932f8daeabf75aa352c1d1c| f695100d]
* номер ревизии PL платы АЦП: [https://gitlab.srns.ru:8080/git/adc_rev3/commit/0a0015868fb8a8914e0abed88c4ec5603d6eeb7b| 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: [https://gitlab.srns.ru:8080/git/src/commit/2c9bf757016cb7796a6188fce514a494d92cdad8| 2c9bf757]
* номер ревизии PS: [https://gitlab.srns.ru:8080/git/src/commit/fc467aa0d30a6d5f54445cc8153944d2d3d9dd0e| fc467aa0]
* номер ревизии PL южного моста: [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/f695100df9f88f713932f8daeabf75aa352c1d1c| f695100d]
* номер ревизии PL платы АЦП: [https://gitlab.srns.ru:8080/git/adc_rev3/commit/0a0015868fb8a8914e0abed88c4ec5603d6eeb7b| 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.

[[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.
** сделано в коммите [https://gitlab.srns.ru:8080/git/adc_rev3/commit/558992d20fd15d5e92f8031fcea4fbed1cd9d225 | 558992d2]
* Поднять обратно 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 - упрощаем монстра.
** сделано в коммите [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/3ecc30ce1dedb84c636e05821723add06d97217a | 3ecc30ce]

Два

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

Три

* Чинить/освежать блоки Calibration и RefInterp в Oryx
** Calibration переделан тут (см. два мердженных коммита) [https://gitlab.srns.ru:8080/git/src/commit/1f59ed4248d6d644a31e3fa8171bf60cdedf7194 | 1f59ed42].
* Поднять UART из ZynQ для управления MCR, прокинуть его через южный мост к плате управления MCR. Там есть джамперы и 3х-пиновый разъем, можно переключаться между разъем на панели прибора / спец разъем.
** Сделано, работает. Коммит src [https://gitlab.srns.ru:8080/git/src/commit/33be60030193279208fa79a1bebb615673422794 | 33be6003]. Коммит южного моста [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/67ed0dbe96634ae136db85261b2c763aed7b31d5 | 67ed0dbe].

{{wl-publish: 2020-06-05 12:52:18 +0300 | Korogodin }}

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

2020-08-21T06:20:46Z

Dneprov: /* 2020.07.28 - План по устранению проблем в платах АЦП и Oryx */

<summary [ hidden ]>

Записи о текущих испытаниях Орикса, Клоникуса и т.п.
</summary>

{{Форма3}}

{{TOCright}}

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

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

Желательно записывать следующие данные:
* дату испытания (в заголовке);
* номер ревизии 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 минут работы:
[[image:Screenshot_20200605_131702.png|center]]

Плотность отправки пакетов:
[[image:Screenshot_20200605_132120.png|center]]

Наибольшую плотность создает отправка эфемерид каждый 30 секунд, несколько десятков пакетов (сотня-две при полной нагрузке):
[[image:20200506_enp4s0_001.png|center]]

При этом достигается пиковая скорость 5кбайт/мс (50 при экстраполяции на полную нагрузку):
[[image:20200506_enp4s0_002.png|center]]



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

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

Измерения от 12 спутников отправляются раз в секунду в пакете 0xF5, 12 спутников занимают порядка 400 байт:
[[image:20200506_enp4s0_003.png|center]]

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

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

== 2020.07.21 - Очередные мучения с PPS OUT в ККН ==

* номер ревизии PL: [https://gitlab.srns.ru:8080/git/src/commit/2c9bf757016cb7796a6188fce514a494d92cdad8| 2c9bf757]
* номер ревизии PS: [https://gitlab.srns.ru:8080/git/src/commit/fc467aa0d30a6d5f54445cc8153944d2d3d9dd0e| fc467aa0]
* номер ревизии PL южного моста: [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/f695100df9f88f713932f8daeabf75aa352c1d1c| f695100d]
* номер ревизии PL платы АЦП: [https://gitlab.srns.ru:8080/git/adc_rev3/commit/0a0015868fb8a8914e0abed88c4ec5603d6eeb7b| 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: [https://gitlab.srns.ru:8080/git/src/commit/2c9bf757016cb7796a6188fce514a494d92cdad8| 2c9bf757]
* номер ревизии PS: [https://gitlab.srns.ru:8080/git/src/commit/fc467aa0d30a6d5f54445cc8153944d2d3d9dd0e| fc467aa0]
* номер ревизии PL южного моста: [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/f695100df9f88f713932f8daeabf75aa352c1d1c| f695100d]
* номер ревизии PL платы АЦП: [https://gitlab.srns.ru:8080/git/adc_rev3/commit/0a0015868fb8a8914e0abed88c4ec5603d6eeb7b| 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.

[[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.
** сделано в коммите [https://gitlab.srns.ru:8080/git/adc_rev3/commit/558992d20fd15d5e92f8031fcea4fbed1cd9d225| 558992d2]
* Поднять обратно 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 - упрощаем монстра.
** сделано в коммите [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/3ecc30ce1dedb84c636e05821723add06d97217a| 3ecc30ce]

Два

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

Три

* Чинить/освежать блоки Calibration и RefInterp в Oryx
** Calibration переделан тут (см. два мердженных коммита) [https://gitlab.srns.ru:8080/git/src/commit/1f59ed4248d6d644a31e3fa8171bf60cdedf7194| 1f59ed42].
* Поднять UART из ZynQ для управления MCR, прокинуть его через южный мост к плате управления MCR. Там есть джамперы и 3х-пиновый разъем, можно переключаться между разъем на панели прибора / спец разъем.
** Сделано, работает. Коммит src [https://gitlab.srns.ru:8080/git/src/commit/33be60030193279208fa79a1bebb615673422794| 33be6003]. Коммит южного моста [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/67ed0dbe96634ae136db85261b2c763aed7b31d5| 67ed0dbe].

{{wl-publish: 2020-06-05 12:52:18 +0300 | Korogodin }}

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

2020-08-21T06:19:55Z

Dneprov:

<summary [ hidden ]>

Записи о текущих испытаниях Орикса, Клоникуса и т.п.
</summary>

{{Форма3}}

{{TOCright}}

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

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

Желательно записывать следующие данные:
* дату испытания (в заголовке);
* номер ревизии 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 минут работы:
[[image:Screenshot_20200605_131702.png|center]]

Плотность отправки пакетов:
[[image:Screenshot_20200605_132120.png|center]]

Наибольшую плотность создает отправка эфемерид каждый 30 секунд, несколько десятков пакетов (сотня-две при полной нагрузке):
[[image:20200506_enp4s0_001.png|center]]

При этом достигается пиковая скорость 5кбайт/мс (50 при экстраполяции на полную нагрузку):
[[image:20200506_enp4s0_002.png|center]]



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

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

Измерения от 12 спутников отправляются раз в секунду в пакете 0xF5, 12 спутников занимают порядка 400 байт:
[[image:20200506_enp4s0_003.png|center]]

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

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

== 2020.07.21 - Очередные мучения с PPS OUT в ККН ==

* номер ревизии PL: [https://gitlab.srns.ru:8080/git/src/commit/2c9bf757016cb7796a6188fce514a494d92cdad8| 2c9bf757]
* номер ревизии PS: [https://gitlab.srns.ru:8080/git/src/commit/fc467aa0d30a6d5f54445cc8153944d2d3d9dd0e| fc467aa0]
* номер ревизии PL южного моста: [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/f695100df9f88f713932f8daeabf75aa352c1d1c| f695100d]
* номер ревизии PL платы АЦП: [https://gitlab.srns.ru:8080/git/adc_rev3/commit/0a0015868fb8a8914e0abed88c4ec5603d6eeb7b| 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: [https://gitlab.srns.ru:8080/git/src/commit/2c9bf757016cb7796a6188fce514a494d92cdad8| 2c9bf757]
* номер ревизии PS: [https://gitlab.srns.ru:8080/git/src/commit/fc467aa0d30a6d5f54445cc8153944d2d3d9dd0e| fc467aa0]
* номер ревизии PL южного моста: [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/f695100df9f88f713932f8daeabf75aa352c1d1c| f695100d]
* номер ревизии PL платы АЦП: [https://gitlab.srns.ru:8080/git/adc_rev3/commit/0a0015868fb8a8914e0abed88c4ec5603d6eeb7b| 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.

[[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.
** сделано в коммите [https://gitlab.srns.ru:8080/git/adc_rev3/commit/d6a6bc53c1451cdc2cfc4cc8398acb213398e685| d6a6bc53]
* Поднять обратно 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 - упрощаем монстра.
** сделано в коммите [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/3ecc30ce1dedb84c636e05821723add06d97217a| 3ecc30ce]

Два

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

Три

* Чинить/освежать блоки Calibration и RefInterp в Oryx
** Calibration переделан тут (см. два мердженных коммита) [https://gitlab.srns.ru:8080/git/src/commit/1f59ed4248d6d644a31e3fa8171bf60cdedf7194| 1f59ed42].
* Поднять UART из ZynQ для управления MCR, прокинуть его через южный мост к плате управления MCR. Там есть джамперы и 3х-пиновый разъем, можно переключаться между разъем на панели прибора / спец разъем.
** Сделано, работает. Коммит src [https://gitlab.srns.ru:8080/git/src/commit/33be60030193279208fa79a1bebb615673422794| 33be6003]. Коммит южного моста [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/67ed0dbe96634ae136db85261b2c763aed7b31d5| 67ed0dbe].

{{wl-publish: 2020-06-05 12:52:18 +0300 | Korogodin }}

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

2020-08-18T10:42:49Z

Dneprov: /* 2020.07.28 - План по устранению проблем в платах АЦП и Oryx */

<summary [ hidden ]>

Записи о текущих испытаниях Орикса, Клоникуса и т.п.
</summary>

{{TOCright}}

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

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

Желательно записывать следующие данные:
* дату испытания (в заголовке);
* номер ревизии 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 минут работы:
[[image:Screenshot_20200605_131702.png|center]]

Плотность отправки пакетов:
[[image:Screenshot_20200605_132120.png|center]]

Наибольшую плотность создает отправка эфемерид каждый 30 секунд, несколько десятков пакетов (сотня-две при полной нагрузке):
[[image:20200506_enp4s0_001.png|center]]

При этом достигается пиковая скорость 5кбайт/мс (50 при экстраполяции на полную нагрузку):
[[image:20200506_enp4s0_002.png|center]]



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

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

Измерения от 12 спутников отправляются раз в секунду в пакете 0xF5, 12 спутников занимают порядка 400 байт:
[[image:20200506_enp4s0_003.png|center]]

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

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

== 2020.07.21 - Очередные мучения с PPS OUT в ККН ==

* номер ревизии PL: [https://gitlab.srns.ru:8080/git/src/commit/2c9bf757016cb7796a6188fce514a494d92cdad8| 2c9bf757]
* номер ревизии PS: [https://gitlab.srns.ru:8080/git/src/commit/fc467aa0d30a6d5f54445cc8153944d2d3d9dd0e| fc467aa0]
* номер ревизии PL южного моста: [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/f695100df9f88f713932f8daeabf75aa352c1d1c| f695100d]
* номер ревизии PL платы АЦП: [https://gitlab.srns.ru:8080/git/adc_rev3/commit/0a0015868fb8a8914e0abed88c4ec5603d6eeb7b| 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: [https://gitlab.srns.ru:8080/git/src/commit/2c9bf757016cb7796a6188fce514a494d92cdad8| 2c9bf757]
* номер ревизии PS: [https://gitlab.srns.ru:8080/git/src/commit/fc467aa0d30a6d5f54445cc8153944d2d3d9dd0e| fc467aa0]
* номер ревизии PL южного моста: [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/f695100df9f88f713932f8daeabf75aa352c1d1c| f695100d]
* номер ревизии PL платы АЦП: [https://gitlab.srns.ru:8080/git/adc_rev3/commit/0a0015868fb8a8914e0abed88c4ec5603d6eeb7b| 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.

[[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.
** сделано в коммите [https://gitlab.srns.ru:8080/git/adc_rev3/commit/d6a6bc53c1451cdc2cfc4cc8398acb213398e685| d6a6bc53]
* Поднять обратно 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 - упрощаем монстра.
** сделано в коммите [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/3ecc30ce1dedb84c636e05821723add06d97217a| 3ecc30ce]

Два

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

Три

* Чинить/освежать блоки Calibration и RefInterp в Oryx
** Calibration переделан тут (см. два мердженных коммита) [https://gitlab.srns.ru:8080/git/src/commit/1f59ed4248d6d644a31e3fa8171bf60cdedf7194| 1f59ed42].
* Поднять UART из ZynQ для управления MCR, прокинуть его через южный мост к плате управления MCR. Там есть джамперы и 3х-пиновый разъем, можно переключаться между разъем на панели прибора / спец разъем.
** Сделано, работает. Коммит src [https://gitlab.srns.ru:8080/git/src/commit/33be60030193279208fa79a1bebb615673422794| 33be6003]. Коммит южного моста [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/67ed0dbe96634ae136db85261b2c763aed7b31d5| 67ed0dbe].

{{wl-publish: 2020-06-05 12:52:18 +0300 | Korogodin }}

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

2020-08-18T10:35:08Z

Dneprov: /* 2020.07.28 - План по устранению проблем в платах АЦП и Oryx */

<summary [ hidden ]>

Записи о текущих испытаниях Орикса, Клоникуса и т.п.
</summary>

{{TOCright}}

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

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

Желательно записывать следующие данные:
* дату испытания (в заголовке);
* номер ревизии 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 минут работы:
[[image:Screenshot_20200605_131702.png|center]]

Плотность отправки пакетов:
[[image:Screenshot_20200605_132120.png|center]]

Наибольшую плотность создает отправка эфемерид каждый 30 секунд, несколько десятков пакетов (сотня-две при полной нагрузке):
[[image:20200506_enp4s0_001.png|center]]

При этом достигается пиковая скорость 5кбайт/мс (50 при экстраполяции на полную нагрузку):
[[image:20200506_enp4s0_002.png|center]]



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

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

Измерения от 12 спутников отправляются раз в секунду в пакете 0xF5, 12 спутников занимают порядка 400 байт:
[[image:20200506_enp4s0_003.png|center]]

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

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

== 2020.07.21 - Очередные мучения с PPS OUT в ККН ==

* номер ревизии PL: [https://gitlab.srns.ru:8080/git/src/commit/2c9bf757016cb7796a6188fce514a494d92cdad8| 2c9bf757]
* номер ревизии PS: [https://gitlab.srns.ru:8080/git/src/commit/fc467aa0d30a6d5f54445cc8153944d2d3d9dd0e| fc467aa0]
* номер ревизии PL южного моста: [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/f695100df9f88f713932f8daeabf75aa352c1d1c| f695100d]
* номер ревизии PL платы АЦП: [https://gitlab.srns.ru:8080/git/adc_rev3/commit/0a0015868fb8a8914e0abed88c4ec5603d6eeb7b| 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: [https://gitlab.srns.ru:8080/git/src/commit/2c9bf757016cb7796a6188fce514a494d92cdad8| 2c9bf757]
* номер ревизии PS: [https://gitlab.srns.ru:8080/git/src/commit/fc467aa0d30a6d5f54445cc8153944d2d3d9dd0e| fc467aa0]
* номер ревизии PL южного моста: [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/f695100df9f88f713932f8daeabf75aa352c1d1c| f695100d]
* номер ревизии PL платы АЦП: [https://gitlab.srns.ru:8080/git/adc_rev3/commit/0a0015868fb8a8914e0abed88c4ec5603d6eeb7b| 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.

[[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.
** сделано в коммите [https://gitlab.srns.ru:8080/git/adc_rev3/commit/d6a6bc53c1451cdc2cfc4cc8398acb213398e685| d6a6bc53]
* Поднять обратно 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 - упрощаем монстра.
** сделано в коммите [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/3ecc30ce1dedb84c636e05821723add06d97217a| 3ecc30ce]

Два

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

Три

* Чинить/освежать блоки Calibration и RefInterp в Oryx
** Calibration починен тут (см. два мердженных коммита) [https://gitlab.srns.ru:8080/git/src/commit/1f59ed4248d6d644a31e3fa8171bf60cdedf7194| 1f59ed42].
* Поднять UART из ZynQ для управления MCR, прокинуть его через южный мост к плате управления MCR. Там есть джамперы и 3х-пиновый разъем, можно переключаться между разъем на панели прибора / спец разъем.
** Сделано, работает. Коммит src [https://gitlab.srns.ru:8080/git/src/commit/33be60030193279208fa79a1bebb615673422794| 33be6003]. Коммит южного моста [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/67ed0dbe96634ae136db85261b2c763aed7b31d5| 67ed0dbe].

{{wl-publish: 2020-06-05 12:52:18 +0300 | Korogodin }}

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

2020-08-18T10:31:34Z

Dneprov: /* 2020.07.28 - План по устранению проблем в платах АЦП и Oryx */

<summary [ hidden ]>

Записи о текущих испытаниях Орикса, Клоникуса и т.п.
</summary>

{{TOCright}}

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

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

Желательно записывать следующие данные:
* дату испытания (в заголовке);
* номер ревизии 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 минут работы:
[[image:Screenshot_20200605_131702.png|center]]

Плотность отправки пакетов:
[[image:Screenshot_20200605_132120.png|center]]

Наибольшую плотность создает отправка эфемерид каждый 30 секунд, несколько десятков пакетов (сотня-две при полной нагрузке):
[[image:20200506_enp4s0_001.png|center]]

При этом достигается пиковая скорость 5кбайт/мс (50 при экстраполяции на полную нагрузку):
[[image:20200506_enp4s0_002.png|center]]



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

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

Измерения от 12 спутников отправляются раз в секунду в пакете 0xF5, 12 спутников занимают порядка 400 байт:
[[image:20200506_enp4s0_003.png|center]]

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

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

== 2020.07.21 - Очередные мучения с PPS OUT в ККН ==

* номер ревизии PL: [https://gitlab.srns.ru:8080/git/src/commit/2c9bf757016cb7796a6188fce514a494d92cdad8| 2c9bf757]
* номер ревизии PS: [https://gitlab.srns.ru:8080/git/src/commit/fc467aa0d30a6d5f54445cc8153944d2d3d9dd0e| fc467aa0]
* номер ревизии PL южного моста: [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/f695100df9f88f713932f8daeabf75aa352c1d1c| f695100d]
* номер ревизии PL платы АЦП: [https://gitlab.srns.ru:8080/git/adc_rev3/commit/0a0015868fb8a8914e0abed88c4ec5603d6eeb7b| 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: [https://gitlab.srns.ru:8080/git/src/commit/2c9bf757016cb7796a6188fce514a494d92cdad8| 2c9bf757]
* номер ревизии PS: [https://gitlab.srns.ru:8080/git/src/commit/fc467aa0d30a6d5f54445cc8153944d2d3d9dd0e| fc467aa0]
* номер ревизии PL южного моста: [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/f695100df9f88f713932f8daeabf75aa352c1d1c| f695100d]
* номер ревизии PL платы АЦП: [https://gitlab.srns.ru:8080/git/adc_rev3/commit/0a0015868fb8a8914e0abed88c4ec5603d6eeb7b| 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.

[[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.
** сделано в коммите [https://gitlab.srns.ru:8080/git/adc_rev3/commit/d6a6bc53c1451cdc2cfc4cc8398acb213398e685| d6a6bc53]
* Поднять обратно 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 - упрощаем монстра.
** сделано в коммите [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/3ecc30ce1dedb84c636e05821723add06d97217a| 3ecc30ce]

Два

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

Три

* Чинить/освежать блоки Calibration и RefInterp в Oryx
* Поднять UART из ZynQ для управления MCR, прокинуть его через южный мост к плате управления MCR. Там есть джамперы и 3х-пиновый разъем, можно переключаться между разъем на панели прибора / спец разъем.
** Сделано, работает. Коммит src [https://gitlab.srns.ru:8080/git/src/commit/33be60030193279208fa79a1bebb615673422794| 33be6003]. Коммит южного моста [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/67ed0dbe96634ae136db85261b2c763aed7b31d5| 67ed0dbe].

{{wl-publish: 2020-06-05 12:52:18 +0300 | Korogodin }}

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

2020-08-18T10:31:22Z

Dneprov: /* 2020.07.28 - План по устранению проблем в платах АЦП и Oryx */

<summary [ hidden ]>

Записи о текущих испытаниях Орикса, Клоникуса и т.п.
</summary>

{{TOCright}}

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

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

Желательно записывать следующие данные:
* дату испытания (в заголовке);
* номер ревизии 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 минут работы:
[[image:Screenshot_20200605_131702.png|center]]

Плотность отправки пакетов:
[[image:Screenshot_20200605_132120.png|center]]

Наибольшую плотность создает отправка эфемерид каждый 30 секунд, несколько десятков пакетов (сотня-две при полной нагрузке):
[[image:20200506_enp4s0_001.png|center]]

При этом достигается пиковая скорость 5кбайт/мс (50 при экстраполяции на полную нагрузку):
[[image:20200506_enp4s0_002.png|center]]



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

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

Измерения от 12 спутников отправляются раз в секунду в пакете 0xF5, 12 спутников занимают порядка 400 байт:
[[image:20200506_enp4s0_003.png|center]]

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

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

== 2020.07.21 - Очередные мучения с PPS OUT в ККН ==

* номер ревизии PL: [https://gitlab.srns.ru:8080/git/src/commit/2c9bf757016cb7796a6188fce514a494d92cdad8| 2c9bf757]
* номер ревизии PS: [https://gitlab.srns.ru:8080/git/src/commit/fc467aa0d30a6d5f54445cc8153944d2d3d9dd0e| fc467aa0]
* номер ревизии PL южного моста: [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/f695100df9f88f713932f8daeabf75aa352c1d1c| f695100d]
* номер ревизии PL платы АЦП: [https://gitlab.srns.ru:8080/git/adc_rev3/commit/0a0015868fb8a8914e0abed88c4ec5603d6eeb7b| 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: [https://gitlab.srns.ru:8080/git/src/commit/2c9bf757016cb7796a6188fce514a494d92cdad8| 2c9bf757]
* номер ревизии PS: [https://gitlab.srns.ru:8080/git/src/commit/fc467aa0d30a6d5f54445cc8153944d2d3d9dd0e| fc467aa0]
* номер ревизии PL южного моста: [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/f695100df9f88f713932f8daeabf75aa352c1d1c| f695100d]
* номер ревизии PL платы АЦП: [https://gitlab.srns.ru:8080/git/adc_rev3/commit/0a0015868fb8a8914e0abed88c4ec5603d6eeb7b| 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.

[[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.
** сделано в коммите [https://gitlab.srns.ru:8080/git/adc_rev3/commit/d6a6bc53c1451cdc2cfc4cc8398acb213398e685| d6a6bc53]
* Поднять обратно 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 - упрощаем монстра.
** сделано в коммите [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/3ecc30ce1dedb84c636e05821723add06d97217a| 3ecc30ce]

Два

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

Три

* Чинить/освежать блоки Calibration и RefInterp в Oryx
* Поднять UART из ZynQ для управления MCR, прокинуть его через южный мост к плате управления MCR. Там есть джамперы и 3х-пиновый разъем, можно переключаться между разъем на панели прибора / спец разъем.
** Сделано, работает. Коммит src [https://gitlab.srns.ru:8080/git/src/commit/33be60030193279208fa79a1bebb615673422794| 33be6003]]. Коммит южного моста [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/67ed0dbe96634ae136db85261b2c763aed7b31d5| 67ed0dbe].

{{wl-publish: 2020-06-05 12:52:18 +0300 | Korogodin }}

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

2020-08-11T11:26:14Z

Dneprov: /* 2020.07.28 - План по устранению проблем в платах АЦП и Oryx */

<summary [ hidden ]>

Записи о текущих испытаниях Орикса, Клоникуса и т.п.
</summary>

{{TOCright}}

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

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

Желательно записывать следующие данные:
* дату испытания (в заголовке);
* номер ревизии 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 минут работы:
[[image:Screenshot_20200605_131702.png|center]]

Плотность отправки пакетов:
[[image:Screenshot_20200605_132120.png|center]]

Наибольшую плотность создает отправка эфемерид каждый 30 секунд, несколько десятков пакетов (сотня-две при полной нагрузке):
[[image:20200506_enp4s0_001.png|center]]

При этом достигается пиковая скорость 5кбайт/мс (50 при экстраполяции на полную нагрузку):
[[image:20200506_enp4s0_002.png|center]]



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

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

Измерения от 12 спутников отправляются раз в секунду в пакете 0xF5, 12 спутников занимают порядка 400 байт:
[[image:20200506_enp4s0_003.png|center]]

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

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

== 2020.07.21 - Очередные мучения с PPS OUT в ККН ==

* номер ревизии PL: [https://gitlab.srns.ru:8080/git/src/commit/2c9bf757016cb7796a6188fce514a494d92cdad8| 2c9bf757]
* номер ревизии PS: [https://gitlab.srns.ru:8080/git/src/commit/fc467aa0d30a6d5f54445cc8153944d2d3d9dd0e| fc467aa0]
* номер ревизии PL южного моста: [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/f695100df9f88f713932f8daeabf75aa352c1d1c| f695100d]
* номер ревизии PL платы АЦП: [https://gitlab.srns.ru:8080/git/adc_rev3/commit/0a0015868fb8a8914e0abed88c4ec5603d6eeb7b| 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: [https://gitlab.srns.ru:8080/git/src/commit/2c9bf757016cb7796a6188fce514a494d92cdad8| 2c9bf757]
* номер ревизии PS: [https://gitlab.srns.ru:8080/git/src/commit/fc467aa0d30a6d5f54445cc8153944d2d3d9dd0e| fc467aa0]
* номер ревизии PL южного моста: [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/f695100df9f88f713932f8daeabf75aa352c1d1c| f695100d]
* номер ревизии PL платы АЦП: [https://gitlab.srns.ru:8080/git/adc_rev3/commit/0a0015868fb8a8914e0abed88c4ec5603d6eeb7b| 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.

[[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.
** сделано в коммите [https://gitlab.srns.ru:8080/git/adc_rev3/commit/d6a6bc53c1451cdc2cfc4cc8398acb213398e685| d6a6bc53]
* Поднять обратно 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 - упрощаем монстра.
** сделано в коммите [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/3ecc30ce1dedb84c636e05821723add06d97217a| 3ecc30ce]

Два

* Оценить стабильность задержки от 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 }}

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

2020-08-11T11:22:23Z

Dneprov: /* 2020.07.28 - План по устранению проблем в платах АЦП и Oryx */

<summary [ hidden ]>

Записи о текущих испытаниях Орикса, Клоникуса и т.п.
</summary>

{{TOCright}}

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

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

Желательно записывать следующие данные:
* дату испытания (в заголовке);
* номер ревизии 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 минут работы:
[[image:Screenshot_20200605_131702.png|center]]

Плотность отправки пакетов:
[[image:Screenshot_20200605_132120.png|center]]

Наибольшую плотность создает отправка эфемерид каждый 30 секунд, несколько десятков пакетов (сотня-две при полной нагрузке):
[[image:20200506_enp4s0_001.png|center]]

При этом достигается пиковая скорость 5кбайт/мс (50 при экстраполяции на полную нагрузку):
[[image:20200506_enp4s0_002.png|center]]



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

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

Измерения от 12 спутников отправляются раз в секунду в пакете 0xF5, 12 спутников занимают порядка 400 байт:
[[image:20200506_enp4s0_003.png|center]]

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

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

== 2020.07.21 - Очередные мучения с PPS OUT в ККН ==

* номер ревизии PL: [https://gitlab.srns.ru:8080/git/src/commit/2c9bf757016cb7796a6188fce514a494d92cdad8| 2c9bf757]
* номер ревизии PS: [https://gitlab.srns.ru:8080/git/src/commit/fc467aa0d30a6d5f54445cc8153944d2d3d9dd0e| fc467aa0]
* номер ревизии PL южного моста: [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/f695100df9f88f713932f8daeabf75aa352c1d1c| f695100d]
* номер ревизии PL платы АЦП: [https://gitlab.srns.ru:8080/git/adc_rev3/commit/0a0015868fb8a8914e0abed88c4ec5603d6eeb7b| 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: [https://gitlab.srns.ru:8080/git/src/commit/2c9bf757016cb7796a6188fce514a494d92cdad8| 2c9bf757]
* номер ревизии PS: [https://gitlab.srns.ru:8080/git/src/commit/fc467aa0d30a6d5f54445cc8153944d2d3d9dd0e| fc467aa0]
* номер ревизии PL южного моста: [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/f695100df9f88f713932f8daeabf75aa352c1d1c| f695100d]
* номер ревизии PL платы АЦП: [https://gitlab.srns.ru:8080/git/adc_rev3/commit/0a0015868fb8a8914e0abed88c4ec5603d6eeb7b| 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.

[[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.
** сделано в коммите [https://gitlab.srns.ru:8080/git/adc_rev3/commit/d6a6bc53c1451cdc2cfc4cc8398acb213398e685| d6a6bc53]
* Поднять обратно 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 - упрощаем монстра.
** сделано в коммите [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/3ecc30ce1dedb84c636e05821723add06d97217a| 3ecc30ce]

Два

* Оценить стабильность задержки от 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 }}

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

2020-07-28T07:11:13Z

Dneprov: /* 2020.07.28 - План по устранению проблем в платах АЦП и Oryx */

<summary [ hidden ]>

Записи о текущих испытаниях Орикса, Клоникуса и т.п.
</summary>

{{TOCright}}

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

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

Желательно записывать следующие данные:
* дату испытания (в заголовке);
* номер ревизии 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 минут работы:
[[image:Screenshot_20200605_131702.png|center]]

Плотность отправки пакетов:
[[image:Screenshot_20200605_132120.png|center]]

Наибольшую плотность создает отправка эфемерид каждый 30 секунд, несколько десятков пакетов (сотня-две при полной нагрузке):
[[image:20200506_enp4s0_001.png|center]]

При этом достигается пиковая скорость 5кбайт/мс (50 при экстраполяции на полную нагрузку):
[[image:20200506_enp4s0_002.png|center]]



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

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

Измерения от 12 спутников отправляются раз в секунду в пакете 0xF5, 12 спутников занимают порядка 400 байт:
[[image:20200506_enp4s0_003.png|center]]

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

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

== 2020.07.21 - Очередные мучения с PPS OUT в ККН ==

* номер ревизии PL: [https://gitlab.srns.ru:8080/git/src/commit/2c9bf757016cb7796a6188fce514a494d92cdad8| 2c9bf757]
* номер ревизии PS: [https://gitlab.srns.ru:8080/git/src/commit/fc467aa0d30a6d5f54445cc8153944d2d3d9dd0e| fc467aa0]
* номер ревизии PL южного моста: [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/f695100df9f88f713932f8daeabf75aa352c1d1c| f695100d]
* номер ревизии PL платы АЦП: [https://gitlab.srns.ru:8080/git/adc_rev3/commit/0a0015868fb8a8914e0abed88c4ec5603d6eeb7b| 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: [https://gitlab.srns.ru:8080/git/src/commit/2c9bf757016cb7796a6188fce514a494d92cdad8| 2c9bf757]
* номер ревизии PS: [https://gitlab.srns.ru:8080/git/src/commit/fc467aa0d30a6d5f54445cc8153944d2d3d9dd0e| fc467aa0]
* номер ревизии PL южного моста: [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/f695100df9f88f713932f8daeabf75aa352c1d1c| f695100d]
* номер ревизии PL платы АЦП: [https://gitlab.srns.ru:8080/git/adc_rev3/commit/0a0015868fb8a8914e0abed88c4ec5603d6eeb7b| 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.

[[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 }}

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

2020-07-28T07:10:21Z

Dneprov: /* 2020.07.27 - Постоянство задержки от сериалайзера платы АЦП до десериалайзера платы Oryx */

<summary [ hidden ]>

Записи о текущих испытаниях Орикса, Клоникуса и т.п.
</summary>

{{TOCright}}

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

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

Желательно записывать следующие данные:
* дату испытания (в заголовке);
* номер ревизии 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 минут работы:
[[image:Screenshot_20200605_131702.png|center]]

Плотность отправки пакетов:
[[image:Screenshot_20200605_132120.png|center]]

Наибольшую плотность создает отправка эфемерид каждый 30 секунд, несколько десятков пакетов (сотня-две при полной нагрузке):
[[image:20200506_enp4s0_001.png|center]]

При этом достигается пиковая скорость 5кбайт/мс (50 при экстраполяции на полную нагрузку):
[[image:20200506_enp4s0_002.png|center]]



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

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

Измерения от 12 спутников отправляются раз в секунду в пакете 0xF5, 12 спутников занимают порядка 400 байт:
[[image:20200506_enp4s0_003.png|center]]

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

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

== 2020.07.21 - Очередные мучения с PPS OUT в ККН ==

* номер ревизии PL: [https://gitlab.srns.ru:8080/git/src/commit/2c9bf757016cb7796a6188fce514a494d92cdad8| 2c9bf757]
* номер ревизии PS: [https://gitlab.srns.ru:8080/git/src/commit/fc467aa0d30a6d5f54445cc8153944d2d3d9dd0e| fc467aa0]
* номер ревизии PL южного моста: [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/f695100df9f88f713932f8daeabf75aa352c1d1c| f695100d]
* номер ревизии PL платы АЦП: [https://gitlab.srns.ru:8080/git/adc_rev3/commit/0a0015868fb8a8914e0abed88c4ec5603d6eeb7b| 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: [https://gitlab.srns.ru:8080/git/src/commit/2c9bf757016cb7796a6188fce514a494d92cdad8| 2c9bf757]
* номер ревизии PS: [https://gitlab.srns.ru:8080/git/src/commit/fc467aa0d30a6d5f54445cc8153944d2d3d9dd0e| fc467aa0]
* номер ревизии PL южного моста: [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/f695100df9f88f713932f8daeabf75aa352c1d1c| f695100d]
* номер ревизии PL платы АЦП: [https://gitlab.srns.ru:8080/git/adc_rev3/commit/0a0015868fb8a8914e0abed88c4ec5603d6eeb7b| 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.

[[file:Screenshot_2020-07-27_1_175704.png|600px]] [[file:Screenshot_2020-07-27_3_175834.png|600px]]

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

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

Два
1. Оценить стабильность задержки от SER Samtec платы АЦП до DESER ZynQ в Oryx. Эксперимент проведен, [[#2020.07.27 - Постоянство задержки от сериалайзера платы АЦП до десериалайзера платы Oryx| результат чуть выше]]. Есть проблема со скачком на клок от включения к включению.

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

{{wl-publish: 2020-06-05 12:52:18 +0300 | Korogodin }}

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

2020-07-28T06:34:22Z

Dneprov: /* 2020.07.27 - Постоянство задержки от сериалайзера платы АЦП до десериалайзера платы Oryx */

<summary [ hidden ]>

Записи о текущих испытаниях Орикса, Клоникуса и т.п.
</summary>

{{TOCright}}

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

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

Желательно записывать следующие данные:
* дату испытания (в заголовке);
* номер ревизии 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 минут работы:
[[image:Screenshot_20200605_131702.png|center]]

Плотность отправки пакетов:
[[image:Screenshot_20200605_132120.png|center]]

Наибольшую плотность создает отправка эфемерид каждый 30 секунд, несколько десятков пакетов (сотня-две при полной нагрузке):
[[image:20200506_enp4s0_001.png|center]]

При этом достигается пиковая скорость 5кбайт/мс (50 при экстраполяции на полную нагрузку):
[[image:20200506_enp4s0_002.png|center]]



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

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

Измерения от 12 спутников отправляются раз в секунду в пакете 0xF5, 12 спутников занимают порядка 400 байт:
[[image:20200506_enp4s0_003.png|center]]

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

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

== 2020.07.21 - Очередные мучения с PPS OUT в ККН ==

* номер ревизии PL: [https://gitlab.srns.ru:8080/git/src/commit/2c9bf757016cb7796a6188fce514a494d92cdad8| 2c9bf757]
* номер ревизии PS: [https://gitlab.srns.ru:8080/git/src/commit/fc467aa0d30a6d5f54445cc8153944d2d3d9dd0e| fc467aa0]
* номер ревизии PL южного моста: [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/f695100df9f88f713932f8daeabf75aa352c1d1c| f695100d]
* номер ревизии PL платы АЦП: [https://gitlab.srns.ru:8080/git/adc_rev3/commit/0a0015868fb8a8914e0abed88c4ec5603d6eeb7b| 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: [https://gitlab.srns.ru:8080/git/src/commit/2c9bf757016cb7796a6188fce514a494d92cdad8| 2c9bf757]
* номер ревизии PS: [https://gitlab.srns.ru:8080/git/src/commit/fc467aa0d30a6d5f54445cc8153944d2d3d9dd0e| fc467aa0]
* номер ревизии PL южного моста: [https://gitlab.srns.ru:8080/Lipa/oryx_south_bridge/commit/f695100df9f88f713932f8daeabf75aa352c1d1c| f695100d]
* номер ревизии PL платы АЦП: [https://gitlab.srns.ru:8080/git/adc_rev3/commit/0a0015868fb8a8914e0abed88c4ec5603d6eeb7b| 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.

[[file:Screenshot_2020-07-27_1_175704.png|600px]] [[file:Screenshot_2020-07-27_3_175834.png|600px]]

{{wl-publish: 2020-06-05 12:52:18 +0300 | Korogodin }}

Список децимальных номеров

2020-07-26T09:20:20Z

Dneprov: /* Список децимальников на ПО выданное по ЕСПД */

Список децимальных номеров

2020-07-26T08:55:42Z

Dneprov: /* Список децимальников на ПО выданное по ЕСПД */

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

2020-07-22T07:12:58Z

Dneprov: /* 2020.07.21 - Очередные мучения с PPS OUT в ККН */

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

2020-07-22T07:12:24Z

Dneprov: /* 2020.07.21 - Очередные мучения с PPS OUT в ККН */

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

2020-07-22T07:11:38Z

Dneprov: /* 2020.06.05 - Интенсивность обмена данными по сети Ethernet по протоколу SRNS */

Blog:Lipa/16.05.2018 PetaLinux

2020-07-03T13:32:05Z

Dneprov: /* Serial port на новом линуксе */

<summary [ hidden ] >

<center>[[File:Petalinux.png|400px]]</center>

Сборка PetaLinux для кастомной железки

</summary>

{{Форма2}}

== Требования ==

Vivado 2018.1 (для single-gigabit ethernet можно более ранние версии)

Начиная с petalinux_2018.1 отсутствует devcfg. Необходимо использовать FPGA manager. Технология нами пока не освоена

Необходима Ubuntu-16.04

Требуется поставить ряд пакетов, полный список приведен в документе [https://www.xilinx.com/support/documentation/sw_manuals/xilinx2019_1/ug1144-petalinux-tools-reference-guide.pdf#page=9 UG1144]

Устанавливаем PetaLinux в систему. Дистрибутив есть на [https://www.xilinx.com/support/download/index.html/content/xilinx/en/downloadNav/embedded-design-tools/2018-1.html Xilinx], либо у меня на компьютере. '''Ставить PetaLinux необходимо БЕЗ прав суперюзера!'''

кидаем в /components/yocto/ sstate-rel-v2017.4.tar.gz

Подготовка завершена

== Правка Vivado ==

Для поддержки MDIO в Vivado 17.1-17.4 нужен [https://www.xilinx.com/support/answers/69132.html патч]. Ставим!

'''Не помогло.''' Ставим 2018.1

== Сборка ==

Пошаговое руководство по сборке содержится в документе UG1156

В консоли пишем source/[путь к петалинух]/settings.sh

Выполняем шаги из UG1156 по главе 5:

* экспортируем из Vivado .hdf (в блок дизайн File->Export->Export Hardware)

* создаем проект PetaLinux
<source lang="bash">
$ petalinux-create --type project --template zynq --name <PROJECT>
</source>

* переходим в папку с текущим проектом

* подключаем файл .hdf
<source lang="bash">
$ petalinux-config --get-hw-description=[путь к папке с файлом .hdf]
</source>

* перед сборкой системы необходимо выполнить '''все''' команды конфигурации в данной последовательности:
<source lang="bash">
$ petalinux-config

$ petalinux-config -c kernel

$ petalinux-config -c rootfs
</source>

=== petalinux-config ===

Если хотим спользовать внешний файл device-tree включаем:

<source lang="bash">
Subsystem AUTO Hardware Settings->
Advances bootable images storage settings->
dtb image settings->
image storage media
primary sd

</source>

Необходимо править netboot offset если оперативной памяти менее ~256МБ

Для клоникуса с 256МБ ставим 8'000'000

<source lang="bash">
$ petalinux-config
</source>

<source lang="bash">
u-boot Configuration->
netboot offset
</source>

Выставляем точку начала распаковки образа системы

Выключаем копирование образа по sftp (Image Packaging Configuration -> Copy final images)

Отключаем интернет-sstate (Yocto Settings -> Enable Network sstate feeds)

=== petalinux-config -c kernel===

* Подключаем в ядре поддержку физика и его дров.

<source lang="bash">
$ petalinux-config -c kernel
</source>

'''для oryx:'''

<source lang="bash">
Device Drivers->
[*]Network device support ->
[*]Ethernet driver support ->
[*] Micrel devices
[*] PHY Device support and infastructure -->
[*] Drivers for Micrel PHYs
</source>

'''для clonicus:'''

<source lang="bash">
Device Drivers->
[*]Network device support ->
[*] PHY Device support and infastructure -->
[*] Texas Instruments DP83867 Gigabit PHY
</source>

=== petalinux-config -c rootfs ===

Подключаем при необходимости ethtool, gdbserver(просто gdb не заработал), libstdc, libgcc, glib2.0, glibc(glibc & ltd)
<source lang="bash">
Filesystem Packages->
misc ->
gcc-runtime ->
[*] libstdc ++
gdb -->
[*] gdb
glib-2.0
[*] glib-2.0
glibc
[*] glibc
[*] ldd
devel ->
python ->
python ->
[*] python
</source>

Опционально:
<source lang="bash">
Filesystem Packages->
base ->
i2c-tools ->
[*] i2c-tools
usbutils ->
[*] usbutils
console ->
network ->
ethtool ->
[*] ethtool // необходимо для oryx! для перенастройки autonegotiation
</source>

Можно еще подключать дебаг i2c

'''Необходимо убедиться, что образ может распаковаться в размер оперативы'''

Если будут проблемы, то надо будет править netboot offset

=== device tree ===

Если необходимо внести изменения в device tree, то смотрим конец статьи

[https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841676/U-Boot+Flattened+Device+Tree Интересная статья по правке devicetree из uboot]

=== Сборка проекта ===

* далее (сборка идет 30-60 минут)
<source lang="bash">
petalinux-build

cd /images/linux/
</source>
* делаем boot.bin в папке /images/linux/
<source lang="bash">
$ petalinux-package --boot --format BIN --fsbl ./zynq_fsbl.elf --u-boot --force

$ petalinux-package --boot --format BIN --fsbl ./zynq_fsbl.elf --fpga name.bit --u-boot --force

$ petalinux-package --boot --format BIN --fsbl ./zynq_fsbl.elf --fpga name.bit --u-boot --kernel --force
</source>

* записываем в загрузочную область флешки файлы boot.bin и image.ub

== Всякое ==

Если мало памяти как у нас - возможна ошибка image is not a fdt [https://forums.xilinx.com/t5/Embedded-Processor-System-Design/Petalinux-problem-on-custom-board-quot-image-is-not-a-fdt-quot/td-p/754892 ссылка]

Необходимо править netboot offset

<source lang="bash">
$ petalinux-config
</source>

<source lang="bash">
u-boot Configuration->
netboot offset
</source>

----

Можно вручную загрузиться из u-boot'а.

<source lang="bash">
$ fatload mmc 0 0xA000000 image.ub
$ bootm 0xA000000
</source>

либо

<source lang="bash">
$ fatload mmc 0 0xA000000 image.ub
$ fatload mmc 0 0x9000000 system.dtb
$ bootm 0xA000000 0xA000000 0x9000000
</source>

Можно поварьировать адрес

------------

Проверка статуса прошитости FPGA

<source lang="bash">
cat /sys/class/xdevcfg/xdevcfg/device/prog_done
</source>

==Uboot==

Для внесения правок в загрузку линукса используем список команд '''env'''

Просмотр текущих команд '''printenv'''

Сброс настроек в дефолт '''env default -a'''

Создать переменную '''env set <имя> <значение>'''

Правка переменной '''env edit <имя переменной>'''

---

Для каждой платы делаем следующее:

* Берем [[Файл:uboot.env.c]]

* Удаляем в конце имени ".c"

* Записываем на флешку рядом с образом линукса

* Запускаем плату и прерываем autoboot

* Пишем '''editenv ethaddr'''

* Редактируем MAC-адрес

* Пишем '''saveenv'''

* Все! можем ребутать '''reset'''

Сохранить в файл '''saveenv'''

==Автозапуск приложений==

Во-первых [https://forums.xilinx.com/t5/Embedded-Linux/Petalinux-Runnning-a-script-file-at-startup/td-p/689051 тыц]

Далее пишем

<source lang="bash">
petalinux-create -t apps --template install -n myapp-init --enable
</source>

Правим файл /project-spec/meta-user/recipes-apps/myapp-init/myapp-init.bb

<source lang="bash">
#
# This file is the myapp-init recipe.
#

SUMMARY = "Simple myapp-init application"
SECTION = "PETALINUX/apps"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"

SRC_URI = "file://myapp-init"

S = "${WORKDIR}"

FILESEXTRAPATHS_prepend := "${THISDIR}/files:"

inherit update-rc.d

INITSCRIPT_NAME = "myapp-init"
INITSCRIPT_PARAMS = "start 99 S ."

do_install() {
install -d ${D}${sysconfdir}/init.d
install -m 0755 ${S}/myapp-init ${D}${sysconfdir}/init.d/myapp-init
}
FILES_${PN} += "${sysconfdir}/*"
</source>

Правим сам исполняемый скрипт project-spec/meta-user/recipes-apps/myapp-init/files/myapp-init

<source lang="bash">
#!/bin/sh

echo "Autorun script"

echo "Try run custom_init"
sh /run/media/mmcblk0p1/custom_init.sh
</source>

Записываем на флешку скрипт custom_init.sh с нужными командами и делаем его исполняемым

Записываем файл interfaces

Скачать архив: [[Файл:Init_interfaces.rar]]

==SSH==

Как победить сохранение ssh-ключей:

Добавляем в init_script следующие строки:

<source lang="bash">
mkdir /run/media/mmcblk0p2/.ssh
ln -s /run/media/mmcblk0p2/.ssh/ /home/root/
mkdir /run/media/mmcblk0p2/dropbear/
chmod 400 /run/media/mmcblk0p2/dropbear/
rm -r /etc/dropbear/
ln -s /run/media/mmcblk0p2/dropbear/ /etc/
</source>

* Создается ссылка на флешку, где хранятся авторизованные пользователи
* Создается папка для хранения секретного ключа платы
* При запуске платы свежесозданный ключ заменяется тем, что лежит на флешке
* При первом включении платы будет создан новый ключ

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

==Daemon==

Для настройки демона:

* Добавляем строки в файл custom_init.sh
* Кидаем на загрузочный раздел флешки папку из архива [[:File:daemon.rar]]

<source lang="bash">
cp -r /run/media/mmcblk0p1/daemon/lsb /lib/
cp /run/media/mmcblk0p1/daemon/receiver.conf /etc/
cp /run/media/mmcblk0p1/daemon/receiver /etc/init.d/
</source>

=== Serial port на новом линуксе ===
Выяснилось, что без доп. настройки, в последовательный порт (dev/ttyPS0) после каждой посылки добавляются символы CR и LF. Оказалось, что и RTKLib, и софт Листопада не хотят работать с таким окончанием пакетов.

Выше не совсем так, скорее мысль в том, что каждый символ LF (0x0A) в наших данных меняется на символы CR LF, т.е. (0x0D0A). И тогда, в нашем битовом потоке меняется размер и содержимое и парсеры работают некорректно.
Старый линукс на Ориксах добавляет только LF. Для решения проблемы нужно через stty выключить в настройках порта опцию '''onlcr''' (преобразовывать перевод строки в возврат каретки и новую строку).

Сделать это удалось пока только изменив скрипт демона receiver. Для решения проблемы заходим в /run/media/mmcblk0p1/daemon/receiver, и в начале секции receiver_start() {...} добавляем команду:

<source lang="bash">
stty -F /dev/ttyPS0 -onlcr
</source>

==device tree==

Для внесения изменений в device tree добавляем нужные строки в файл

project-spec/meta-user/recipes-bsp/device-tree/files/system-user.dtsi

[https://www.xilinx.com/support/answers/61117.html пример]

Для разборки device-tree [http://xillybus.com/tutorials/device-tree-zynq-1 ссылка]
<source lang="bash">
$ dtc -I dtb -O dts -o <name>.dts <name>.dtb
</source>

Для сборки device-tree
<source lang="bash">
$ dtc -I dts -O dtb -o <name>.dtb <name>.dts
</source>

== Модификация device-tree ==

После долгих мучений получилось поднять DP83867 только после добавления модификатора в файл [https://forums.xilinx.com/t5/Embedded-Linux/ZC702-Like-Board-with-DP83867CR-Ethernet-Petalinux-2017-4/td-p/831873 волшебная статья]

[https://www.kernel.org/doc/Documentation/devicetree/bindings/net/ti%2Cdp83867.txt описание параметров]

project-spec/meta-user/recipes-bsp/device-tree/files/system-user.dtsi

=== Single Kit-board eth ===

В Vivado включен eth1(с mdio) и выключен eth0.

'''Так работает'''

<source lang="bash">
&gem1{
status = "okay";
phy-handle = <&phy0>;
phy-mode = "rgmii-id";

xlnx,eth-mode = <0x1>;

mdio {
status = "okay";
#address-cells = <1>;
#size-cells = <0>;
phy0: phy@12 {
compatible = "ethernet-phy-ieee802.3-c22";
device_type = "ethernet-phy";

reg = <12>;
ti,rx-internal-delay = <0x7>;
ti,tx-internal-delay = <0x7>;
ti,fifo-depth = <0x01>;
ti,min-output-impedance;
ti,dp83867-rxctrl-strap-quirk;
status = "okay";
};
};
};
</source>

{{Начало скрытого блока|Выравнивание_заголовка = left| Ссылка = left|Заголовок = Развернутый .dtb:}}
<source lang="bash">
/dts-v1/;

/ {
#address-cells = <0x1>;
#size-cells = <0x1>;
compatible = "xlnx,zynq-7000";

cpus {
#address-cells = <0x1>;
#size-cells = <0x0>;

cpu@0 {
compatible = "arm,cortex-a9";
device_type = "cpu";
reg = <0x0>;
clocks = <0x1 0x3>;
clock-latency = <0x3e8>;
cpu0-supply = <0x2>;
operating-points = <0xa2c2a 0xf4240 0x51615 0xf4240>;
};

cpu@1 {
compatible = "arm,cortex-a9";
device_type = "cpu";
reg = <0x1>;
clocks = <0x1 0x3>;
};
};

fpga-full {
compatible = "fpga-region";
fpga-mgr = <0x3>;
#address-cells = <0x1>;
#size-cells = <0x1>;
ranges;
};

pmu@f8891000 {
compatible = "arm,cortex-a9-pmu";
interrupts = <0x0 0x5 0x4 0x0 0x6 0x4>;
interrupt-parent = <0x4>;
reg = <0xf8891000 0x1000 0xf8893000 0x1000>;
};

fixedregulator {
compatible = "regulator-fixed";
regulator-name = "VCCPINT";
regulator-min-microvolt = <0xf4240>;
regulator-max-microvolt = <0xf4240>;
regulator-boot-on;
regulator-always-on;
linux,phandle = <0x2>;
phandle = <0x2>;
};

amba {
u-boot,dm-pre-reloc;
compatible = "simple-bus";
#address-cells = <0x1>;
#size-cells = <0x1>;
interrupt-parent = <0x4>;
ranges;

adc@f8007100 {
compatible = "xlnx,zynq-xadc-1.00.a";
reg = <0xf8007100 0x20>;
interrupts = <0x0 0x7 0x4>;
interrupt-parent = <0x4>;
clocks = <0x1 0xc>;
};

can@e0008000 {
compatible = "xlnx,zynq-can-1.0";
status = "disabled";
clocks = <0x1 0x13 0x1 0x24>;
clock-names = "can_clk", "pclk";
reg = <0xe0008000 0x1000>;
interrupts = <0x0 0x1c 0x4>;
interrupt-parent = <0x4>;
tx-fifo-depth = <0x40>;
rx-fifo-depth = <0x40>;
};

can@e0009000 {
compatible = "xlnx,zynq-can-1.0";
status = "disabled";
clocks = <0x1 0x14 0x1 0x25>;
clock-names = "can_clk", "pclk";
reg = <0xe0009000 0x1000>;
interrupts = <0x0 0x33 0x4>;
interrupt-parent = <0x4>;
tx-fifo-depth = <0x40>;
rx-fifo-depth = <0x40>;
};

gpio@e000a000 {
compatible = "xlnx,zynq-gpio-1.0";
#gpio-cells = <0x2>;
clocks = <0x1 0x2a>;
gpio-controller;
interrupt-controller;
#interrupt-cells = <0x2>;
interrupt-parent = <0x4>;
interrupts = <0x0 0x14 0x4>;
reg = <0xe000a000 0x1000>;
emio-gpio-width = <0x40>;
gpio-mask-high = <0x0>;
gpio-mask-low = <0x5600>;
};

i2c@e0004000 {
compatible = "cdns,i2c-r1p10";
status = "disabled";
clocks = <0x1 0x26>;
interrupt-parent = <0x4>;
interrupts = <0x0 0x19 0x4>;
reg = <0xe0004000 0x1000>;
#address-cells = <0x1>;
#size-cells = <0x0>;
};

i2c@e0005000 {
compatible = "cdns,i2c-r1p10";
status = "disabled";
clocks = <0x1 0x27>;
interrupt-parent = <0x4>;
interrupts = <0x0 0x30 0x4>;
reg = <0xe0005000 0x1000>;
#address-cells = <0x1>;
#size-cells = <0x0>;
};

interrupt-controller@f8f01000 {
compatible = "arm,cortex-a9-gic";
#interrupt-cells = <0x3>;
interrupt-controller;
reg = <0xf8f01000 0x1000 0xf8f00100 0x100>;
num_cpus = <0x2>;
num_interrupts = <0x60>;
linux,phandle = <0x4>;
phandle = <0x4>;
};

cache-controller@f8f02000 {
compatible = "arm,pl310-cache";
reg = <0xf8f02000 0x1000>;
interrupts = <0x0 0x2 0x4>;
arm,data-latency = <0x3 0x2 0x2>;
arm,tag-latency = <0x2 0x2 0x2>;
cache-unified;
cache-level = <0x2>;
};

memory-controller@f8006000 {
compatible = "xlnx,zynq-ddrc-a05";
reg = <0xf8006000 0x1000>;
};

ocmc@f800c000 {
compatible = "xlnx,zynq-ocmc-1.0";
interrupt-parent = <0x4>;
interrupts = <0x0 0x3 0x4>;
reg = <0xf800c000 0x1000>;
};

serial@e0000000 {
compatible = "xlnx,xuartps", "cdns,uart-r1p8";
status = "okay";
clocks = <0x1 0x17 0x1 0x28>;
clock-names = "uart_clk", "pclk";
reg = <0xe0000000 0x1000>;
interrupts = <0x0 0x1b 0x4>;
device_type = "serial";
port-number = <0x0>;
};

serial@e0001000 {
compatible = "xlnx,xuartps", "cdns,uart-r1p8";
status = "disabled";
clocks = <0x1 0x18 0x1 0x29>;
clock-names = "uart_clk", "pclk";
reg = <0xe0001000 0x1000>;
interrupts = <0x0 0x32 0x4>;
};

spi@e0006000 {
compatible = "xlnx,zynq-spi-r1p6";
reg = <0xe0006000 0x1000>;
status = "disabled";
interrupt-parent = <0x4>;
interrupts = <0x0 0x1a 0x4>;
clocks = <0x1 0x19 0x1 0x22>;
clock-names = "ref_clk", "pclk";
#address-cells = <0x1>;
#size-cells = <0x0>;
};

spi@e0007000 {
compatible = "xlnx,zynq-spi-r1p6";
reg = <0xe0007000 0x1000>;
status = "disabled";
interrupt-parent = <0x4>;
interrupts = <0x0 0x31 0x4>;
clocks = <0x1 0x1a 0x1 0x23>;
clock-names = "ref_clk", "pclk";
#address-cells = <0x1>;
#size-cells = <0x0>;
};

spi@e000d000 {
clock-names = "ref_clk", "pclk";
clocks = <0x1 0xa 0x1 0x2b>;
compatible = "xlnx,zynq-qspi-1.0";
status = "disabled";
interrupt-parent = <0x4>;
interrupts = <0x0 0x13 0x4>;
reg = <0xe000d000 0x1000>;
#address-cells = <0x1>;
#size-cells = <0x0>;
};

memory-controller@e000e000 {
#address-cells = <0x1>;
#size-cells = <0x1>;
status = "disabled";
clock-names = "memclk", "aclk";
clocks = <0x1 0xb 0x1 0x2c>;
compatible = "arm,pl353-smc-r2p1";
interrupt-parent = <0x4>;
interrupts = <0x0 0x12 0x4>;
ranges;
reg = <0xe000e000 0x1000>;

flash@e1000000 {
status = "disabled";
compatible = "arm,pl353-nand-r2p1";
reg = <0xe1000000 0x1000000>;
#address-cells = <0x1>;
#size-cells = <0x1>;
};

flash@e2000000 {
status = "disabled";
compatible = "cfi-flash";
reg = <0xe2000000 0x2000000>;
#address-cells = <0x1>;
#size-cells = <0x1>;
};
};

ethernet@e000b000 {
compatible = "cdns,zynq-gem", "cdns,gem";
reg = <0xe000b000 0x1000>;
status = "disabled";
interrupts = <0x0 0x16 0x4>;
clocks = <0x1 0x1e 0x1 0x1e 0x1 0xd>;
clock-names = "pclk", "hclk", "tx_clk";
#address-cells = <0x1>;
#size-cells = <0x0>;
};

ethernet@e000c000 {
compatible = "cdns,zynq-gem", "cdns,gem";
reg = <0xe000c000 0x1000>;
status = "okay";
interrupts = <0x0 0x2d 0x4>;
clocks = <0x1 0x1f 0x1 0x1f 0x1 0xe>;
clock-names = "pclk", "hclk", "tx_clk";
#address-cells = <0x1>;
#size-cells = <0x0>;
phy-mode = "rgmii-id";
xlnx,ptp-enet-clock = <0x69f6bcb>;
local-mac-address = [00 0a 35 00 22 01];
phy-handle = <0x5>;
xlnx,eth-mode = <0x1>;

mdio {
status = "okay";
#address-cells = <0x1>;
#size-cells = <0x0>;

phy@12 {
compatible = "ethernet-phy-ieee802.3-c22";
device_type = "ethernet-phy";
reg = <0xc>;
ti,rx-internal-delay = <0x8>;
ti,tx-internal-delay = <0xa>;
ti,fifo-depth = <0x1>;
ti,min-output-impedance;
ti,dp83867-rxctrl-strap-quirk;
status = "okay";
linux,phandle = <0x5>;
phandle = <0x5>;
};
};
};

sdhci@e0100000 {
compatible = "arasan,sdhci-8.9a";
status = "okay";
clock-names = "clk_xin", "clk_ahb";
clocks = <0x1 0x15 0x1 0x20>;
interrupt-parent = <0x4>;
interrupts = <0x0 0x18 0x4>;
reg = <0xe0100000 0x1000>;
xlnx,has-cd = <0x1>;
xlnx,has-power = <0x0>;
xlnx,has-wp = <0x0>;
};

sdhci@e0101000 {
compatible = "arasan,sdhci-8.9a";
status = "disabled";
clock-names = "clk_xin", "clk_ahb";
clocks = <0x1 0x16 0x1 0x21>;
interrupt-parent = <0x4>;
interrupts = <0x0 0x2f 0x4>;
reg = <0xe0101000 0x1000>;
};

slcr@f8000000 {
u-boot,dm-pre-reloc;
#address-cells = <0x1>;
#size-cells = <0x1>;
compatible = "xlnx,zynq-slcr", "syscon", "simple-mfd";
reg = <0xf8000000 0x1000>;
ranges;
linux,phandle = <0x6>;
phandle = <0x6>;

clkc@100 {
u-boot,dm-pre-reloc;
#clock-cells = <0x1>;
compatible = "xlnx,ps7-clkc";
fclk-enable = <0x0>;
clock-output-names = "armpll", "ddrpll", "iopll", "cpu_6or4x", "cpu_3or2x", "cpu_2x", "cpu_1x", "ddr2x", "ddr3x", "dci", "lqspi", "smc", "pcap", "gem0", "gem1", "fclk0", "fclk1", "fclk2", "fclk3", "can0", "can1", "sdio0", "sdio1", "uart0", "uart1", "spi0", "spi1", "dma", "usb0_aper", "usb1_aper", "gem0_aper", "gem1_aper", "sdio0_aper", "sdio1_aper", "spi0_aper", "spi1_aper", "can0_aper", "can1_aper", "i2c0_aper", "i2c1_aper", "uart0_aper", "uart1_aper", "gpio_aper", "lqspi_aper", "smc_aper", "swdt", "dbg_trc", "dbg_apb";
reg = <0x100 0x100>;
ps-clk-frequency = <0x1fca055>;
linux,phandle = <0x1>;
phandle = <0x1>;
};

rstc@200 {
compatible = "xlnx,zynq-reset";
reg = <0x200 0x48>;
#reset-cells = <0x1>;
syscon = <0x6>;
};

pinctrl@700 {
compatible = "xlnx,pinctrl-zynq";
reg = <0x700 0x200>;
syscon = <0x6>;
};
};

dmac@f8003000 {
compatible = "arm,pl330", "arm,primecell";
reg = <0xf8003000 0x1000>;
interrupt-parent = <0x4>;
interrupt-names = "abort", "dma0", "dma1", "dma2", "dma3", "dma4", "dma5", "dma6", "dma7";
interrupts = <0x0 0xd 0x4 0x0 0xe 0x4 0x0 0xf 0x4 0x0 0x10 0x4 0x0 0x11 0x4 0x0 0x28 0x4 0x0 0x29 0x4 0x0 0x2a 0x4 0x0 0x2b 0x4>;
#dma-cells = <0x1>;
#dma-channels = <0x8>;
#dma-requests = <0x4>;
clocks = <0x1 0x1b>;
clock-names = "apb_pclk";
};

devcfg@f8007000 {
compatible = "xlnx,zynq-devcfg-1.0";
interrupt-parent = <0x4>;
interrupts = <0x0 0x8 0x4>;
reg = <0xf8007000 0x100>;
clocks = <0x1 0xc 0x1 0xf 0x1 0x10 0x1 0x11 0x1 0x12>;
clock-names = "ref_clk", "fclk0", "fclk1", "fclk2", "fclk3";
syscon = <0x6>;
linux,phandle = <0x3>;
phandle = <0x3>;
};

efuse@f800d000 {
compatible = "xlnx,zynq-efuse";
reg = <0xf800d000 0x20>;
};

timer@f8f00200 {
compatible = "arm,cortex-a9-global-timer";
reg = <0xf8f00200 0x20>;
interrupts = <0x1 0xb 0x301>;
interrupt-parent = <0x4>;
clocks = <0x1 0x4>;
};

timer@f8001000 {
interrupt-parent = <0x4>;
interrupts = <0x0 0xa 0x4 0x0 0xb 0x4 0x0 0xc 0x4>;
compatible = "cdns,ttc";
clocks = <0x1 0x6>;
reg = <0xf8001000 0x1000>;
};

timer@f8002000 {
interrupt-parent = <0x4>;
interrupts = <0x0 0x25 0x4 0x0 0x26 0x4 0x0 0x27 0x4>;
compatible = "cdns,ttc";
clocks = <0x1 0x6>;
reg = <0xf8002000 0x1000>;
};

timer@f8f00600 {
interrupt-parent = <0x4>;
interrupts = <0x1 0xd 0x301>;
compatible = "arm,cortex-a9-twd-timer";
reg = <0xf8f00600 0x20>;
clocks = <0x1 0x4>;
};

usb@e0002000 {
compatible = "xlnx,zynq-usb-2.20a", "chipidea,usb2";
status = "disabled";
clocks = <0x1 0x1c>;
interrupt-parent = <0x4>;
interrupts = <0x0 0x15 0x4>;
reg = <0xe0002000 0x1000>;
phy_type = "ulpi";
};

usb@e0003000 {
compatible = "xlnx,zynq-usb-2.20a", "chipidea,usb2";
status = "disabled";
clocks = <0x1 0x1d>;
interrupt-parent = <0x4>;
interrupts = <0x0 0x2c 0x4>;
reg = <0xe0003000 0x1000>;
phy_type = "ulpi";
};

watchdog@f8005000 {
clocks = <0x1 0x2d>;
compatible = "cdns,wdt-r1p2";
interrupt-parent = <0x4>;
interrupts = <0x0 0x9 0x1>;
reg = <0xf8005000 0x1000>;
timeout-sec = <0xa>;
};
};

chosen {
bootargs = "console=ttyPS0,115200 earlyprintk";
stdout-path = "serial0:115200n8";
};

aliases {
ethernet0 = "/amba/ethernet@e000c000";
serial0 = "/amba/serial@e0000000";
};

memory {
device_type = "memory";
reg = <0x0 0x10000000>;
};
};

</source>
{{Конец скрытого блока}}

=== Single On-board eth ===

В Vivado включен eth0(с mdio) и выключен eth1.

'''Работает гигабит через type-c! Работает hot plug. Успех.'''

<source lang="bash">
&gem0{
status = "okay";
phy-handle = <&phy0>;
phy-mode = "rgmii-id";

xlnx,eth-mode = <0x1>;

mdio {
status = "okay";
#address-cells = <1>;
#size-cells = <0>;
phy0: phy@0 {
compatible = "ethernet-phy-ieee802.3-c22";
device_type = "ethernet-phy";

reg = <0>;
ti,rx-internal-delay = <0x7>;
ti,tx-internal-delay = <0x7>;
ti,fifo-depth = <0x01>;
ti,min-output-impedance;
ti,dp83867-rxctrl-strap-quirk;
status = "okay";
};
};
};
</source>

=== Dual eth ===

[https://forums.xilinx.com/t5/Embedded-Linux/Dual-phys-on-MDIO-EMIO/td-p/737716 интересная статья о дуал eth]

Попытка поднять два физика. '''Пока не работает'''

<source lang="bash">
&gem0{
local-mac-address = [00 0a 35 00 00 00];
enet-reset = <&gpio0 47 0>;
status = "okay";
phy-handle = <&phy0>;
phy-mode = "rgmii-id";

xlnx,eth-mode = <0x1>;

mdio {
status = "okay";
#address-cells = <1>;
#size-cells = <0>;
phy0: phy@0 {
compatible = "ethernet-phy-ieee802.3-c22";
device_type = "ethernet-phy";

reg = <0>;
ti,rx-internal-delay = <0x8>;
ti,tx-internal-delay = <0xa>;
ti,fifo-depth = <0x01>;
ti,min-output-impedance;
ti,dp83867-rxctrl-strap-quirk;
status = "okay";
};
phy1: phy@12 {
compatible = "ethernet-phy-ieee802.3-c22";
device_type = "ethernet-phy";

reg = <12>;
ti,rx-internal-delay = <0x8>;
ti,tx-internal-delay = <0xa>;
ti,fifo-depth = <0x01>;
ti,min-output-impedance;
ti,dp83867-rxctrl-strap-quirk;
status = "okay";
};
};
};

&gem1{
local-mac-address = [00 0a 35 00 00 01];
enet-reset = <&gpio0 47 0>;
status = "okay";
phy-handle = <&phy1>;
phy-mode = "rgmii-id";

xlnx,eth-mode = <0x1>;
};
</source>

=== Oryx ===

Итоговый system-user.dtsi

Меняем номера uart, чтобы системным был ttyPS1, а пользовательским ttyPS0
<source lang="bash">
/include/ "system-conf.dtsi"
/ {
aliases {
serial0 = &uart0;
serial1 = &uart1;
};
};

&gem0{
status = "okay";
phy-handle = <&phy0>;
phy-mode = "rgmii-id";

xlnx,eth-mode = <0x1>;

mdio {
status = "okay";
#address-cells = <1>;
#size-cells = <0>;
phy0: phy@1 {
compatible = "ethernet-phy-ieee802.3-c22";
device_type = "ethernet-phy";
rxc-skew-ps = <1800>;
rxdv-skew-ps = <0>;
txc-skew-ps = <1800>;
txen-skew-ps = <0>;
reg = <1>;
status = "okay";
};
};
};

/ {
chosen {
bootargs = "console=ttyPS1,115200 earlyprintk uio_pdrv_genirq.of_id=generic-uio";
stdout-path = "serial1:115200n8";
};
};

&amba {
hififo: hififo@40000000 {
compatible = "generic-uio";
interrupt-parent = <&intc>;
interrupts = <0 29 1>;
reg = <0x40000000 0x1000 0x18000000 0x8000000>;
};
};

&uart0{
port-number = <0>;
};

&uart1{
port-number = <1>;
};
</source>

В Vivado включен eth0(с mdio) и выключен eth1.
Pullup пока что все включены

[https://github.com/Xilinx/u-boot-xlnx/blob/master/doc/device-tree-bindings/net/micrel-ksz90x1.txt статья в помощь]

'''Работает'''

На новых платах(с отпаянными линиями линиями eth):
* на полноценных проводах с ходу
* на обкусанных проводах только если выставить 10 в ethtool

На старых платах:

* на полноценных проводах только если выставить 100 в ethtool
* на обкусанных проводах только если выставить 10 в ethtool

Везде работает так:
<source lang="bash">
ethtool -s eth0 speed 10 duplex full autoneg on
</source>
Спидометр показывает 2,5МБ/с, т.е. 20Мбит/с!

Можно в custom_itit.sh прописать:
<source lang="bash">
ifdown eth0
ethtool -s eth0 speed 10 duplex full autoneg on
ifup eth0
</source>

<source lang="bash">
&gem0{
status = "okay";
phy-handle = <&phy0>;
phy-mode = "rgmii-id";

xlnx,eth-mode = <0x1>;

mdio {
status = "okay";
#address-cells = <1>;
#size-cells = <0>;
phy0: phy@1 {
compatible = "ethernet-phy-ieee802.3-c22";
device_type = "ethernet-phy";
rxc-skew-ps = <1800>;
rxdv-skew-ps = <0>;
txc-skew-ps = <1800>;
txen-skew-ps = <0>;
reg = <1>;
status = "okay";
};
};
};
</source>

В принципе, работает сеть на новой плате с нормальным кабелем без модификации devicetree. Остальные комбинации плат-кабелей надо проверять

== i2c ==

В rootfs включаем
<source lang="bash">
Filesystem Packages ->
base ->
i2c-tools ->
[*] i2c-tools
</source>

Для поиска устройств можно написать

<source lang="bash">
i2cdetect -y -r 0
</source>

[https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842160/Cadence+I2C+Driver Статья] по i2c и RTC

== QSPI Flash ==

для работы по флешь памяти как в ките (S25FL128S) - оставляем в дев.три родные compatible = "n25q512a","micron,m25p80";

== SWDT System Watchdog Timer==

* Модифицируем device-tree

Вставляем в девайс три:
<source lang="bash">
&watchdog0 {
status = "okay";
reset-on-timeout;
timeout-sec = <60>;
};
</source>

== RTC ==

* Включаем в ядро подходящий драйвер

* Модифицируем device-tree

Вставляем в девайс три:
<source lang="bash">
&amba {
i2c0: i2c@e0004000 {
clock-frequency = <0xC350>;
rtc@51 {
compatible = "nxp,pcf85363";
reg = <0x51>;
};
};
i2c1: i2c@e0005000 {
clock-frequency = <0xC350>;
};
};
</source>

Будет выглядеть так:
<source lang="bash">
i2c@e0004000 {
compatible = "cdns,i2c-r1p10";
status = "okay";
clocks = <0x1 0x26>;
interrupt-parent = <0x4>;
interrupts = <0x0 0x19 0x4>;
reg = <0xe0004000 0x1000>;
#address-cells = <0x1>;
#size-cells = <0x0>;
clock-frequency = <0xc350>;

rtc@51 {
compatible = "nxp,pcf85363";
reg = <0x51>;
};
};

i2c@e0005000 {
compatible = "cdns,i2c-r1p10";
status = "okay";
clocks = <0x1 0x27>;
interrupt-parent = <0x4>;
interrupts = <0x0 0x30 0x4>;
reg = <0xe0005000 0x1000>;
#address-cells = <0x1>;
#size-cells = <0x0>;
clock-frequency = <0xc350>;
};
</source>

Если готового драйвера нет:

UG1144 pg.54

Создаем новый модуль
<source lang="bash">
petalinux-create -t modules --name <name_module> --enable
petalinux-create -t modules --name rtc-pcf85363 --enable
</source>

Правим исходный код в project-spec/meta-user/recipes-modules/rtc-pcf85363/files

Исправленный драйвер лежит в git Clonicus\linux\

Для удаления модуля:

* удаляем папку из project-spec/meta-user/recipes-modules

* В файле project-spec/meta-user/recipes-core/images/petalinux-image.bbappend удаляем соответствующую строку

* переоткрыть petalinux-config -c rootfs

Пробуем собрать модуль
<source lang="bash">
petalinux-build -c <name_module>
</source>

Если ОК, собираем (собирать модуль необязательно, petalinux-build его соберет)
<source lang="bash">
petalinux-build
</source>

И перепаковываем BOOT.bin

Пересобираем deveice-tree с указанием нового драйвера (petalinux-build соберет сам deveice-tree)

просмотр модулей

<source lang="bash">
lsmod
</source>

загрузить драйвер можно

<source lang="bash">
insmod /lib/modules/4.9.0-xilinx-v2017.4/extra/rtc-pcf85363.ko
</source>
или
<source lang="bash">
modprobe rtc-pcf85363
</source>

'''Если все ок и в девайс три прописан правильный драйвер для устройства, то модуль будет загружен сам'''

Прошиваем .bit (для клоникуса нужен бит для работы PL-i2c). После этого можно пользоваться RTC

Чтение времени из rtc если этот rtc не дефолтный (у нас rtc2)
<source lang="bash">
hwclock -r -f /dev/rtc2
</source>

Синхронизация rtc по системному времени
<source lang="bash">
hwclock -w -f /dev/rtc2
</source>

Правим custom_init.sh для изменения default-rtc на наше устройство
<source lang="bash">
rm /dev/rtc
ln -s /dev/rtc2 /dev/rtc
</source>

Установка системного времени
<source lang="bash">
date --set "2013-7-31 09:30"
</source>

Запись системного времени в RTC
<source lang="bash">
hwclock -w
</source>

Запись времени RTC в системное время
<source lang="bash">
hwclock -s
</source>

Получить время с интеренета
<source lang="bash">
rdate -s <IP address of time server>
rdate -s 132.163.96.5 (example)
</source>

При перезагрузке "reboot" система автоматически запишет системное время в RTC

== FPGA CONFIG from Uboot ==

Для того, чтобы прошить PL из uboot используем команду:
<source lang="bash">
fpga loadb 0 <ddr_file_addr> <file_size>
</source>

либо скриптами:
<source lang="bash">
load_bit=fatload mmc 0 0x100000 clonicus.bit // читаем файл в ddr
pl_load=fpga loadb 0 0x100000 0x1400000 // прошиваем PL
fpga_config=run load_bit && run pl_loadipaddr // вызов самих скриптов
</source>
0x10_0000 - начальный адрес ddr

0x1_400_000 - размер в байтах для 20МБайт - указываем размер битника с запасом. Теоретически может так не работать, но работает

== ETH over TTY==

В ядре включаем: slip, Universal TUN/TAP (возможно еще PPP)

В rootfs включаем net-tools

PC1:

slattach -L -s 115200 -p slip /dev/ttyPS1 &

ifconfig sl0 192.168.1.1/24 up

route add default gw 192.168.1.1 sl0

PC2:

slattach -L -s 115200 -p slip /dev/ttyPS1 &

ifconfig sl0 192.168.1.2/24 up

route add default gw 192.168.1.1 sl0

== UART_PL ==

Включаем в настройках ядра поддержку uart_lite

Модифицируем system-user.dtsi

Обращаем внимание на нумерацию serial, axi_uartlite, она должна не повторяться. То же самое с interrupts
Указываем верный физический адрес на шине и диапазон адресов в <reg>

<source lang="bash">
/include/ "system-conf.dtsi"
/ {
aliases {
serial2 = &axi_uartlite_0;
serial3 = &axi_uartlite_1;
};
};
/ {
amba_pl {
#address-cells = <0x1>;
#size-cells = <0x1>;
compatible = "simple-bus";
ranges;

axi_uartlite_0: serial@80000008 {
clock-names = "ref_clk";
clocks = <&clkc 0>;
compatible = "xlnx,xps-uartlite-1.00.a";
current-speed = <115200>;
device_type = "serial";
interrupt-parent = <&intc>;
interrupts = <0 30 1>;
port-number = <3>;
reg = <0x80000008 0x14>;
xlnx,baudrate = <0x1c200>;
xlnx,data-bits = <0x8>;
xlnx,odd-parity = <0x0>;
xlnx,s-axi-aclk-freq-hz-d = "100.0";
xlnx,use-parity = <0x0>;
};
axi_uartlite_1: serial@8000001C {
clock-names = "ref_clk";
clocks = <&clkc 0>;
compatible = "xlnx,xps-uartlite-1.00.a";
current-speed = <115200>;
device_type = "serial";
interrupt-parent = <&intc>;
interrupts = <0 31 1>;
port-number = <4>;
reg = <0x8000001C 0x14>;
xlnx,baudrate = <0x1c200>;
xlnx,data-bits = <0x8>;
xlnx,odd-parity = <0x0>;
xlnx,s-axi-aclk-freq-hz-d = "100.0";
xlnx,use-parity = <0x0>;
};
};
};
</source>

Если ПЛИС не прошита - будет кернел паник

== IRQ ==

Для поддержки irq добавляем в device-tree

'''Важно - мы перетираем bootargs!'''
<source lang="bash">
/ {
chosen {
bootargs = "console=ttyPS0,115200 earlyprintk uio_pdrv_genirq.of_id=generic-uio";
};
};

&amba {
hififo: hififo@40000000 {
compatible = "generic-uio";
interrupt-parent = <&intc>;
interrupts = <0 29 1>;
reg = <0x40000000 0x1000 0x18000000 0x8000000>;
};
};
</source>

== USB ==

Запустил на Z706

[http://www.wiki.xilinx.com/Zynq+Linux+USB+Device+Driver во-первых]
[http://zedboard.org/content/using-petalinux-configure-zedboard%EF%BC%8C-usb-otg-can-not-work во-вторых]
[https://forums.xilinx.com/t5/Embedded-Linux/Petalinux-2016-3-zynq-7010-USB-not-working/td-p/737696 в-третьих]

В дефолтных настройках ядра petalinux_2018.1 все было включено

включаем ресет на MIO7 pullup disabled

все ноги интерфейса ulpi pullup disabled

Содержимое system-user.dtsi
<source lang="bash">
/include/ "system-conf.dtsi"
/{

usb_phy0:phy0 {

compatible="ulpi-phy";

#phy-cells = <0>;

reg = <0xe0002000 0x1000>;

view-port=<0x170>;

drv-vbus;

};

};

&usb0 {

status = "okay";

dr_mode = "host";

usb-phy = <&usb_phy0>;

} ;
</source>

== USB-ETHERNET ==
<source lang="bash">
Device Drivers ->
USB support ->
[*] USB Modem (CDC ACM)
USB Gadget Support ->
[*] Ethernet Control Model (all)
[*] RNDIS
[*] Ethernet Emulation Model
[*] CDC Composite Device (Ethernet and ACM)
[*] USB Gadget Drivers (Ethernet gadget...)
Network device support ->
USB Network Adapters ->
[*] Realtek RTL8152/RTL8153
[*] Multi-purpose USB Networking Framework
</source>

== WiFi Dongle ==

[https://forum.trenz-electronic.de/index.php?topic=747.0 раз]
[https://github.com/jinchenglee/zybo_linux_setup_doc два]
[http://billauer.co.il/blog/2014/06/linux-realtek-hostapd/ три]

Творим:
<source lang="bash">
Networking support ->
Wireless ->
[*] cfg80211
[*] Generic IEEE 802.11 ... (mac80211)
Device Drivers ->
Network device support ->
Wireless LAN ->
Realtek rtlwifi family of devices ->
[*] Realtek ..../RTL8188CE Wireless Network Adapter ???
[*] Realtek RTL8188EE Wireless Network Adapter ???
[*] Realtek RTL8192CU/RTL8188CU USB Wireless Network Adapter
Staging drivers ->
[*] Realtek RTL8188EU wireless LAN MIC driver
</source>

rootfs
<source lang="bash">
Filesystem packages ->
network ->
wpa-supplicant ->
[*] wpa-supplicant
</source>

[https://github.com/lwfinger/rtl8188eu/blob/master/rtl8188eufw.bin качаем файл]

Модификаци инит-скрипта
<source lang="bash">
cp /run/media/mmcblk0p1/wpa_supplicant.conf /etc/

mkdir /lib/firmware/
mkdir /lib/firmware/rtlwifi/
cp /run/media/mmcblk0p1/rtl8188eufw.bin /lib/firmware/rtlwifi/
</source>

== WiFi ESP ==

[http://www.wiki.xilinx.com/Zynq+SDIO+Wifi Xilinx SDIP WiFi]

[http://zedboard.org/content/sdio-wifi-driver-ar6103-problem Zedboard раз]

[https://stackoverflow.com/questions/32129689/how-to-bind-sdio1-with-wi-fi-linux два]

[http://picozed.org/content/steps-get-wlink8-working-using-petalinux-picozed picozed три]

[http://zedboard.org/content/adding-wi-fi-and-bluetooth-connectivity-zedboard-using-murata-1dx-pmod zedboard четыре]

== webserver ==

* [https://github.com/emlid/ReachView Репозиторий emlid ReachView] (bnd на py/Flask, fnd на html/Ajax/js/Bootstrap)

'''Backend:'''

* [http://svenand.blogdrives.com/archive/195.html#.XPTYt4gzaUk Источник по busybox-httpd]

* [https://www.afternerd.com/blog/python-http-server/ Гайд по python server]

* [https://ru.wikibooks.org/wiki/Flask Викиучебник по Flask]

* [https://habr.com/ru/post/193242/ ХаброГайд по python/Flask]

'''Frontend:'''

* [https://unminify.com/ unminify CSS]

* [https://getbootstrap.com/docs/4.3/getting-started/introduction/ Bootstrap EN getting started]

* [https://bootstrap-4.ru/ Bootstrap RU]

* [http://htmlbook.ru/samhtml/tekst/spetssimvoly Справочник по операторам и тегам HTML/CSS]

* [https://www.w3schools.com/howto/default.asp Сборник шаблонов CSS W3schools]

* [https://www.w3schools.com/w3css/w3css_tabulators.asp Анимированный сайдбар/табы]

* [https://css-tricks.com/ CSS Tricks]

* [https://www.cssmatic.com/ Онлайн тени/границы/градиент блоков]

* [https://internetingishard.com/html-and-css/semantic-html/ Semantic HTML grid layout]

* [https://habr.com/ru/post/202408/ Хаброгайд(ч1) по верстке]

* [https://habr.com/ru/post/211032/ ХаброГайд(ч2) по Bootstrap]

* [https://fontawesome.com/icons?d=gallery Fontawesome ICONS open lib]

:* [https://htmlacademy.ru/courses/43/run/1 Нормальный онлайн HTML/CSS/JS editor]

=== busybox httpd ===
В petalinux многие пакеты скукожены до их минимальных вариантов и встроены в общий пакет busybox.
В busybox есть также и вебсервер busybox-httpd.
Для использования нужно на этапе настройки файловой системы его включить:

$ petalinux-config -c rootfs

Конфиг:
base ->
busybox ->
[*] busybox
[*] busybox-httpd
[ ] busybox-hwclock
[*] busybox-inetd
[*] busybox-mdev
[ ] busybox-syslog
[*] busybox-udhcpc
[ ] busybox-udhcpd

Сам httpd будет в '''/usr/sbin'''.
Рабочая папка по умолчанию в '''/srv/www/'''. Если в нее кидать файлы, то именно из нее будет отображаться контент в браузере. Папку можно изменить, перезапустив httpd с ключом -h <workdir>.

Порт по умолчанию 80. Работает, как демон в /etc/init.d/, вкл-выкл оттуда же.

Если положить в /srv/www/ файл index.html с неким кодом, то в браузере отобразится вебморда. Картинки работают по ссылкам.

'''index.html'''
<source lang="html4strict">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>clonicus'112 webserver</title>
</head>
<body>
<h3>Hello, World!</h3>
<h4>Web server is now up!</h4>
<img src="https://i.redd.it/oagz5eobkkt11.jpg" width="50%">
<br><br>
<a href="http://www.srns.ru">For more information see SRNS.ru</a>
<br>
</body>
</html>
</source>

=== python в petalinux ===
В petalinux 2017.4 есть 2 питона - 2.7 и 3.5.

$ petalinux-config -c rootfs

'''python2.7'''
Filesystem Packages->
devel->
python->

'''python3.5'''
Filesystem Packages->
misc->
python3-*>

Модуль runpy.py для запуска команд вида 'python -m <module>' находится в python -> python-misc.

=== SimpleHTTPServer.py ===
Для первого теста поднимем встроенный в python2.7 минисервер SimpleHTTPServer.py в /usr/lib/python2.7.

Для его запуска напишем скрипт

'''webserver.py''':

<source lang="python">
import SimpleHTTPServer
import SocketServer

PORT = 80

Handler = SimpleHTTPServer.SimpleHTTPRequestHandler

httpd = SocketServer.TCPServer(("", PORT), Handler)

print "serving at port", PORT
httpd.serve_forever()
</source>

$ python webserver.py

При наличии в папке со скриптом файла index.html сервер поднимется автоматически.

=== Добавление слоев в сборку ===

[https://www.srns.ru/wiki/Blog:DneprovD/18.07.2019_Yocto_layers Переехало в статью]

[[Категория:HOWTO]]
[[Категория:Oryx]]
[[Категория:Zynq]]
[[Категория:EmbeddedLinux]]
[[Category:Clonicus]]

{{wl-publish: 2018-05-16 10:06:30 +0300 | Lipa }}

Список децимальных номеров

2020-06-10T09:28:18Z

Dneprov: /* Список децимальников на ПО выданное по ЕСПД */

Список децимальных номеров

2020-06-10T09:26:38Z

Dneprov: /* Список децимальников на ПО выданное по ЕСПД */

Список децимальных номеров

2020-06-10T08:10:09Z

Dneprov: /* Список децимальников на ПО выданное по ЕСПД */

Список децимальных номеров

2020-06-10T08:09:18Z

Dneprov: /* Список децимальников на ПО выданное по ЕСПД */