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

**UA3DJY** · 24.12.2018, 23:18

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

На скрине я вижу что WSJT, мода JT9. ... Если не так, поправьте меня.

На картинке Вы видите работающий процесс jt9.exe, этот процесс отвечает за декодирование сигналов нескольких мод в программе WSJT-X.

**UX8IW** · 24.12.2018, 23:21

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

Объясните на моём примере что нарушится, если программа отключит передачу СРАЗУ после декодирования сообщения, адресованного не мне, а не ПОСЛЕ декодирования остальных сообщений?

Юрий, так программа и отключает передачу сразу после получения 73. У вас цикл декода не закончился, из-за чего новая команда на отключение Тх программой не сформирована, поэтому и осуществляется передача предыдущего сообщения.
У меня этих проблем нет.

**UX8IW** · 24.12.2018, 23:29

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

Из Ваших скринов не совсем понятно какая программа работает? какая мода? Какая полоса декодирования. На скрине я вижу что WSJT, мода JT9. Прог JTDX вообще не просматривается, процессор 2- ядерный, полоса не обозначена? Как-то не корректно... Если не так, поправьте меня.

Почему не понятно, над каждым скрином есть надпись, мода - обсуждаемая сейчас FT8. Полоса пропускания - 3,4кгц
О процессах Игорь вам объяснил. Я и хотел показать, какие процессы задействованы.

**UN7JID** · 25.12.2018, 01:10

Не первый раз сталкиваюсь с ситуацией, когда при получении РР73 программа продолжает передавать "R-рапорт".
причем окно DX очищается. Пришлось в процессе повторной мне передачи корреспондентом РР73, снова дважды кликнуть на его сообщении, курсор встал на TX5 но когда подошла очередь моей передачи, передача пошла и тут же отключилась.
в ALL.TXT это видно по сообщению "partial loss of data "
Кусок ALL.TXT

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

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

ЗЫ. Обновился до версии 117 и через пару QSO словил тотже глюк.
Но в этот раз сразу же дважды кликнул на сообщении корреспондента с его РР73 и прога начала передавать как положено 73 в ответ.
В ALL.TXT это видно.

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

Работа в обоих случаях шла "на поиск", то есть я отвечал на CQ корреспондента. Отвечал не на его частоте, а в стороне.

**RN9AZ** · 25.12.2018, 06:55

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

В большинстве случаев. Всё можно отследить на экране вашего монитора. Следя за порядком вывода строк на экране приём передача. И многие вопросы отпадут.

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

**RX4HX** · 25.12.2018, 07:00

У меня не первый раз такая проблема:
вызываяю станцию, получаю рапорт, предаю R-рапорт, и если получаю RR73, то программа кратковременно переходит на передачу 73, но потом сбрасывается. Кусок ALL.TXT

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

Я правда, после передачи рапорта нажал на кнопку передачи макроса 73, но раньше это не влияло.

**RX3ASP** · 25.12.2018, 08:39

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

У меня этих проблем нет.

Понятно, что не столкнувшись самому с проблемой, иногда её трудно себе представить.

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

Юрий, так программа и отключает передачу сразу после получения 73.

Программа отключает ТХ только после декодирования ВСЕХ "кандидатов", хотя собственно корреспондент QSO уже был декодирован ранее.

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

У вас цикл декода не закончился, из-за чего новая команда на отключение Тх программой не сформирована, поэтому и осуществляется передача предыдущего сообщения.

Цикл декода закончился - цикл это 15 секунд. Декодирование RX цикла не закончилось. Но корреспондент QSO уже был декодирован ранее.

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

Софту уже требуется более мощный процессор.

Для того, чтобы в описанной мной ситуации отключить передачу мощный процессор не требуется. Я отключаю TX Enable вручную, а мои глаза, голова и палец реагируют медленнее, чем Intel 8080

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

