Comments 8
Отличная работа! Интересно, пробовали ли вы моделировать поведение канала уже на уровне протоколов?
LEO-траектория даёт предсказуемые RTT-скачки, и современные контроллеры перегрузки (BBR/GCC) реагируют на них не всегда корректно. Сейчас много обсуждают адаптацию транспортного слоя для таких спутников.
При использовании приёмников прямого преобразования, к коим относится AD936x, на котором построен PlutoSDR, для приёма узкополосных сигналов рекомендуется работать на низкой ПЧ, что позволяет избавиться от фликер-шума и постоянной составляющей.
Низкую ПЧ удобно делать 1/4 от частоты дискретизации, тогда NCO вырождается в перестановку и/или смену знака квадратурных составляющих, потому что значения sin/cos будут [-1, 0, 1].
Для случая целевой ЧД=96 кГц удобно взять ЧД трансивера = 384 кГц и номинал ПЧ 96 кГц.
К сожалению практическая минимальная частота дискретизации Pluto равна 521 кГц
Непосредственно Pluto у меня нет, но вот кусочек точно рабочего профиля, загружаемого в AD9364, выходная частота дискретизации 288 кГц.
{884736000, 13824000, 4608000, 2304000, 1152000, 288000}, // tx_path_clks[6]
200000 // tx_bandwidth
В Pluto стоит AD9363, я думаю, что выпускают всегда AD9361, если один из каналов бракованный, то прошивается как AD9364, а если ещё и по частотам не тянет, то как AD9363.
Ну и 1/4 это просто для удобства, можно любую другую взять.
Вообще egui самый экономный по части потребления ресурсов из всех gui крейтов, точно менее прожорлив чем таури. И кстати егуи код отлично генерится по промпту, ежели уж использовать ИИ то для этого, потому как мало кто любит ручками гуи писать
1) На Rust есть очень не плохая FurureSDR
2) Тащить WSJT-X с пробросом аудио такое себе. FT4/FT8 библиотеки доступны и вполне могут работать прямо внутри Pluto (ибо там ARM и Linux) принимая IQ поток через IIO.
73 de R1CBU
Самописный SDR для спутника RS44