Прога начинает повторно и сразу отрубает
Имеем:
UR5EQF_Log3 последней версии, из-под него запускается через WSJTinterface - JTDX 2.0.1-rc124
Трансивер ICOM IC-7000, подключение к компьютеру через RigExpert TI-5.
OmniRig 1.16, RIG 1 :: Rig type: IC-7000v2, Port: COM3, Baud rate: 19200, 8N1, Poll int: 100 ms, Timeout: 4000 ms
Настройки:
Radio :: Rig: OmniRig 1, Tx delay: 0.1 s, PTT Method: CAT, Mode: USB, Split Operation: Fake It!
При первом "холодном" запуске (в предыдущем сеансе все параметры были выставлены, связи проводились нормально) при переходе на передачу модулирующий сигнал как будто где-то "глушится", на индикаторе трансивера - минимум, т.е. передача включается, а "полезной" модуляции нет. Если вызвать настройки, сначала дать [Test CAT], дождаться "зеленой" кдавиши, дать [Test PTT], потом его выключить - внешне ничего не меняется, но...
Движение на "водопаде" останавливается. Декодирования нет. Если закрыть JTDX, то, как и положено, WSJTinterface тоже закрывается. А вот при повторном запуске выдается сообщение, что JTDX уже запущен. Через Task manager проверяю - так и есть, "висит" неснятый процесс. Хотя все окна закрылись до этого нормально. Хорошо, снимаю JTDX (убиваю процесс). Закпускаю повторно. Не вызываю настроек, просто смотрю на работающую программу. отвечаю на интересный вызов. И - о чудо! - появляется модуляция, все сигналы проходят "как надо". Корреспондент отвечает, QSO проводится. И потом всё вроде как бы работает. И вроде как бы процесс JTDX снимается при закрытии окон.
Такие симптомы. Чем могу помочь еще для выявления ошибок?
Добрый день в 124 версии наблюдается несколько декодирований одной и той же станции не зависимо включен или выключен Hint. В 123 такого не было, может что в настройках надо поменять?
Вложение 226727
И что с того? Я ему передал 73 и декодировал его очередное CQ - мне тоже должно быть до лампочки, но я зачем-то передаю 73. Зачем? Что JTDX хочет в ответ получить?
В зависимости от быстродействия ПК и загрузки диапазона, иногда сразу, а иногда до упора.
Смотри скриншот
Троллите?
Прога получила от него РР73, передала ему первый раз 73, получила и декодировала от него следующее CQ, вывела это CQ на экран, покрасила его в цвет worked и ПОСЛЕ ЭТОГО опять передаёт 73, дожидаясь окончания декодирования остальных присутствующих в полосе.
Я вижу глазами, что это QSO безусловно состоялось, а программа сомневается.
Ну так я об этом и говорю, что необходимости внести изменения в протокол. Получил RR73, все, гуляй Вася, вноси в лог. Никаких ответных 73. QSO состоялось. Оператор, если передал Вам RR73, уже внес QSO в лог. Разумно ведь сделано HOUND моде! да и многие американцы, да и не только они, только так и работают. Поэтому, заметьте, что практически все якобы глюки, возникают на границе RR73 и 73. И все это списывать на то что компьютер не декодировал, будет не совсем правильно. Всё декодирует и декодирует, а как только RR73 то не декодирует. Так не бывает.
Такой алгоритм: на картинке первое декодирование с SNR -24, второе с SNR -04, для AutoSeq вторая частота правильная поэтому сообщение с сигнала с большим SNR будет выведено на экран независимо от опции скрытия повторов. Первое сообщение на момент декодирования второго уже было выведено на экран, поэтому как повтор первое сообщение не удаляется.
И для WSJT-X и для JTDX полезны. JTDX будет быстрее декодировать, JTDX и WSJT-X смогут более уверенно работать в условиях нескольких одновременно работающих программ либо при выделении ресурсов процессора другим задачам. Чем больше процессор имеет работающих логических ядер (физические ядра + hyper threading) тем больше программ JTDX (например для разных диапазонов или разных антенн/приемников) на нем можно использовать.