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

[UA3DJY]

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

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

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

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

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

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

[RX3ASP]

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

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

[UA3DJY]

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

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

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

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

Сегодня был еще один патч в 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]

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

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

[RM1F]

JTDX-2.2.0-rc154_Yaesu_patch-win64.exe.......

Увы, пока желаемого результата нет. Ошибка Hamlib ровно такая же, как в посте #25979

[UA3DJY]

Увы, пока желаемого результата нет. Ошибка Hamlib ровно такая же, как в посте #25979

Пора ставить диагностику и задействовать разработчиков Hamlib.

Сборка с диагностикой CAT Hamlib, пишет два лога:

в папке %TEMP%, имя файла JTDX_trace.log
в папке где находится лог связей JTDX, имя файла JTDX_trace.log

Оба лога пожалуйста отправьте мне на почту c_igor inbox ru

собранный софт(win64) https://cloud.mail.ru/public/3sz7/3crJdr2KH
кодовая сумма JTDX-2.2.0-rc154_CAT_debug-win64.exe
SHA-256: 3574F361A3B80E5D5B9F1A4135B667B62DE5C203719D4AC6C7967B41D12D2AFB

PS пришло сообщение что последнее обновление Hamlib в rc154_Yaesu_patch починило CAT c FTDX101

[R2PU]

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

Плохо что больше не проходит , именно в таком "полуручном" режиме было сработано (и подтверждено!) около 10% из wanted DXCC\CQ zones\US States.
Человек он много на что способен : например заранее подведя указатель мыши к следующему в последовательности макросу "клацнуть кнопкой" отправив правильное ответное сообщение , это занимает не более 0,1 сек.

Вообще у нас в запасе изрядно времени на смену макроса (скрины старых экспериментов не нашёл , пришлось делать по новой).
Вот запоздалая реакция оператора "на ходу" меняющего макрос (то самое "полуручное" управление):

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

Видно, да - у нас "в запасе" 6 (!!!) секунд на "жмакнуть правильный макрос"

А вот так сказать наиболее приближённое к реальной ситуёвине в DXинге : запоздалый ответ "автомата" не тем макросом (вследствии большой задержки окончания декодирования) + ещё и запоздалая реакция оператора в полуручном режиме сменившего макрос:

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

Видно , да - умнющий софт на приёмной стороне декодирует вплоть до 4х секунд (!!!) задержки (3 секунды на Lag на передающей стороне +1 секунда на неторопливого оператора там же).

Помехи (не сказать хаос) будут как раз в варианте: "автопоследовательность не отработала - оператор моментально жмёт нужный макрос -но софт упорно блокирует передачу - и упустивший DXа оператор победив наконец софт видит что его Tx частоту уже тем временем заняли - и в попытках ещё раз дозваться DXа начинает таскать свой TX маркер по всему водопаду сея помехи и хаос"
Но никак не в варианте : "оператор в разумном интервале помог автопоследовательности быстро и вменяемо отработать QSO".

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

Сомнительный вариант , у меня на втором скрине добавилась как раз таки секунда из-за необходимости "таскать указатель мыши" по кнопкам Enable Tx - Tx2 нажимая их в необходимой последовательности. upd: И выбирал то в итоге не то (надо было Tx3 , но с этими "молниеносными тасканиями указателя мыши по кнопкам" жал на Tx2 , только сейчас заметил)
В то время как при работе в реальном эфире "жмакнуть" по нужному макросу (если указатель мыши уже заранее подведён к нему) занимает не более 0,1 сек. upd: возможность ошибки в выборе при этом многократно снижается (см первый скрин).
Усложняем и удлиняем минимально необходимое действие - сеем дополнительные помехи и хаос на бэндах (их и так там хватает).

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

Мда , если на максимальных то настройках декодирования вожделенный DX декодируется "на грани" , то для проведения QSO совсем не айс ухудшать декодирование вообще никак и не насколько .
К хорошему привыкаешь быстро (поэтому я например бил аларм прямо в теме когда с переходом на FT8v2 в JTDX перестал давать результат функционал подпрохода) , от каждой новой версии ждёшь : "ещё лучше , ещё злее - чтобы вытаскивало доселе невытаскиваемое и давало возможность отработать заведомо гиблое QSO" , а тут теперь вона как : "робот главнее человека" + уменьшить количество запусков декодера + проредить список кандидатов на декодирование (чёт мне сильно не по себе от мысли что софт "под эту гребёнку" проредит вдруг и меганужное).

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

С привычкой некоторых DX "прыгать" на частоту зовущего , или пропав на пару циклов вдруг обьявиться на другой частоте , да нередкой ситуёвиной : "долго и безуспешно зовём одного редчайшего DX , да вдруг в совершенно другом месте водопада возникает другой редчайший DX" - смысл декодировать по максимуму и во всей полосе есть всегда.

