# 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-канал продолжает жить.