Files
cudaSDR/Source/WORKLOG_PROTOCOL2_2026-04-14.md
T
2026-04-14 22:06:31 +03:00

109 lines
5.3 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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-канал продолжает жить.