В прошлом году на виндовс ХР , sdr 1361 уверено ловил на квадрофилярную спутники NOAA DDE tracker уверено подхватывал доплеровское смещение , но Метеор -2 мой старый пентиум 4 не тянул , зависал. В этом году собрал комп на 4-х ядерном amd ryzen поставил sdr sharp 1765 , orbitron 3.71 . плагины dde tracking .demodulator meteor , прописал связи . В режиме симуляции в шарп приходит информация о доплеровском сдвиге частот и по мере движения спутника она меняется , но как только я нажимаю клавишу пуск шарп виснет и спектр водопада как бы стекает вниз.. может дело в net framework но у меня стоит 4.6 и 4.8 . почему нет никаких логов , где искать причину зависания? кто подскажет стабильную версию шарпа и плагинов для записи метеора -2

Крайняя сборка шарпа - крайне не стабильная! Откатился на 1732.

Спасибо комрад ! 1732 решила проблемы и сразу вопрос метеор м 2 дохлый ?Орбитрон рассчитал что он пройдет в зените , шарп подхватил но сигнала нет на 137.1000

TLE обновить, а по статусу спутника можно в соседних ветках спросить.

При запуске одновременно двух Airspy или двух RTL в режиме сканирования и записи обратил внимание, что на одном приемнике запись без искажений все мягко, а на втором появляются трески при старте записи и при громких звуках. Может кто с подобным уже встречался и знает в чем причина?

Вот нашел описание подобной проблемы с треском и щелчками при использовании виртуального кабеля. Но я не использую виртуальный кабель, а проявляется на втором устройстве записи sdr#. Видимо также связано с переполнением буфера, но где его искать в WIN10?
https://forums-radioreference-com.translate.goog/threads/unitrunker-trunking-recorder-using-vac-distorted-audio.468268/?_x_tr_sl=en&_x_tr_tl=ru&_x_tr_hl=ru&_x_tr_pto=wapp
Из руководства VAC:

Аудиосигнал, проходящий через виртуальный кабель, искажается.

Искажение сигнала (искажение, треск, треск, статические щелчки и т. д.) обычно возникают из-за проблем с буферизацией в аудиоприложениях, System Audio Engine или самом драйвере VAC, если длины/размера буфера, используемого для передачи аудиоданных, недостаточно для компенсации приложения. и/или задержки обработки системы. В частности, это связано с нереальной природой системы Windows, и особенно ее ядра.

Прежде всего, проверьте, подходит ли ваша система для потоковой передачи звука в реальном времени . Для достижения стабильной потоковой передачи все времена буферизации должны быть в 1,5–2 раза больше, чем самая длинная внутренняя задержка. Например, если LatencyMon показывает внутренние системные задержки 20 мс, стабильную потоковую передачу звука можно будет получить только при длине буферизации 30–40 мс или больше. Но это может не решить проблему, поскольку System Audio Engine обычно использует буферы длительностью 10–30 мс для связи с аудиодрайверами. Если задержки происходят в коде режима ядра, нет смысла увеличивать буферы приложения.

С такой проблемой не сталкивался именно на нескольких свистках, разве что на древних компах на одном, но попробовал бы драйвер ASIO4ALL, в котором можно регулировать время задержки/буферизации прямо из иконки в трее. В аудио устройствах назначить его.
Когда писал музло в проге FL Studio, при большом использовании аудио плагинов, появлялся треск, решалось именно увеличением буфера в этом драйвере.

Спасибо попробую! Комп не древний, при запуске 2 Airspy + 2 RTL загрузка процессора около 20%, оперативки свободно больше 20Gb.

Что значит приоритет реального времени? Может с высокого на него изменить в диспетчере задач все связанное с аудио?

Можно попробовать изменить приоритет самого шарпа с реального времени на высокий этой строчкой <add key="processPriority" value="256" /> на 128.
И уменьшить Resolution во вкладке FFT.

Можно попробовать изменить приоритет самого шарпа с реального времени на высокий
Вчера в диспетчер заходил посмотреть приоритеты. Так он на шарпах и стоял высокий, а не реальный.

От версии наверно зависит, хотя у меня все реального времени. Игры с этими параметрами у меня слабо влияли на хрип на стареньких компах.

Изменение приоритета поможет только если процессор загружен другими фоновыми задачами на 100%. Если загрузка меньше 100% или других задач нет, то изменение приоритета ни на что не повлияет.
Если 2 AirSpy R2 (примерно то же, что и HackRF на 16Msps) подключены через хаб в один порт, то нормально работать они не будут. Если 2 AirSpy HF, то зависит от хаба. На некоторых (без MTT) будут проблемы.
2 RTL в одном хабе работают нормально.

Вроде звуковой буфер прямо в шарпе регулируется на закладке аудио. И семпл-рейт тоже где-то (может в конфиге).
Ну и тип вывода аудио можно разный перепробовать, т.е. мме, асио, вдм...

Переключил с ММЕ на Windows Direct Sound.
Задержка стояла 100ms хотя стандартно должно быть 50ms, а в инструкции рекомендуется и вовсе поставить 2ms на SDR#1783 и выше (у меня SDR#1700), у меня повисло на 2ms, на 10ms запускается. Пока поставил стандартную 50ms.
Посмотрим в таком варианте.

Остановился на 150ms. Треск пропал.
Тут понятным языком разжевано, что такое размер буфера или задержка аудио сигнала.