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

[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 ставить, Так более мение.

[US-E-12]

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

Так вроде Вы сами уже разобрались. Если устанавливается оригинальная версия, то в AppData\Local\JTDX хранятся файлы необходимые для работы (ALL.txt, CALL3.TXT, wsjtx_log.adi, wsjtx.ini и др.). Это сделано для того, чтобы при ошибочном удалении программы эти файлы сохранились. В моей версии эти файлы перемещены в папку установки\bin.

[UA9OP]

Если виртуальный аудио кабель не используется то накопление задержки может быть вызвано потерей части фреймов, например если частота дискретизации звуково

Виртувльный кабель пользуется, короче все выбрасывать и обычным трансивером поьзоваться,

[R0JF]

преднамеренно сделал установку файла ALLCALL.TXT в папку \bin\data\,

Понятно. Вроде с исправлениями работает нормально.
Игорь, а больше никаких путей не меняли? Чтобы
сюрпризов не было?

Исправленная версия 17.4 для Linux amd64:

UI1 - https://cloud.mail.ru/public/6qoK/SExqwWtCv

UI3 - https://cloud.mail.ru/public/7eGd/9KRvpGAQo

Внимание! В архиве лежит дополнительно файл ALLCALL.TXT,
его надо бросить в /home/$USERNAME$/.local/share/JTDX

[UR4UM]

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

Аналогично! Вчера 1 станция с хорошим уровнем 2 раза звала JT9, декода небыло, и от одной 73 не принял...
Но на всех 17х версиях не переключало моды, а в 17.4 заработало!

[UR4UM]

Но на всех 17х версиях не переключало моды, а в 17.4 заработало!

Поспешил... заработало но иногда и не переключает...