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

**UA3DJY** · 13.05.2020, 12:41

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

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

Дополнительная загрузка логического ядра процессора декодером во время получения звукового потока, на слабых двухядерных процессорах без сомнений приведет к потере части фреймов звукового потока, и потере декодирования слабых сигналов DX корреспондентов. ИМХО оценка трех циклов декодирования WSJT-X 2.2.0 не так оптимистична и однозначна. Тем более что уже есть обратная связь от пользователей таких процессоров.

Обычно чем шустрее декодер тем меньше выдает сообщений на выходе. Команда WSJT принципиально отказывается от использования согласованных фильтров в FT8 декодере, поэтому для WSJT-X это утверждение является аксиомой.

**R6LCF** · 13.05.2020, 12:47

Я думаю ничего вводить в JTDX .....нет необходимости. Кого устраивает такой алгоритм работы пусть и работает на WSJT-X ,а кого устраивает алгоритм работы JTDX....+ отличная работа с низкими уровнями в шумах будет продолжать работать на ней. Установлена у меня последняя версия WSJT-X ,комп мощный ,настройки по максимуму, трансивер SDR....прямой оцифровки ,АРУ при работе выкл. затыканий "0" из под шумов только так выцарапывает сигналы. Сколько раз за двое последних суток заставлял себя перейти на WSJT-X ...никак. Явное неудобство в работе +убогий интерфейс .а при моих настройках в JTDX....по максимуму ,далеко впереди.Отсутствие фильтров запрета на континенты в частности на Европу ...из себя выводит. Еще дорабатывать и дорабатывать. Главное у нас есть то что мы хотели , получили и успешно работаем.
Кстати сегодня опять Япония на диапазоне 10м ,не так как вчера ,сигналы довольно слабые " спорадик" отошел от направления на Японию и Сибирь но для тестирования самое то.Пяток связей провел. Сейчас одна Европа ,самое время вкл. фильтр на них.На рефлектор(антенна задом к ним) вызывают.

**UA3DJY** · 13.05.2020, 13:26

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

Я думаю ничего вводить в JTDX .....нет необходимости.

В принципе можно стартовать циклически FT8 декодер на одном потоке начиная с шестой секунды интервала, но это только видимость быстрой работы - будут декодированы сигналы с ломовым уровнем которые для диэксинга в подавляющем большинстве случаев не представляют интереса, но при этом вырастет нагрузка на процессор и появятся дополнительные проблемы с приемом звукового потока которые уже наблюдают пользователи двухядерных процессоров на WSJT-X 2.2.0. Окончание декодирования за счет дополнительного подпрохода в WSJT-X 2.2.0 должно быть позже по сравнению с версией 2.1.2, часто именно момент окончания декодирования определяет успешное проведение QSO за счет более полной передачи TX сообщения оператором.

**RN6MT** · 13.05.2020, 13:45

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

наблюдают пользователи двухядерных процессоров на WSJT-X 2.2.0.

В моем стареньком ноуте два ядра, четыре потока и я такого не наблюдаю. Более того- последняя версия wsjtx заметно меньше грузит процессор и шустрее работает.
Об этом пишут пользователи и на vhfdx.ru. Так что не все так просто)))) Мне последняя версия нравится намного больше, чем предидущая.
К JTDX претензий нет, но я ее не пользую по причине отсутствия в ней УКВ мод.

**UA3DJY** · 13.05.2020, 13:53

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

В моем стареньком ноуте два ядра, четыре потока и я такого не наблюдаю. Более того- последняя версия wsjtx заметно меньше грузит процессор и шустрее работает. Об этом пишут пользователи и на vhfdx.ru. Так что не все так просто)))) Мне последняя версия нравится намного больше, чем предидущая.

Виртуальная реальность или самообман

Звучит как 'новые чипсы нашей марки на 25% вкуснее'

Последняя версия WSJT-X трижды запускает FT8 декодер да еще и с дополнительным подпроходом декодирования тогда как предпоследняя только один раз, о каком снижении нагрузки на процессор идет речь?

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

К JTDX претензий нет, но я ее не пользую по причине отсутствия в ней УКВ мод.

Мы их специально удалили потому что диэксинг на КВ имеет мало общего с УКВ модами, тем не менее благодаря высокой чувствительности FT8 декодера программа JTDX очень популярна на диапазоне 6м, например в Японии.

**RN6MT** · 13.05.2020, 14:08

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

Виртуальная реальность или самообман

Да нет.Это явно видно. Возможно авторы как-то оптимизировали код. Приведу пример. Раннее частенько бывало, программа переходит на передачу, а декод еще не закончился, а сейчас этого нет.Еще- ранее, во время работы программы запуск интернет браузера на моем компе приводил к кратковременному прераванию в работе программы. В результате- отсутствие декода. Сейчас этого нет. Да и товарищ привел инфо о загрузке процессора.

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

очень популярна на диапазоне 6м, например в Японии.

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

**UX8IW** · 13.05.2020, 14:24

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

Да и товарищ привел инфо о загрузке процессора.

Ну, он сравнил только пиковую загрузку.
На графике видно, что время декода wsjtx ~в два раза больше.
Реальная загрузка ресурсов процессора - это площадь этих импульсов, и скорее всего у обеих программ она будет примерно равная.

**R6LCF** · 13.05.2020, 14:24

Диспетчер задач.
Скрин 1 диапазон 20м программа WSJT-X. А вот здесь не совсем по минимуму.
Скрин 2 диапазон 20м программа JTDX.Станций более чем ,в интервал декодирования попадают все. Загрузка проц ,а у меня 8 логич.проц равномерная .
Скрин 3 диапазон 10м программа JTDX.Станций не более десятка.Все тоже самое с меньшей продолжительностью периода.
Скрин 4 диапазон 20м JTDX станций более чем все попадают в интервал ,смотрим Lag.....а что еще надо?

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

**RN6MT** · 13.05.2020, 14:25

Спасибо Борис, наверное так и есть.

**UA3DJY** · 13.05.2020, 15:11

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

Ну, он сравнил только пиковую загрузку. На графике видно, что время декода wsjtx ~в два раза больше. Реальная загрузка ресурсов процессора - это площадь этих импульсов, и скорее всего у обеих программ она будет примерно равная.

В JTDX зависит от настроек FT8 декодера, при максимальных количество выполненных операций процессора будет в несколько раз больше. За счет дополнительного использования доступных ресурсов процессора JTDX декодирует больше сигналов.

**UX8IW** · 13.05.2020, 16:35

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

В JTDX зависит от настроек FT8 декодера, при максимальных количество выполненных операций процессора будет в несколько раз больше. За счет дополнительного использования доступных ресурсов процессора JTDX декодирует больше сигналов.

Да, эта зависимость прослеживается. Но есть ещё одна, (для моего железа она не очень

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

**RU7K** · 13.05.2020, 19:20

Приветствую всех!
Пользуюсь JTDX, режим FT8. При отправке CQ вижу вызывающие станции, однако программа вместо захвата одной из них продолжает отправлять CQ.
Ранее такого не было. Настройки не менял. Сегодня обновил до версии rc150, но проблема имеет место быть. Режим AutoSeq включен.
Что я не так делаю?