SDR-Rover/PROJECT_LOG.md

# Инженерный журнал SDR Rover Link

## Назначение журнала

Этот файл содержит хронологию разработки проекта SDR Rover Link.

В журнале фиксируются:

- выполненные работы;
- полученные результаты;
- обнаруженные ошибки;
- принятые технические решения;
- результаты экспериментов;
- планы следующего этапа.

Записи не следует удалять. Если решение изменилось, необходимо добавить новую запись и объяснить причину изменения.

---

# Запись 001

## Дата

10 июля 2026 года

## Тема

Создание структуры проекта и локального Git-репозитория.

## Выполнено

1. Проверена установленная версия Git:

```text
git version 2.51.1.windows.1
```

---

# Запись 002

## Дата

27 июля 2026 года

## Тема

Завершение Lab028: пакетирование синхронного BASE + ROI.

## Выполнено

- Реализован фиксированный бинарный заголовок размером 32 байта.
- Добавлены packet CRC32 для заголовка и payload и object CRC32 для полного JPEG.
- Исследованы размеры payload 64, 128, 256, 512 и 1024 байта.
- Размер payload 512 байт принят как рабочий кандидат.
- Окончательный выбор размера пакета перенесён в Lab029.

---

# Запись 003

## Дата

27 июля 2026 года

## Тема

Завершение Lab029: моделирование потерь и ошибок видеопакетов.

## Выполнено

- Исследованы независимые потери пакетов и независимые битовые ошибки.
- Проверены короткие, средние и длинные серии потерь по модели Gilbert–Elliott.
- Выполнено сравнение payload 256, 512 и 1024 байта.
- Подтверждены packet CRC32, изоляция соседних кадров и атомарная сборка BASE + ROI.
- Зафиксировано ограничение пакетной временной шкалы Lab029.
- Сравнение помех одинаковой физической длительности перенесено в Lab029B.

---

# Запись 004

## Дата

27 июля 2026 года

## Тема

Завершение Lab029B: временная модель серийных потерь.

## Выполнено

- Помехи смоделированы на непрерывной временной шкале.
- Контрольная скорость передачи установлена равной 300 кбит/с.
- Исследованы средние длительности Bad 10, 50, 200 и 1000 мс.
- Payload 512 байт выбран для дальнейшей разработки.
- Payload 1024 байта оставлен резервным вариантом.
- Подтверждено, что без исправления ошибок возможны длительные прерывания видеопотока.

---

# Запись 005

## Дата

29 июля 2026 года

## Тема

Завершение Lab030: блочное исправление стираний.

## Выполнено

- Реализовано блочное исправление стираний над GF(256).
- Проверены режимы без исправления, 8+1, 8+2 и 8+4.
- Режим 8+2 выбран основным рабочим режимом.
- Режим 8+4 оставлен контрольным.
- Подтверждено, что без перемежения продолжительные серии потерь не исправляются.
- Следующая лабораторная посвящена перемежению пакетов.

---

# Запись 006

## Дата

29 июля 2026 года

## Тема

Завершение Lab031: перемежение блоков исправления ошибок.

## Выполнено

- Исследовано перемежение блоков исправления ошибок.
- Проверены глубины D=1, 2, 4 и 8.
- Подтверждено, что глубокое перемежение повышает задержку сильнее, чем полезность для операторского видеопотока.
- D=1 оставлен основным режимом.
- D=2 сохранён как резервный вариант.
- D=4 и D=8 исключены из основной линии разработки.
- Следующая лабораторная подбирает размер блока и количество проверочных пакетов.

---

# Запись 007

## Дата

29 июля 2026 года

## Тема

Завершение Lab032: параметры блочного исправления потерянных пакетов.

## Выполнено

