Files
SDR-Rover/docs/lab049_crsf_elrs_architecture.md
2026-09-08 13:26:06 +03:00

42 KiB
Raw Blame History

Lab049: CRSF / ExpressLRS и отдельный SDR-видеоканал

Состояние на 8 сентября 2026 года. SOFTWARE + ARCHITECTURE ONLY, RF TX = 0. Решение по результатам аудита: сохранить стандартный ELRS для управления, а SDR оптимизировать под изображения и объёмные данные. Смешанная модель CONTROL 20 Гц + TELEMETRY 10 Гц, каждый в полном видеокадре, остаётся историческим стресс-тестом; она не определяет бюджет этой архитектуры.

Источники и границы доказанного

Проверены официальный последний релиз ExpressLRS 4.1.0 от 17 июля 2026 года и его коммит 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.

Код / лаборатории Для чего создавался Что сохраняется при отдельном 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/ и старые тесты не менялись.

Одна схема системы

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: кадр содержит 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. Настройки обеих сторон должны совпадать. Расчёт сериализации 26 байт при 420000 бод: 26×10/420000 = 0,619 мс; это только провод, не радиозадержка.

SerialCRSF::sendRCFrame упаковывает текущие каналы в 0x16 только при frameAvailable. Это не сквозная пересылка исходных CRSF-байтов через эфир: ELRS сначала кодирует OTA, затем RX заново формирует CRSF. Статистика и сообщения контроллера идут отдельными кадрами. Не все 16 выходных полей обновляются по радио одновременно; часть может содержать состояние, полученное ранее.

Для обычных стиков специальная прошивка RadioMaster не требуется: нужен вариант с ELRS либо совместимый внешний ELRS-модуль и штатная настройка CRSF. Вариант RadioMaster с другим внутренним RF-модулем сам по себе ELRS не даёт. Нужен RX с доступным CRSF UART, общий поддерживаемый диапазон и совместимая версия ELRS; конкретную пару ещё надо выбрать. См. настройку передатчика. Программное сопряжение CRSF с ровером остаётся будущей задачей.

ELRS в эфире

OTA.h задаёт OTA4 = 8 байт, OTA8 = 13 байт, включая служебные поля и CRC. Это длина содержимого радиопакета ELRS, не весь физический расход LoRa/FLRC/GFSK. RC-пакеты, DATA, SYNC и LINK имеют разные назначения; 26 байт CRSF не следует подставлять вместо этих размеров. Поле DATA в telemetry_protocol.h содержит 5 либо 10 байт, а не 8/13 байт пользовательской нагрузки.

Точные периоды и Std взяты из ExpressLRS_AirRateConfig. Таблица ниже рассчитана для установившегося соединения, без потерь, без повторных режимов 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. Для внешнего модуля 333 Гц и выше требуется скорость связи с пультом выше 400 кбод. Не все режимы доступны одному и тому же RX.

Full повышает число полноразмерных каналов в OTA. В режиме 8ch каналы 1–8 передаются вместе; 16ch Rate/2 делит частоту пополам; 12ch Mixed оставляет первые четыре быстрыми, остальные передаёт с половинной частотой. Hybrid/Wide передают дополнительные переключатели по очереди. Поэтому аварийный орган нельзя без проверки помещать в медленно обновляемую группу. Источник: Switch Configs, варианты 4.x. 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-планировщик заменяет часть передач 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. Это параметры режимов из официальной таблицы, а не обещание дальности. ELRS-дальность и будущая дальность SDR на 180 МГц проверяются отдельно; дальнее видео не компенсирует короткий радиус управления.

Полная цепь задержки управления: считывание стиков → цикл RadioMaster → CRSF к TX → ожидание слота и OTA → RX → CRSF к роверу → цикл управления → привод. Она не измерена. К рассчитанному ожиданию нельзя приписывать название stick-to-rover latency.

Сколько данных в штатной телеметрии и почему это не видео

Верхний предел одного тракта DATA: P×f/D байт/с, P=5 либо 10. RX-планировщик 4.1.0 чередует 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 при 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 порог давности последнего RC от пульта — 1000000 мкс. При остановке обновлений RadioMaster до этого порога TX может посылать прежнее состояние. Приём регулярных UART RC-кадров не обеспечивает исходную свежесть за 100/200 мс. Сценарий требует отдельного решения и проверки всей цепи; нормальное неизменное положение стика нельзя считать отказом только потому, что значения равны предыдущим.
  6. На возобновление соединения, reboot RX/контроллера, старый reset/ACK, удерживаемый разрешающий тумблер и отсутствие обратной телеметрии нужны воспроизводимые проверки. До них SAFETY INTEGRATION = NOT VALIDATED. Автомат Lab041 нельзя просто обойти синтезом «нового сеанса» на каждый пакет.

Таким образом, отдельный ELRS устраняет конкуренцию с видеокадрами, но сам по себе не доказывает безопасность готового ровера. Сохранённые модули и их тесты остаются эталоном свойств для последующей реализации.

Видео: фактическая упаковка контрольного JPEG

Объект Lab047: 8724 байта, RGB 320×240, SHA-256 e913dab9ac32795250880a4be67fbbbf89a4f96536842476ab591d1acaafc02a. JPEG не перекодирован. Расчётчик вызывает настоящие build_object_frames и build_transmission_plan из Lab046 / Lab045, не генерируя 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, 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: 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, более лёгкий кодек и межкадровые/дельта-данные. Контрольная картинка не окончательна, но в этой работе ни один из этих параметров не менялся.

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. Он хранит источники, версию, допущения, 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.