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

**RX4HX** · 17.04.2019, 09:50

Сообщение от R6LCF

не слышат/видят с большей разницей в частотах из за каких то "местных" причин.

Тут вполне может быть, что на той частоте, на которой Вы его вызывали была другая станция, которую Вы могли и не слышать, а декоду она помешала. Сам неоднократно такое наблюдал - зовешь на одной частоте - не отвечает, сместился (не обязательно на частоту станции), получаешь рапорт +5

**K2PAL** · 17.04.2019, 13:33

Сообщение от UA3DJY

Либо конфликт настроек в логе N1MM (JTDX так же как и WSJT-X посылает UDP сообщение QSO Logged), можно попробовать снять галочку Enable WSJT/JTAlert, либо 'антивирус' блокирует TCP пакеты.

Игорь,
Я сегодня все пробовал и как админ и вирус закрывал, хоть убей, JTDX не работает,а WSJT без проблем.
Может кто-то может у себя проверить, для убедительности или у меня проблемма.
Спасибо

**ER3KS** · 17.04.2019, 14:52

LOGHX3.265 и JTDX134, после очистки DX, кнопкой, в LOGHX окно ввода QSO не очищается и другие другие позывные не заносятся. С JTDX127 такого нет. Сейчас установил JTDX135, такой же глюк.

**R2PU** · 17.04.2019, 16:55

Сообщение от UA3DJY

JTDX v2.0.1-rc135 измененный функционал:
- в FT8S декодере должен применяться порог чувствительности 'низкая'('low') в той части последовательности сообщений QSO где возможен ответ корреспондента другому оператору

99% времени работаю практически на "максимальных" настройках по декодированию .
Ложные декоды бывают , но оператор то на что .... некритично.

Игорь , я правильно понимаю что функционал rc135 в некоторых случаях принудительно занижает порог чувствительности декодера FT8S на low - даже если у меня в настройках стоит high ?

Не очень пока понимаю что происходит - но работа в реальном эфире создаёт местами нехорошее впечатление что rc135 местами уступает rc134 по декодированию (при том что прогоны тестовых пакетов этого не подтверждают) - не могу пока отловить в чём дело , во мне или всё таки в софте ...

**RQ3M** · 17.04.2019, 17:20

А для чего надо удалять старый ини файл ? Я что каких то ништяков лишаюсь ?

**RX3ASP** · 17.04.2019, 17:31

Сообщение от R2PU

Не очень пока понимаю что происходит - но работа в реальном эфире создаёт местами нехорошее впечатление что rc135 местами уступает rc134 по декодированию (при том что прогоны тестовых пакетов этого не подтверждают) - не могу пока отловить в чём дело , во мне или всё таки в софте ...

Тоже такое ощущение есть. Например, когда начинаю звать того, кто даёт рапорт другому, JTDX 135 часто пропускает декодирование, хотя на водопаде что-то шевелится. Конечно, для чистоты эксперимента, надо бы включить параллельно 134-ю.

**UA3DJY** · 17.04.2019, 21:22

Сообщение от UR5LCZ

Позвал R6UAC и он ответил сразу с двух разных частот и с разными рапортами.

Дефект устранен в версии JTDX rc136_4.

**UA3DJY** · 17.04.2019, 21:39

Сообщение от R2PU

99% времени работаю практически на "максимальных" настройках по декодированию .
Ложные декоды бывают , но оператор то на что .... некритично.

Игорь , я правильно понимаю что функционал rc135 в некоторых случаях принудительно занижает порог чувствительности декодера FT8S на low - даже если у меня в настройках стоит high ?

Не очень пока понимаю что происходит - но работа в реальном эфире создаёт местами нехорошее впечатление что rc135 местами уступает rc134 по декодированию (при том что прогоны тестовых пакетов этого не подтверждают) - не могу пока отловить в чём дело , во мне или всё таки в софте ...

JTDX rc135 повышает порог срабатывания декодера до настройки 'low' если возможен ответ корреспондента другому оператору. Есть сетапы где даже для rc135 соотношение ложное/верное декодирование при ответе корреспондента другому оператору достигает 50/50.

FT8S декодер кроме RX частоты QSO еще ориентируется на DT корреспондента. В версии rc134 при начале QSO DT корреспондента не определялся и FT8S декодер не включался на часть сообщений QSO. В версии rc135 DT корреспондента вынимается с последнего декодированного сообщения от этого корреспондента, в том числе сообщения предыдущего QSO корреспондента если оно было в последнем RX интервале, и в подавляющем большинстве случаев FT8S декодер включается для всех сообщений QSO.

С точки зрения эффективности работы FT8S декодера будет просадка для тех корреспондентов кто привязывает RX/TX частоты. В этом случае например при вызове корреспондента передающего сообщение RR73, отвечая на вызов он прыгнет TX частотой на TX частоту оператора и как минимум на одно сообщение выпадет из поля зрения FT8S декодера.

Также операторы которые 'частят' с синхронизацией времени будут иметь скачки DT как своего передаваемого так и принимаемого сигнала. Те операторы кто выполняет синхронизацию часов компьютера не чаще чем раз один..три часа будут получать максимум от FT8S декодера.

**RK1NA** · 17.04.2019, 22:55

Сообщение от R6LCF

Пример: только что вызываю австралийца на 20м по "длинному пути" с разницей в частотах около 1кГц ,упорно не отвечает ,но продолжает давать вызов. Мне надоело и вызвал с разницей около 100Гц

Допплера никто не отменял.

**US5WE** · 18.04.2019, 09:14

Сообщение от RX3ASP

Тоже такое ощущение есть. Например, когда начинаю звать того, кто даёт рапорт другому, JTDX 135 часто пропускает декодирование, хотя на водопаде что-то шевелится. Конечно, для чистоты эксперимента, надо бы включить параллельно 134-ю.

Через пару недель начнет открываться 50 МГц - хочется встретить сезон во всеоружии и, соответственно, определиться с версией, которая не подведет. Если 134 лучше, сделаю downgrade. заранее благодарю за рекомендации.

**R3OZ** · 18.04.2019, 09:50

Добрый день! Работая в основном в FT8, количество QSO показывает правильно, но в JT65,JT9,JT10 не соответствует действительному, хотя в папке wsjt_log.adi количество
связей на много больше в этих модах. В JT65 примерно 4000 или чуть более. У кого как, интересно и что у меня не так, или это предусмотрено программой.Заранее благодарю.

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