Игорь приветствую!Цитата:
Сообщение от UA3DJY
Вот эта проблема устранена?
Цитата:
Сообщение от RX4HX
Игорь приветствую!Цитата:
Сообщение от UA3DJY
Вот эта проблема устранена?
Цитата:
Сообщение от RX4HX
Всем спасибо за помощь.Нашел папку.Тупо всю удалил.По новому установил все работает.Да сам бы в жизнь не докумекал.С омни надолго завязую чур меня чур:)
я так понял что пока не будет или???Цитата:
Сообщение от UA3DJY
Опция записи диагностики в файл ALL.TXT, диагностика нам подскажет по какой причине отключается передача.Цитата:
Сообщение от RX4HX
- - - Добавлено - - -
Всю не надо - в ней Ваш лог находится, достаточно переименовать файл JTDX.ini при выключенной программе.Цитата:
Сообщение от UT7EV
- - - Добавлено - - -
Сборка JTDX rc154 под Windows XP а также сборки для Mac уже доступны на английском сайте JTDX.Цитата:
Сообщение от DL9NO
To UA3DJY
Игорь. Спасибо. Время держит железно. Декодирование настроил, приемливое для меня. Три потока на программу работают, один на нужды ПК. В скрин задержка при декодировании 52 станций на сороковке. Меня вполне устраивает. Буду рыть дальше.
Linux Ubuntu 20.04 32-bit audio version:Цитата:
Сообщение от UA3DJY
https://cloud.mail.ru/public/3r4z/4RZ6RXNtQ
SHA256: 0b9ed5459ad3a3a75d2c056535b43241481d3f24b020278b02f762df097a4d3b
Остальные соберу сегодня после работы.
JTDX 2.2.0-rc154 Linux version from original source files by Igor UA3DJY (Many Thanks him):
Коллеги, изменился URL 32-х бит Аудио версии для Ubuntu 20.04! SHA256 тот же.
Используете двойной запуск декодера, в результате получается большая задержка окончания декодирования. Появляется желание вручную скорректировать работу алгоритма автопоследовательности чтобы не было поздней смены сообщения R+рапорт на 73. Но у Вас включено автоматическое внесение в лог и в сочетании с АвтоВыбор3 при большой задержке окончания декодирования ручной выбор сообщения 73 ломает работу алгоритма автопоследовательности.Цитата:
Сообщение от RX4HX
Попытка схитрить на полуручном управлении получая больше от декодера не проходит, более того, поскольку человек не способен в рамках отведенного на декодирование FT8 сигналов времени успеть выбрать правильное ответное сообщение, то попытка ручного и даже полуручного управления приводит к созданию дополнительных помех на диапазоне.
Если есть необходимость вручную выбирать сообщения Tx1-Tx5 то сначала отключаем автопоследовательность кнопкой АвтоВыбор, затем выбираем необходимое сообщение.
По результатам анализа лога пробуем немного улучшить алгоритм.
Возможно такой стиль работы Вам больше подойдет: для мониторинга диапазона используете кнопку SWL c подобранным количеством запусков декодера, при проведении QSO эту кнопку отключаете, сводя к минимуму задержку окончания декодирования во время QSO использованием одиночного запуска декодера и может быть минимальной чувствительности в широкой полосе.
На приемной частоте QSO всегда применяются низкие пороги, поэтому при проведении QSO использовать низкие пороги в широкой полосе обычно смысла нет.
К сожалению нет. Снова откатился на проверенную 152.Цитата:
Сообщение от UA3DJY
Вложение 285971
Нельзя ли сделать немного наоборот - для более уверенного окончания QSO: На частоте QSO добавить возможность выбора количества запусков декодера 1-2-3. Может быть только при включении RX Фильтра?Цитата:
Сообщение от UA3DJY
Или на частоте QSO включено по умолчанию 3х кратное декодирование?
Часто бывает, что сигнал теряется, но после ручного включения SWL х3+RX Filter и повторного декодирования, данные выводятся. Но уже поздно - период потерян.
Сегодня был еще один патч в Hamlib для свежих моделей Yaesu, сделаю с ним сборку win64, опубликую линк на форуме.Цитата:
Сообщение от RM1F
- - - Добавлено - - -
Повторные запуски декодера сделаны для широкой полосы. Можно было бы сфокусироваться на DT корреспондента, но основная проблема в другом: декодирование и вычитание мешающих сигналов. Эти сигналы не всегда на приемной частоте QSO, и часто декодирование напоминает разгадывание кроссворда, где к сигналу корреспондента можно подобраться лишь последовательно декодировав и вычтя два..три других накладывающихся спектром сигнала, один из которых пересекается с сигналом корреспондента. То есть требуется декодирование в достаточно широкой полосе, в результате увеличение времени декодирования.Цитата:
Сообщение от RX3ASP
Но, при включенном фильтре, полоса узкая. Или, даже в этом случае, "требуется декодирование в достаточно широкой полосе"?Цитата:
Сообщение от UA3DJY
Включение фильтра частот по списку кандидатов уже приводит к потере декодирования на приемной частоте в части интервалов, та же причина разгадывания кроссворда.Цитата:
Сообщение от RX3ASP
В этом отношении прореживание списка кандидатов наносит меньше ущерба чем использование фильтра JTDX.
- - - Добавлено - - -
Для пользователей у кого сбоит CAT Hamlib c трансиверами Yaesu, сборка JTDX rc154-win64 сделана на основе Hamlib commit 7a93ce3Цитата:
Сообщение от UA3DJY
собранный софт(win64) https://cloud.mail.ru/public/2CEJ/3TC2hLUXY
кодовая сумма JTDX-2.2.0-rc154_Yaesu_patch-win64.exe
SHA-256: FBC1FBB4D0705C6EAF4994D70E0E56FAD56788ADD3B0E0BF65980EF66242E8E7
Изменения в коде Hamlib можно посмотреть здесь.
Понятно. Несколько раз обращал на это внимание, когда с SWL без фильтра декодировал, а с фильтром через раз, но подумал, что случайность.Цитата:
Сообщение от UA3DJY
Увы, пока желаемого результата нет. Ошибка Hamlib ровно такая же, как в посте #25979Цитата:
Сообщение от UA3DJY