проект WSJT-X: моды JT65,JT9,WSPR,JT4,JTMS,MSHV - работа с тестовым софтом

[UA3DJY]

Выскакивает это окно, жмём OK и всё горит Decode и нет декодирования. После копирования полного CALL.TXT всё нормально работает.

все верно, без этого файла софт не может работать

[RN9AZ]

Жаль но похоже придётся откатится на старую версию. Одно ядро 2.7ггц похоже ужо не тянет. Провёл одно QSO на втором дал 73 ответ не декодируется. И пошло то включится декодирование то через раз. уменьшил адванцед, до 2 4 толку нет. Хоть JT65 или JT9 без разницы. Отключаю передачу кадр прошёл второй молчком, постоит только в режиме приёма, вроде опять начинает декодировать. Декодирует конечно не плохо. Хотя на моих тестовых файлах один в один, что и прежние версии. И плюс Игорь ваши файлы как раньше по десять янков декодируют.

[EW6BN]

Если проблема останется на версии 17.4 то для воспроизведения необходим Ваш INI файл записанный при использовании WSPR, и выключении софта до момента сбоя (при сбое конфигурация в INI не сохраняется).

Проблема также может быть связана с работой CAT и с работой на передачу WSPR, можно попробовать поменять варианты CAT Hamlib/OmniRig.

Игорь, СПАСИБО! Не знаю что Вы сделали, но в 17.4 вылеты в WSPR прекратились, всё теперь заработало. Это было не связано с CAT, т.к. вылет происхдил при попытке начала деколирования, а не при переходе на передачу.

[UT2XL]

Выскакивает это окно, жмём OK и всё горит Decode и нет декодирования. После копирования полного CALL.TXT всё нормально работает.

Олег посмотрите мою переписку с поста 3677 по 3686 по этому вопросу, может у Вас появятся идеи.

[UA3DJY]

Игорь, в чем может проблема....при запущенных программах сдр, лог ....jtdx DT начинает ползти, доходит до 5 но декод проходит, перепробовал все с временем связанный программы одно и тоже...когда на чистый трансивер было то все нормально, сдр что ли влияет....что то можно сделать?

Если виртуальный аудио кабель не используется то накопление задержки может быть вызвано потерей части фреймов, например если частота дискретизации звукового потока немного смещается относительно частоты процессора компьютера - может где железо неисправно (USB звуковая карта), или СДР греется и убегает опорный генератор, так трудно сказать.

[UT2XL]

Провёл одно QSO на втором дал 73 ответ не декодируется.

Тоже было - дважды станция давала окончание связи - не декодировалось, мода JT9. CQ, рапорт декодировался нормально а окончание нет. Сигнал отличный -08.

[UA3DJY]

Игорь, СПАСИБО! Не знаю что Вы сделали, но в 17.4 вылеты в WSPR прекратились, всё теперь заработало. Это было не связано с CAT, т.к. вылет происхдил при попытке начала деколирования, а не при переходе на передачу.

Софт стал очень сложным и вполне где то я мог сделать ошибку в коде приводящую к утечке памяти, от версии к версии исходный код очень сильно изменяется и часто переписывается заново, поэтому если есть утечки памяти то они на разных версиях и разных машинах могут сказываться по разному и с разными симптомами.

[UA3DJY]

Тоже было - дважды станция давала окончание связи - не декодировалось, мода JT9. CQ, рапорт декодировался нормально а окончание нет. Сигнал отличный -08.

Обычно JT9 не декодируется если плывет частота или есть наложение спектра другой станции. Девиация частоты при отражении сигнала от сполохов Северного сияния тоже не позволяет декодировать JT9 сигнал.

Если в интервале был очень сильный сигнал от другой станции то перепад шума не дает декодировать сигналы, в этом случае спасает функционал компенсации АРУ - кнопка AGCc,
последовательность нажатия кнопок AGCc -> Decode позволит повторно декодировать интервал уже с включенным функционалом компенсации действия АРУ приемника.

Примерно полтора года назад у меня на WSJT-X тоже была проблема декодирования части JT9 сигналов и тогда она была вызвана поломанным INI файлом, в этом случае Ваш звуковой файл должен декодироваться на другом компьютере.

[UA3DJY]

