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

[UA3DJY]

Я не догадался сразу сохранить лог. Сейчас уже не найду.

Ситуация примерно такая - при ВЫЗОВЕ станции, работающей на CQ, если ДВА
раза она не ответила, и продолжает давать CQ - программа тут же переходит
также на CQ на этой же частоте.

Возможно сбой идет из-за включенных счетчиков в JTDX.INI, если это так то закладка Sequencing будет показывать галочки в недоступных счетчиках.

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

Сейчас код счетчиков частично сделан но управление специально оставлено недоступным(код счетчиков незакончен). Если в ранних версиях, например 18.1.0.34 или 18.0.0.133 включить счетчики и затем перейти на 18.1.0.80 то будут проблемы в работе AutoSeq. Такой сбой решается удалением файла JTDX.INI.

При использовании указанных версий вместе (по очереди) с 18.1.0.80 используйте разные INI файлы через ключ --rig-name=.

[R4GM]

не уверен. с TY7C тоже на 80, все таки удалось закончить связь. сегодня 7Q7 видел что полностью провел ЩСО с UK9AA и еще несколькими. Лог покажет

можно ли провести qso(c получением 73) со станцией работающей как FOX in dxmode если я использую версию wsjtx -которая не поддерживает режим dxmode?

[UA3DJY]

можно ли провести qso(c получением 73) со станцией работающей как FOX in dxmode если я использую версию wsjtx -которая не поддерживает режим dxmode?

Нет, более того, используя для вызова софт который не поддерживает протокол DXpedition Вы будете создавать помехи как корреспонденту которого Вы зовете так и другим операторам.

По причине использования отличающего протокола в режиме DXpedition 'лисы' (FOX) и вызывающие их операторы должны работать вне общепринятых полос FT8 частот.

[R4GM]

Нет, более того, используя для вызова софт который не поддерживает DXpedition Вы будете создавать помехи как корреспонденту которого Вы зовете так и другим операторам.

По причине использования отличающего протокола в режиме DXpedition лисы (FOX) должны работать вне общепринятых FT8 полос частот.

Спасибо Игорь....тем не менее вижу в логе 7q7ei Ty7c (экспедиции ..использующие foxmode в своей работе) позывные многих кто "сработал" с ними -работая на обычной программе

[UA3DJY]

Спасибо Игорь....тем не менее вижу в логе 7q7ei Ty7c (экспедиции ..использующие foxmode в своей работе) позывные многих кто "сработал" с ними -работая на обычной программе

Даже если угадать что 'лиса' передала завершающее QSO сообщение RR73, WSJT-X 1.8 и JTDX не поддерживают укороченную последовательность сообщений в этом режиме и не позволяют автоматически уводить частоту во время QSO ниже 1000 Гц согласно протоколу DXpedition.

[R4GM]

Даже если угадать что 'лиса' передала завершающее QSO сообщение RR73, WSJT-X 1.8 и JTDX не поддерживают укороченную последовательность сообщений в этом режиме и не позволяют автоматически уводить частоту во время QSO ниже 1000 Гц согласно протоколу DXpedition.

видимо эти экспедиции переходили иногда(временно) просто на обыкновенный вид работы?

[RN9AZ]

Здравствуйте Игорь!
Программа JTDX v18.0.80 отработала без проблем. Не считая нарушений сценария, зовущими станциями. И ещё пришлось пожертвовать качеством декодирования, поставил medium. В этой версии моё железо не поспевает, увы, идут пропуски, Пошла передача, но декодирование ещё продолжается, в режиме deep, доли секунды. Поменял на medium, проблема ушла. Тестировал в режиме FT8. Тип ЦП DualCore Intel Pentium E5300, 2*2600 MHz, Кэш L2 2 Мб. Ресурсы ПК выбраны до придела. Но ещё пока эта версия работает. Что дальше, менять железо? Или в софте обозначить для быстрых машин. С требованием к ним.

С уважением Виталий RN9AZ.

[R0JF]

Возможно сбой идет из-за включенных счетчиков в JTDX.INI, если это так то закладка Sequencing будет показывать галочки в недоступных счетчиках.

Да, действительно! Галочки стоят... ini от 79-й версии не удалял.
Попробую.

[UA3DJY]

