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

**RX4HX** · 09.12.2020, 20:35

Сообщение от UA3DJY

JTDX v2.2.0-rc154, для замены проблемной версии rc153.

Игорь приветствую!
Вот эта проблема устранена?

Сообщение от RX4HX

если при проведении связи самому нажать на кнопочку "73", то передача прерывается примерно на 2-й секунде цикла. Если кнопочку не нажимать, то все ок!

**UT7EV** · 09.12.2020, 21:01

Всем спасибо за помощь.Нашел папку.Тупо всю удалил.По новому установил все работает.Да сам бы в жизнь не докумекал.С омни надолго завязую чур меня чур

**DL9NO** · 09.12.2020, 21:06

Сообщение от UA3DJY

JTDX 2.2.0-rc153, измененный функционал:[SPOILER][LEFT]
где Windows XP&Vista не поддерживаются
Сборка под Windows XP возможно будет завтра.

я так понял что пока не будет или???

**UA3DJY** · 09.12.2020, 22:33

Сообщение от RX4HX

если при проведении связи самому нажать на кнопочку "73", то передача прерывается примерно на 2-й секунде цикла. Если кнопочку не нажимать, то все ок! В файлах все нормально пишет.

Опция записи диагностики в файл ALL.TXT, диагностика нам подскажет по какой причине отключается передача.

- - - Добавлено - - -

Сообщение от UT7EV

Нашел папку.Тупо всю удалил.По новому установил все работает.

Всю не надо - в ней Ваш лог находится, достаточно переименовать файл JTDX.ini при выключенной программе.

- - - Добавлено - - -

Сообщение от DL9NO

я так понял что пока не будет или???

Сборка JTDX rc154 под Windows XP а также сборки для Mac уже доступны на английском сайте JTDX.

**RN9AZ** · 09.12.2020, 23:41

To UA3DJY

Игорь. Спасибо. Время держит железно. Декодирование настроил, приемливое для меня. Три потока на программу работают, один на нужды ПК. В скрин задержка при декодировании 52 станций на сороковке. Меня вполне устраивает. Буду рыть дальше.

->Скрытый текст<-

**R0JF** · 10.12.2020, 00:55

Сообщение от UA3DJY

JTDX v2.2.0-rc154, для замены проблемной версии rc153.

Linux Ubuntu 20.04 32-bit audio version:

https://cloud.mail.ru/public/3r4z/4RZ6RXNtQ
SHA256: 0b9ed5459ad3a3a75d2c056535b43241481d3f24b020278b02f762df097a4d3b

Остальные соберу сегодня после работы.

**R0JF** · 10.12.2020, 11:34

JTDX 2.2.0-rc154 Linux version from original source files by Igor UA3DJY (Many Thanks him):

Коллеги, изменился URL 32-х бит Аудио версии для Ubuntu 20.04! SHA256 тот же.

->Скрытый текст<-

**UA3DJY** · 10.12.2020, 14:20

Сообщение от RX4HX

Вот эта проблема устранена?

Сообщение от RX4HX

если при проведении связи самому нажать на кнопочку "73", то передача прерывается примерно на 2-й секунде цикла. Если кнопочку не нажимать, то все ок!

Используете двойной запуск декодера, в результате получается большая задержка окончания декодирования. Появляется желание вручную скорректировать работу алгоритма автопоследовательности чтобы не было поздней смены сообщения R+рапорт на 73. Но у Вас включено автоматическое внесение в лог и в сочетании с АвтоВыбор3 при большой задержке окончания декодирования ручной выбор сообщения 73 ломает работу алгоритма автопоследовательности.

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

Если есть необходимость вручную выбирать сообщения Tx1-Tx5 то сначала отключаем автопоследовательность кнопкой АвтоВыбор, затем выбираем необходимое сообщение.

По результатам анализа лога пробуем немного улучшить алгоритм.

Возможно такой стиль работы Вам больше подойдет: для мониторинга диапазона используете кнопку SWL c подобранным количеством запусков декодера, при проведении QSO эту кнопку отключаете, сводя к минимуму задержку окончания декодирования во время QSO использованием одиночного запуска декодера и может быть минимальной чувствительности в широкой полосе.

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

**RM1F** · 10.12.2020, 15:46

Сообщение от UA3DJY

