Lab049: define ELRS control and SDR video architecture

docs/LABS_INDEX.md

@@ -200,6 +200,46 @@
 - **RF:** новый радиосеанс не выполнялся, `RF TX = 0`.
 - **Журнал:** запись 035 ([`PROJECT_LOG.md`](../PROJECT_LOG.md)).
 
+## Lab049
+
+- **Актуальная архитектура:** RadioMaster + штатные ELRS TX/RX, CRSF к контроллеру
+  ровера; независимый SDR для видео и объёмных данных. Будущий SDR около 180 МГц,
+  лабораторная база 1400 МГц. Это не перенос штатного ELRS на 180 МГц.
+- **Аудит CRSF/ELRS:** официальный релиз 4.1.0, размеры OTA 8/13 байт,
+  реальные интервалы и доли телеметрии; ELRS недостаточно для JPEG >3 кадра/с.
+- **Бюджет SDR:** RC/критическая телеметрия в отдельном ELRS не вычитаются.
+  20/50/100/200 ксимв/с дают в идеале 0,09635 / 0,24088 / 0,48175 / 0,96350 JPEG/с.
+  Для 3/5/10 требуются минимум 622,728 / 1037,880 / 2075,760 ксимв/с
+  по фактическому текущему PHY. 3 — промежуточный уровень; цель >3, ориентиры 5 и 10.
+- **Задача предыдущего опыта:** 20/50/100/200 ксимв/с при Fs=8 Мвыб/с,
+  полный независимый IQ-приём и исторический стресс-тест общего канала.
+- **Актуальный результат:** идеал — 36/36 во всех режимах. Шум Eb/N0=7 dB, CFO +10 Гц:
+  20 — 6/36, FAIL; 50/100/200 — точный JPEG 36/36, CRC 36/0, PARTIAL.
+- **Полный приёмник Lab048:** processing/IQ 16,60454 / 1,35433 / 3,60210 / 7,31872;
+  ни один режим не успевает в реальном времени в шумном сценарии.
+- **Исторические задержки общего канала:** блокировка 288,30 / 115,32 / 57,66 / 28,83 мс. Доставка EMERGENCY
+  в худшей фазе включает ещё один кадр; даже на 200 она требует почти 57,66 мс.
+- **Исторический стресс-тест:** CONTROL 20 Гц и TELEMETRY 10 Гц в 30 полных
+  кадрах/с оставляли VIDEO только на 200. Это не целевая CRSF/ELRS-архитектура.
+- **Диагностический PHY-кандидат:** 50 ксимв/с, 160 выборок/символ —
+  наименьшая вычислительная перегрузка среди точных шумных проходов. RF не разрешён.
+- **Код:** [расчётчик ELRS/SDR](../experiments/lab049_crsf_elrs_budget.py),
+  [Lab049 IQ](../experiments/lab049_bpsk_symbol_rate.py),
+  [независимый IQ-адаптер](../experiments/lab049_independent_iq.py).
+- **Тесты:** [35 расчётных](../tests/test_lab049_crsf_elrs_budget.py),
+  [исходные](../tests/test_lab049_bpsk_symbol_rate.py),
+  [регрессии IQ](../tests/test_lab049_independent_iq.py).
+- **Отчёт:** [архитектура CRSF/ELRS](lab049_crsf_elrs_architecture.md),
+  [новый бюджет JSON](../data/processed/lab049/crsf_elrs_budget.json),
+  [состояние](lab049_current_state.md), [аудит](lab049_audit.md),
+  [JSON](../data/processed/lab049/result.json).
+- **История:** [старый frame-aligned результат](../data/processed/lab049/frame_aligned_result.json)
+  не измерял полный независимый поиск. Журнал: записи 036–038.
+- **Безопасность:** свойства Lab038–041 сохраняются; сопряжение CRSF ещё не проверено.
+  Видео не разрешает движение при потере ELRS. Модули protocol и прежние тесты сохранены.
+- **Далее:** программный Lab050 — профиль RX, поток видео и ограничение возраста очереди.
+- **RF:** RF TX = 0, STOP.
+
 ## Правило хранения данных
 
 Большие записи IQ, потоки `cs8`, бинарные объекты и другие аппаратные исходные

docs/lab049_audit.md

@@ -0,0 +1,86 @@
+# Lab049: аудит исходного незакоммиченного варианта
+
+8 сентября 2026 года. Корень `C:/Users/user/Desktop/projects/SDR_Rover`,
+ветка `main`, HEAD `ac6cc792b896e34f7dd6d291955a0387fdafcf41`.
+До работы уже существовали незакоммиченные реализация Lab049, тесты,
+`data/processed/lab049/result.json`, документ состояния и запись 036 журнала.
+Прежний JSON сохранён; он относится к выровненным кадрам и не является
+результатом полного независимого приёмника.
+
+## Карта архитектуры
+
+1. Базовый Rs задан в `experiments/lab043_hackrf_bpsk.py`: 20 000 символов/с.
+   Lab044 и Lab045 наследуют его, Lab047 явно проверяет аппаратную точку.
+2. В Lab043 `SAMPLES_PER_SYMBOL = SAMPLE_RATE_HZ // SYMBOL_RATE`; Lab047
+   отдельно фиксирует 400. Lab049 теперь отвергает дробные частоты и
+   нецелое отношение, не округляя вход.
+3. Жёсткие зависимости Lab043: `_refine_frame_start`, `_matched_filter_taps`,
+   `_matched_waveform`, `_preamble_timing_offset`, `_estimate_cfo_gain`,
+   `_evaluate_symbols`. Lab044: `_scale_and_carrier`,
+   `_preamble_reference_samples`. Lab045: длительности TransmissionPlan;
+   Lab046B: `_extract_soft_window` и `_decode_iq_candidate`. Временные шкалы
+   используют Rs, фильтры и индексы — samples/symbol. В локальном поиске
+   также есть фиксированные пределы ±800 и ±2000 выборок; они сохранены.
+4. `shape_frame_like_lab042`, RRC-фильтр ядра, преобразования бит/BPSK,
+   фрагментация, packet/PHY header, FEC, перемежитель, CRC и сборка объекта
+   уже параметрические либо вообще не зависят от Rs.
+5. `protocol/priority_scheduler.py`: строгий приоритет четырёх классов,
+   непрерываемая передача пакета и `LATEST_STATE` для ожидающих состояний.
+   Lab034–Lab036 добавили удаление устаревших изображений и изоляцию
+   видеокадров в собственных блоках FEC; это внешнее стирающее кодирование
+   видео, не новый свёрточный FEC Lab045.
+6. Минимальная доработка: адаптер скорости и чтения синтетического IQ к
+   `lab046c_offline_recovery.stream_process_capture`, который используется
+   Lab048; разделение ожидания/доставки и активного окна/опустошения очереди.
+   Новый планировщик и изменения `protocol/` не потребовались.
+
+## Проверка Lab033–Lab041
+
+Сверены сохранённые отчёты этих лабораторий и связанные модули.
+Lab033 подтверждает строгий приоритет и отдельно считает ожидание начала
+и завершение передачи. Lab034: frame-aligned FEC изолирует удаляемое
+изображение, начатый пакет не прерывается. Lab035–Lab036 ограничивают возраст
+изображения и число ожидающих кадров. Lab037 подтверждает вставку управления
+между пакетами VIDEO. Lab038–Lab040 добавляют failsafe, аварийную защёлку,
+повторы и ACK; Lab041 — сеансы/перезапуски. Эти механизмы безопасности
+в Lab049 не заменены и не заявлены как аппаратно проверенные.
+
+CONTROL взят из последнего Lab041: `ControlStateMessage`, 36 байт, 20 Гц;
+с 32-байтным LinkPacket — 68 байт и 10 880 бит/с до физического кодирования.
+TELEMETRY наследуется из Lab037 через Lab038–Lab041: синтетические 64 байта,
+10 Гц, с LinkPacket — 96 байт и 7680 бит/с. Отдельного формата физических
+измерений телеметрии эти лаборатории не задают.
+
+## Воспроизведённые несоответствия
+
+Проверки выполнены независимыми `verifier` и `adversary`, без правок с их
+стороны и без оборудования.
+
+- Исходный `receive_iq_frame`: идеальный кадр 100 ксимв/с проходит CRC,
+  добавление 240 нулевых выборок перед ним даёт `PHY=False, CRC=NOT_REACHED`.
+  Поиск ограничивался двумя символами от известной TX-границы.
+- Добавление +10 Гц к тому же кадру даёт `PHY=True, CRC=NOT_REACHED`;
+  +100 Гц — `PHY=False`. Остаточная частота не оценивалась.
+- При 100 ксимв/с старый отчёт CONTROL max 47,980 мс описывал начало,
+  а получение пакета занимает 105,640 мс; пропущены 6 сроков CONTROL.
+  EMERGENCY: 30,240 мс до начала, 87,900 мс до получения — пропущен срок 50 мс.
+- При 200 ксимв/с EMERGENCY через 1 мкс после VIDEO доставляется через
+  57,659 мс, а не за 50 мс. Штатный failsafe до получения пакета остаётся
+  в `normal`. Блокировка 28,83 мс и доставка почти 57,66 мс — разные метрики.
+- На 20/50/100 ксимв/с в двухсекундном окне не доставлено ни одного
+  TELEMETRY. Единственное сообщение старой таблицы доставляется при
+  последующем опустошении очереди.
+
+Регрессии воспроизводятся командой:
+
+```powershell
+python -m pytest tests/test_lab049_independent_iq.py -q
+```
+
+Исторический `receive_iq_frame` сохранён для локальных регрессий формы;
+основной проход Lab049 его больше не использует. Старые тесты не изменены.
+Новый RX получает полный поток, самостоятельно находит начало, оценивает CFO,
+фазу и полярность. PRBS7, физические и пакетные форматы, FEC, CRC и порог
+Lab047 `0.030964473262429237` сохранены.
+
+RF TX = 0. Git add/commit/push/pull/fetch не выполнялись.

