Проект 12.1 — Итоговый проект: QPSK-модем¶

Цель¶

Построить и задокументировать цепочку передачи/приёма QPSK с синхронизацией и количественными метриками.

Необходимая цепочка¶

flowchart LR
    BITS[Биты] --> QPSK[QPSK-маппер]
    QPSK --> CH[Канал / искажения]
    CH --> SYNC[Коррекция CFO / фазы / тайминга]
    SYNC --> DEC[Решения]
    DEC --> METRICS[EVM / BER]

Минимальные результаты¶

модель сигнала;
модель искажений;
этапы синхронизации;
созвездие до/после;
EVM и BER;
итоговый отчёт.

Критерии успеха¶

Критерий	Цель
BER после синхронизации	определяет студент
EVM после синхронизации	определяет студент
Воспроизводимая команда	обязательно
JSON с метриками	обязательно

Цели фиксируются в предложении (proposal) до финального прогона. Результат, не достигший цели, всё равно может быть сильной инженерной работой, если измерение корректно, ограничение локализовано, а вывод не сдвигает ворота.

Выберите один трек выполнения¶

Проект намеренно выполним без конкретной платы. Выберите самый сильный трек из тех, которые обеспечивает оборудование, которым вы реально владеете; не заявляйте доказательств более высокого трека.

Трек	Минимальная реализация	Необходимые доказательства
A: офлайн-воспроизведение	модель на Python/MATLAB/GNU Radio по фиксированному IQ-набору данных	манифест набора данных + контрольная сумма, созвездие до/после, JSON с BER/SER/EVM
B: RTL/FPGA	fixed-point модель плюс HDL-модем или блок синхронизации	побитовые векторы, HDL-регрессия, отчёт по задержке/ресурсам/таймингу
C: измерения RF	трек A или B плюс контролируемый тракт передатчика/приёмника	схема стенда, RF-безопасные настройки, сырой или сводный артефакт измерения, статистика повторных прогонов

Железо: не обходной путь вокруг воспроизведения. Трек C всё равно требует артефакта, читаемого офлайн, или машиночитаемой сводки, которая позволяет другому инженеру проверить арифметику отчёта.

Заморозьте предложение¶

До реализации напишите одну страницу с содержанием:

Поле	Необходимое содержание
инженерный вопрос	одно опровержимое предложение
базовый уровень	простейшая цепочка, которую улучшение должно превзойти
независимая переменная	что именно меняется в сравнении A/B
фиксированные параметры	скорость, SPS, roll-off/размах RRC, кадр и преамбула, усиления или модель канала
метрики	BER/SER, EVM и минимум одна метрика синхронизации
порог приёмки	числовое правило «прошёл/не прошёл»
правило остановки	когда проект завершён, даже если дальнейшая настройка возможна
запасной трек	путь только с воспроизведением, если железо станет недоступно

Пример вопроса: «При Eb/N0 = 8 дБ снижает ли выбранное восстановление несущей/тайминга BER ниже 1e-3, не увеличивая EVM выше замороженного предела?» «Сделать BER лучше», непроверяемое предложение.

Ворота верификации¶

Переходите дальше, только когда для текущих ворот есть сохранённый артефакт:

G0 это контракт: предложение, таблица параметров, архитектура и порог приёмки закоммичены.
G1 это эталон: модель без искажений восстанавливает известный payload при BER/SER 0.
G2 это чувствительность: CFO, фаза, тайминг и шум изменяются независимо; отказ базового уровня виден на графике или в таблице метрик.
G3 это синхронизация: улучшенная цепочка сравнивается с замороженным базовым уровнем на идентичных входах. Парное или детерминированное воспроизведение предпочтительнее не связанных между собой прогонов.
G4 это реализация: fixed-point/HDL или аппаратные доказательства согласуются с моделью в пределах заявленного допуска. Работа с FPGA должна сообщать и функциональность, и разведённый тайминг.
G5 это воспроизведение: чистый checkout выполняет описанную команду и заново создаёт или проверяет итоговый JSON с метриками.

Опровергнутые гипотезы принадлежат отчёту, если они меняют диагноз. Не удаляйте честный отрицательный результат только потому, что он не стал итоговой архитектурой.

Пакет доказательств¶

Используйте компактную, удобную для ревью структуру (эквивалентные имена допустимы):

