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

[UA3DJY]

кажется что JTDX при хорошей силе сигнала, не может декодить...

Если поймаете такой сильный сигнал что декодирует WSJT-X и не декодирует JTDX, покажите пожалуйста звуковой файл - устраним.

[UA3DJY]

Запустил одновременно обе программы от одной и той же звуковой карты. Рапорты и количество декодов отличаются в пользу WSJTX

В JTDX SNR был калиброван еще для FT8v1, в WSJT-X - нет.
Минутное дело добавить в коде JTDX смещение рапортов на 1 дБ, сразу появится много положительных отзывов о росте чувствительности на основании выводимого на экран рапорта .

[RA3QH]

это уже не в первый раз V 115

Наблюдал такое и в последней американской программе.

Про это уже не раз писали тут...эта комбинация показывает что позывной не был еще ни разу не декодирован вашей программой

[UA3DJY]

Одновременно с UA4PAY позвал UY5MU.
Прога ответила первому, в соотв. с настройкой (max distance).
Прошло QSO. Вызывает UY5MU с рапортом. Вместо ответного рапорта RR-?? прога дала RR73.
QSO logged. UY5MU отвечает RR73 и вроде бы QSO состоялось, но формально нет: я рапорт не передавал.
До этого такого ни разу не встречал.

115-я - таже картина на 160м звали два японца и оба рапортом. С первым QSO нормально, второму сразу начала давать RR73. Пришлось "втыкать" вручную" то что положено. Дальше сама "добивала".

Дефект, был в JTDX 18.1.106 и более ранних версиях. Патч есть в 2.0.1-rc117, нам проверить сейчас нечем - придется Вам смотреть в эфире ушел ли этот сбой.

[UA3DJY]

А вот кто подскажет? JTDX. Режим "AutoTX". Устанавливаю фильтр на Европу, ну или какой другой. Естественно в окне в декодированном тексте сообщений от европейцев нет, а вот вызов "европейца" прога распознает и отвечает вызывающему.
Т.е весь эффект фильтрации в том, что я не вижу часть "все-таки декодированных" сообщений?
Или фильтр отменяет таки декод этих станций?

Описание функционала фильтрации сообщений в JTDX: https://ru.jtdx.tech/ru-faq/26-filte...-v18-1-russian

[UA3DJY]

вопрос - какое максимальное отклонение времени допустимо по протоколу этого вида связи ?

В разных программах поддерживается разный диапазон времени захвата синхропоследовательности сигнала FT8.
Например в WSJT-X этот диапазон находится в пределах от -1.5 до + 2.5 секунды.
Синхропоследовательность состоит из трех одинаковых блоков по 7 тонов каждый(массив Костаса), занимает 1..7-й, 37..43-й, 73..79-й тона передаваемой последовательности сигнала.

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

Синхропоследовательности FT8v2 и FT8v1 в указанных блоках отличаются настолько что декодер FT8v2 не будет пытаться декодировать сигнал FT8v1 и наоборот.

[R7CA]

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

А вот скажите... ФТ8 один раз передаёт сообщение или несколько? В jt65 вроде несколько раз..
И что в начале сообщения мы так боимся пропустить когда передача идёт с задержкой

[UA3DJY]

Вот это мне не очень понятно - хэш, да, может совпадать для разных позывных - позывные очень короткие, вот и хэш совпадает. Но то, что это приводит к ложному декодированию... весьма удивительно.
Допустим для позывных RX4HX и UA3ALE хэш может быть одинаковый, и если программа приняла UA3?LE и хэш, она должна по хэшу восстановить позывной UA3ALE (часть то принято!), но уж никак не RX4HX.
Или WSJT-X/JTDX вообще целиком позывные по хэшу восстанавливает? Типа хешь есть, значит это или UA3ALE, или RX4HX.

Целиком, при использовании в QSO одного нестандартного позывного вместо одно из позывных сообщения в эфир передается вычисленный хэш этого сообщения. Сообщение с двумя нестандартными позывными не поддерживается протоколом FT8v2, чтобы операторы с дробными или специальными позывными провели между собой QSO им придется очень постараться печатая свободные сообщения.

Сценарий который встретил Виталий UA3ALE - он проводил QSO с таким специальным позывным и декодировал сообщение RR73, но софт поискав в оперативной памяти соответствие хэш нашел недавно бывший в эфире позывной R2AE хэш которого совпадает с хэшем позывного UA3ALE.
В результате декодер выдал сообщение R2AE S511NNN RR73 которое AutoSeq у Виталия явно не ожидал после получения рапорта от корреспондента.