- Исследованы параметры блочного исправления потерянных пакетов.
- Сравнивались режимы без исправления, 4+1, 8+2, 12+3, 6+2, 8+3, 4+2 и 8+4.
- Режим 12+3 выбран основным.
- Его транспортный поток составляет 226,951 кбит/с.
- Запас до контрольных 300 кбит/с составляет 73,049 кбит/с.
- Режим 8+4 оставлен усиленным экспериментальным вариантом.
- Режим 8+3 не принят из-за отсутствия устойчивого преимущества.
- Подтверждено, что продолжительные помехи нельзя компенсировать только увеличением числа проверочных пакетов.
- Следующий этап посвящён совместной передаче команд, телеметрии и видео с приоритетным обслуживанием.

---

# Запись 008

## Дата

3 августа 2026 года

## Тема

Завершение Lab033: общий пакет канала и приоритетное обслуживание.

## Выполнено

- Добавлен общий 32-байтный заголовок канала для команд, телеметрии и видео.
- Общая предложенная нагрузка составляет 258,214 кбит/с.
- Подтверждено, что FIFO не обеспечивает требуемую задержку команд.
- Выбран строгий приоритет с заменой устаревших состояний.
- Аварийная команда имеет наивысший приоритет.
- Скорость 260 кбит/с практически полностью загружена.
- При 230 кбит/с видеоданные накапливаются и устаревают.
- Итоговое восстановление всех кадров после освобождения очереди не означает работу видео в реальном времени.
- Расчёты и графики выполнены с Matplotlib 3.11.1.
- Следующий этап посвящён отбрасыванию устаревших видеокадров.

---

# Запись 009

## Дата

3 августа 2026 года

## Тема

Завершение Lab034: реактивное отбрасывание устаревших видеокадров.

## Выполнено

- Сравнены непрерывные FEC-блоки и блоки, выровненные по составным кадрам.
- Выравнивание увеличивает видеопоток на 5,975 кбит/с, или на 2,633%.
- При 300 кбит/с удаление кадров не требуется.
- При 260 кбит/с ограничения 1000 и 1500 мс не срабатывают, а ограничение 500 мс уже чрезмерно.
- При 230 кбит/с реактивное удаление устаревших кадров уменьшает очередь, но резко снижает частоту обновления.
- Ограничение 500 мс оставляет только 3 из 63 кадров.
- Ограничение 1500 мс оставляет 27 из 63 кадров.
- Подтверждено, что короткая очередь сама по себе не означает свежее изображение.
- Текущая реактивная политика не принята.
- Следующий этап посвящён упреждающему допуску кадров и обслуживанию видео целыми кадрами.

---

# Запись 010

## Дата

3 августа 2026 года

## Тема

Завершение Lab035: упреждающий допуск и обслуживание видео целыми составными кадрами.

## Выполнено

- Lab035 исследует упреждающий допуск и обслуживание видео целыми составными кадрами.
- Начатый кадр всегда передаётся полностью.
- Команды и телеметрия могут передаваться между его пакетами.
- Реактивное удаление Lab034 окончательно не принято.
- Основная политика — хранение только самого свежего не начатого кадра.
- При 230 кбит/с опубликовано 56 из 63 кадров с частотой около 2,6 кадра/с.
- Бесполезно переданных видеобайтов нет.
- Очередь из двух кадров увеличивает возраст изображения.
- Прогноз 1000 мс не дал преимущества над более простой политикой.
- Прогноз 500 мс чрезмерно снижает частоту обновления.
- Следующая лабораторная проверяет долговременную устойчивость и изменение пропускной способности канала.

---

# Запись 011

## Дата

3 августа 2026 года

## Тема

Завершение Lab036: долговременная устойчивость видеопланировщика при изменении пропускной способности.

## Выполнено

- Lab036 проверяет видеопланировщик на протяжении 600 секунд.
- Расчётный рост очереди без удаления совпал с моделью.
- При 230 кбит/с очередь без удаления выросла до 4139 пакетов.
- 95-й процентиль возраста изображения достиг 74,6 секунды.
- Плавное поступление сильно устаревших кадров непригодно для управления.
- Политика хранения только самого свежего не начатого кадра ограничивает очередь.
- При 230 кбит/с она обеспечила около 2,615 кадра/с.
- После восстановления скорости возраст изображения снизился ниже 500 мс за 0,077 секунды.
- Политика двух ожидающих кадров оставлена резервной.
- Следующая лабораторная объединяет планировщик с моделью ошибок радиоканала и защитой команд управления.

