SDR-Rover/docs/lab049_crsf_elrs_architecture.md

# 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.