docs/lab049_crsf_elrs_architecture.md

@@ -0,0 +1,450 @@
+# Lab049: CRSF / ExpressLRS и отдельный SDR-видеоканал
+
+Состояние на 8 сентября 2026 года. SOFTWARE + ARCHITECTURE ONLY, RF TX = 0.
+Решение по результатам аудита: **сохранить стандартный ELRS для управления,
+а SDR оптимизировать под изображения и объёмные данные**. Смешанная модель
+CONTROL 20 Гц + TELEMETRY 10 Гц, каждый в полном видеокадре, остаётся
+историческим стресс-тестом; она не определяет бюджет этой архитектуры.
+
+## Источники и границы доказанного
+
+Проверены официальный [последний релиз ExpressLRS 4.1.0](https://github.com/ExpressLRS/ExpressLRS/releases/tag/4.1.0)
+от 17 июля 2026 года и его
+[коммит a9d4a9cb5b5687c4c9d7e9e7fbdf44ad93651da6](https://github.com/ExpressLRS/ExpressLRS/commit/a9d4a9cb5b5687c4c9d7e9e7fbdf44ad93651da6).
+Версия исходников не означает, что такая прошивка уже стоит у пользователя.
+Ссылки ниже закреплены на этом коммите; страницы документации проверены в дату отчёта.
+
+Локальная база: main, HEAD `ac6cc792b896e34f7dd6d291955a0387fdafcf41`.
+До работы уже были изменены журнал и индекс, присутствовали незакоммиченные
+Lab049, её тесты и результаты, а также сторонние локальные файлы. Они сохранены.
+README описывает старую точку Lab042 и диапазон 200–250 МГц; текущая постановка
+пользователя уточняет будущий SDR-видеоканал как примерно 180 МГц.
+
+Физические модели RadioMaster, ELRS TX/RX и их диапазон пока не указаны.
+Поэтому приведено сравнение, а не назначение конкретных настроек оборудования.
+Инвентаризация и аппаратная проверка не выполнялись. Совместимость системы
+ниже — архитектурная, сопряжение с контроллером ровера ещё не реализовано.
+
+## Что уже есть в проекте
+
+Аудит README, PROJECT_LOG, LABS_INDEX, Lab033–Lab041, Lab047–048 и связанных
+модулей дополняет [предыдущий аудит Lab049](lab049_audit.md).
+
+| Код / лаборатории | Для чего создавался | Что сохраняется при отдельном ELRS |
+|---|---|---|
+| `protocol/link_packet.py`, `priority_scheduler.py`; Lab033 | Один абстрактный непрерываемый ресурс для двух направлений, EMERGENCY > CONTROL > TELEMETRY > VIDEO, последнее ожидающее состояние | Историческая модель и регрессии; не размещаем её CONTROL/TELEMETRY в бюджете SDR |
+| `video_frame_scheduler.py`, Lab034–036 | Удаление устаревшего видео, допуск целого изображения, ограничение очереди, FEC-блоки в пределах изображения | Нужны принципы возраста и ограничения очереди; сопряжение с нынешним JPEG/PHY ещё предстоит |
+| Lab037, `control_repetition.py` | Повторы управления, потери и видео в одном канале, удаление дубликатов | Тестовые сценарии потерь; собственные повторы не накладываются автоматически поверх ELRS |
+| Lab038, `control_failsafe.py`, `emergency_ack.py` | Таймер свежей команды, остановка, подтверждение аварии | Локальный контроль потери управления и идемпотентная аварийная остановка остаются обязательными |
+| Lab039, `two_stage_failsafe.py` | Две ступени замедления/торможения, кинематика | Автомат и сценарии; тормозные параметры реального ровера пока не измерены |
+| Lab040, `persistent_emergency.py` | Намерение остановить сохраняется после ACK; отдельный подтверждённый сброс | Смысл аварийной защёлки и запрет самовозобновления; перенос наземного автомата на обычный пульт не выполнен |
+| Lab041, `control_messages.py`, `session_state.py` | Сеансы, загрузки, эпохи, номера команд, защита от старых ACK/reset | Сохранить свойства; CRSF не предоставляет эти поля автоматически |
+| Lab047–048, Lab049 IQ | JPEG как двоичный объект, независимый PHY/FEC/CRC, производительность | Доказательная база отдельного SDR-видеоканала |
+
+Синтетические 64 байта TELEMETRY из Lab037 и собственные сообщения CONTROL
+Lab041 не являются форматами CRSF. Модули `protocol/` и старые тесты не менялись.
+
+## Одна схема системы
+
+```mermaid
+flowchart TB
+  subgraph RC[Управление и критическая телеметрия]
+    RM[RadioMaster: стики и переключатели] <-->|CRSF| ETX[Штатный ExpressLRS TX]
+    ETX <-->|ELRS OTA: поддерживаемый аппаратурой диапазон| ERX[Штатный ExpressLRS RX]
+    ERX <-->|CRSF UART| R[Контроллер ровера]
+    R --> S[Локальный таймер, аварийная защёлка, торможение]
+    S --> M[Приводы]
+  end
+  subgraph VIDEO[Независимый SDR video/data]
+    C[Камера] --> J[JPEG; будущий видеокодек]
+    J --> STX[SDR передатчик]
+    B[Объёмные данные ровера] --> STX
+    STX -->|Будущий RF около 180 МГц; лабораторная база 1400 МГц| SRX[SDR приёмник]
+    SRX --> D[Декодер изображения] --> O[Экран оператора]
+  end
+```
+
+При пропаже ELRS продолжающееся видео **не продлевает разрешение движения**.
+Таймер, тормозной автомат и аварийная защёлка должны работать независимо от
+очередей видео, загруженности декодера и доступности экрана.
+Частота 180 МГц относится к будущему SDR-тракту, не к стандартному ELRS.
+Это целевая архитектура; готовый двухканальный ровер пока не испытан.
+
+## CRSF на проводных границах
+
+По [спецификации TBS](https://github.com/tbs-fpv/tbs-crsf-spec/blob/main/crsf.md):
+кадр содержит sync/address, длину, тип, данные и CRC8 (полином 0xD5).
+Длина считает тип, данные и CRC, исключая первые два байта; полный кадр ≤64 байт.
+Расширенный заголовок добавляет destination и origin.
+
+| Тип | Содержание | Данные / полный кадр, байт |
+|---|---|---:|
+| 0x16 | 16 RC-каналов по 11 бит | 22 / 26 |
+| 0x14 | Статистика связи | 10 / 14 |
+| 0x08 | Батарея | 8 / 12 |
+| 0x02 | GPS | 15 / 19 |
+| 0x1E | Ориентация | 6 / 10 |
+| 0x21 | Режим, строка с завершающим нулём | переменный |
+| 0x28–0x2D, 0x32 | Обнаружение, параметры, команды/ACK | переменный, расширенный |
+
+Пульт↔модуль: обычно однопроводный полудуплекс, 400 кбод, 8N1, 3,3 В;
+приёмник↔контроллер: двухпроводный полный дуплекс, без инверсии,
+в спецификации 416666 бод, 8N1, 3,0–3,3 В.
+У ELRS штатная настройка UART приёмника — **420000 бод**:
+[официальная Web UI](https://www.expresslrs.org/quick-start/webui/#receiver-options).
+Настройки обеих сторон должны совпадать. Расчёт сериализации 26 байт при
+420000 бод: 26×10/420000 = 0,619 мс; это только провод, не радиозадержка.
+
+[SerialCRSF::sendRCFrame](https://github.com/ExpressLRS/ExpressLRS/blob/a9d4a9cb5b5687c4c9d7e9e7fbdf44ad93651da6/src/src/rx-serial/SerialCRSF.cpp)
+упаковывает текущие каналы в 0x16 только при `frameAvailable`.
+Это не сквозная пересылка исходных CRSF-байтов через эфир: ELRS сначала
+кодирует OTA, затем RX заново формирует CRSF. Статистика и сообщения
+контроллера идут отдельными кадрами. Не все 16 выходных полей обновляются
+по радио одновременно; часть может содержать состояние, полученное ранее.
+
+Для обычных стиков специальная прошивка RadioMaster не требуется: нужен
+вариант с ELRS либо совместимый внешний ELRS-модуль и штатная настройка CRSF.
+Вариант RadioMaster с другим внутренним RF-модулем сам по себе ELRS не даёт.
+Нужен RX с доступным CRSF UART, общий поддерживаемый диапазон и совместимая
+версия ELRS; конкретную пару ещё надо выбрать. См.
+[настройку передатчика](https://www.expresslrs.org/quick-start/transmitters/lua-howto/).
+Программное сопряжение CRSF с ровером остаётся будущей задачей.
+
+## ELRS в эфире
+
+[OTA.h](https://github.com/ExpressLRS/ExpressLRS/blob/a9d4a9cb5b5687c4c9d7e9e7fbdf44ad93651da6/src/lib/OTA/OTA.h)
+задаёт OTA4 = **8 байт**, OTA8 = **13 байт**, включая служебные поля и CRC.
+Это длина содержимого радиопакета ELRS, не весь физический расход LoRa/FLRC/GFSK.
+RC-пакеты, DATA, SYNC и LINK имеют разные назначения; 26 байт CRSF не следует
+подставлять вместо этих размеров. Поле DATA в
+[telemetry_protocol.h](https://github.com/ExpressLRS/ExpressLRS/blob/a9d4a9cb5b5687c4c9d7e9e7fbdf44ad93651da6/src/include/telemetry_protocol.h)
+содержит **5 либо 10 байт**, а не 8/13 байт пользовательской нагрузки.
+
+Точные периоды и Std взяты из
+[ExpressLRS_AirRateConfig](https://github.com/ExpressLRS/ExpressLRS/blob/a9d4a9cb5b5687c4c9d7e9e7fbdf44ad93651da6/src/src/common.cpp).
+Таблица ниже рассчитана для установившегося соединения, без потерь,
+без повторных режимов D/DK; RC означает возможности отправки, не измеренные обновления стиков.
+
+| Режим | Доступность | OTA, байт | Период, мс | Std | TLM-слотов/с | RC-возможностей/с ≤ | Среднее / верхнее ожидание RC, мс |
+|---|---|---:|---:|---:|---:|---:|---:|
+| 25 | 900 | 8 | 40 | 1:8 | 3,125 | 21,875 | 25 / 80 |
+| 50 | 900 и 2,4 | 8 | 20 | 1:16 | 3,125 | 46,875 | 11,250 / 40 |
+| 100 | 900 | 8 | 10 | 1:32 | 3,125 | 96,875 | 5,313 / 20 |
+| 100 Full | 900 и 2,4 | 13 | 10 | 1:32 | 3,125 | 96,875 | 5,313 / 20 |
+| 150 | 2,4 | 8 | 6,666 | 1:32 | 4,688 | 145,327 | 3,541 / 13,332 |
+| 200 | 900 | 8 | 5 | 1:64 | 3,125 | 196,875 | 2,578 / 10 |
+| 250 | 2,4; 900 на LR1121 | 8 | 4 | 1:64 | 3,906 | 246,094 | 2,063 / 8 |
+| 333 Full | 2,4 | 13 | 3,003 | 1:128 | 2,602 | 330,399 | 1,525 / 6,006 |
+| 500 LoRa | 2,4 | 8 | 2 | 1:128 | 3,906 | 496,094 | 1,016 / 4 |
+| F1000 / K1000 | 2,4, SX128X / LR1121 | 8 | 1 | 1:128 | 7,813 | 992,188 | 0,508 / 2 |
+| K1000 Full | 900, LR1121 | 13 | 1 | 1:128 | 7,813 | 992,188 | 0,508 / 2 |
+
+Это представительная, не исчерпывающая таблица. Также существуют F500,
+900 200 Full на LR1121, D50, D250/D500, DK250/DK500 и двухдиапазонные X-режимы;
+аппаратные ограничения описаны в
+[официальном руководстве Packet Rate](https://www.expresslrs.org/quick-start/transmitters/lua-howto/#packet-rate-and-telemetry-ratio).
+Для внешнего модуля 333 Гц и выше требуется скорость связи с пультом выше 400 кбод.
+Не все режимы доступны одному и тому же RX.
+
+Full повышает число полноразмерных каналов в OTA. В режиме 8ch каналы 1–8
+передаются вместе; 16ch Rate/2 делит частоту пополам; 12ch Mixed оставляет
+первые четыре быстрыми, остальные передаёт с половинной частотой.
+Hybrid/Wide передают дополнительные переключатели по очереди.
+Поэтому аварийный орган нельзя без проверки помещать в медленно обновляемую группу.
+Источник: [Switch Configs, варианты 4.x](https://www.expresslrs.org/software/switch-config/).
+D50 повторяет команду четыре раза в слотах по 5 мс; D250/DK250 — четыре раза
+по 1 мс, D500/DK500 — два. Называть их 200/1000 новыми командами в секунду нельзя.
+Расчётчик отвергает повторные режимы вместо ложного пересчёта.
+
+## Задержка управления и телеметрия
+
+Обозначения: T — период RF-слота, D — знаменатель 1:D, f=1/T.
+При фиксированном D телеметрии выделяется 1/D слотов, RC остаётся не более
+f×(D−1)/D возможностей. До произвольного ближайшего RF-слота среднее ожидание
+T/2, верхняя граница T. Если исключить каждый D-й слот под TLM, промежутки
+между RC равны T или 2T; при равномерной временной фазе среднее ожидание
+T×(1/2+1/D), верхняя граница 2T. Это наши аналитические расчёты, проверенные
+независимым перечислением интервалов в тестах.
+
+[TX-планировщик](https://github.com/ExpressLRS/ExpressLRS/blob/a9d4a9cb5b5687c4c9d7e9e7fbdf44ad93651da6/src/src/tx_main.cpp)
+заменяет часть передач RC на SYNC и активный DATA uplink; телеметрийные
+слоты освобождаются для обратного направления. Стандартный Std зависит от режима,
+Race выключает телеметрию при вооружении, служебный обмен может временно
+изменить отношение до 1:2. Следовательно, 2T — граница только упрощённого
+расписания RC/TLM, **не гарантия реального ELRS**. Потери или разрыв связи
+вообще не имеют такой конечной верхней границы доставки.
+
+Пример 100 Full (T=10 мс), все величины ниже вычислены тем же расчётчиком:
+
+| TLM | Доля слотов | TLM/с | RC/с ≤ | Ожидание RC среднее / верхнее, мс | DATA с учётом LINK ≤ байт/с |
+|---|---:|---:|---:|---:|---:|
+| Off | 0% | 0 | 100 | 5 / 10 | 0 |
+| 1:128 | 0,78125% | 0,781 | 99,219 | 5,078 / 20 | 6,250 |
+| 1:64 | 1,5625% | 1,563 | 98,438 | 5,156 / 20 | 12,500 |
+| 1:32 Std | 3,125% | 3,125 | 96,875 | 5,313 / 20 | 25,000 |
+| 1:16 | 6,25% | 6,250 | 93,750 | 5,625 / 20 | 54,167 |
+| 1:8 | 12,5% | 12,500 | 87,500 | 6,250 / 20 | 116,667 |
+| 1:4 | 25% | 25 | 75 | 7,500 / 20 | 241,667 |
+| 1:2 | 50% | 50 | 50 | 10 / 20 | 492,000 |
+
+Предварительный кандидат для программной модели ровера — **100 Full, 8ch,
+TLM 1:8**, если выбранная пара его поддерживает: достаточно быстрые каналы
+стиков/остановки и больше места служебным сообщениям, чем при Std.
+Это не назначенная конфигурация и не доказательство сроков аварии/ACK.
+Для 900 МГц при приоритете чувствительности следует сравнить 50 и обычный 100;
+для 2,4 ГГц — 50/100 Full/150. Окончательный выбор требует моделей TX/RX,
+диапазона, требований к дальности и отдельного измерения задержек/потерь.
+
+Чувствительность действительно меняется: официальные ориентиры для 2,4 ГГц
+50/100 Full/250/500 — −115/−112/−108/−105 dBm, для 900 МГц 50/100/100 Full —
+−120/−117/−112 dBm. Это параметры режимов из
+[официальной таблицы](https://www.expresslrs.org/software/mavlink/#throughput-per-rf-mode),
+а не обещание дальности. ELRS-дальность и будущая дальность SDR на 180 МГц
+проверяются отдельно; дальнее видео не компенсирует короткий радиус управления.
+
+Полная цепь задержки управления: считывание стиков → цикл RadioMaster →
+CRSF к TX → ожидание слота и OTA → RX → CRSF к роверу → цикл управления →
+привод. Она **не измерена**. К рассчитанному ожиданию нельзя приписывать
+название stick-to-rover latency.
+
+## Сколько данных в штатной телеметрии и почему это не видео
+
+Верхний предел одного тракта DATA: P×f/D байт/с, P=5 либо 10.
+[RX-планировщик 4.1.0](https://github.com/ExpressLRS/ExpressLRS/blob/a9d4a9cb5b5687c4c9d7e9e7fbdf44ad93651da6/src/src/rx_main.cpp)
+чередует LINK и серию DATA. LINK занимает четыре байта статистикой,
+оставляя 1/6 байт DATA. При постоянной насыщенной очереди:
+B=max(1, floor(512×floor(f)/D/1000)−1), средний предел
+C=(f/D)×(P−4/(B+1)). Это учёт слотов, а не гарантированный полезный поток:
+CRC/служебные поля OTA уже вычтены размером P; добивка, подтверждения,
+повторы DATA, потери и заголовки переносимых CRSF/MAVLink снижают результат.
+При низкой частоте TLM цель LINK раз в 512 мс сама по себе не гарантируется.
+
+Даже предельно щедрая оценка K1000 Full, 1:2 даёт 5000 байт/с на один тракт
+до LINK; условное удвоение для двух DATA-трактов даёт 10000 байт/с. Уже
+**JPEG 3 кадра/с требует 26172 байт/с**, то есть больше даже такого потолка.
+
+[Официальные оценки MAVLink](https://www.expresslrs.org/software/mavlink/#throughput-per-rf-mode)
+при 1:2: 100 Full около 435 байт/с, 333 Full около 1470,
+F1000 около 2375; K1000 Full около 4420, Gemini около 8845 байт/с.
+Последнее — 70,76 кбит/с, против 209,376 кбит/с одного JPEG payload при 3 кадрах/с.
+Это документированные оценки специального режима MAVLink, не наши замеры
+и не обещание доступного JPEG-сокета у обычного CRSF RX.
+**STANDARD ELRS VIDEO CAPABILITY = INSUFFICIENT.**
+
+Телеметрию разделяем так:
+
+| Класс | Путь | Реализация и бюджет |
+|---|---|---|
+| Качество RC-связи: LQ, RSSI, SNR | Штатный ELRS LINK → RadioMaster; CRSF к роверу | Поддерживается ELRS, но не подтверждает выполнение команды |
+| Напряжение/батарея | Контроллер → CRSF → ELRS DATA → RadioMaster | Формат 0x08 предусмотрен; датчик и выдачу значений должен реализовать контроллер |
+| Аварийная защёлка, режим ровера, подтверждение критического действия | Тот же ELRS/CRSF обратный путь | Семантика, события, идентификаторы и отображение на пульте ещё не согласованы/реализованы; 0x21/0x32 не дают их автоматически |
+| Большие диагностические структуры и сенсорные массивы | SDR data/video | Отдельный будущий ограниченный бюджет и политика возраста, нагрузка пока не задана |
+
+Для масштаба: батарея 12 байт CRSF дважды в секунду требует 24 байт/с.
+При 100 Full Std расчётный потолок после LINK всего 25 байт/с до прочих потерь:
+запаса почти нет. При 1:8 потолок 116,667 байт/с. Предлагаемый начальный лимит
+периодической служебной нагрузки — 50 байт/с **включая CRSF-заголовки**;
+остаток не объявляется гарантированным: нужны измерения и резерв событий/повторов.
+Критические события должны опережать периодические датчики в будущей очереди
+контроллера. TLM 1:8 даёт слот раз в 80 мс: ACK за 50 мс здесь не обещается.
+Остановка происходит локально по управляющему тракту и не ждёт обратного ACK.
+Off/Race не подходят для требуемой постоянной критической телеметрии.
+
+## Связь с безопасностью Lab038–Lab041
+
+Здесь сформулирован контракт будущего сопряжения, код CRSF/bridge не написан.
+
+1. Ровер стартует с запрещённым движением; после загрузки, пропажи RC или
+   аварии одно появление старого положения стиков не разрешает движение.
+   Нужны безопасное положение органов и явное новое разрешение оператора.
+2. Команда остановки поступает через быстрый RC-орган ELRS/CRSF. Локальная
+   защёлка сохраняет остановку независимо от последующих стиков; ACK только
+   сообщает о ней. Снятие защёлки и разрешение движения — отдельные действия.
+   Обычный тумблер пульта не заменяет весь `PersistentEmergencyController`.
+3. Таймер свежести управления не обновляется от JPEG, LINK statistics,
+   напряжения, DATA или любого произвольного CRSF-кадра. На потерю допустимого
+   управления реагируют существующие ступени торможения. Пороги Lab039
+   100/200 и 150/250 мс являются исследованными модельными вариантами,
+   не измеренными тормозными нормативами ровера; здесь они не изменены.
+4. `ground_session_id`, `rover_boot_id`, `control_epoch`, `sequence_number`,
+   идентификаторы аварии/сброса Lab041 отсутствуют в RC 0x16. Локально
+   присвоенный номер приёма доказывает порядок UART-событий, но не свежесть
+   источника, защиту от повтора или подлинность команды. CRC этого не заменяет.
+   Binding/model match также нельзя объявлять эквивалентом автомата Lab041.
+5. В [SendRCdataToRF](https://github.com/ExpressLRS/ExpressLRS/blob/a9d4a9cb5b5687c4c9d7e9e7fbdf44ad93651da6/src/src/tx_main.cpp)
+   порог давности последнего RC от пульта — 1000000 мкс. При остановке
+   обновлений RadioMaster до этого порога TX может посылать прежнее состояние.
+   Приём регулярных UART RC-кадров не обеспечивает исходную свежесть за
+   100/200 мс. Сценарий требует отдельного решения и проверки всей цепи;
+   нормальное неизменное положение стика нельзя считать отказом только
+   потому, что значения равны предыдущим.
+6. На возобновление соединения, reboot RX/контроллера, старый reset/ACK,
+   удерживаемый разрешающий тумблер и отсутствие обратной телеметрии нужны
+   воспроизводимые проверки. До них `SAFETY INTEGRATION = NOT VALIDATED`.
+   Автомат Lab041 нельзя просто обойти синтезом «нового сеанса» на каждый пакет.
+
+Таким образом, отдельный ELRS устраняет конкуренцию с видеокадрами, но сам
+по себе не доказывает безопасность готового ровера. Сохранённые модули и
+их тесты остаются эталоном свойств для последующей реализации.
+
+## Видео: фактическая упаковка контрольного JPEG
+
+Объект [Lab047](../data/processed/lab047/tx_image.jpg): 8724 байта, RGB 320×240,
+SHA-256 `e913dab9ac32795250880a4be67fbbbf89a4f96536842476ab591d1acaafc02a`.
+JPEG не перекодирован. [Расчётчик](../experiments/lab049_crsf_elrs_budget.py)
+вызывает настоящие `build_object_frames` и `build_transmission_plan` из
+[Lab046](../experiments/lab046_bpsk_object_transport.py) /
+[Lab045](../experiments/lab045_hackrf_bpsk_fec.py), не генерируя IQ.
+
+| Ступень на одно изображение | Объём |
+|---|---:|
+| JPEG | 8724 байта |
+| 36 фрагментов: заголовки по 12 байт + 60 байт добивки последнего | 9216 байт нагрузки пакетов |
+| 36 пакетов по 268 байт: ещё 12 байт заголовка/CRC на пакет | 9648 байт |
+| Свёрточный FEC R=1/2, шесть хвостовых бит на пакет | 154800 кодированных бит |
+| PHY-заголовки 144×36 | 5184 бит |
+| Преамбулы 1280×36 | 46080 бит |
+| Передаваемые биты BPSK, сумма | 206064 бит |
+| Защитные интервалы + хвост фильтра (32+10)×36 | 1512 интервалов без новых бит |
+| Полное занятие радио | **207576 символьных интервалов** |
+
+Перемежитель длину не меняет. Внешний стирающий FEC старого видеопланировщика
+Lab034 сюда дополнительно не добавлен: в доказанном потоке Lab047 его нет.
+Радиосимвол BPSK несёт один передаваемый бит, но защитный интервал не является
+битом. Поэтому ниже отдельно показаны поток передаваемых бит и минимальная
+символьная скорость с учётом всего занятого времени. Это расход текущего
+формата; он не переносится на ELRS и не включает новую модуляцию.
+
+| Цель | JPEG, байт | Только JPEG, байт/с | Только JPEG, кбит/с | Передаваемые BPSK-биты, кбит/с | Требуемая PHY с защитными интервалами, ксимв/с | RX: изображений/с; RF-кадров/с | Максимум обслуживания RX на изображение | Предложенный предел полной задержки* |
+|---|---:|---:|---:|---:|---:|---:|---:|---:|
+| 3 кадра/с, промежуточно | 8724 | 26172 | 209,376 | 618,192 | **622,728** | 3; 108 | 333,33 мс | 333,33 мс |
+| 5 кадров/с, следующий ориентир | 8724 | 43620 | 348,960 | 1030,320 | **1037,880** | 5; 180 | 200 мс | 200 мс |
+| 10 кадров/с, дальнейший ориентир | 8724 | 87240 | 697,920 | 2060,640 | **2075,760** | 10; 360 | 100 мс | 100 мс |
+
+*Предел полной задержки предложен как один период изображения. Это открытое
+инженерное допущение, **не утверждённый пользователем предел безопасности и
+не измеренная характеристика**. RX service budget — необходимая средняя
+производительность последовательного обработчика, не разрешение занять этим
+весь сквозной бюджет. Измерение хвостов распределения задержки также необходимо.
+
+Числа PHY — нижние границы при отсутствии потерь, повторов и объёмной нагрузки,
+весь ресурс отдан видео. На границе ёмкости нет запаса от роста очереди.
+Произвольные 20 CONTROL + 10 TELEMETRY из SDR **не вычитаются**.
+Когда появятся объёмные данные, расчётчик принимает их явно как расход
+символьных интервалов в секунду. Если занято 20% ресурса, требуемая PHY
+для того же видео возрастает в 1/0,8=1,25 раза — это пример, не выбранный резерв.
+Точные требуемые скорости выше проверенных 200 ксимв/с; их работоспособность
+и допустимое число выборок/символ при Fs=8 Мвыб/с не доказаны этой арифметикой.
+
+## Текущая ёмкость и фактическая обработка
+
+Замеры переиспользованы из
+[independent/result.json](../data/processed/lab049/independent/result.json),
+SHA-256 `8a2c799a9754cf439159ebd68f3d77212200a391ecfdbd3520c312a71a4e49b3`.
+Полный тяжёлый IQ-опыт на этом архитектурном этапе повторно не запускался.
+Расчётчик проверяет SHA JPEG, число кадров и согласие длительности с текущим PHY.
+
+| Rs, ксимв/с | Полезно в идеале, кбит/с | JPEG в эфире, с | Идеальные кадры/с без RC-резерва | Измеренная обработка шумного IQ, с | Длительность IQ, с | Обработка/IQ | JPEG в этом шумном сценарии |
+|---|---:|---:|---:|---:|---:|---:|---|
+| 20 | 6,724 | 10,37880 | 0,09635 | 173,65057 | 10,45802 | 16,60454 | Нет, 6/36 |
+| 50 | 16,811 | 4,15152 | 0,24088 | 5,72980 | 4,23074 | 1,35433 | Точный, 36/36 |
+| 100 | 33,622 | 2,07576 | 0,48175 | 7,76244 | 2,15498 | 3,60210 | Точный, 36/36 |
+| 200 | 67,245 | 1,03788 | 0,96350 | 8,17573 | 1,11710 | 7,31872 | Точный, 36/36 |
+
+Шумной модели заданы одинаковые coded-bit Eb/N0=7 dB, CFO +10 Гц, фаза 0,73 рад,
+чередование полярности и фиксированные seeds. Порог независимого приёмника
+Lab047 сохранён: 0.030964473262429237. Это один программный сценарий,
+не оценка дальности и не аппаратное подтверждение ускоренных режимов.
+
+Исторический [Lab048](lab048_current_state.md): 15 с записи → 13,966058 с
+обработки при 20 ксимв/с, отношение 0,931071. Это реальное время только на
+той сохранённой записи. В нынешней шумной модели ни один режим не успевает;
+для 5 кадров/с нужен RX как минимум 180 RF-кадров/с, а не нынешние 36 за
+5,73–8,18 с. Производительность нельзя линейно экстраполировать по Rs.
+При неизменном Fs вход остаётся 8 Мвыб/с, но число кандидатов и полезных
+кадров возрастает. 50 ксимв/с — полезная точка для профилирования, а не цель видео.
+
+## Движение и задержка изображения
+
+Расчёт расстояния: d=(v/3,6)/fps. Все числа — метры между моментами съёмки
+при постоянной скорости, не тормозной путь и не полный возраст изображения.
+
+| Скорость | 1 кадр/с | 3 кадра/с | 5 кадров/с | 10 кадров/с |
+|---|---:|---:|---:|---:|
+| 10 км/ч | 2,778 | 0,926 | 0,556 | 0,278 |
+| 15 км/ч | 4,167 | 1,389 | 0,833 | 0,417 |
+| 25 км/ч | 6,944 | 2,315 | 1,389 | 0,694 |
+
+При 25 км/ч ещё 200 мс возраста показанной сцены соответствуют 1,389 м
+пройденного пути. Потому 3 кадра/с — только промежуточный минимум;
+конечная цель **больше 3**, следующий практический ориентир 5, дальнейший 10.
+
+| Участок сквозной задержки | Что известно сейчас |
+|---|---|
+| Съёмка/экспозиция/считывание камеры | Не измерено; сейчас готовый JPEG |
+| Кодирование JPEG | Не измерено в живом тракте; перекодирование здесь не выполнялось |
+| Радиоочередь | В расчёте ёмкости нулевая; живая очередь не реализована/не измерена |
+| Передача RF | Рассчитанное время из фактической формы 10,37880 / 4,15152 / 2,07576 / 1,03788 с |
+| Поиск и обработка RX | Измерены вместе со сборкой и JPEG decode в таблице выше |
+| Декодирование JPEG | Входит в общее время RX; отдельно не выделено, второй раз не прибавляется |
+| Очередь экрана/отрисовка | Не измерено |
+
+Полная задержка L = capture + encode + queue + RF + RX + JPEG decode + display.
+Сложение RF и имеющегося общего RX описывает последовательную обработку
+после накопления записи, не измеренный потоковый конвейер. Для такого
+варианта на 50 ксимв/с известная часть уже 4,15152+5,72980=9,88132 с,
+плюс неизвестные стадии; реального измерения камера→экран пока нет.
+
+Предложение для следующего проектирования: при 5 кадрах/с L≤200 мс,
+например не более 100 мс на радио и оставшиеся 100 мс суммарно на прочие
+стадии. Тогда по нынешнему формату требуется уже ≥2075,760 ксимв/с,
+а не 1037,880: минимальный потоковый битрейт сам по себе задержку не обеспечивает.
+Это иллюстративное распределение бюджета, которое предстоит проверить.
+Удаление устаревших изображений ограничит возраст очереди, но не ускорит PHY.
+
+## Если отказаться от отдельного ELRS
+
+Перенос CRSF-семантики на SDR означал бы собственные радиомодем,
+синхронизацию, дуплекс/планировщик, повторения, контроль потерь и весь путь
+безопасности. Стандартный ELRS RX такой SDR-поток не декодирует; для
+RadioMaster понадобился бы совместимый проводной адаптер/модуль.
+Теряются готовая OTA-совместимость и доказанная работа штатной пары ELRS.
+Это уже не стандартный ExpressLRS. Пользователь такой переход не запросил;
+в данной Lab049 он не реализуется.
+
+## Следующий этап и воспроизведение
+
+Рекомендуемый Lab050 — **программный потоковый SDR-видеотракт и профиль RX**:
+тот же JPEG, независимый непрерывный поиск, ограничение возраста/очереди,
+измерение стадий обработки и проверка выполнимости 5 кадров/с по вычислениям
+и PHY. Начать с профиля существующих 50/100/200 ксимв/с; отделить стоимость
+поиска ложных кандидатов от FEC и сборки. Не объявлять ускорение успешным
+до полного CRC/SHA и устойчивой очереди. Для CRSF отдельно подготовить
+контракт безопасности и сценарии отказов; реализация сопряжения требует
+следующей согласованной постановки и уточнения аппаратуры.
+
+Позднее сравнить разрешение, grayscale, JPEG quality, ROI, более лёгкий
+кодек и межкадровые/дельта-данные. Контрольная картинка не окончательна,
+но в этой работе ни один из этих параметров не менялся.
+
+```powershell
+python experiments/lab049_crsf_elrs_budget.py
+python -m pytest tests/test_lab049_crsf_elrs_budget.py -q -p no:cacheprovider
+python tools/quick_gate.py
+python -m pytest tests/ -q
+git diff --check
+```
+
+Машинный результат: [crsf_elrs_budget.json](../data/processed/lab049/crsf_elrs_budget.json).
+Он хранит источники, версию, допущения, SHA исходных замеров, расходы PHY,
+таблицы ELRS, видео и движения. Старые JSON не перезаписаны.
+
+Итог: 35 расчётных тестов PASS; quick_gate PASS — 606 тестов и 13 функциональных
+проверок; полный pytest — 606 passed за 64,32 с, одно предупреждение о доступе
+к `.pytest_cache`; git diff --check PASS. Дополнительный ruff недоступен:
+модуль не установлен. Verifier независимо подтвердил числа и источники;
+adversary подтвердил семь проверок сеансов и локальный watchdog при живом видео.
+Сквозная безопасность CRSF/ELRS остаётся непроверенной, поскольку сопряжения нет.
+
+RF TX = 0. HackRF и другое оборудование не запускались.
+Git add/commit/push/pull/fetch не выполнялись. STOP.

docs/lab049_current_state.md

@@ -0,0 +1,219 @@
+# Lab049: отдельный ELRS для управления и SDR для видео
+
+Актуальная архитектурная постановка от 8 сентября 2026 года:
+**RadioMaster → штатный ELRS → CRSF → контроллер ровера** для управления и
+критической телеметрии; отдельный SDR — для изображений и объёмных данных.
+Будущие примерно 180 МГц относятся только к SDR; аппаратная лабораторная
+база остаётся 1400 МГц. Стандартный ELRS не объявляется работающим на 180 МГц.
+
+Подробный [аудит CRSF/ELRS, схема и контракт безопасности](lab049_crsf_elrs_architecture.md)
+сверен с официальным ExpressLRS 4.1.0. Модели аппаратуры пока не указаны,
+сопряжение контроллера с CRSF и сквозная безопасность не реализованы/не проверены.
+Сохраняются локальное торможение при потере управления, аварийная защёлка,
+защита от самовозобновления. Видео не обновляет таймер управления.
+
+Прежний общий CONTROL > TELEMETRY > VIDEO — исторический стресс-тест ниже.
+Его 20 CONTROL и 10 TELEMETRY в секунду **не резервируют ёмкость SDR**.
+Старые программные результаты и отрицательные вердикты сохранены.
+
+| SDR, ксимв/с | JPEG 8724 байта в идеале, кадры/с | Полезно, кбит/с |
+|---|---:|---:|
+| 20 | 0,09635 | 6,724 |
+| 50 | 0,24088 | 16,811 |
+| 100 | 0,48175 | 33,622 |
+| 200 | 0,96350 | 67,245 |
+
+Требуется **больше 3 кадров/с**: 3 — промежуточный минимум, 5 — следующий
+ориентир, 10 — дальнейший. Тот же JPEG в нынешнем PHY требует соответственно
+622,728 / 1037,880 / 2075,760 ксимв/с с защитными интервалами, без запаса на
+потери и объёмные данные. Только JPEG: 209,376 / 348,960 / 697,920 кбит/с.
+Штатная ELRS-телеметрия для такого видео недостаточна; официальные источники,
+расходы по ступеням, движение и бюджет полной задержки приведены в новом отчёте.
+
+Новый [расчётчик](../experiments/lab049_crsf_elrs_budget.py) создаёт отдельный
+[crsf_elrs_budget.json](../data/processed/lab049/crsf_elrs_budget.json),
+переиспользует существующие независимые замеры IQ по SHA и не запускает RF.
+Он считает ELRS-возможности слотов, не измеренную задержку стики→ровер.
+35 новых тестов бюджета проходят; quick_gate: 606 тестов и 13 функциональных
+проверок, полный pytest: 606 passed, git diff --check: PASS. Одно предупреждение
+pytest относится к доступу к `.pytest_cache`; ruff не установлен.
+Независимые verifier/adversary не обнаружили воспроизведённых расхождений.
+Подробности общих проверок — в записи 038.
+Следующий рекомендуемый Lab050: программное профилирование и потоковая
+обработка SDR-видео с ограничением возраста очереди; затем отдельное сопряжение CRSF.
+
+## Сохранённый независимый IQ-опыт и общий стресс-тест
+
+Актуальный программный результат от 8 сентября 2026 года: **полностью пригодного режима нет**.
+Максимальная проверенная скорость с точным JPEG в идеальном и фиксированном шумном сценариях —
+200 ксимв/с. Полный приёмник в шумном сценарии не успевает в реальном времени ни в одном режиме.
+Это результат одного воспроизводимого сценария, не универсальная оценка предела устойчивости BPSK.
+
+Для отдельного будущего диагностического PHY-опыта выбран **50 ксимв/с, 160 выборок/символ**:
+точный JPEG, полезная скорость в 2,5 раза выше базовой и наименьшая вычислительная перегрузка
+среди точных шумных проходов (1,3543). Он не готов к непрерывному объединённому каналу:
+блокировка 115,32 мс, перегрузка служебным трафиком и нарушенный аварийный срок.
+Это кандидат для диагностики, не разрешение RF. 100 ксимв/с лучше по блокировке, но требует
+3,60 длительности IQ для обработки; 200 ксимв/с — 7,32.
+
+## Аудит и исправления
+
+При входе в задачу Lab049 уже существовала без коммита. Старый результат сохранён как
+`data/processed/lab049/frame_aligned_result.json`; запись 036 журнала не переписана.
+Они измеряли заранее выровненные кадры без остаточного CFO. Новые данные —
+`data/processed/lab049/result.json` и идентичный `independent/result.json`.
+[Аудит](lab049_audit.md) содержит карту функций, проверку Lab033–Lab041 и воспроизведённые отказы.
+
+Основной RX получает целый IQ-поток без TX-границ, payload, объекта или ожидаемого числа кадров.
+Используются блочный поиск и строгий декодер Lab048: `lab046c_offline_recovery.stream_process_capture`.
+Сохранён порог Lab047 `0.030964473262429237`. Адаптер последовательно задаёт Rs/SPS и предоставляет
+чтение синтетического complex64; исходные константы и функции возвращаются через finally.
+Старый локальный `receive_iq_frame` остаётся для регрессий формы, основной проход его не использует.
+
+Fs = 8 000 000 выборок/с. Отношения Fs/Rs точные, дробные входы и нецелое samples/symbol
+отвергаются. BPSK, PRBS7, PHY header, packet/fragment, CRC, свёрточный FEC R=1/2 K=7
+(171/133 octal), tail bits и перемежитель сохранены. Новый планировщик не создан, protocol не изменён.
+
+## Канал и объект
+
+Один JPEG Lab047: 8724 байта, RGB 320×240, SHA-256
+`e913dab9ac32795250880a4be67fbbbf89a4f96536842476ab591d1acaafc02a`; без перекодирования.
+Каждый проход: JPEG → фрагменты → protocol packets → FEC → interleaver → BPSK/RRC →
+CS8-квантование → IQ → независимый поиск → CFO/фаза/полярность → PHY/FEC/CRC → сборка → JPEG decode.
+
+Идеальный канал не добавляет шум/CFO. Шумный: единый coded-bit Eb/N0=7 dB,
+seed=49000+номер кадра, остаточный CFO +10 Гц, фаза 0,73 рад и чередование полярности.
+Eb = sum(abs(IQ)**2)/число символов; sigma² каждой компоненты шума = Eb/(2×10**(7/10)).
+Нормировка одинакова во всех режимах, параметры не подбирались до PASS.
+Ведущий, межкадровые и конечный интервалы не кратны символу; фон имеет отдельные фиксированные seeds.
+После добавления шума IQ не переквантован в CS8, чтобы не отсекать шум.
+
+Кадр занимает 5766 символьных интервалов с фильтром и защитными интервалами; JPEG — 36 кадров.
+Длительность IQ включает ещё 0,079217625 с фона. Полезная скорость считается по чистому времени
+JPEG, отношение обработки — по всей длительности IQ. Измеряются поиск, декодирование, сборка и
+JPEG decode; генерация канала и TX-сравнение после вердикта исключены. Все восемь проходов
+завершились END_OF_STREAM. Первый пробный прогон с лимитами Lab046B 32/256 был неполным;
+итоговые результаты получены после перехода на полный блочный путь с независимыми лимитами 4096/100000.
+
+## Результаты IQ
+
+| Метрика | 20 ксимв/с | 50 ксимв/с | 100 ксимв/с | 200 ксимв/с |
+|---|---:|---:|---:|---:|
+| Выборок/символ | 400 | 160 | 80 | 40 |
+| Кадр, мс | 288.300 | 115.320 | 57.660 | 28.830 |
+| Кадров JPEG | 36 | 36 | 36 | 36 |
+| JPEG airtime, с | 10.37880 | 4.15152 | 2.07576 | 1.03788 |
+| Полезно, байт/с, идеал | 840.560 | 2101.399 | 4202.798 | 8405.596 |
+| Полезно, кбит/с, идеал | 6.724 | 16.811 | 33.622 | 67.245 |
+| Идеал: кадры / SHA | 36/36 / да | 36/36 / да | 36/36 / да | 36/36 / да |
+| Шум: кадры | 6/36 | 36/36 | 36/36 | 36/36 |
+| До FEC, принятые кадры | 67 | 147 | 119 | 125 |
+| После FEC, принятые кадры | 0 | 0 | 0 | 0 |
+| CRC PASS / FAIL | 6 / 0 | 36 / 0 | 36 / 0 | 36 / 0 |
+| Шум: JPEG SHA / decode | нет / нет | да / да | да / да | да / да |
+| Ошибки JPEG байт / бит | не восстановлен | 0 / 0 | 0 / 0 | 0 / 0 |
+| Обработка идеала, с | 8.73746 | 5.69848 | 7.36877 | 6.45915 |
+| Обработка шума, с | 173.65057 | 5.72980 | 7.76244 | 8.17573 |
+| Длительность IQ, с | 10.458018 | 4.230738 | 2.154978 | 1.117098 |
+| Обработка / IQ, шум | 16.604540 | 1.354327 | 3.602096 | 7.318724 |
+| Реальное время, шум | нет | нет | нет | нет |
+| Статус | FAIL | PARTIAL | PARTIAL | PARTIAL |
+
+На 20 ксимв/с 67 ошибок до FEC и 0 после относятся **только к шести принятым кадрам**.
+JPEG не восстановлен; полезная скорость целых JPEG в шумном проходе равна нулю.
+Остальные 30 кадров нельзя объявлять безошибочными. Проверено 2378 кандидатов, 2372
+отклонены на PHY header. На 50/100/200 проверено 59/237/474 кандидата.
+Кандидат, не достигший CRC, не записан как CRC FAIL. Причины сохранены в JSON.
+Порог и шум после отказов не менялись. Все идеальные проходы имеют ноль ошибок до/после FEC.
+
+Базовые 6,724 кбит/с согласуются с примерно 6,7 кбит/с Lab047. Выигрыш 2,5/5/10
+рассчитан по фактической форме и числу кадров, а не обещан заранее.
+Исторические аппаратные результаты Lab047/Lab048 не опровергнуты: здесь другой канал.
+
+## Планирование и задержки
+
+Переиспользован LATEST_STATE: EMERGENCY > CONTROL > TELEMETRY > VIDEO.
+Проверка даёт VIDEO(active) → EMERGENCY → CONTROL → TELEMETRY → VIDEO.
+Физический кадр не прерывается, но весь JPEG не удерживает канал.
+CONTROL — штатные 36 байт, 20 Гц (Lab041); TELEMETRY — синтетические 64 байта,
+10 Гц (Lab037–Lab041); EMERGENCY — штатный EmergencyStop, 34 байта, t=0,777 с.
+Служебная нагрузка генерируется 2 с. Запас VIDEO 256 пакетов не исчерпывается в этом окне.
+
+Каждый пакет модели занимает один полный PHY-кадр. Это модель занятости;
+упаковка LinkPacket в аппаратный 256-байтный PHY payload не реализована.
+Прикладные CONTROL/EMERGENCY сохраняют точные сериализованные байты.
+Задержки не включают программное время RX, потери, повторы и привод; это не гарантия
+времени физического торможения. Блокировка — остаток начатого VIDEO;
+доставка EMERGENCY в худшей фазе — почти два кадра, включая саму команду.
+Старое поле deadline в priority_probe сохранено как совместимое поле блокировки
+с явным scope; классификация использует новый delivery flag.
+
+| Метрика | 20 ксимв/с | 50 ксимв/с | 100 ксимв/с | 200 ксимв/с |
+|---|---:|---:|---:|---:|
+| CONTROL max VIDEO blocking, мс | 288.30 | 115.32 | 57.66 | 28.83 |
+| EMERGENCY max VIDEO blocking, мс | 288.30 | 115.32 | 57.66 | 28.83 |
+| EMERGENCY worst delivery, мс | 576.60 | 230.64 | 115.32 | 57.66 |
+| CONTROL blocking <100 / <50 мс | нет / нет | нет / нет | да / нет | да / да |
+| EMERGENCY delivery ≤50 мс | нет | нет | нет | нет |
+
+Доставка **в активном окне 0–2 с**, min / median / max, мс. Заменённые и ещё не доставленные состояния сюда не входят:
+
+| Метрика | 20 ксимв/с | 50 ксимв/с | 100 ксимв/с | 200 ксимв/с |
+|---|---:|---:|---:|---:|
+| CONTROL | 289.90 / 303.20 / 316.50 | 116.92 / 136.28 / 162.88 | 58.84 / 82.03 / 105.64 | 30.01 / 43.94 / 61.07 |
+| EMERGENCY | 376.20 / 376.20 / 376.20 | 145.56 / 145.56 / 145.56 | 87.90 / 87.90 / 87.90 | 30.24 / 30.24 / 30.24 |
+| TELEMETRY | нет доставленных | нет доставленных | нет доставленных | 33.84 / 45.54 / 89.69 |
+| VIDEO | 288.30 / 288.30 / 288.30 | 115.32 / 115.32 / 115.32 | 57.66 / 57.66 / 57.66 | 28.83 / 850.49 / 1845.12 |
+
+Доставка **до полного опустошения очереди**, отдельно от активной нагрузки:
+
+| Метрика | 20 ксимв/с | 50 ксимв/с | 100 ксимв/с | 200 ксимв/с |
+|---|---:|---:|---:|---:|
+| CONTROL, мс | 289.90 / 303.20 / 331.40 | 116.92 / 139.48 / 216.08 | 58.84 / 83.84 / 105.64 | 30.01 / 43.73 / 61.07 |
+| EMERGENCY, мс | 376.20 / 376.20 / 376.20 | 145.56 / 145.56 / 145.56 | 87.90 / 87.90 / 87.90 | 30.24 / 30.24 / 30.24 |
+| TELEMETRY, мс | 644.70 / 644.70 / 644.70 | 356.40 / 356.40 / 356.40 | 183.42 / 183.42 / 183.42 | 33.84 / 45.54 / 89.69 |
+| VIDEO, мс | 288.30 / 39352.95 / 76111.20 | 115.32 / 17009.70 / 31713.00 | 57.66 / 9485.07 / 16836.72 | 28.83 / 5434.46 / 9110.28 |
+| Конец опустошения, с | 76.11120 | 31.71300 | 16.83672 | 9.11028 |
+| Превышения CONTROL / EMERGENCY | 6 / 1 | 17 / 1 | 6 / 1 | 0 / 0 |
+
+Очередь заменяет старое ожидающее состояние, но не удаляет пакет по deadline.
+На 20/50/100 за активные 2 с доставлено 0 TELEMETRY. У 200 конкретная EMERGENCY
+доставлена за 30,24 мс, но худшая фаза 57,66 мс всё равно нарушает срок 50 мс.
+
+## Исторический бюджет единого канала — не бюджет целевой архитектуры
+
+Прикладные CONTROL/TELEMETRY: 5760/5120 бит/с; вместе с LinkPacket до PHY —
+10880/7680 бит/с. Физическая стоимость: 20/10 полных кадров/с, или
+**115320/57660 символьных интервалов в секунду** BPSK, включая всю форму.
+Эту стоимость нельзя прямо вычитать из JPEG-бит/с: остаток считается через время эфира.
+JSON-поля reserved_link_bps 46080/23040 относятся к внутренним 288-байтным
+представителям планировщика, а не к физическому кодированному потоку.
+
+| Метрика | 20 ксимв/с | 50 ксимв/с | 100 ксимв/с | 200 ксимв/с |
+|---|---:|---:|---:|---:|
+| CONTROL, запрошено % эфира | 576.60 | 230.64 | 115.32 | 57.66 |
+| TELEMETRY, запрошено % эфира | 288.30 | 115.32 | 57.66 | 28.83 |
+| EMERGENCY, событие/2с, % эфира | 14.415 | 5.766 | 2.883 | 1.442 |
+| VIDEO после C+T, кбит/с | 0.000 | 0.000 | 0.000 | 9.085 |
+| Теоретические JPEG/с после C+T | 0.00000 | 0.00000 | 0.00000 | 0.13017 |
+| VIDEO после C+T+E, кбит/с | 0.000 | 0.000 | 0.000 | 8.115 |
+
+Процент больше 100 означает перегрузку, а не фактически переданные данные.
+Только 200 оставляет VIDEO: 9,085 кбит/с и около 0,1302 JPEG/с;
+с одной EMERGENCY за 2 с — 8,116 кбит/с. Это потенциал модели, не видеопоток:
+вычислительная перегрузка и аварийный срок остаются.
+
+## Проверки предыдущего IQ-этапа
+
+Независимые verifier/adversary воспроизвели прежние отказы и подтвердили исправления.
+Verifier: 24 целевых теста PASS, независимый пересчёт JSON совпал.
+Adversary: правильный отрицательный аварийный вердикт и отдельное активное окно.
+
+- python tools/quick_gate.py: PASS, 571 тест ядра, 12 функциональных проверок.
+- python -m pytest tests/ -q: 571 passed, 0 failed; одно предупреждение о запрете записи .pytest_cache.
+- git diff --check: PASS.
+
+RF TX = 0. HackRF не запускался. Git add/commit/push/pull/fetch не выполнялись.
+STOP. Следующий этап требует отдельной постановки: вычислительная перегрузка,
+бюджет и задержки перед аппаратным опытом. QPSK, новый FEC, реальное видео и
+переход на 180 МГц в этой работе не выполнялись.