---

# Запись 012

## Дата

4 августа 2026 года

## Тема

Завершение Lab037: полный транспорт с серийными потерями и повторением критических команд.

## Выполнено

- Lab037 объединяет видеопоток, обычные и аварийные команды, телеметрию и временные серийные потери пакетов.
- Близкие повторные копии команд часто попадают в один и тот же интервал помехи.
- Повторение Lab037 лишь умеренно уменьшило долю недоставленных управляющих состояний.
- Максимальный промежуток без свежей команды остался более одной секунды.
- Своевременная доставка аварийной команды по радиоканалу не гарантируется.
- Для безопасного поведения при потере связи требуется локальный сторожевой таймер на ровере.
- Следующий этап исследует сторожевой таймер, временно разнесённую аварийную команду и подтверждение получения.

---

# Запись 013

## Дата

4 августа 2026 года

## Тема

Завершение Lab038: локальный сторожевой таймер и подтверждаемая аварийная команда.

## Выполнено

- Lab038 исследует локальный сторожевой таймер, разнесённую аварийную команду и подтверждение получения.
- Три инварианта безопасности не нарушены ни разу.
- Подтверждение не является условием выполнения аварийной остановки.
- Режим с подтверждением сохранил итоговую доставку аварийной команды 99,694%.
- Среднее число аварийных копий уменьшилось с 11 до 1,071.
- Дополнительная нагрузка подтверждаемого режима составляет около 0,0093 кбит/с.
- Дополнительное повторение обычных команд не принято как основной режим.
- Порог 100 мс вызывает слишком частые безопасные остановки.
- Порог 500 мс допускает слишком большой путь до реакции.
- Для следующей проверки принята двухступенчатая логика: предварительная реакция после 150 мс и обязательная остановка после 250 мс.

---

# Запись 014

## Дата

5 августа 2026 года

## Тема

Завершение Lab039: двухступенчатая безопасная реакция и оценка пути до остановки.

## Выполнено

- Lab039 реализует состояния NORMAL, STAGE1_DECELERATION, STAGE2_BRAKING и EMERGENCY_LATCHED.
- Используется точное событийное интегрирование движения.
- Аналитические значения совпали с моделью с нулевой ошибкой.
- Максимальный полный путь составил 13,9642 м.
- При 25 км/ч и номинальном профиле политика 150/250 мс дала полный путь около 9,5388 м.
- Основную часть пути составляет торможение после реакции.
- Пара 150/250 мс сохраняется как предварительный кандидат, но окончательно не утверждается.
- Фактические замедления должны быть измерены на реальном ровере.
- Локальный сторожевой таймер сохранил безопасную реакцию в опытах, где аварийная команда не была доставлена.
- Следующий этап исследует постоянное аварийное намерение наземной станции и безопасное разрешение повторного движения.

---

# Запись 015

## Дата

5 августа 2026 года

## Тема

Завершение Lab040: постоянное аварийное намерение и безопасное повторное разрешение движения.

## Выполнено

- Lab040 реализует постоянное аварийное намерение наземной станции.
- Ограниченное окно повторения 500 мс признано небезопасным.
- При полностью потерянной аварийной передаче ограниченный режим допускал последующее возобновление движения.
- В одном из тяжёлых условий путь после такого восстановления достигал в среднем около 490 м при 25 км/ч.
- Постоянное аварийное намерение исключило положительные задания скорости и небезопасные возобновления движения.
- Подтверждение аварийной команды не снимает аварийное намерение.
- Сброс принимается только после остановки, при свежей связи и корректных идентификаторах.
- Подтверждение сброса не восстанавливает старую команду движения.
- Движение требует новой явной команды оператора.
- Следующий этап посвящён сеансам связи, перезапускам устройств и защите от пакетов предыдущего сеанса.