[Vic3q]

Добрый день, подскажите по проблеме TX/RX IC-746Pro wid 7 -64 после установки.ошибка Hamlib откатить ни на какую версию не удаётся начиная с 147 до 152, вернул WSJX, то же самое,заранее благодарен

[UA3DJY]

Исправил ошибку в описании алгоритма автоматического выбора количества потоков FT8 декодера начиная с JTDX rc153:

количество логических ядер процессора/количество потоков в декодере
1 / 1
2..4 / (количество логических ядер процессора)-1
5..8 / (количество логических ядер процессора)-2
9..15 / (количество логических ядер процессора)-3
>15 / 12

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

Добрый день, подскажите по проблеме TX/RX IC-746Pro wid 7 -64 после установки.ошибка Hamlib откатить ни на какую версию не удаётся начиная с 147 до 152, вернул WSJX, то же самое,заранее благодарен

В деталях сообщения есть описание ошибки, покажите пожалуйста эту картинку.

[RX4HX]

Плохо что больше не проходит , именно в таком "полуручном" режиме было сработано (и подтверждено!) около 10% из wanted DXCC\CQ zones\US States.
Человек он много на что способен : например заранее подведя указатель мыши к следующему в последовательности макросу "клацнуть кнопкой" отправив правильное ответное сообщение , это занимает не более 0,1 сек.

+100500!
Причем хочу выделить слово больше! Раньше то с этим все было ок!

[UA3DJY]

+100500!
Причем хочу выделить слово больше! Раньше то с этим все было ок!

Разница может быть при внесении QSO в лог по приглашению и при автоматическом внесении QSO в лог:

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

В любом случае мы алгоритм в этой части не меняли по крайней мере по сравнению с rc152.

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

Добрый день, подскажите по проблеме TX/RX IC-746Pro wid 7 -64 после установки.ошибка Hamlib откатить ни на какую версию не удаётся начиная с 147 до 152, вернул WSJX, то же самое,заранее благодарен

Немного деталей по вопросу Виктора UA3QJJ:

работал jtdx v152, появилась v154 скачал .установил, пропала catsistem?
пишет ошибка hamlib ввода вывода, и в mix, частота настройки меняется.на передачу не переходит
и после перезагрузки диапазон переключать перестала, может сможете проконсультировать,заранее благодарен

IC-746PRO если включаю JTDX, то пропадает Cat MixW, перезапускаю MixW работает

Коллеги, если кто нибудь использует JTDX/WSJT-X и MixW, подскажите пожалуйста по тонкостям конфигурации COM портов в таком сочетании и порядку запуска используемых в этой связке программ.

[UA1NAN]

Коллеги, если кто нибудь использует JTDX/WSJT-X и MixW, подскажите пожалуйста по тонкостям конфигурации COM портов в таком сочетании и порядку запуска используемых в этой связке программ.

Запускаю программы через JTalert:



Com порт под трансивер сконфигурирован в HamRadioDeluxe, все работает. Windows 10 LTSC 64.

[UA3WBW]

В то время как при работе в реальном эфире "жмакнуть" по нужному макросу (если указатель мыши уже заранее подведён к нему) занимает не более 0,1 сек.

Полностью поддерживаю, сам так часто делаю. Программа не должна за меня решать. Если я нажал 73!, значит должно улететь 73!, а не остановиться передача. Надеюсь это будет доработано.
А вообще программа отличная, спасибо!

[RX4CD]

В то время как при работе в реальном эфире "жмакнуть" по нужному макросу (если указатель мыши уже заранее подведён к нему) занимает не более 0,1 сек.

Никогда не работал в "полуручном" режиме. Всегда, с самого освоения FT8, работал в полуавтомате - выбираю позывной сам, все остальное - программа. Вношу связь в лог сам. Считаю, что в "полуручном" режиме так используется не полные возможности программы. Зачем делать шаг назад, если можно идти вперед? А если, в нужный момент, вас отвлекли от монитора или зазвонил телефон, или ...что-то еще помешало. Что тогда? Ждать следующий цикл? Тем самым затягивая связь и отнимая время у других. Или попал мышкой не в тот макросс - это еще хуже. Считаю, что этот вариант, с ручным выбором макроссов, надо убрать вообще. Или сделать, чтобы они появлялись из отдельной вкладки в "Настройках". Результат - меньше ошибок будет, отсюда - меньше мешать друг другу будем. Ну, если понадобиться какому-нибудь "динозавру" такой "полуручной" режим, то включит.

[UA9AOH]

Здравствуйте дорогие форумчане! При работе в jtdx появляется сообщение: invalid floating point operation, какая запятая плавает? Подскажите, что не так? Спасибо, ua9aoh.