JTDX v2.2.0-rc154, для замены проблемной версии rc153. ........ В этой сборке Hamlib есть патч для Yaesu, возможно сбой CAT FT-950 уйдет.

К сожалению нет. Снова откатился на проверенную 152.

Название: 2.jpg
Просмотров: 756

Размер: 17.6 Кб

**RX3ASP** · 10.12.2020, 16:11

Сообщение от UA3DJY

Возможно такой стиль работы Вам больше подойдет: для мониторинга диапазона используете кнопку SWL c подобранным количеством запусков декодера, при проведении QSO эту кнопку отключаете, сводя к минимуму задержку окончания декодирования во время QSO использованием одиночного запуска декодера и может быть минимальной чувствительности в широкой полосе.
На приемной частоте QSO всегда применяются низкие пороги, поэтому при проведении QSO использовать низкие пороги в широкой полосе обычно смысла нет.

Нельзя ли сделать немного наоборот - для более уверенного окончания QSO: На частоте QSO добавить возможность выбора количества запусков декодера 1-2-3. Может быть только при включении RX Фильтра?
Или на частоте QSO включено по умолчанию 3х кратное декодирование?

Часто бывает, что сигнал теряется, но после ручного включения SWL х3+RX Filter и повторного декодирования, данные выводятся. Но уже поздно - период потерян.

**UA3DJY** · 10.12.2020, 16:50

Сообщение от RM1F

К сожалению нет. Снова откатился на проверенную 152.

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

- - - Добавлено - - -

Сообщение от RX3ASP

Нельзя ли сделать немного наоборот - для более уверенного окончания QSO: На частоте QSO добавить возможность выбора количества запусков декодера 1-2-3. Может быть только при включении RX Фильтра?
Или на частоте QSO включено по умолчанию 3х кратное декодирование?

Часто бывает, что сигнал теряется, но после ручного включения SWL х3+RX Filter и повторного декодирования, данные выводятся. Но уже поздно - период потерян.

Повторные запуски декодера сделаны для широкой полосы. Можно было бы сфокусироваться на DT корреспондента, но основная проблема в другом: декодирование и вычитание мешающих сигналов. Эти сигналы не всегда на приемной частоте QSO, и часто декодирование напоминает разгадывание кроссворда, где к сигналу корреспондента можно подобраться лишь последовательно декодировав и вычтя два..три других накладывающихся спектром сигнала, один из которых пересекается с сигналом корреспондента. То есть требуется декодирование в достаточно широкой полосе, в результате увеличение времени декодирования.

**RX3ASP** · 10.12.2020, 16:54

Сообщение от UA3DJY

То есть требуется декодирование в достаточно широкой полосе, в результате увеличение времени декодирования.

Но, при включенном фильтре, полоса узкая. Или, даже в этом случае, "требуется декодирование в достаточно широкой полосе"?

**UA3DJY** · 10.12.2020, 18:10

Сообщение от RX3ASP

Но, при включенном фильтре, полоса узкая. Или, даже в этом случае, "требуется декодирование в достаточно широкой полосе"?

Включение фильтра частот по списку кандидатов уже приводит к потере декодирования на приемной частоте в части интервалов, та же причина разгадывания кроссворда.

В этом отношении прореживание списка кандидатов наносит меньше ущерба чем использование фильтра JTDX.

- - - Добавлено - - -

Сообщение от UA3DJY

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

Для пользователей у кого сбоит CAT Hamlib c трансиверами Yaesu, сборка JTDX rc154-win64 сделана на основе Hamlib commit 7a93ce3

собранный софт(win64) https://cloud.mail.ru/public/2CEJ/3TC2hLUXY
кодовая сумма JTDX-2.2.0-rc154_Yaesu_patch-win64.exe
SHA-256: FBC1FBB4D0705C6EAF4994D70E0E56FAD56788ADD3B0E0BF65980EF66242E8E7

Изменения в коде Hamlib можно посмотреть здесь.

**RX3ASP** · 10.12.2020, 19:31

Сообщение от UA3DJY

Включение фильтра частот по списку кандидатов уже приводит к потере декодирования на приемной частоте в части интервалов, та же причина разгадывания кроссворда.

Понятно. Несколько раз обращал на это внимание, когда с SWL без фильтра декодировал, а с фильтром через раз, но подумал, что случайность.