У меня не первый раз такая проблема:
вызываяю станцию, получаю рапорт, предаю R-рапорт, и если получаю RR73, то программа кратковременно переходит на передачу 73, но потом сбрасывается. Кусок ALL.TXT

Это ОНО и есть. Хорошо, если "кратковременно" это 1 сек., а когда это >4 сек., то ваш устаревший процессор создаёт проблемы состоятельным любителям больших скоростей и они вынуждены (по аналогии с автомобилями) объезжать пробку по обочине... киловаттами

Может какую-то галочку где-то надо поставить или убрать? Но ни счетчики ни Clear DX Call after logging не влияют.

Надеюсь, Игорь UA3DJY прокомментирует и исправит эту проблемку, когда основной объём работ завершит.

**RX4HX** · 25.12.2018, 08:42

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

ваш устаревший процессор

В том то и дело, что процессор не такой уж и устаревший: i-5 и 12 Гб оперативки. Загрузка процессора на самом пике (JTDX+Лог+ExpertSDR) не превышает 30-40%.

**RX3ASP** · 25.12.2018, 09:04

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

В том то и дело, что процессор не такой уж и устаревший: i-5 и 12 Гб оперативки. Загрузка процессора на самом пике (JTDX+Лог+ExpertSDR) не превышает 30-40%.

Загрузка ЦП может ни о чём не говорить. У меня на WSJT загрузка макс.60%, а декодирование идёт с огромной задержкой. JTDX загрузка до 100%, но задержка в разы меньше.
Посмотрите в ALL.TXT параметр Decoding finished - это как раз задержка декодирования

**US4IRT** · 25.12.2018, 09:16

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

Программа отключает ТХ только после декодирования ВСЕХ "кандидатов", хотя собственно корреспондент QSO уже был декодирован ранее.

Смотря какой вариант AutoCQ использовать. Выбор AutoCQ и сделан для того, чтоб избегать подобного при различном "железе" и загруженности диапазона.

**R6LCF** · 25.12.2018, 09:30

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

Но проблема, о чём тут пишут возникает не редко на двух ядрах четырёх потоках.

Возможно вы и правы.У меня ничего подобного нет , не было и быть не может. У меня включены на стационарном компе постоянно 12 потоков,проблем "0".Загрузка максимум до 60-редко 80% при большой загруженности диапазона.Работает в паре с SunSDR2Pro.
Но как писал ниже у меня есть старый ноут для выездов ....в свете последних замечаний начал на нем эксперименты с последними версиями ,количество потоков по минимуму и чувствительность декодера минимальная.Работает в паре с ic7300. Замеченное буду выкладывать в теме .А далее буду увеличивать нагрузку. Пока в норме.

**RN9AZ** · 25.12.2018, 11:20

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

Возможно вы и правы.У меня ничего подобного нет , не было и быть не может. У меня включены на стационарном компе постоянно 12 потоков,проблем "0".Загрузка максимум до 60-редко 80% при большой загруженности диапазона.Работает в паре с SunSDR2Pro.
Но как писал ниже у меня есть старый ноут для выездов ....в свете последних замечаний начал на нем эксперименты с последними версиями ,количество потоков по минимуму и чувствительность декодера минимальная.Работает в паре с ic7300. Замеченное буду выкладывать в теме .А далее буду увеличивать нагрузку. Пока в норме.

Дело в том. Что хоть 100 потоков. Если у вашего корреспондента будут проблемы, во время проведения QSO проблемы будут и у вас. Я пишу о своём ПК. Автору программы, как ПК справляется с максимум чувствительности, декодирования. И о том что программа не сбоит. Мощности компа вот точно не хватает. А проблемы, То у одного время сбито почти на минуту не заметил. Другой не смог рапорт получить, третий как в голову взбредёт связь проводит. и так далее. Недавно новую версию SIMPSK тестировал. Умудряются подойти в автомате и без вызова, сразу рапорт и всё остальное. Вот там сразу видно что как хочу так и работаю а софт такого алгоритма не держит. Да и JTDX в FT8 работая частенько вижу подобную работу. А читая посты складывается впечатление что людям нужен полный автомат. Нажал кнопку и спина в мыле. Передав 73 своему корреспонденту. Обычно сразу жму на CQ. И если им рапорт принят обычно нет проблем. А если не жму, стоп передачи. Поверьте не каких глюков программы. Повторы блокирует. чего ещё надо. Но расслабится некогда. А вы говорите проблем быть не может. Нет так сделают.