И ещё пришлось пожертвовать качеством декодирования, поставил medium. В этой версии моё железо не поспевает, увы, идут пропуски, Пошла передача, но декодирование ещё продолжается, в режиме deep, доли секунды. Поменял на medium, проблема ушла. Тестировал в режиме FT8. Тип ЦП DualCore Intel Pentium E5300, 2*2600 MHz, Кэш L2 2 Мб. Ресурсы ПК выбраны до придела. Но ещё пока эта версия работает. Что дальше, менять железо? Или в софте обозначить для быстрых машин. С требованием к ним.

Повышение эффективности декодирования требует увеличения количества вычислений, переход с Deep на режим Medium, выключение кнопки Hint уменьшают количество вычислений.

Настройки позвляют сконфигурировать софт для разных процессоров и рецепта какую комбинацию настроек использовать для конкретного процессора нет, каждый пользователь решает для себя это самостоятельно.

Сейчас в оптимизации FT8 декодера в JTDX почти исчерпаны возможности дальнейшего повышения эффективности декодирования за счет небольшого увеличения количества вычислений, с многопотоком пока не вижу возможности сделать более плотную загрузку ядер.

Из-за оставленных протоколом 600 миллисекунд на декодирование интервала FT8 мне пришлось ряд изменений увести под кнопку SWL, поскольку подавляющее большинство используемых процессоров не успевает декодировать, по этой же причине сделана опция использования сниженных порогов выбора сигналов-кандидатов (use low thresholds). В любом случае дальше буду добиваться большей эффективности декодирования и операторы с новым железом будут получать максимум отдачи от софта.

[UA3DJY]

Да, действительно! Галочки стоят... ini от 79-й версии не удалял.
Попробую.

Эти галочки были недоступны после версии 18.1.0.34, либо с тех пор не удаляли INI, либо когда то возвращались на версию 18.1.0.34 или 18.0.0.133.

[RN1ON]

Ситуация примерно такая - при ВЫЗОВЕ станции, работающей на CQ, если ДВА
раза она не ответила, и продолжает давать CQ - программа тут же переходит также на CQ на этой же частоте.

Работал эту ночь на англоязычной версии JTDX 18.1.0.80, были подобные ситуации описанные выше,
но у меня лично всё работало штатно. Хочу отметить, что данная версия работает без каких-либо нареканий,
за что огромное спасибо!!!... (Да! 18.1.0.79 перескочил, INI не удалял).

[R3RR]

сегодня наблюдал работу 7q7ei на 18096 в режиме DX
очевидно что он работал программой WSJT...
.... такое впечатление, что некоторые пытались сработать с ним работая программой JTDX..
удивляюсь терпению 7q7ei, которому приходилось 5-7 раз отвечать этим "глухим" товарищам...

! чтобы прекратить этот безобразие
необходимо...
или сделать в программе JTDX режим DX...
или запретить работу программы JTDX вне участка FT8...
в противном случае все пользователи программы JTDX являются помехой для работы в DX участках....



сейчас он работает на 14070
сработал за 2 минуты, такой должен быть обмен

124915 Tx 2265 ~ 7Q7EI R3RR LO02

124930 6 -0.0 335 ~ RU3EQ RR73; R3RR <7Q7EI> -04

124945 Tx 337 ~ 7Q7EI R3RR R+03

125000 6 -0.1 335 ~ R3RR RR73; N0FW <7Q7EI> -10

[R0JF]

Эти галочки были недоступны после версии 18.1.0.34, либо с тех пор не удаляли INI, либо когда то возвращались на версию 18.1.0.34 или 18.0.0.133.

Нет, не возвращался...
И в 79-й все штатно работало...
Странно как-то вышло.

[RC3C]

Что дальше, менять железо ?

ответ очевиден

[UA3DJY]

сегодня наблюдал работу 7q7ei на 18096 в режиме DX
очевидно что он работал программой WSJT...
.... такое впечатление, что некоторые пытались сработать с ним работая программой JTDX..
удивляюсь терпению 7q7ei, которому приходилось 5-7 раз отвечать этим "глухим" товарищам...

! чтобы прекратить этот безобразие
необходимо...
или сделать в программе JTDX режим DX...
или запретить работу программы JTDX вне участка FT8...
в противном случае все пользователи программы JTDX являются помехой для работы в DX участках....

Сколько эмоций.. так запретите

Тоже удивляюсь, только терпению команды WSJT, когда софт предназначенный для тестирования используют для работы в DX экспедиции.

Еще интересно узнать что такое DX участки в FT8 и где Вы нашли информацию о частотном распределении FT8 DX участков.