Если к UDP порту JTDX/WSJT-X уже подключена одна программа то другая не получит к нему доступа.
Вложение 316639 Может кому пригодится
Есть. Сначала идём в закладку UDP в WSJTInterface. Включаем Rebroadcast UDP, запоминаем порт 2240. Затем открываем JTSync и идём в настройки. Меняем порт 2237 на 2240. Жмём кнопку Listen
Наблюдаю очередной глюк софта.
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
Занёс вручную в DXCALL SV2RSG/A без Grid - декодирует нормально оба позывных, до этого были <...> Но! Звал SV2RSG, а ответил SV2RSG/A программа перескочила на его частоту. Правда QSO не состоялось.
Возможно одновременно два позывных создают какой-то конфликт. Похоже и на той стороне.
Приём поганый - помехи от бесчисленных LAN на 14090
Я оба позывных вносил и с гридом и без грида и перезаписывал, когда софт просил - ситуация не менялась.
Несколько раз нажимал с введенным /А позывным иконку "Lookup".
После N-ого нажатия, шрифт в обоих окнах вдруг стал серым и декод позывного SV2RSG/A "пошел".
Это явный глюк программы.
На 14.090 сегодня связь удалась с SV2RSG.С трудом правда,но RRR получил.Во первых отвечал-его позывной в кавычках.Пришлось ему рапорт давать в ручном режиме,программа в автомате не работает.Связь в лог автоматом не пошла,опять таки заносил вручную.Используется JTDX-156.Как заметил-эти проблемы с FH в последних версиях.В FH долгое время работал с JTDX-151,там всё чётко,этих проблем не было.
Все верно, в описании протокола DXpedition WSJT-X пункт 5 четко сказано - внесите позывной корреспондента в окно DXCall. В противном случае придется ждать передачи корреспондентом стандартного сообщения чтобы программа смогла рассчитать хеш его позывного.
Не зная хеша и позывного корреспондента программа будет декодировать все специальные сообщения (два в одном) корреспондента с текстом <...> вместо позывного корреспондента.
- - - Добавлено - - -
Попробуйте включить запись диагностики в файл ALL.TXT, из нее должно быть видно что было не так в последовательности сообщений и конфигурации настроек.
На этом примере хорошо видно ошибки: UA6HBM занес в окно DX Call позывной без дроби и по этой причине не сможет провести QSO, потому что программа которую он использует вычислила хеш для позывного без дроби, а в специальном сообщении передается хеш составного позывного с дробью. В результате UA6HBM будет декодировать <...> во всех сообщениях где есть позывной SV2RSG/A.Цитата:
С вызывающими та же история
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
Остальные операторы в этом примере верно внесли позывной в окно DX Call.
На этой картинке видно что оператор SV2RSG/A во время работы в эфире зачем то меняет свой позывной с дробного на домашний..(интересно какой это софт так чудит, может WSJT-X 2.5.1 ?) что скорее всего и приводит к хаосу в режиме DXpedition Fox/Hound:
Вложение 316690
На картинке специальное сообщение передано с позывным SV2RSG/A, остальные стандартные сообщения были переданы с позывным SV2RSG.