Ассоциацию позывного с хэшем в версии протокола FT8v2 в WSJT-X перенесли в модуль упаковки/распаковки сообщений, при этом не сделали проверку на наличие позывного корреспондента с окна DX Call в этом сообщении, факта проведения QSO с этим позывным и в этом случае приоритет проверки принятого хэша с позывным пользователя программы. Результат налицо, сейчас чтобы в JTDX устранить такое поведение программы придется дублировать сравнение хэша для уже распакованного сообщения с неправильным позывным с позывным пользователя и при выполненнии указанных выше критериев подменять неправильно распакованный позывной позывным пользователя.

[UA3DJY]

А вот скажите... ФТ8 один раз передаёт сообщение или несколько? В jt65 вроде несколько раз..
И что в начале сообщения мы так боимся пропустить когда передача идёт с задержкой

На пальцах: сообщение представляет из себя кусок информации. Этот кусок нарезается на мелкие кусочки которые определенным образом перемешиваются и компонуются в передаваемые информационные тона так что каждый информационный тон содержит кусочек каждого слова в передаваемом текстовом сообщении.
Когда передача включается с задержкой по отношению к началу интервала то часть тонов не передается(теряется) но при этом оставшиеся тона содержат кусочки слов текстового сообщения и при определенном их количестве это сообщение можно восстановить из оставшихся тонов.

То есть сообщение передается один раз и при этом много раз одновременно.

Чем ниже SNR сигнала тем меньше оставшихся тонов принимается без ошибок, соответственно тем ниже вероятность восстановления сообщения. Поэтому при начале передачи вместе с началом интервала будет наилучшая синхронизация декодера с принимаемым сигналом (первые 7 тонов - 1.12 секунды относятся к синхропоследовательности сигнала, далее идут и при задержке начала передачи теряются информационные тона).

[RX3ASP]

После обмена рапортами в JTDX получаю от корреспондента RR73, записываю QSO в LOG (или автоматом), передаю 73, перехожу на приём.
Сигнал моего корреспондента - новое CQ или ответ другому, УЖЕ декодирован и выведен на экран!
Но программа ждёт окончание цикла декодирования всех сигналов в полосе. Только после этого очищается DX Call и сбрасывается Enable TX.
Зачем ждать окончания декодирования в этом случае? Если декодирования нет, тогда другое дело. В этом случае правильно было бы отключить Enable TX, но оставить DX Call - для принятия решения оператором.
На не очень шустрых компьютерах этот процесс тянется долгие секунды. В это время включается передача повторного 73 и перебивает корреспонденту возможность принять ответ другого.
При декодировании обычного 73, программа реагирует мгновенно.

[UA3DJY]

UA3DJY
Игорь, в описании ограничений для FT-8 77 bit есть ограничения на работу не "стандартных" корреспондентов, будет ли возможен обмен в JTDX между собой двух таких "нестандартных" корреспондентов, (CALL/IMAGE) ведь к этому не стандартному мэсэджу CALL/IMAGE присоединяется массив данных?

Массив данных(сама картинка) идет через Интернет, возможность такого QSO зависит от текста сообщений которые должны быть переданы/выведены с декодирования в окнах программы WSJT-X/JTDX. Необходим пример текста такого QSO между двумя корреспондентами.

[RK1AT]

возможность такого QSO

Игорь, всё работает штатно, пока ограничений никаких нет, паника была преждевременной, спасибо за 77 бит, желаю удачи и с Наступающим Новым Годом.

[RV3DBK]

Добрый вечер, коллеги!

В версиях 1.104 и в 2.0.1-rc115 столкнулся с непредсказуемым поведением RX курсора - после завершения процесса декодирования он перемещается в другое место. В настройках checkbox "Monitor returns to last used frequency" не выбран (пустой). Как справиться с этим?

Виктор

[UA3DJY]

В версиях 1.104 и в 2.0.1-rc115 столкнулся с непредсказуемым поведением RX курсора - после завершения процесса декодирования он перемещается в другое место. В настройках checkbox "Monitor returns to last used frequency" не выбран (пустой). Как справиться с этим?

Частота берется с истории QSO для последнего позывного. Если в окно DX Call вносить позывной через двойной щелчок левой клавишей мыши на декодированном сообщении то RX частота будет соответствовать этому позывному, то есть не будет прыгать на когда то ранее внесенный позывной. Позывной можно вычистить одновременно с окна DX Call и истории QSO правой клавишей мыши на кнопке Clear DX основного окна интерфейса.

С какой целью вбиваете позывной в окно DX Call вручную?

[UY7VY]

Добрый день.
Подскажите про назначение "кнопок" Нound, S meter (вроде не активна) и DXpedition.