Жаль но похоже придётся откатится на старую версию. Одно ядро 2.7ггц похоже ужо не тянет. Провёл одно QSO на втором дал 73 ответ не декодируется. И пошло то включится декодирование то через раз. уменьшил адванцед, до 2 4 толку нет. Хоть JT65 или JT9 без разницы. Отключаю передачу кадр прошёл второй молчком, постоит только в режиме приёма, вроде опять начинает декодировать. Декодирует конечно не плохо. Хотя на моих тестовых файлах один в один, что и прежние версии. И плюс Игорь ваши файлы как раньше по десять янков декодируют.

Похоже на выпадание фреймов в звуковом потоке - должно быть заметно по сжатию основного сигнала на водопаде и расширению продолжительности шума во временной области (видно при проигрывании разных звуковых файлов). Последнее время было несколько репортов что такая проблема возникает если какой то другой софт занимает ресурсы процессора во время записи звукового файла, на протяжении приемного интервала, никак не связано с самим декодированием, в этом случае на декодирование уже считывается битый звуковой файл.

[EW6BN]

Софт стал очень сложным и вполне где то я мог сделать ошибку в коде приводящую к утечке памяти, от версии к версии исходный код очень сильно изменяется и часто переписывается заново, поэтому если есть утечки памяти то они на разных версиях и разных машинах могут сказываться по разному и с разными симптомами.

Понятно, но слава Богу, что она устранилась в 17.4, просто часто мониторю ночью 630м WSPR-2, теперь нет необходимости в дополнительном софте, ну разве что для WSPR-15.
Железо здесь MiniPC на Intel I5 6300U, RAM 8GB, интересно, что 17.4 в режиме 3-4-1 стала на 2 сек быстрее декодировать чем 17.3.2, раньше конец декодирования был ровно в 60 сек, сейчас на 58 сек.

[UA3DJY]

Железо здесь MiniPC на Intel I5 6300U, RAM 8GB, интересно, что 17.4 в режиме 3-4-1 стала на 2 сек быстрее декодировать чем 17.3.2, раньше конец декодирования был ровно в 60 сек, сейчас на 58 сек.

Да, тоже интересно, для поддержки повторного декодирования JT9 я был вынужден добавить два огромных промежуточных массива для временного хранения входного сигнала после его обработки функционалом компенсации АРУ, и наоборот ожидал возрастания времени декодирования, о чем мне говорили во время тестирования 17.4.

[EW6BN]

Да, тоже интересно,

Действительно интересно, возможно оптимизировалась загрузка по ядрам при обработке, сейчас вообще обратил внимание, что при увеличении количества станций окончание стало на 56-57й секунде

[UA3DJY]

Действительно интересно, возможно оптимизировалась загрузка по ядрам при обработке, сейчас вообще обратил внимание, что при увеличении количества станций окончание стало на 56-57й секунде

Забыл сказать, я сильно метелил код Фортрана под многопоток, переводя статические переменные-массивы в динамические. Скорее всего в этом причина.

Сделал не всё что хотел, вернее сделал почти всё но откатил часть изменений обратно, потому что стало немного падать количество декодированных сообщений на тестовых файлах.

В версии 17.5 продолжу эту работу одновременно с выводом массивов хранения сигналов из стек памяти, чтобы уйти от возможного влияния выполняемого кода на обрабатываемые данные.

Еще во время тестирования софта заметил что при компенсации работы АРУ (включена кнопка AGCc) ощутимо снижается время декодирования интервала.

[RK6C]

Поставил 17.4. Кнопка Decode продолжает светится вплоть до 35 секунды следующего интервала. В 17.3.2 декодировка длилась до 58 сек текущего интервала. i3 3225 3.3 Ghz 4G ОЗУ.

[RN9AZ]

Похоже на выпадание фреймов в звуковом потоке - должно быть заметно по сжатию основного сигнала на водопаде и расширению продолжительности шума во временной области (видно при проигрывании разных звуковых файлов). Последнее время было несколько репортов что такая проблема возникает если какой то другой софт занимает ресурсы процессора во время записи звукового файла, на протяжении приемного интервала, никак не связано с самим декодированием, в этом случае на декодирование уже считывается битый звуковой файл.

Спасибо Игорь. Сладил с систему, но всё равно, ПК, программа грузить стала больше, твои установки, 3 4 1 идут со скрипом. Пришлось 2 4 1 ставить, Так более мение.