JTDX v18.1.0.78 _ AutoSeq2
По окончании QSO прога гасит кнопку ТХ, но включается передача и даётся CQ...?
Было 2 раза, почти подряд... норма или баг? :confused:
P.S. - Второй "выстрел", на другом бенде, опции те же:
JTDX v18.1.0.78 _ AutoSeq2
По окончании QSO прога гасит кнопку ТХ, но включается передача и даётся CQ...?
Было 2 раза, почти подряд... норма или баг? :confused:
P.S. - Второй "выстрел", на другом бенде, опции те же:
У Вас декодирование JT65 заканчивается вплоть до десятой секунды интервала передачи, может быть в этом проблема?
В закладке Advanced попробуйте поставить number of decoding attempts 1, и если будет продолжать выходить декодированием в интервал передачи number of decoding passes 3 или 2.
При использовании сообщения RR73 иногда бывают сбои в коде причину которых пока не смогли поймать, вариант RRR+73 работает без сбоев.
Ни разу не получилось чтобы при работе на CQ после окончания QSO программа сама начала давать CQ. Всегда выключает передачу и нужно мышкой нажимать EnableTx. Ставил Settings галки в разных сочетаниях. AutoSeq3. Было бы неплохо иметь режим типа Single shot QSO, то только на CQ.
Есть старый компютер:Intel(R)CPU
1000 MHZ 256 МБ ОЗУ
JT-65 работает
FT-8 не могу установить
При установке пишет: Ошибка при инициализации(0xc000001d)
Windoys XP
Помогите !
2 RT4W
Лучше и не заморачиваться.
Меняйте комп.
В последних версиях JTDX (0.78 не пробовал) при переключении программы RX → TX, отсчёт времени TX начался, но трансивер переключается на передачу через ≈ > 1 секунды. Управление через АСС2 разъём. Вернулся к версии 0.34, проблема с задержкой исчезла. Может кто подскажет какие настройки в новых версиях могут отвечать за это.
посмотрите какая выставлена задержка на TX в программе
Трансивер переключается в ТХ сразу, но сигнал начинает поступать с задержкой, которая зависит от задержки декодирования.
FT8 threads поставьте в "1", немножко поможет, но время декодирования увеличится.
Либо переведите декодирование в "medium" или " fast", но потеряете слабые сигналы.
Либо держите фильтр включенным, но замучаетесь работать с любителями "split".
Дело не в TX delay. Старые ядра!
У кого нет суперкомпьютера, могут идти в..., как говаривал про миллиард г-н Полонский. На CQ перехожу иногда в WSJT, но там других проблем хватает.
Да, Игорь проблема в этом.
Эти настройки уменьшают время декодирования принятых сигналов.
Я думаю, что в данном случае причина была именно из-за того, что.Цитата:
декодирование JT65 заканчивается вплоть до десятой секунды интервала передачи
Но такого декодирования в более ранних версиях не было. Вчера на диапазоне одновременно находилось более 10-ти станций. Я нашел в ALL.TXT похожий вариант, но там все отрабатывалось нормально:
А вчера было так:
Почему так получилось - не понятно.
Сегодня было максимум до 9-ти станций одновременно. Но декод заканчивался до 58-й сек. Автомат работал корректно.
Какой-то прямой зависимости между количеством декодированных сигналов и периодом декодирования я не увидел. Вот пример для 5-ти сигналов:
В одном случае интервал декодирования заканчивался на 56-й сек., а во втором на 59-й ....
Зависит от характера шума - если шум Гауссовский то ложных кандидатов почти нет и декодирование идет быстро, если есть разрядный шум или кто то имеет грязный сигнал, или есть искажения в приемном тракте то количество кандидатов на декодирование резко возрастает и растет время потраченное на декодирование.
Количество JT65 кандидатов можно принудительно уменьшать сужая полосу частот на водопаде и устанавливая верхнюю границу декодирования JT65 сигналов в закладке Advanced: нет смысла искать JT65 сигналы на тех частотах где их нет.
Может быть проблема в поломанном файле JTDX.INI, попробуйте его удалить. Также могут к задержке приводить неисправности железа, драйвера, использование звукового устройства в операционке по умолчанию и даже настройки BIOS, например при разгоне процессора может сбоить оперативная память.
Интересно, в какое время суток на радиолюбительских диапазонах наблюдается Гауссовский шум.
https://ru.wikipedia.org/wiki/%D0%90...88%D1%83%D0%BC
Похоже в то время когда отсутствует прохождение.
И именно в это время декодирование самое быстрое.
Или как то не так?