В AutoSeq0 Как передавал 73, так и передаёт ДО ПОЛНОГО ОКОНЧАНИЯ декодирования всех сигналов.
Сейчас работаем над проверкой соотвествия значений параметров INI файлов допустимому диапазону, будет в версии rc131, объем работы большой но с такой проверкой количество сбоев связанных с разрушением данных в оперативной памяти и в результате некорретными значениями в INI ощутимо сократится.
Нет, на 73 реакция программы моментальная - очищается окно DXCall (как и настроено в разделе reporting) и гаснет Enable TX(если 1QSO).
Это происходит, когда отвечаешь на CQ > обмен рапортами, RR73 от корреспондента, 73 ему от меня, далее он уже даёт новое CQ (молчит, отвечает другому), а я ему опять передаю 73. До тех пор, пока программа не закончит попытку декодирования всех кандидатов в полосе. У меня на экране корреспондент уже подсвечен, как отработанный, QSO 100% закончено, но 73 зачем-то передаётся повторно.
Вложение 229216
Я тут уже несколько раз этот вопрос поднимал, но безрезультатно. Понятно, что дело в медленном компьютере. Но в чём необходимость ждать декодирования непонятно каких сообщений в этом случае? На 73 ведь нормально реагирует.
Тоже присоединяюсь, тоже поднимал вопрос... Ответом было - другой алгоритм.
Но нельзя ли лучше вместо autoseq0 сделать autoseqWSJT, с алгоритмом полностью аналогичным по алгоритму с autoseq1 в WSJT, где нет повторных 73.
Я уверен, что многие увидев этот режим сразу перейдут на JTDX, что бы в полной мере насладиться всеми её удобствами. А если ещё сделать (вернуть (версия 34)) "ожидающий enable TX", то этот режим стал бы любимой и необходимой "фишкой" пользователей.
ну вот кто такую картину пояснить может? на одной частоте идет одновременно передача RRR и 2-х различных рапортов от UA9LL греку....Вложение 229278
да Василий есть и 4-й я просто про него не стал упоминать т.к это вполне обычное явление:s7: