protocol 2 fix

2026-04-14 22:06:31 +03:00
parent dde80e5696
commit 6ca18411cf
13 changed files with 1135 additions and 1024 deletions
@@ -0,0 +1,108 @@
+# Protocol 2 Worklog - 2026-04-14
+
+## Что подтверждено
+
+- Устройство корректно находится по Protocol 2.
+- Для `Orion MkII / boardID 5` рабочий RX действительно идёт через `DDC2`, то есть поток приходит с `UDP 1037`.
+- Реальное железо шлёт обратный трафик не на отдельные локальные порты `1025/1037/...`, а на локальный ephemeral-порт сессии.
+- Поэтому схема с отдельными `QUdpSocket` для status/DDC не работала на реальном трансивере, хотя по tcpdump трафик был виден.
+- После перехода на приём через общий сокет входящие IQ начали реально доходить:
+  - `dgrams > 0`
+  - `samples > 0`
+  - `iqFrames > 0`
+- `iq_queue` и упаковка в legacy-кадр уже не являются первичным блокером: спектр/водопад появляются хотя бы кратковременно.
+
+## Что уже исправлено в коде
+
+### Protocol 2 mapping и пакеты
+
+- Добавлен high-end mapping `RX1 -> DDC2`, `RX2 -> DDC3` для `boardID 3/4/5/10`.
+- `High Priority` пишет RX частоты в реальные DDC-слоты.
+- Добавлена запись `DUC frequency` в `HP bytes 329..332`.
+- `DDC Specific` отправляется полным пакетом `1444` байта.
+- Sample rate в `DDC Specific` передаётся в `ksps`, а не в `Hz`.
+- В `General Packet` исправлены:
+  - `DUC Specific port = 1026`
+  - `Mic data port = 1026`
+  - `Hardware watchdog enable`
+  - `PA enable`
+- Добавлен минимальный `DUC/TX Specific` пакет.
+
+### Сокеты и входящий трафик
+
+- Исходно была реализована схема с отдельными UDP-сокетами под `1025`, `1037` и т.д.
+- По tcpdump выяснилось, что реальный Orion MkII шлёт status/DDC/mic обратно на локальный порт командного сокета.
+- После этого реализован приём как в `pihpsdr`:
+  - один основной сокет с локальным session-port
+  - demux по `source port`
+  - `1025 -> status`
+  - `1026 -> mic`
+  - `1035+N -> DDC IQ`
+  - `1027 -> wideband`
+
+### Диагностика
+
+- Добавлены счётчики:
+  - `dgrams`
+  - `samples`
+  - `iqFrames`
+  - `hpTx`
+  - `hpRx`
+- Добавлен периодический лог состояния RX.
+
+## Что показывают последние логи
+
+- `hpTx` продолжает расти.
+- `hpRx` продолжает расти.
+- Значит:
+  - общий UDP сокет работает
+  - `QSocket/readyRead()` не является основным подозреваемым
+  - status-трафик живой
+- Но `dgrams` по DDC останавливаются на фиксированном числе.
+- Это означает, что после короткого времени именно радио перестаёт слать `DDC IQ`, при том что control/status канал остаётся жив.
+
+## Что уже проверено как гипотезы
+
+- Только `HP` в heartbeat.
+- `HP` каждые `50 ms`.
+- Только `HP + DDC Specific`.
+- Цикл, близкий к `pihpsdr`:
+  - `HP` каждые `100 ms`
+  - `TX Specific` / `RX Specific` по очереди
+  - `General` раз в `800 ms`
+
+Поведение меняется, но DDC поток всё равно обрывается.
+
+## Что нужно сделать следующим
+
+Нужен лог с разбивкой по входящим `source port`, чтобы зафиксировать точную картину после остановки RX потока.
+
+Ожидаемый лог теперь имеет вид:
+
+```text
+Protocol2:: rx flow: ... ports[1025=..., 1026=..., 1037=...]
+```
+
+### Критичный вопрос
+
+Что происходит после остановки `dgrams`:
+
+- если растут только `1025/1026`, а `1037` стоит:
+  - радио отключает именно DDC поток, при том что session/status живы;
+- если `1037` растёт, а `dgrams` нет:
+  - ошибка в нашем demux/parse;
+- если появляется другой неожиданный порт:
+  - нужно смотреть новую маршрутизацию/режим потока.
+
+## Главный вывод на текущий момент
+
+Проблема уже не выглядит как:
+
+- ошибка DSP,
+- пустой `iq_queue`,
+- неверные номера портов в `General`,
+- мёртвый `QSocket`.
+
+Основной текущий подозреваемый:
+
+- содержимое или cadence одного из Protocol 2 control-пакетов всё ещё не совпадает с тем, что ожидает реальный `Orion MkII`, и из-за этого радио через короткое время прекращает выдачу `DDC IQ`, хотя status-канал продолжает жить.