:offtopic:
Это все Windows Defender в 10ке
Не смог у себя воспроизвести в паре JTDX<->WSJT-X:
Воспроизвел зацикливание в связке JTDX<->JTDX, в сценарии когда корреспондент вручную выбрал сообщение для вызова R+рапорт. После этого у корреспондента зацикливается AutoSeq.
Пока не знаю сможем ли сделать защиту от таких действий корреспондента, и нет гарантии что корреспондент не начнет QSO с передачи сообщения '73' после чего несколько интервалов будет наблюдать за происходящим :)
А может не надо и далее усложнять "протоколы связи"?
Как бы оператор должен быть главным лицом в этом действии.
А может "робот"???
Тогда пора смартфон подключать.
Что не сделает "робот" в эфире, то исправит смартфон в интернете?
Следующий шаг - на какой хрен нужен эфир?
Недурно бы понять на каком шаге "роботизации" должны завершиться.
С Новым Годом.
В последние дни получил несколько вопросов о разном формировании в окне Tx1 сообщения для вызова нестандартного позывного из JTDX по сравнению с WSJT-X:
JTDX: "<DF2019ARDF> UA3DJY KO85"
WSJT-X: "<DF2019ARDF> UA3DJY"
Сделал запрос о совместимости с WSJT-X и получил от команды WSJT ответ что сообщение "<DF2019ARDF> UA3DJY KO85" поддерживается протоколом FT8v2 и декодируется в WSJT-X правильно.
В текущей версии WSJT-X передача такого сообщения поддерживается с окна Tx5.
Сделали защиту от такого действия оператора
Сбой происходил при смене оператором вручную сообщения с Grid на рапорт или R+рапорт, то есть когда в одном интервале для вызова оператор передавал два разных сообщения.
Начиная с JTDX 2.0.1-rc122 связка JTDX<->JTDX не будет зацикливаться.
Про это уже писали ----- ответ"Сколько мне разрешено столько и выдаю " а потом появляются вопросы:confused:
Вот то же не Вложение 225838как не мог отвязаться