HI ES1JA
OK, у меня "RC6" нету, говорю только за "RC7"
HI ES1JA
OK, у меня "RC6" нету, говорю только за "RC7"
Правило " Скрывать сообщения от позывных "
Полагал, что правило " Скрывать сообщения от позывных " работает независимо то настроек в " Уведомления "
Но по ходу это не так.
Для понимания как я это себе представляю.
Занимаюсь Challenge_DXCC_FT
Да бы отсечь подтверждённое в LOTW и не нужное.
1. Из основного лога я делаю выборку QSO подтверждённых в LOTW и загружаю в JTDX.(wsjtx_log.adi)
2. Но если корреспондент тупо клянчит деньги за подтверждение своей территории в LOTW
То на кой мне тогда видеть его в приёмном окне допустим как Новая DXCC. Это моё сугубо личное мнение !
Подобная ситуация с Анголой, т.к. часто крутится в эфире.
Arvo спасибо за ответ.
Спрошу трохи по другому.
Вложение 361723
Это правило " Скрывать сообщения от позывных " привязано к файлу wsjtx_log.adi ?
Вложение 361724
Приветствую Всех! Нужен совет знатоков WSJT...
Обычно использую программу JTDX,а тут решил попробывать WSJT 2.7.1 и столкнулся с проблемой.
После CQ - отвечает станция, но моя программа "не замечает" её и опять начинает давать CQ и так может до бесконечности.
Если же по позывному вызывающей станции - "мышкой", то дальшейшая часть QSO проходит в штатном режиме.
Подскажите, где "засада"? :)
Вложение 361805
В этой проге так заложено
вроде всё Удачи.
Кнопка "Автовыбор" у меня была включена. Решение проблемы:
По-умолчанию, на кнопке было включено "CQ:None" и надо было переключить в положение "CQ:First"
На скрине все видно:
Вложение 361828
Не обязательно First. Можно выбрать Max dB (у многих именно так). Или Max Dist...
Такой вопрос. программа jtdx-160-rc7 derivative . Когда мне дают рапорт то мой позывной,а когда рр73 то UW5EQM вместо моего
я бы не знал,пока мне из Турции корреспонент не прислал письмо на мыло с вопросом,типа зачем я снова его зову,если он мне рр73 передал и таких заходов было 4!!!!
сейчас дал мне рапорт 3da0dl с моим позывным а рр73 не увидел,снова зову,опять рапорт а 73 нет,3й раз зову,такая же ситуация. стал смотреть что он давал и снова этот UW5EQM и рр73
20241021_220500 -2 0.4 1699 ~ UA3GX TC101TC +00
20241021_220515.040(0) Transmitting 7.074 MHz + 1249Hz FT8: TC101TC UA3GX R-02
20241021_220530 -5 0.1 1700 ~ UW5EQM TC101TC RR73
Может так декодер козлит? Попробуй ALLCALL7.txt обновить. Брать тут: https://sourceforge.net/projects/jtd...0.zip/download
Looks like UA3GX and UW5EQM have same shorter hash value (not checked this), but from where UW5EQM gets into jtdx-s internal hash table is question (he should be also active same time there) and in general there no good solution at all, ft8 global current long (not standard) callsign support has this problem. We need to think about it, which callsign to show when hash table has a conflict with mycall. Currently You get wrong RR73. Other way is that You get RR73 to You not even called long callsign. Not so easy to explain.
Похоже, что UA3GX и UW5EQM имеют одинаковое более короткое хэш-значение (это не проверялось), но откуда UW5EQM попадает во внутреннюю хеш-таблицу jtdx-s, это вопрос (он также должен быть активен там в одно и то же время), и в целом хорошего решения вообще нет, Глобальная поддержка длинных (не стандартных) позывных ft8 имеет эту проблему. Нам нужно подумать о том, какой позывной показывать, когда хеш-таблица конфликтует с mycall. В настоящее время вы ошибаетесь в RR73. Другой способ заключается в том, что вы получаете RR73, даже не называя длинный позывной. Не так-то просто объяснить.