---

# Запись 016

## Дата

5 августа 2026 года

## Тема

Завершение Lab041: сеансы связи, безопасный запуск и защита от пакетов предыдущего сеанса.

## Выполнено

- Lab041 вводит идентификаторы сеанса станции, запуска ровера и периода управления.
- Одного номера сообщения недостаточно после перезапуска.
- В основном режиме все 2807 введённых старых пакетов были отклонены.
- Ошибочно принятых старых пакетов не было.
- Исходный режим без идентификаторов принял все старые пакеты.
- После перезапуска движение запрещено до нового согласования, подтверждения разрешения и новой команды оператора.
- Аварийное намерение наземной станции сохраняется после перезапуска.
- Неоднозначная разность номеров 2^31 отклоняется.
- Следующий этап посвящён криптографической проверке подлинности управляющих сообщений и защите от намеренной подделки.

---

# Запись 017

## Дата

7 августа 2026 года

## Тема

Аудит достоверности Lab041 и удаление показателей, не выводимых из модели. Начало этапа стабилизации после Lab041.

## Причина записи

Запись 016 не отменяется, но нуждается в уточнении. Машинный аудит репозитория показал, что часть числовых результатов Lab041 не выводилась ни из модели этой лабораторной, ни из указанного источника. Согласно правилу журнала прежняя запись сохранена, а изменение зафиксировано отдельно.

## Что обнаружено

- В функции `simulate_trial` доли публикации видео, доставки телеметрии и доставки управления, а также базовая длина очереди задавались вписанными таблицами, а не вычислялись.
- Значение доли видео 0,910 для канала 260 кбит/с не соответствовало заявленному источнику: Lab040 даёт 0,9603, Lab037 — разброс 0,9026...0,9174.
- Базовая длина очереди 31 для того же канала не соответствовала Lab040, где получено 36...38 пакетов.
- Коэффициенты влияния нагрузки 0,15, 0,10 и 0,05 не выводились ни из какой модели.
- Параметры торможения были зашиты литералами `0.250` и делителем `6.0` без связи с профилем `nominal` Lab039, откуда они происходят.
- Пять из четырнадцати инвариантов безопасности не измерялись: два вычислялись выражением с умножением на ноль, один был литеральным нулём, ещё два опирались на поля, которые никогда не заполнялись. Проверка `validate_outputs` подтверждала эти константы, то есть проверяла тождество.
- Формулировка «все 2807 введённых старых пакетов были отклонены» описывает перебор таблицы сценариев, а не измеренную вероятность отклонения. Число раскладывается как семь сценариев на 401 повтор.

## Выполнено

- Из Lab041 удалены четыре показателя: доли доставки видео, телеметрии и управления и максимальная длина очереди. Они относятся к Lab037 и Lab040 и в Lab041 не моделируются.
- Удалён график `lab041_traffic_impact.png`, потерявший основание. Осталось семь графиков.
- Удалены поля `negative_speed_cases` и `speed_limit_exceeded_cases`, которые никогда не вычислялись, и тождественные проверки в `validate_outputs`.
- Параметры торможения связаны с профилем `nominal` Lab039 через именованные константы `LAB039_NOMINAL_STAGE2_MPS2` и `LAB039_STAGE2_THRESHOLD_SECONDS`; горизонт незащищённого движения выделен как явно принятое допущение.
- Перенесённые величины `VIDEO_OFFERED_LOAD_KBPS` и `TELEMETRY_OFFERED_LOAD_KBPS` снабжены указанием источника: Lab038, поля `video_load_kbps` и `telemetry_load_kbps`.
- Секция инвариантов переписана: девять свойств, следующих из архитектуры, снабжены ссылками на подтверждающие функциональные проверки; пять свойств, которые матрица не может измерить, вынесены в отдельный раздел со ссылками на проверки 04, 06, 07, 10, 16 и 19.
- В отчёт добавлено разграничение того, что моделируется розыгрышем, что задано архитектурой и что не моделируется вовсе.
- Проверка 04 расширена отрицательной скоростью и границей 15 м/с, поэтому соответствующее свойство теперь подтверждается реально, а не константой.
- Оценка пути после перезапуска помечена как расчёт по замкнутой формуле, одинаковый во всех повторах, а не как результат розыгрыша.