**UA6JQ** · 25.12.2018, 11:21

...rc117 Глюк.
UA3RBM HF19NY RR73
HF19NY UA6JQ -06
UA6JQ HF19NY R+00
HF19NY SP4GED RR73 QSO logged: HF19NY
SP4GED HF19NY 73
HF19NY SP4GED RR73
Отключаю AutoSeq, Жму бутон 73. Выдает HF19NY SP4GED RR73
Весь *концерт* отображается в правом окне и в файле ALLTXT. А в окошке Gen.msg отображает правильно: HF19NY <UA6JQ> RR73 и HF19NY <UA6JQ> 73
У спейстанции в окошке DXCall должен был быть мой позывной и на глюк она попрощаться не могла. Думаю, глючила сама с собой, а в эфир шла првильная информация.
Обычно старые версии полностью удаляю с инифайлом. Чищу Regorganiser, VITregistry и CleanCenter. Только потом ставлю новую с нуля и установки по новой. Первый раз поставил поверх rc115...

**R0JF** · 25.12.2018, 11:24

Уважаемые Коллеги, всем доброго здоровья!

Может быть кому-нибудь будут интересны мои наблюдения по поводу загрузки процессоров программой JTDX в операционной системе Windows. Честно говоря, я работаю в Linux, но есть и машина с Windows-7, так что было где поэкспериментировать.

Итак:

ОС - Windows-7 Профессиональная SP1 32-bit (не "ворованная)
ЦПУ - Intel Celeron J1900 1,99 GHz (довольно шустрый - 4 ФИЗИЧЕСКИХ ядра)
ОЗУ - 4 Gb (именно поэтому операционка 32-битная! Нет смысла ставить 64-бит - будет только тормозить).

Кроме JTDX на этой же машине "крутится" PowerSDR, работающая с Flex-3000. Так что загрузку процессора кроме JTDX неслабо дает и программа SDR-трансивера.

Установки в меню "Decode->FT8 Threads":

Auto - загрузка до 98% при декодировании
1 thread - загрузка до 37%
2 thread - загрузка до 67%
4 thread - загрузка до 72%
8 thread - загрузка до 92%
12 thread - загрузка до 99%

К чему я все это...
Есть смысл прежде всего "вылизать" Вашу ОС - поставить проприетарные (РОДНЫЕ) драйверы на всё "железо" (особенно на видео!!!), максимально "облегчить" ее от лишних работающих служб, НЕ СТАВИТЬ 64-битную версию, если памяти у Вас менее 4 Гбайт (!!!!!!!!!), ну и потратить немного времени на простой анализ загрузки процессора, выбрав вручную (а не Auto) "FT8 Threads"...

Допускаю, что моя "лабораторка" не очень адекватна - всё-таки уникальность процессора J1900, не так уж и много отстающего от скажем i3... Но как тема для размышлений, думаю не помешает.

73! С Наступающим!

**UA3DJY** · 25.12.2018, 11:32

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

Не первый раз сталкиваюсь с ситуацией, когда при получении РР73 программа продолжает передавать "R-рапорт".
причем окно DX очищается.

Возможно что это сбой в работе счетчиков сообщений, включите пожалуйста запись диагностики в закладке Reporting настроек. Тогда в файле ALL.TXT будет видно что вызвало очистку окна DX Call.