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

[UA1OMZ]

В версии 18.1.0.34 в алгоритм было заложено что факт передачи сообщения RR73/73 является окончанием QSO, что не есть правильно с точки зрения корреспондента, поскольку он QSO еще не завершил при передаче оператором RR73/73 и мог это сообщение просто не декодировать.

Фактом окончания QSO в любом виде связи является подтверждение получения рапорта. В нашем случае это R00, RRR или RR73, именно после этих символов программа предлагает сохранить QSO. В версии 18.1.0.34 окончание QSO проходит очень корректно, даже уже после сохранения QSO, когда корреспондент по несколько раз передает мне RRR или RR73, желая увидеть от меня 73, программа автоматом подсовывает ему это сообщение, не сохраняя при этом QSO дважды и трижды...
Но и Ваш вариант имеет право на жизнь, вот только бы время изменения сообщения на CQ сократить немного, а то по 6 секунд иногда получается...

[UA1OMZ]

а в режиме TX=RX начинает второй раз передавать RR73, но в течении 3-5 секунд просто прекращается передача.

А вот существенного недостатка то и не заметили. При работе на поиск и при такой концовке теряется целый период приема, для меня это очень существенная потеря. Попробовал в режиме single shot qso, такая же беда.
Наверное буду опять уговаривать Вас, Игорь, сделать такую же концовку QSO, как в 34 версии.

[RX1AG]

...В случае продолжительного CQ когда Вас не зовут увеличивайте значение TX watchdog таймера в настройках закладки Settings->General.

У меня сейчас стоит версия 34 и почему-то окно TX watchdog timer не активно, просматривается установка "6 minutes". Как сделать его активным?

[UA3DJY]

У меня сейчас стоит версия 34 и почему-то окно TX watchdog timer не активно, просматривается установка "6 minutes". Как сделать его активным?

TX Watchdog таймер сделан в коде JTDX начиная с версии 18.1.0.39

[VA3LLZ]

Кто-нибудь может дать ссылку, где можно скачать JTDX 18.1.0.34?

[RC2SC]

Кто-нибудь может дать ссылку, где можно скачать JTDX 18.1.0.34?

JTDX - JTDX Release History

[UT8NT]

Доброе время суток всем.
Немного потестировал v70_5
Режим Call First. Очень похож на Auto Seg3
Тестировал в основном на CQ.
В целом работа понравилась, явных непредсказуемых "боков " не заметил.
На CQ когда от корреспондента не получаю 73, программа "считает " QSO завершенным и не "выпрашивает" 73, а становиться на СQ, по отношению к корр-ту это да, не совсем справедливо...
Не справилась программа с этим позывным:

[RZ1OA]

Фактом окончания QSO в любом виде связи является подтверждение получения рапорта. В нашем случае это R00, RRR или RR73, именно после этих символов программа предлагает сохранить QSO.

А вот тут единого подхода нет. Мода пришла с УКВ, там "кошерным" считается полный цикл связи.... Типа нужно быть уверенным, что приняли RR73. Ну и многие "не полные", с их точки зрения, связи в лог не заносят. PZ5RA, например, один из них.

[UT3IB]

Обнаружил неточность в алгоритме последней JTDX
Отработав с HC2TE, отошел на некоторое время от компьютера.
Вернувшись, озадачился свежим декодом :

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

[UA1OMZ]

А вот тут единого подхода нет. Мода пришла с УКВ, там "кошерным" считается полный цикл связи.... Типа нужно быть уверенным, что приняли RR73. Ну и многие "не полные", с их точки зрения, связи в лог не заносят. PZ5RA, например, один из них.

Согласен, но честно говоря немного выбешивает, когда тебе по несколько раз дают RRR или RR73, когда сами мою R уже зафиксировали, особенно когда в это время много "вкусного" в эфире...
Вот только одно не могу понять Игоря - почему в 34-то версии концовка некорректная???

В версии 18.1.0.34 в алгоритм было заложено что факт передачи сообщения RR73/73 является окончанием QSO, что не есть правильно с точки зрения корреспондента, поскольку он QSO еще не завершил при передаче оператором RR73/73 и мог это сообщение просто не декодировать.

Все очень даже корректно происходит и на CQ и на поиск.
Вот ничего руками не трогал, все автоматика
Не одного "НЕ ПОЛНОГО" QSO по инициативе автоматики не остается, если только сам не "саскочишь" со связи. А вот в 70_5 версия, концовочка ну скажем не очень...

[UA9FFV]