## Результат

- Lab041 перезапущена полностью: 180 сочетаний, 24 из 24 функциональных проверок пройдены, пять CSV и семь PNG.
- Сверка с прежними файлами показала, что удалено ровно шесть столбцов, а все сохранённые значения совпали до последнего знака. Расхождений в общих столбцах ноль.
- Научные выводы Lab041 не изменились. Максимальный путь после перезапуска остался 9,7737 м, постоянная нагрузка управления 10,88000 кбит/с, полный предложенный поток 262,076 кбит/с.
- Выводы Записи 016 о сеансах, безопасном запуске и отклонении старых пакетов остаются в силе. Уточняется их основание: доказательством служат 24 функциональные проверки, работающие с настоящими автоматами, а не счётчики матрицы из 180 сочетаний.

## Следующий этап

Криптографическая аутентификация отложена. Сначала выполняется этап стабилизации: быстрые тесты `protocol/` вместо единственной точки входа через лабораторную, разделение быстрых проверок и экспериментов, воспроизводимое описание окружения.

---

# Запись 018

## Дата

10 августа 2026 года

## Тема

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

## Исходные данные

- Устройство опрошено напрямую: `Analog Devices PlutoSDR Rev.C (Z7010-AD9361)`. Приёмник перестраивается от 70 МГц до 6 ГГц, передатчик от 46,9 МГц. Минимальная частота дискретизации 2 083 333 Гц.
- Ограничений по разрешённым частотам у проекта нет.
- Усилителя мощности нет, покупка отложена до первых испытаний.

## Отвергнутые варианты и причины

**Выбор редкой фиксированной частоты.** Рассматривался как защита от подавления. Отклонён: одиночная несущая в пустом эфире обнаруживается сканирующим приёмником тривиально. Уязвимость создаёт не значение частоты, а её неизменность.

**Скачки по всему диапазону 70 МГц – 6 ГГц.** Теоретически требуют от заградительной помехи на 42 дБ больше мощности, но выигрыш недостижим. Отношение крайних частот 86:1, одна антенна такой полосы не перекрывает; разброс потерь на 10 км составляет 39 дБ, проектировать пришлось бы по худшему краю; выше примерно 1 ГГц дифракция исчезает и для наземного ровера без прямой видимости эти каналы мертвы. Кроме того, подавление направлено на диапазон, в котором связь действительно работает, а не на тот, который способно настроить оборудование.

**Диапазоны 330–433 МГц.** Отклонены как плотно занятые и общеизвестные.

## Принято

Рабочий диапазон **200–250 МГц**. Обоснование: четвертьволновая антенна 33 см пригодна для установки на ровер, дифракция ещё эффективна, участок заметно свободнее любительского 144 МГц и УКВ выше 300 МГц. Потери на 10 км составляют около 99,5 дБ.

Совокупность мер против подавления:

1. **Скачки по частоте в пределах 200–250 МГц.** Требуют от заградительной помехи на 22 дБ больше мощности при неизменной антенне и механике ровера.
2. **Направленная антенна наземной станции.** Даёт 10–20 дБ усиления и пространственно подавляет помеху, приходящую с иного направления.
3. **Расширение спектра для команд управления.** Поток команд составляет 10,88 кбит/с, поэтому расширение для него реализуемо в узкой полосе, в отличие от видеопотока.

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

## Запрещённые участки

- 108–137 МГц — авиационная связь.
- 243 МГц — международная аварийная частота.

## Ограничения решения