project_12_1/
├── proposal.md
├── config.json
├── manifest.yml
├── run.py
├── metrics.json
├── figures/
│   ├── constellation_before.svg
│   ├── constellation_after.svg
│   └── ber_or_evm_sweep.svg
└── report.md

config.json содержит каждый параметр, влияющий на результат. manifest.yml определяет входные данные, формат, происхождение и контрольную сумму. metrics.json содержит как сырые счётчики, так и отношения, чтобы проценты можно было пересчитать независимо. Для BER сохраняйте минимум:

{
  "compared_bits": 100000,
  "bit_errors": 17,
  "ber": 0.00017,
  "locked_frames": 398,
  "total_frames": 400
}

Никогда не публикуйте только скриншот сводки терминала.

Отправная точка, безопасная для CI¶

Трек A может стартовать с публичного детерминированного QPSK-фикстура. Из корня репозитория:

python tools/generate_demo_qpsk_dataset.py
python tools/analyze_demo_qpsk_dataset.py --generate-if-missing
python tools/check_dataset_manifests.py
python -m pytest tests/test_demo_qpsk_dataset.py -q

Трек B добавляет каноническую HDL-проверку:

python tools/run_block5_hdl_smoke.py --no-generate

Не делайте пересборку Vivado единственным путём воспроизведения. Коммитьте нормализованные отчёты по таймингу и ресурсам, чтобы рецензенты без лицензионного инструмента могли посмотреть результат реализации.

Итоговый чек-лист приёмки¶

Предложение и числовые цели предшествуют финальному измерению.
Известный payload восстанавливается в эталоне без искажений.
Базовый уровень и кандидат используют идентичные входные данные и фиксированные параметры.
Каждое приведённое отношение можно пересчитать из закоммиченных счётчиков.
Задокументировано минимум одно ограничение или отвергнутая гипотеза.
Утверждения об FPGA включают разведённые WNS/TNS/WHS/THS и статус трассировки.
Утверждения об оборудовании включают топологию, ослабление/усиления и безопасную процедуру выключения.
Команда на чистом checkout проверяет доказательства без доступа к исходному стенду.
Вывод говорит достигает или не достигает замороженного порога.

Оцените работу по рубрике оценки итоговых проектов и напишите отчёт по шаблону отчёта Блока 12.

Шаблон вывода отчёта¶

QPSK-модем достиг BER ____ и EVM ____ %. Доминирующее искажение — ____.
Проект достигает / не достигает критериев успеха, потому что ______.

Эталонная реализация (Блок 11)¶

Начинать с чистого листа не обязательно: в Блоке 11 есть завершённый, проверенный на железе экземпляр именно этого проекта это QPSK-модем в fabric на Zynq-7020 + AD9361, закрытый на двухплатном RF-канале 915 МГц. Рассматривайте его как разобранный пример того, как выглядит «достигает критериев», а не как ответ, который нужно копировать; ваш трек, модель искажений и цели остаются вашими.

Итоговый измерительный отчёт: Lab 11.4 это архитектура, настройка, таблица «прошёл/не прошёл», воспроизводимость.
Цепочка синхронизации: DC-блокер → согласованный RRC → выбор фазы прямой связью → тайминг по Гарднеру → грубый CFO → восстановление несущей по Костасу → жёсткое решение → дифференциальный декодер → счётчик BER с разрешением квадранта. История отладки каждого этапа в Lab 11.41 (DC-блокер/бит 189), 11.42 (ложный захват frame-sync), 11.43–11.45 (дифференциальный QPSK и преамбула, которая всё исправила).
Достигнутые метрики (для калибровки, а не как ваша цель): BER fabric loopback < 5,3×10⁻⁷ на 5,6 млн бит; BER payload двухплатного RF-канала ~4×10⁻⁴ без сбоев поворота всего пакета, инвариантен к повороту.
Машиночитаемые итоговые доказательства: docs/assets/lab1144_diff_qpsk_live.json содержит A/B абсолютного/дифференциального приёма, а docs/assets/lab1145_diff_long_preamble_live.json это итоговый 800-кадровый прогон с длинной преамбулой.

Хорошей работе 12.1 такая глубина не нужна, но нужна та же дисциплина: заявленный критерий успеха, честное измерение и воспроизводимая команда, заново создающая метрику.