Lab049: define ELRS control and SDR video architecture

PROJECT_LOG.md

@@ -1367,3 +1367,277 @@ passed и 0 failed; `git diff --check` прошёл.
 
 STOP. Не переходить к Lab049, видео, QPSK, повышению символьной скорости или
 новому RF-сеансу без отдельной постановки. `RF TX = 0`; HackRF не запускать.
+
+# Запись 036
+
+## Дата
+
+3 сентября 2026 года
+
+## Тема
+
+Lab049: программное повышение символьной скорости BPSK с сохранением
+приоритета управления.
+
+## Выполнено
+
+До изменения кода проверены Lab047--Lab048, зависимости PHY и решения
+Lab033--Lab041. Подтверждено, что новый планировщик не нужен:
+`protocol/priority_scheduler.py` уже задаёт непрерываемое обслуживание с
+порядком `EMERGENCY > CONTROL > TELEMETRY > VIDEO`, а `LATEST_STATE` заменяет
+устаревшие ожидающие состояния CONTROL и TELEMETRY. Политики Lab034--Lab036
+сохраняют целостность видеокадров и допускают служебный трафик между пакетами.
+
+Реализован отдельный программный параметрический адаптер Lab049, не меняющий
+доказанный аппаратный тракт Lab047. При `Fs = 8 Мвыб/с` проверены 20, 50, 100
+и дополнительный режим 200 ксимв/с, то есть ровно 400, 160, 80 и 40
+выборок/символ. Режим 20 ксимв/с побайтно воспроизводит прежнюю CS8-форму
+Lab045. BPSK, PRBS7, PHY-заголовок, свёрточный FEC `R=1/2, K=7, 171/133
+octal`, перемежитель, CRC, packet format и fragment format не изменялись.
+
+Во всех режимах использован сохранённый JPEG Lab047: 8724 байта, RGB
+320 x 240, SHA-256
+`e913dab9ac32795250880a4be67fbbbf89a4f96536842476ab591d1acaafc02a`,
+36 физических кадров. Каждый режим прошёл полный frame-aligned IQ-тракт от
+фрагментации и BPSK/RRC до независимого восстановления PHY-длины, FEC, CRC и
+сборки объекта. Приёмник кадра не получает TX bits, payload, packet или
+ожидаемое число кадров; диагностическое сравнение выполняется после CRC.
+
+До полного прогона для всех скоростей одинаково зафиксирован шум
+`coded-bit Eb/N0 = 7,0 dB`, семена `49000 + frame_index`. Sigma вычисляется
+из фактической энергии кодированного BPSK-бита, поэтому корректно меняется с
+samples/symbol и не подбирается по результату режима.
+
+Идеальный и шумный каналы восстановили 36/36 кадров и точный JPEG во всех
+четырёх режимах. В шумном канале получено 129/114/107/110 ошибок кодированных
+бит до FEC для 20/50/100/200 ксимв/с; после FEC во всех режимах 0 ошибок,
+CRC PASS/FAIL `36/0`, ошибочных байтов и битов JPEG `0/0`.
+
+Длительность одного физического кадра равна 288,30/115,32/57,66/28,83 мс,
+полного JPEG — 10,37880/4,15152/2,07576/1,03788 с. Полезная скорость объекта
+равна 6,724/16,811/33,622/67,245 кбит/с: фактический выигрыш 1,0/2,5/5,0/10,0
+раза, рассчитанный по неизменному кадру.
+
+Шумный приём занял 7,14440/3,15468/1,92894/1,30565 с; отношение обработки к
+длительности сигнала 0,68836/0,75989/0,92927/1,25799. Режимы 20, 50 и 100
+ксимв/с успевают в реальном времени, 200 ксимв/с — нет. Поэтому 200 ксимв/с
+является устойчиво декодируемым, но только частичным результатом.
+
+Проверка существующего `LATEST_STATE` на постоянно заполненной VIDEO-очереди,
+CONTROL каждые 50 мс, TELEMETRY каждые 100 мс и одной EMERGENCY подтвердила
+порядок `VIDEO(active) -> EMERGENCY -> CONTROL -> TELEMETRY -> VIDEO`.
+Начатый кадр не прерывается. Верхняя граница блокировки новой CONTROL или
+EMERGENCY равна длительности кадра: 288,30/115,32/57,66/28,83 мс.
+
+Для нагрузки планировщика каждое сообщение занимает целый неизменный
+физический кадр Lab045. Прикладные CONTROL и EMERGENCY не дополняются внутри
+`LinkPacket`: сохранены точные 36- и 34-байтные сообщения, проверено их
+обратное декодирование. При CONTROL 20 сообщений/с и TELEMETRY 10 сообщений/с
+требуется 30 физических кадров/с. Ёмкость режимов равна
+3,469/8,672/17,343/34,686 кадра/с, поэтому остаток полезной скорости VIDEO
+равен 0/0/0/9,085 кбит/с, или 0/0/0/0,1302 JPEG в секунду. Это программная
+модель планирования, а не реализованная упаковка `LinkPacket` в физический
+кадр.
+
+Штатный `LATEST_STATE` заменяет ожидающее старое состояние, но сам по себе не
+удаляет пакет по истечении `deadline_ms`. В нагрузочном сценарии при 50
+ксимв/с один CONTROL начал передаваться через 100,760 мс при сроке 100 мс;
+при 20 ксимв/с EMERGENCY ожидала 87,900 мс при сроке 50 мс. Конкретное
+событие при 100 ксимв/с ожидало 30,240 мс, но худшая фаза 57,660 мс всё равно
+нарушает 50-миллисекундный срок EMERGENCY.
+
+Статусы всех режимов — `PARTIAL`. 20 и 50 ксимв/с нарушают требования по
+блокировке и не оставляют VIDEO; 100 ксимв/с укладывает CONTROL в 100 мс, но
+нарушает срок EMERGENCY и также не оставляет VIDEO; 200 ксимв/с исправляет
+эти ограничения, но приёмник не успевает в реальном времени с отношением
+1,25799. Для следующего отдельного аппаратного опыта только с PHY выбран
+диагностический кандидат 100 ксимв/с и 80 выборок/символ. Для объединённой
+работы он не рекомендован: `recommended_for_integrated_operation = false`,
+полностью пригодного режима не найдено.
+
+Созданы `experiments/lab049_bpsk_symbol_rate.py`,
+`tests/test_lab049_bpsk_symbol_rate.py`, `docs/lab049_current_state.md` и
+`data/processed/lab049/result.json`. Новый RF не выполнялся, `RF TX = 0`,
+HackRF не запускался.
+
+Целевые проверки Lab049 дали 17 passed. `python tools/quick_gate.py` прошёл:
+564 теста ядра и 12 функциональных проверок. `python -m pytest tests/ -q` дал
+564 passed и 0 failed; единственное предупреждение относится к запрету записи
+в служебный `.pytest_cache`. `git diff --check` прошёл.
+
+## Следующий этап
+
+STOP. До объединённого режима отдельно решить просроченные команды, упаковку
+служебных сообщений в физический кадр и перегрузку бюджета. Не выполнять
+аппаратный Lab049, QPSK, реальное видео, новый RF или переход на 180 МГц без
+отдельной постановки и явной авторизации.
+
+# Запись 037
+
+## Дата
+
+8 сентября 2026 года.
+
+## Тема
+
+Lab049: независимый IQ-приём и исправление расчёта полной доставки команд.
+
+## Выполнено
+
+Проверен HEAD ac6cc792b896e34f7dd6d291955a0387fdafcf41 и обнаружен уже
+существующий незакоммиченный вариант Lab049. Запись 036 сохранена.
+Независимые verifier/adversary воспроизвели отказ исходного приёмника при
+неизвестном начале +240 выборок и CFO +10 Гц на 100 ксимв/с, а также ошибочный
+расчёт аварийного срока по началу вместо конца передачи.
+
+Основной IQ-проход использует блочный поиск и строгий декодер Lab048,
+lab046c_offline_recovery.stream_process_capture. Адаптер читает синтетический
+complex64 без отсечения шума, временно задаёт Rs/SPS и возвращает константы
+и функции через finally. TX offsets, объект и число кадров в RX не передаются.
+Порог Lab047 0.030964473262429237, PRBS7, BPSK, PHY, FEC, CRC и форматы сохранены.
+Дробные скорости и нецелое samples/symbol отвергаются без округления.
+
+При Fs=8 Мвыб/с проверен тот же JPEG 8724 байта, RGB 320×240,
+SHA e913dab9ac32795250880a4be67fbbbf89a4f96536842476ab591d1acaafc02a,
+в режимах 20/50/100/200 ксимв/с. Идеальный канал восстановил 36/36 и точный JPEG
+во всех режимах. Шум един: coded-bit Eb/N0=7 dB, фиксированные seeds,
+остаточный CFO +10 Гц, фаза 0,73 рад и чередование полярности.
+
+В шуме 20 ксимв/с восстановил только 6/36 кадров, JPEG не собран — FAIL.
+50/100/200 восстановили 36/36, CRC PASS/FAIL 36/0, SHA match, ошибки JPEG 0/0.
+До FEC на принятых кадрах 67/147/119/125 ошибок, после FEC — 0; первая пара
+относится только к шести кадрам. Все восемь проходов дошли до конца IQ.
+
+Полная обработка шумного IQ заняла 173,65057 / 5,72980 / 7,76244 / 8,17573 с,
+при длительности IQ 10,458018 / 4,230738 / 2,154978 / 1,117098 с.
+Отношения 16,60454 / 1,35433 / 3,60210 / 7,31872: ни один режим не успевает
+в реальном времени. Меньшие времена записи 036 описывали заранее выровненные
+кадры и не переносятся на полный независимый тракт. 50/100/200 — PARTIAL.
+
+Переиспользован LATEST_STATE и сохранены форматы CONTROL/EMERGENCY.
+Отдельно считаются ожидание начала, полная доставка, активное окно 2 с
+и последующее опустошение очереди. На 100 ксимв/с максимум доставки CONTROL
+105,64 мс и EMERGENCY 87,90 мс; превышений сроков соответственно 6 и 1.
+На 20/50/100 внутри активного окна не доставлен ни один TELEMETRY.
+На 200 худшая доставка EMERGENCY равна почти 57,66 мс, а не 28,83 мс:
+к блокировке добавляется передача самой команды. Срок 50 мс нарушается.
+
+В модели одного полного PHY-кадра на пакет CONTROL 20 Гц и TELEMETRY 10 Гц
+перегружают 20/50/100 ксимв/с. На 200 остаются 9,085 кбит/с VIDEO, около
+0,1302 JPEG/с; с одной EMERGENCY за 2 с — 8,116 кбит/с. Аппаратная упаковка
+служебных LinkPacket в PHY не реализована и этой моделью не доказывается.
+
+Для отдельного будущего диагностического PHY-опыта выбран 50 ксимв/с:
+наименьшая вычислительная перегрузка среди точных шумных проходов. Это не
+пригодный объединённый канал и не разрешение RF. Старый JSON сохранён как
+data/processed/lab049/frame_aligned_result.json; актуальный result.json
+и docs/lab049_current_state.md содержат отрицательные результаты.
+Добавлены docs/lab049_audit.md, experiments/lab049_independent_iq.py и
+семь регрессий tests/test_lab049_independent_iq.py. Старые тесты не изменялись.
+Обновлён docs/LABS_INDEX.md. Модули protocol не изменялись.
+
+Verifier: 24 целевых теста PASS, независимый пересчёт JSON совпал.
+Adversary подтвердил корректный отрицательный аварийный вердикт.
+quick_gate PASS: 571 тест ядра, 12 функциональных проверок.
+pytest: 571 passed, 0 failed; одно предупреждение служебного .pytest_cache.
+git diff --check PASS. RF TX=0. Git add/commit/push/pull/fetch не выполнялись.
+
+Следующий этап: STOP; отдельная постановка для вычислительной перегрузки,
+бюджета и задержек перед аппаратной проверкой. Не запускать RF, QPSK,
+реальный видеопоток, новый FEC или 180 МГц в рамках этой работы.
+
+# Запись 038
+
+## Дата
+
+8 сентября 2026 года.
+
+## Тема
+
+Lab049: архитектура CRSF/ExpressLRS и бюджет отдельного SDR-видеоканала.
+
+## Выполнено
+
+Повторно проверены main и HEAD ac6cc792b896e34f7dd6d291955a0387fdafcf41.
+Существовавшие незакоммиченные Lab049, тесты, данные и записи 036–037 сохранены.
+Аудит README, журнала, индекса, Lab033–041, Lab047–048 и protocol подтвердил:
+общий EMERGENCY > CONTROL > TELEMETRY > VIDEO создавался для собственного
+единого ресурса. Его CONTROL 20 Гц и TELEMETRY 10 Гц в полных видеокадрах
+остаются историческим стресс-тестом, не целевой моделью CRSF/ELRS.
+
+По официальному ExpressLRS 4.1.0, коммиту
+a9d4a9cb5b5687c4c9d7e9e7fbdf44ad93651da6 и спецификации TBS проверены
+CRSF framing, UART, OTA, интервалы, Full/повторные режимы и телеметрия.
+CRSF RC: 26 байт по проводу; ELRS OTA4/OTA8: 8/13 байт, DATA: 5/10 байт.
+Ссылки на источники и точные допущения размещены в
+docs/lab049_crsf_elrs_architecture.md и crsf_elrs_budget.json.
+
+Рекомендуемая архитектура: обычный RadioMaster, штатные ELRS TX/RX,
+CRSF к контроллеру ровера для управления и критической телеметрии;
+отдельный SDR для изображений и объёмных данных. Будущие примерно 180 МГц
+относятся к SDR, не к стандартному ELRS. Лабораторная RF-база — 1400 МГц.
+Модели аппаратуры и ELRS-диапазон не уточнены; 100 Full/8ch/1:8 — условный
+кандидат сравнительной модели, не назначенная аппаратная конфигурация.
+
+При 100 Full/1:8 расчёт даёт до 87,5 RC-возможностей/с, 12,5 TLM-слотов/с,
+среднее ожидание RC 6,25 мс и верхнюю границу 20 мс только для идеального
+расписания RC/TLM. Полная задержка стики→ровер не измерена. DATA после
+LINK имеет потолок 116,667 байт/с до прочих расходов. Даже наиболее щедрый
+предел 10000 байт/с для двух DATA-трактов ELRS ниже JPEG 3 кадра/с:
+26172 байт/с. Обычная ELRS-телеметрия для видео недостаточна.
+
+Свойства безопасности Lab038–041 сохранены. При потере ELRS живое видео
+не разрешает движение. Требуются локальный таймер, аварийная защёлка,
+безопасная загрузка и отдельное повторное разрешение движения.
+Сопряжение не реализовано: RC CRSF не содержит session/boot/epoch/sequence
+нашего протокола. Локальная нумерация UART не доказывает свежесть источника.
+Порог ELRS TX для старого ввода пульта 1 с явно отмечен как незакрытое
+ограничение относительно модельных таймеров 100/200 и 150/250 мс.
+
+JPEG Lab047 сохранён: 8724 байта, RGB 320×240, SHA
+e913dab9ac32795250880a4be67fbbbf89a4f96536842476ab591d1acaafc02a.
+Фактические планы Lab046/Lab045 дают 36 кадров, 206064 BPSK-бита и
+207576 символьных интервалов с защитными интервалами/фильтром.
+Для 3/5/10 кадров/с JPEG payload требует 209,376/348,960/697,920 кбит/с,
+нынешняя PHY — минимум 622,728/1037,880/2075,760 ксимв/с без запаса.
+Управление ELRS из этого SDR-бюджета не вычитается.
+
+20/50/100/200 ксимв/с дают в идеале 0,09635/0,24088/0,48175/0,96350 JPEG/с.
+Существующие независимые шумные замеры переиспользованы по SHA, не повторены:
+на 50/100/200 точный JPEG, но обработка занимает 5,72980/7,76244/8,17573 с,
+отношение к IQ 1,35433/3,60210/7,31872. На 20 только 6/36 кадров.
+Lab048 15 с → 13,966058 с остаётся фактом одной записи, не доказательством
+реального времени при повышении скорости PHY.
+
+Конечная цель — больше 3 кадров/с; 3 промежуточно, далее 5 и 10.
+При 25 км/ч между изображениями соответственно 2,315/1,389/0,694 м.
+Рассчитана полная таблица для 10/15/25 км/ч и 1/3/5/10 кадров/с.
+Предел задержки изображения в один период (333,33/200/100 мс) обозначен
+как инженерное предложение, не измеренный или утверждённый норматив.
+Камера, живое кодирование, очередь и экран пока не измерены; RX включает
+JPEG decode, поэтому оно не прибавляется повторно. Кодек не менялся.
+
+Добавлены experiments/lab049_crsf_elrs_budget.py, 35 тестов в
+tests/test_lab049_crsf_elrs_budget.py и отдельный машинный результат
+data/processed/lab049/crsf_elrs_budget.json. Обновлены документы состояния,
+индекс и краткий указатель актуальной архитектуры в README.
+Старые protocol tests и модули protocol не изменены.
+
+Verifier независимо пересчитал расходы PHY, RC-ожидание перечислением
+интервалов, LINK/DATA и SHA исходных замеров; 35 целевых тестов PASS.
+Adversary: 7 проверок сеансов PASS; при живом видео без команд watchdog
+переходит в ступени 100/200 мс. Искусственная нумерация старого состояния
+подтверждает описанное ограничение свежести, не готовность bridge.
+Воспроизведённых расхождений в новой работе не обнаружено.
+
+quick_gate PASS: 606 тестов и 13 функциональных проверок.
+pytest: 606 passed за 64,32 с; одно предупреждение о доступе к .pytest_cache.
+git diff --check PASS. Дополнительный ruff не выполнен: модуль не установлен.
+RF TX = 0; оборудование не запускалось и не инвентаризировалось.
+Git add/commit/push/pull/fetch не выполнялись.
+
+Следующий этап: STOP. Рекомендуемый Lab050 — отдельная программная задача
+профилирования/потоковой обработки SDR-видео с ограничением возраста очереди
+и проверкой выполнимости 5 кадров/с. Сопряжение CRSF и его сценарии отказов
+требуют отдельной постановки и уточнения аппаратуры. Нового RF, QPSK,
+CRSF/ELRS-протокола, перекодирования JPEG или переноса на 180 МГц здесь нет.