Lab049: define ELRS control and SDR video architecture

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.