Я все повторы и QSO на дипломы отслеживаю в JTAlert. Весьма удобный инструмент.Предлагаю в меню "File" добавить пункт "Open JTAlert B4log.mdb".
Иногда приходится его править и этот пункт ускорит процесс его поиска. Строго говоря это надо делать в JTAlert. Но, на мой взгляд так удобнее. Да и надо предусмотреть похожий механизм в JTDX. В этой программе тоже надо управлять повторами.
Например, недавно сработал с АА9А. На следующий день получил LoTW подтверждение, а программа JTAlert при приеме этого позывного не выдает B4. Кажется, не было принято 73, но в QSO был уверен почти на 100 и поэтому сохранил. Программа, разумеется, не занесла позывной в базу B4.
Или другой случай. Корреспондент не записал по какой-то причине QSO. Подтверждения от него нет, а qrz.com утверждает, что он ежедневно заливается в LoTW. Тогда этот позывной надо удалить из базы.
Формат базы простой и каждый разберется. Но можно дать пользователю эти функции через дополнительное окно в котором можно было бы найти позывной и удалить его из базы или занести в базу позывной, диапазон и моду. Попутно заложить процедуру управления повторами и в JTDX.

[UA1OMZ]

В случае продолжительного CQ когда Вас не зовут увеличивайте значение TX watchdog таймера в настройках закладки Settings->General.

А почему вообще ушли от значений TX watchdog в периодах, как в 34 версии, а сделали в минутах???? Вот и появились бяки с неожиданными обрывами... Поверьте какой бы длинный TX watchdog вы бы не делали в минутах, рано или поздно он залезет к вам в интересное QSO и если не сорвет его, то сильно помешает. TX watchdog в периодах было очень практично и удобно и он никогда не залезал не то что на передачу, но и на QSO. Единственное НО, он был нерегулируемым, но это особо и не напрягало.

[RA3QH]

Я все повторы и QSO на дипломы отслеживаю в JTAlert. Весьма удобный инструмент.Предлагаю в меню "File" добавить пункт "Open JTAlert B4log.mdb".
Иногда приходится его править и этот пункт ускорит процесс его поиска. Строго говоря это надо делать в JTAlert. Но, на мой взгляд так удобнее. Да и надо предусмотреть похожий механизм в JTDX. В этой программе тоже надо управлять повторами.
Например, недавно сработал с АА9А. На следующий день получил LoTW подтверждение, а программа JTAlert при приеме этого позывного не выдает B4. Кажется, не было принято 73, но в QSO был уверен почти на 100 и поэтому сохранил. Программа, разумеется, не занесла позывной в базу B4.
Или другой случай. Корреспондент не записал по какой-то причине QSO. Подтверждения от него нет, а qrz.com утверждает, что он ежедневно заливается в LoTW. Тогда этот позывной надо удалить из базы.
Формат базы простой и каждый разберется. Но можно дать пользователю эти функции через дополнительное окно в котором можно было бы найти позывной и удалить его из базы или занести в базу позывной, диапазон и моду. Попутно заложить процедуру управления повторами и в JTDX.

так оно в принципе есть...можно поставить галочку и прога будет отвечать на В4....может я что то не понял,тогда прошу извинить....

[UA9FFV]

можно поставить галочку и прога будет отвечать на В4....

Не то чтобы не дает работать, а короче говоря, ты зовешь, а тебе в ответ B4 (связь даже уже подтверждена через LoTW, а в проге JTAlert или JTDX она не попала в базу B4). Или программа говорит B4, и ты конечно не зовешь. Хотя в журнале подтверждения нет и не предвидится (корр не зарегистрировал). В журнале эти белые пятна видны. Проверяешь по LoTW и видишь, что должно быть подтверждение. Т.е. иногда требуется коррекция лога B4.
Не разбирался с JTDX, а в JTAlert все повторы (по сути все связи) регистрируются в файле базы mdb. Его и надо править.

[UA1OMZ]

TO UA3DJY
Версия 70_5 Первый (повторяющийся) сбой - обрыв передачи во время CQ. Обрыв произошел на 47 секунде, но на 52 я смог восстановить передачу нажатием на enable TX.
До этого при таких обрывах enable TX на нажатие не реагировала.

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

Второй повторяющийся сбой, как близнец похожий на концовку, но уже в середине QSO

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

Видно, что RR73 получен и декодирован вовремя, но программа зачем-то начала передавать еще раз рапорт, правда изменив его через 3 секунды на правильное сообщение.