- Нижняя граница 70 МГц определяется приёмником Pluto и без смены оборудования не преодолевается.
- Скачки требуют согласованной последовательности у обеих сторон, то есть зависят от криптографической аутентификации, которая пока не реализована.
- Расчёты выполнены для свободного пространства. Потери на препятствиях 20–40 дБ учтены оценочно и подлежат измерению.
- Дальность 10 км без усилителя мощности не достигается.

## Влияние на ближайшие работы

На Lab042 не влияет: там кабельная петля, несущая 435 МГц выбрана произвольно. Диапазон 200–250 МГц вступает в силу начиная с эфирных испытаний.

---

# Запись 019

## Дата

10 августа 2026 года

## Тема

Lab042: первая передача изображения через реальный радиотракт. Эфирная проверка на паре антенн.

## Причина эфирного прогона

Кабельная петля требует переходника SMA папа-папа, которого пока нет: пигтейлы к антеннам оканчиваются папой, а разъёмы Pluto — мамы. Чтобы не простаивать, выполнена вспомогательная эфирная проверка на двух антеннах, разнесённых на 60 см. Она не заменяет кабельный опыт: уровни в помещении не контролируются строго, возможны переотражения. Её задача — снять последнюю неизвестность в коде, а именно обвязку вокруг устройства, которая в моделях не проверяется.

## Условия

- Устройство Analog Devices PlutoSDR Rev.C, чип AD9361, прошивка v0.32.
- Несущая 225 МГц, внутри целевого диапазона Записи 018.
- Антенны, рассчитанные на 108 МГц, работают на несущей как полуволновые. Частота передачи и частота, на которую рассчитана антенна, различны, поэтому в авиационный диапазон 108–137 МГц опыт не заходит.
- Изображение 320x180 в градациях серого, JPEG 4756 байт при качестве 35, десять фрагментов.

## Результат

- Изображение передано и собрано побайтово идентично исходному. Контрольная сумма MD5 переданного и принятого файла совпала.
- Десять фрагментов из десяти, ни одной несошедшейся контрольной суммы.
- Средняя нормированная корреляция при поиске кадра 0,99951.
- Средняя оценка ухода несущей минус 0,368 Гц, что отражает общий опорный генератор передатчика и приёмника.
- Канальная скорость 18,404 кбит/с при длительности сигнала в эфире около 2,07 секунды.
- Результат воспроизведён тремя запусками подряд с одинаковой контрольной суммой.

## Дефекты, вскрытые железом

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

- Кадр длиной 566 528 отсчётов не помещался в приёмный буфер 262 144. Между отдельными чтениями поток отсчётов не является непрерывным, и кадр на стыке разрушался. Приём переведён на один буфер, размер которого рассчитывается по длине кадра.
- Частотная коррекция применялась всегда, тогда как при общем опорном генераторе истинный уход близок к нулю. Оценка по маркеру длиной 80 символов состояла из шума, и коррекция им поворачивала фазу вдоль всего кадра: измерено 65 процентов ошибочных битов. Перенесена защита should_apply_cfo_correction из Lab023, разрешающая коррекцию только вне мёртвой зоны.
- Усиление приёмника 20 дБ давало сигнал около 0,0003 от шкалы АЦП. Рабочие уровни подобраны измерением: приёмник 50 дБ, передатчик минус 10 дБ дают ноль ошибочных битов с запасом.
- Величина вектора ошибки при неудачном приёме возвращала ноль, то есть показывала идеальный сигнал там, где сигнала не было. Это тот же класс ошибки, что вписанные показатели Lab041: метрика при отказе рапортует лучшее значение. Заменена на явный признак невычислимости.

## Ограничения

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

## Следующий этап

Кабельная петля через аттенюатор 30 дБ после получения переходника папа-папа. Это и есть заявленный опыт Lab042 с контролируемыми уровнями, его результат станет основным для лабораторной. Затем Lab043 — разведение на два устройства.

---

# Запись 020

## Дата

11 августа 2026 года

