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

[UA3DJY]

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

Если к UDP порту JTDX/WSJT-X уже подключена одна программа то другая не получит к нему доступа.

[UY7VY]

Если к UDP порту JTDX/WSJT-X уже подключена одна программа то другая не получит к нему доступа.

А если возможность как то их троих подружить, или только по одной или лог или время?

[RW4WZ]

Есть информация что у одного пользователя после установки этого драйвера был поломан реестр Windows: даже после удаления ASIO драйвера операционная система не может найти USB Aудио кодек в подключенном IC7300.

Операционка Windows 10 64 бит, с установленным USB-ASIO Qt в JTDX не видит звуковое устройство на передачу.

Дополнение: установка этого драйвера создает дополнительный USB концентратор в устройствах операционной системы, удаление драйвера не удаляет USB концентратор, последний пришлось удалить вручную в диспетчере устройств и после перезагрузки операционной системы поддержка USB Аудио кодека трансивера ICOM IC7300 операционной системой восстановилась. Увы, более чем два человеко-часа на ветер..

Может кому пригодится

[US-E-12]

JTDX "подвязан" у логу UR5EQF через WSJTInterface там же и WSJT. Попробовал запускать JTSync

А если возможность как то их троих подружить

Есть. Сначала идём в закладку UDP в WSJTInterface. Включаем Rebroadcast UDP, запоминаем порт 2240. Затем открываем JTSync и идём в настройки. Меняем порт 2237 на 2240. Жмём кнопку Listen

->Скрытый текст<-

[UY7VY]

Есть. Сначала идём в закладку UDP в WSJTInterface. Включаем Rebroadcast UDP, запоминаем порт 2240. Затем открываем JTSync и идём в настройки. Меняем порт 2237 на 2240. Жмём кнопку Listen

->Скрытый текст<-

Спасибо буду пробовать, эти настройки останутся на постоянно или каждый раз при включении надо прописывать?

[US5WE]

Наблюдаю очередной глюк софта.
SV2RSG/A 14090 F/H
SV2RSG декодируется нормально, а вместо SV2RSG/A вижу <...>
074700 -4 0.7 263 ~ JH3AIU <...> RR73
074700 -4 0.7 263 ~ JA6VQA <...> -10
074700 -2 0.7 203 ~ JE6KYA <...> RR73
074700 -2 0.7 203 ~ JA5DNJ <...> -12
Оба позывных SV2RSG KN20 и SV2RSG/A KN20 введены в call3.txt.
За день до этого оба позывных на 40 метрах декодировались нормально!
JTDX v2.2.0-rc155 32bit под Ubuntu 16.04
Перезагрузка программы и компа ситуацию не меняет.
Страна нужна на 160 метрах, поэтому хочется знать, что нужно сделать с этим глюком.

- - - Добавлено - - -
С вызывающими та же история
083045 -14 0.5 1426 ~ <...> TM6M IN78 •France
083045 -7 0.6 1500 ~ <...> R7NA LN07 •EU Russia
083045 -13 0.8 1303 ~ SV2RSG UA6HBM LN14 *EU Russia
083045 -14 0.6 1575 ~ <...> UT1US KO50

[RX3ASP]

Занёс вручную в DXCALL SV2RSG/A без Grid - декодирует нормально оба позывных, до этого были <...> Но! Звал SV2RSG, а ответил SV2RSG/A программа перескочила на его частоту. Правда QSO не состоялось.
Возможно одновременно два позывных создают какой-то конфликт. Похоже и на той стороне.
Приём поганый - помехи от бесчисленных LAN на 14090

[US5WE]

Занёс вручную в DXCALL SV2RSG/A без Grid - декодирует нормально оба позывных, до этого были <...> Но! Звал SV2RSG, а ответил SV2RSG/A программа перескочила на его частоту. Правда QSO не состоялось.
Возможно одновременно два позывных создают какой-то конфликт. Похоже и на той стороне.
Приём поганый - помехи от бесчисленных LAN на 14090

Я оба позывных вносил и с гридом и без грида и перезаписывал, когда софт просил - ситуация не менялась.
Несколько раз нажимал с введенным /А позывным иконку "Lookup".
После N-ого нажатия, шрифт в обоих окнах вдруг стал серым и декод позывного SV2RSG/A "пошел".
Это явный глюк программы.

[RX3ASP]

Это явный глюк программы.

Возможно. Однако несколько раз перезапускал 155 Win 64. Вначале /А не декодирует. После ввода в DX Call SV2RSG/A (просто ввод, без Add и Lookup) сразу начинает писать правильно в т.ч. и в сообщениях вызывающих. В CALL3 ничего не прописывал.

[US4IRT]

