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

**UA3DJY** · 28.03.2019, 16:17

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

В 134_11 есть эта функция, знаю. В 134_8 нет, но не знаю в каком положении там это. Когда есть возможность видеть и менять, думаю, это хорошо.
Как я понял, дошли уже то такого порога, что ложные декоды неизбежны?

Весь вопрос в рациональности высокой чувствительности. У каждого оператора свой порог рациональности, кто то считает что на 10 проведенных QSO благодаря чувствительности -30дБ SNR одно потерянное QSO будет приемлемо, для кого то этот порог составляет 1/1000. Баланс между тем что получает пользователь и что теряет.

В rc134_11 мы дошли до такой чувствительности которую я считаю приемлемой при наличии Гауссовского шума (например почти закрытый ВЧ диапазон ночью при условии отсутствия бытовых помех, для моего региона при хорошей солнечной активности это может быть ночное прохождение на Чили в феврале/марте на диапазоне 15 метров), поскольку в симуляторе FT8 сигналов используется Гауссовский шум то мне достаточно просто протестировать вероятность ложного декодирования в присутствии и отсутствии адресованного мне сигнала, результаты я привожу в таблицах.

Поскольку Гауссовский шум с каждым годом все больше становится исключением чем нормой то вероятность ложных декодирований возрастает и пользователю придется самостоятельно настраивать чувствительность в зависимости от обстановки. 10% декодированных сигналов при -30дБ SNR в rc134_11 не предел, можно еще выжать примерно 0.5 дБ чувствительности (одна строка в коде), но при этом соотношение ложных декодирований к верным при Гауссовском шуме будет уже настолько велико что может из трех проведенных QSO сделать одну недействительной. В определенных условиях и такой вариант может быть востребован, например если с меньшей чувствительностью не получается провести ни одного QSO а декодирование с другой стороны решается энергетикой сетапа.

С точки зрения загруженного сигналами диапазона повышение чувствительности также повышает вероятность декодирования сообщения при наложении спектров разных сигналов во время QSO, но при этом вероятность ложного декодирования тоже намного больше чем для сценария когда только один сигнал + Гауссовский шум.

Декодер FT8S ориентируется на DT ранее декодированного сигнала, чтобы он работал в полную силу должно быть ранее декодировано одно из сообщений корреспондента, например CQ или одно из сообщений QSO корреспондента. В сценарии когда оператор работает на общий вызов первое входящее сообщение может быть декодировано только другими декодерами (неизвестна частота, позывной и DT), с соответствующим декодеру FT8 AP ограничением чувствительности.

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

Последние версии стали "задумываться" после запуска. С чем это связано?

У себя не наблюдаю, либо дефект в коде либо что то с настройками(ini). Декодер FT8S (сообщения QSO на RX частоте) работает в максимальную силу уже в режиме deep.

**US4IRT** · 28.03.2019, 17:08

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

Весь вопрос в рациональности высокой чувствительности.

Я не против, чтоб это было, Игорь. Только что опробовал 134_11 на разных порогах (на XR0ZRC на 18 мГц) - не было ложных только на low. На medium почти тоже самое, что и на high.
Подчеркиваю - это в реальном эфире и на уровнях от -21 до -25 (меньшие не видел).
Сейчас он идет гораздо громче.

**UR7TT** · 28.03.2019, 17:36

Не очищаются окна при смене бенда из внешней программы.

**UR4IOR** · 28.03.2019, 17:41

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

Только что опробовал 134_11

А где скачать 134?

**RX6LQ** · 28.03.2019, 17:50

[QUOTE=UR7TT;1572195]Не очищаются окна при смене бенда из внешней программы.

Галка установлена?

**UA3DJY** · 28.03.2019, 17:51

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

Я не против, чтоб это было, Игорь. Только что опробовал 134_11 на разных порогах (на XR0ZRC на 18 мГц) - не было ложных только на low. На medium почти тоже самое, что и на high.
Подчеркиваю - это в реальном эфире и на уровнях от -21 до -25 (меньшие не видел).
Сейчас он идет гораздо громче.

Когда дадим в широкое тестирование будет больше информации о работе, тогда либо добавим супеньки либо настроим существующие.

**UA3DJY** · 28.03.2019, 18:10

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

Не очищаются окна при смене бенда из внешней программы.

Программа управляет трансивером а не трансивер программой, эта тема уже неоднократно поднималась на форуме. Вы меняете диапазон трансивера с другой программы и считаете что трансивер должен сказать программе WSJT-X/JTDX что ей делать, в коде программы так не предусмотрено.

**R6LCF** · 28.03.2019, 18:21

Игорь поздравляю.Ничего не наезжает ,все вернулось как было ранее ,то что надо!

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

**US4IRT** · 28.03.2019, 18:37

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

А где скачать 134?

Это промежуточные версии, Сергей. Их нет в общем доступе. Скоро появится.

**UR7TT** · 28.03.2019, 20:05

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

Программа управляет трансивером а не трансивер программой, эта тема уже неоднократно поднималась на форуме. Вы меняете диапазон трансивера с другой программы и считаете что трансивер должен сказать программе WSJT-X/JTDX что ей делать, в коде программы так не предусмотрено.

Все так, но, JTDX видит , что частота сменилась с 7 МГц на 14 к примеру, и это знак для очистки окон.

**UA3DJY** · 28.03.2019, 20:09

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

Программа управляет трансивером а не трансивер программой, эта тема уже неоднократно поднималась на форуме. Вы меняете диапазон трансивера с другой программы и считаете что трансивер должен сказать программе WSJT-X/JTDX что ей делать, в коде программы так не предусмотрено.

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

Все так, но, JTDX видит , что частота сменилась с 7 МГц на 14 к примеру, и это знак для очистки окон.

При кратковременном сбое CAT частота меняется на 0, при установке пользователем большого периода опроса CAT частота обновляется с соответствующей задержкой и еще есть ряд сценариев которые приведут к нестабильной работе программы если пытаться ей управлять с трансивера.

**R6LCF** · 28.03.2019, 20:11

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

и это знак для очистки окон.

Самому ,двойной клик и оба окна чистые!

**R0AEB** · 29.03.2019, 10:33

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

**R2EA** · 29.03.2019, 16:44

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

На мой взгляд лучше пусть в ручную окна очищаются при смене диапазонов, не так уж это и часто нужно чтоб на этом заморачиваться

Кто в лес , кто по дрова...

Но если речь пошла про очистку окон, то:
-Сделать право выбора галочкой в меню разное,
очистка обоих окон после внесения qso в лог!
Я при смене каждого режима - постоянно чищу.
Особенно, когда сижу на cq с вкл. фильтрами...
то на один континент, то на другой.
И хорошо бы сделать пару счетчиков с выбором галочкой.
Один отвечал бы за очистку обеих окон (поминутно),
а другой за очистку чёрного списка (тоже поминутно).
Выставил счетчик на 5 минут - вот вам чистые окна.
Выставил стереть список тех кого звал, но они не ответили
на 30 минут и вот вам новые связи в лог.
А то прога их или не будет подхватывать,
или же будет звать до посинения...!

Возможно это уже реализовано, но мы ещё об этом не знаем...

**R6LCF** · 29.03.2019, 16:52

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

На мой взгляд лучше пусть в ручную окна очищаются

Поддерживаю. Только сам. Окно приема (левое)вообще чистить только при смене диапазона "левой мышей",или в этом случае сразу оба двойным кликом ,а (правое) только сам по мере переполнения "правой мышей"или когда это требуется .