3 Commits

Include renames

Author	SHA1	Message	Date
ew8bakandClaude Opus 5	adbb8d02ac	fix(tci): Stream.length — вещественные отсчёты всего блока, а не на канал ... MSHV не декодировал FT4 по TCI (по виртуальному кабелю — декодировал). Регрессия из dc6f996: там length аудио был переведён на «сэмплы на канал» по формулировке §4.3, а живые клиенты считают по нему БАЙТЫ блока (network.cpp: `int cr2 = pStream->length*bit_s;` с шагом `chan*bit_s`, на передаче `quint32 cr3 = pStream->length*bit_s;`). При Channels=2 (умолчание MSHV) клиент разбирал половину каждого блока: звук с дырами 50%, водопад шире и грязнее, декодер разваливался. В моно дефекта не видно — единицы совпадают, поэтому первый прогон стенда увёл в сторону. Правка верна и по документу, а не только по клиенту: §3.4 после IQ («количество вещественных отсчётов… комплексных = length/channels») говорит «аудиопоток приёмника ПОЛНОСТЬЮ ПОВТОРЯЕТ IQ поток» и перечисляет ровно три отличия — каналы, формат сэмплов, число сэмплов в пакете. Единиц length среди них нет, поле в struct Stream одно. Развилка по типу потока была вычитана из воздуха. §4.3 путает две величины, и её формулировка верна лишь для моно: AUDIO_STREAM_SAMPLES — кадры НА КАНАЛ, Stream.length — отсчёты ВСЕГО блока. Что arg1 считает кадры, видно из самой §4.3 дважды: минимум 512/256/128/100 на 48/24/12/8 кГц даёт обещанные «не меньше 10 мс» только при счёте на канал, и потолок data[16384] = 2048 × 2 × float32. TX_CHRONO замыкает круг: клиент шлёт столько отсчётов, сколько названо в length маркера, и возвращает то же число обратно. Размер блока не менялся (2048@48к = 42.7 мс). Гипотеза про клиппинг тапа RX_AUDIO проверена замером и снята: пик 0.115. Стенд: проверки length переписаны на инвариант «байт = length × размер отсчёта»; новый test/tci/ft4_bench.py снимает поток TCI и PipeWire- источник одновременно, режет на нарезки FT4 по общим часам и гоняет через настоящий jt9 --ft4 (блок разбирает КАК MSHV — этим и поймал). Проверено вживую: MSHV декодирует FT4 по TCI. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-19 12:26:29 +03:00
ew8bakandClaude Opus 5	bb48f5d3fa	feat(tci): приёмник = слот слайса; TRX/TUNE адресуют передатчик; стенд «как MSHV» ... Модель приёмников переделана: приёмник TCI — это СЛОТ СЛАЙСА, а не панадаптер. rx0 — главный тракт (каналы A/B = VFO A/B), rx N — слайс слота N−1, то есть буквы B..G с флага, на каком бы пане он ни стоял. Панорама стала свойством приёмника: от неё берутся DDS (у слайса только чтение) и поток IQ. Почему: у Pluto панорама ровно одна (MaxPans = 1), и второй приёмник там существует ТОЛЬКО как слайс главного пана — при нумерации по панам он был недоступен вовсе, а TRX_COUNT навсегда равнялся единице. С другого конца — клиенты: у MSHV в настройках всего «TCI Client rx1/rx2», то есть приёмники 0 и 1, третьего номера ввести некуда. Со слотами правило «первый созданный слайс = приёмник 1» держится на любом железе: на openHPSDR слайс второго пана и на Pluto слайс главного одинаково занимают слот B. Номер совпадает с буквой на экране и с портом слайс-CAT. Цена: панорама без слайсов из TCI пропала, а второй слайс пана перестал быть «каналом B» и стал своим приёмником — у канала B в протоколе только частота, IF и громкость, у приёмника же всё. TRX/TUNE раньше игнорировали arg1 (номер передатчика) целиком: клиент доп. приёмника уводил в эфир слайс ОПЕРАТОРА — чужая частота, а с кросс-бандовым мультислайс-TX и чужой диапазон, с чужими антенной и фильтрами; trx:9,true жал PTT. Теперь номер разбирается и проверяется, приёмник N > 0 идёт через RequestSliceTx (та же дверь, что у CAT-порта слайса: «в эфире только один» и Auto TX), у контроллера появился параметр Tune для TUN тем же путём. Чужую передачу не трогаем вовсе — ни источник модуляции, ни тон: SetMOX(True) поверх идущей передачи не выходит рано, а заново выбирает микрофон. Хозяином эфира клиент становится, только если передача началась именно от его команды, и решает это Sync-метод в потоке контроллера (снимок «шла ли передача», взятый в потоке клиента, врал: между разбором и исполнением влезает PTT оператора). Разбор исходников MSHV (он фильтрует ВСЕ строки и бинарные блоки по номеру приёмника) дал ещё три правки: * ответ на TRX/TUNE адресуется номером АВТОРА, состояние в нём — «в эфире именно твой слайс»; в рассылку идёт номер реально передающего; * tx_enable рассылается каждому живому приёмнику со своим номером и входит в картину нового приёмника — без этого у MSHV молча мёртвая PTT (set_ptt начинается с `if (!tci_tx_enable) return;`); * про несуществующий приёмник молчим целиком (LiveRx), в том числе на чтение: ответ «vfo:1,0,0» MSHV принимал бы за конец инициализации. Попутно, вне TCI: SendDUCSpecificFromSettings трогала FNetwork без Assigned, а зовут её по любому PTT/TUN (SetMOX → SyncCWKeyer → она) — до подключения устройства это была Access violation, у TCI её глотал обработчик команды. Стенды: новый test/tci/mshv_sim.py — точная копия логики клиента MSHV, отвечает на вопрос «почему он не подключается» одной строкой (на живом приложении воспроизвёл ошибку инициализации для rx2 до правки). tcitest — 158/158, в сквозном прогоне добавлено создание слайса на главном пане: он становится приёмником 1, отвечает на vfo:1,0, слушается командой, отдаёт аудио с receiver = 1 и замолкает после удаления. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-18 22:10:02 +03:00
ew8bakandClaude Opus 5	dc6f996e70	fix(tci): дефекты живого прогона — length аудио, маршруты тапов, MOX, рекордер, EOF сокета ... Восемь дефектов, найденных прогоном настоящего TCI-клиента (три приёмника: NFM, DIGU, FMRAW) и его отчётом. 1. UI доп. панорам не перерисовывался: rfSliceState рассылался, но ветки в MainForm.OnControllerState не было (частоту несёт отдельный rfSliceFreq). 2. Stream.length у аудио — сэмплы НА КАНАЛ (§4.3), у IQ — вещественные отсчёты (§3.4: комплексных = length/channels). Было ×каналы везде, у стерео получалось вдвое больше. Развилка в TCIFillHeader + разбор TX-аудио в HandleBinary. 3+4. Дыры в маршрутах аудио движка: demod-тап звался только для DMR/FMRAW (у DIGU не было RX_AUDIO), а пост-громкостный — только для нецифровых (у FMRAW не было LINEOUT). Плюс мьют слайса больше не убивает RX_AUDIO: движку сообщают SetAudioTapsActive. 5. Клиент, поставивший TRX, уходил — MOX оставался. FTrxOwner + StopTxOf; TCIMicRequested снимается и по окончании любой передачи. 6. Гонка снятия IQ-тапа: SetIQTap(nil) возвращался раньше, чем DSP-поток выходил из вызова. FIQTapLock (порядок FSliceLock → FIQTapLock). 7. Рекордер был кольцом «последние N секунд», а §4.3 говорит про МАКСИМАЛЬНОЕ время записи с удалением по истечении. Переделан в линейный буфер с окном по часам от START. 8. TCIServer.HandleClient считал recv = 0 таймаутом: ноль — это EOF, errno при нём не трогается и несёт EAGAIN от прошлого истёкшего TCI_POLL_MS. Обычный TCP-разрыв без close-кадра не освобождал слот до остановки сервера, и после нескольких аварийных отключений новые клиенты упирались в TCI_MAX_CLIENTS. Теперь R = 0 рвёт связь безусловно, errno спрашивается только при R < 0. Попутно: MainForm.RecreateDSPEngine (смена sample rate до START) терял внутренние колбэки контроллера — введён AttachEngineCallbacks. Стенд test/tci заведён в репозиторий (run.sh, 126/126 зелёных, включая сквозной прогон через живой WDSP), доп. проверки на оба пути отключения клиента. doc/TCI.md приведена в соответствие: правило про recv = 0 в §1.1, единицы Stream.length, линейный буфер рекордера. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-18 18:10:29 +03:00