SV2RSG/A "пошел".

А не пират ли это? Если нет, то смотришь и в ЛОТВ эта страна появится.

[UA3GJM]

Я оба позывных вносил и с гридом и без грида и перезаписывал, когда софт просил - ситуация не менялась.
Несколько раз нажимал с введенным /А позывным иконку "Lookup".
После N-ого нажатия, шрифт в обоих окнах вдруг стал серым и декод позывного SV2RSG/A "пошел".
Это явный глюк программы.

На 14.090 сегодня связь удалась с SV2RSG.С трудом правда,но RRR получил.Во первых отвечал-его позывной в кавычках.Пришлось ему рапорт давать в ручном режиме,программа в автомате не работает.Связь в лог автоматом не пошла,опять таки заносил вручную.Используется JTDX-156.Как заметил-эти проблемы с FH в последних версиях.В FH долгое время работал с JTDX-151,там всё чётко,этих проблем не было.

[US5WE]

Возможно. Однако несколько раз перезапускал 155 Win 64. Вначале /А не декодирует. После ввода в DX Call SV2RSG/A (просто ввод, без Add и Lookup) сразу начинает писать правильно в т.ч. и в сообщениях вызывающих. В CALL3 ничего не прописывал.

Cпасибо, я сделал подборку трюков, о которых ребята писали, надеюсь хоть один пригодится.

[UA3DJY]

Возможно. Однако несколько раз перезапускал 155 Win 64. Вначале /А не декодирует. После ввода в DX Call SV2RSG/A (просто ввод, без Add и Lookup) сразу начинает писать правильно в т.ч. и в сообщениях вызывающих. В CALL3 ничего не прописывал.

Все верно, в описании протокола DXpedition WSJT-X пункт 5 четко сказано - внесите позывной корреспондента в окно DXCall. В противном случае придется ждать передачи корреспондентом стандартного сообщения чтобы программа смогла рассчитать хеш его позывного.

Не зная хеша и позывного корреспондента программа будет декодировать все специальные сообщения (два в одном) корреспондента с текстом <...> вместо позывного корреспондента.

- - - Добавлено - - -

На 14.090 сегодня связь удалась с SV2RSG.С трудом правда,но RRR получил.Во первых отвечал-его позывной в кавычках.Пришлось ему рапорт давать в ручном режиме,программа в автомате не работает.Связь в лог автоматом не пошла,опять таки заносил вручную.Используется JTDX-156.Как заметил-эти проблемы с FH в последних версиях.В FH долгое время работал с JTDX-151,там всё чётко,этих проблем не было.

Попробуйте включить запись диагностики в файл ALL.TXT, из нее должно быть видно что было не так в последовательности сообщений и конфигурации настроек.

[US5WE]

Все верно, в описании протокола DXpedition WSJT-X пункт 5 четко сказано - внесите позывной корреспондента в окно DXCall. В противном случае придется ждать передачи корреспондентом стандартного сообщения чтобы программа смогла рассчитать хеш его позывного.

Не зная хеша и позывного корреспондента программа будет декодировать все специальные сообщения (два в одном) корреспондента с текстом <...> вместо позывного корреспондента.[

Проблема в том, что я вносил позывной корреспондента в окно DXCall, но ничего не происходило.
Add Call тоже не помогал, но трюки запомнил.

[UA3DJY]

Проблема в том, что я вносил позывной корреспондента в окно DXCall, но ничего не происходило.
Add Call тоже не помогал, но трюки запомнил.

С вызывающими та же история
083045 -14 0.5 1426 ~ <...> TM6M IN78 •France
083045 -7 0.6 1500 ~ <...> R7NA LN07 •EU Russia
083045 -13 0.8 1303 ~ SV2RSG UA6HBM LN14 *EU Russia
083045 -14 0.6 1575 ~ <...> UT1US KO50

На этом примере хорошо видно ошибки: UA6HBM занес в окно DX Call позывной без дроби и по этой причине не сможет провести QSO, потому что программа которую он использует вычислила хеш для позывного без дроби, а в специальном сообщении передается хеш составного позывного с дробью. В результате UA6HBM будет декодировать <...> во всех сообщениях где есть позывной SV2RSG/A.

Остальные операторы в этом примере верно внесли позывной в окно DX Call.

На этой картинке видно что оператор SV2RSG/A во время работы в эфире зачем то меняет свой позывной с дробного на домашний..(интересно какой это софт так чудит, может WSJT-X 2.5.1 ?) что скорее всего и приводит к хаосу в режиме DXpedition Fox/Hound:

На картинке специальное сообщение передано с позывным SV2RSG/A, остальные стандартные сообщения были переданы с позывным SV2RSG.