## Тема

Lab042 завершена: кабельная петля через аттенюатор, зависимость доставки от мощности, устранение трёх дефектов отчётности.

## Схема опыта

Выход передатчика PlutoSDR через кабель SMA, аттенюатор AT30S 30 дБ, переходник и второй кабель на вход приёмника того же устройства. Антенны сняты. Это заявленный основной опыт лабораторной с контролируемыми уровнями, в отличие от вспомогательной эфирной проверки Записи 019.

## Зависимость доставки от мощности передатчика

Кабельный тракт при неизменной схеме исследован по усилению передатчика. Получен отчётливый переход от отказа к устойчивой передаче:

- TX минус 30 дБ: 0 из 10 фрагментов, контрольная сумма не сходится ни разу, средняя корреляция 0,936. Сигнал ниже порога уверенного приёма.
- TX минус 20 дБ: 8 из 10 фрагментов, средняя корреляция 0,992. Пограничный режим: часть кадров проходит.
- TX минус 10 дБ: 10 из 10 фрагментов, изображение собрано побайтово. Устойчивая передача.

Значения TX минус 30 и минус 20 дБ — исследование порога, повторять их не требуется. Рабочая точка кабельной петли: TX минус 10 дБ, RX плюс 20 дБ, аттенюатор 30 дБ, несущая 435 МГц.

Начальные умолчания кабельного режима TX минус 30 и RX плюс 20 дБ на железе прежде не проверялись; отказ первого прогона объяснялся именно этим, а не дефектом обработки.

## Результат рабочей точки

- Найдено 10 кадров из 10, контрольная сумма сошлась у всех десяти, восстановлены все фрагменты.
- Изображение собрано и совпадает с переданным. Совпадение подтверждено независимо: SHA-256 принятого файла сверен с SHA-256 переданного JPEG, пересобранного из исходника отдельно от прогона. Оба равны 751d7ea0d8711e2ef54fc5cf209a809cfee5bbb14916dd20aa201d5285b40286.
- Размер JPEG 4756 байт, качество 30, десять фрагментов.
- Длительность сигнала около 2,07 секунды, канальная скорость 18,404 кбит/с.
- Кадр 8 прошёл контрольную сумму при пониженной корреляции поиска 0,866 против 0,998 у остальных: низкая корреляция маркера не означает испорченных данных, фаза дискретизации была подобрана и кадр демодулировался чисто.

## Устранённые дефекты отчётности

Разбор кабельного прогона вскрыл три дефекта, при которых провал мог быть принят за успех. Все три устранены, каждый закрыт быстрым тестом в tests/test_lab042_reporting.py.

- Величина вектора ошибки нормировалась на единичный эталон, из-за чего при слабом сигнале становилась искусственно малой: провалившийся прогон показывал EVM меньше, чем успешный. Нормировка исправлена на мощность подогнанного сигнала. При невозможности вычислить величину возвращается признак невычислимости, а не ноль.
- Отчёт перечислял lab042_received.jpg среди созданных файлов безусловно, даже когда изображение не собрано и файла нет. Теперь файл указывается только при фактической сборке.
- Программа завершалась кодом ноль при полном отказе передачи. Введён критерий приёмки: при несобранном изображении код завершения ненулевой, чтобы автоматика не приняла провал за успех.

## Проверки

- Быстрые тесты ядра расширены с 125 до 135. Добавленные проверяют неуспешный путь: провал даёт ненулевой код, отсутствующий файл не объявляется созданным, невычислимая метрика не превращается в ноль.
- Окончательный кабельный прогон рабочей точки выполнен уже исправленной версией программы, поэтому итоговый отчёт сформирован ею.

## Следующий этап

Lab043: передаёт PlutoSDR, принимает RTL-SDR. Общий опорный генератор исчезает, впервые появляется реальное рассогласование несущей и частоты дискретизации двух независимых устройств. Здесь понадобится защищённая частотная коррекция, перенесённая в Записи 019.