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

**R0JF** · 25.12.2018, 11:42

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

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

Игорь, доброго дня!
Сегодня столкнулся с занимательным моментом (правда rc115) - позвал меня коллега из UN сразу рапортом, от меня ушло R-**, и всё!

Программы "зациклились" - он мне R-**, я ему - R-**... И так по--кругу.

Пока ручками "73" не ответил, так бы до сих пор наверное и общались.

Увы, лог не догадался сохранить. Был не дома, несколько торопился...

**UA3DJY** · 25.12.2018, 11:45

Всем кто использует JTDX 2.0.1-rc115: пожалуйста перейдите на версию rc117. Сейчас в эфире работают DU6/PE1NSQ и DU7/PA0HIP, версия rc115 неправильно генерирует сообщения с этими позывными что приводит к сбою при попытке провести c ними QSO.

**UA3DJY** · 25.12.2018, 11:50

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

Игорь, доброго дня!
Сегодня столкнулся с занимательным моментом (правда rc115) - позвал меня коллега из UN сразу рапортом, от меня ушло R-**, и всё!

Программы "зациклились" - он мне R-**, я ему - R-**... И так по--кругу.

Пока ручками "73" не ответил, так бы до сих пор наверное и общались.

Увы, лог не догадался сохранить. Был не дома, несколько торопился...

Приветствую,
у нас был патч который при определенной последовательности сообщений удалял позывной из истории QSO, возможно что он вызвал зацикливание. Если включена запись диагностики то причину и что спровоцировало сбой скорее всего можно будет понять из файла ALL.TXT.

**UA3DJY** · 25.12.2018, 11:59

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

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

Включите пожалуйста запись диагностики в файл ALL.TXT, тогда возможно увидим в чем причина сбоя.

**US5WE** · 25.12.2018, 12:45

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

Всем кто использует JTDX 2.0.1-rc115: пожалуйста перейдите на версию rc117. Сейчас в эфире работают DU6/PE1NSQ и DU7/PA0HIP, версия rc115 неправильно генерирует сообщения с этими позывными что приводит к сбою при попытке провести c ними QSO.

Это проблемы версии 2.0 ? Летом на предыдущей проблем не было.
Details US5WE DU7/PA0HIP 2018-06-20 07:47:14 6M FT8 50.00204
Виллем много лет на Филипинах сидит.

**R2FAF** · 25.12.2018, 13:11

сорри за оффтоп. есть процессоры E5300 E5500 775 сокет. за так. r2faf()bk.ru

**R0JF** · 25.12.2018, 13:23

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

сорри за оффтоп. есть процессоры E5300 E5500 775 сокет. за так. r2faf()bk.ru

Я в личку напишу.

**RN9AZ** · 25.12.2018, 13:57

Сейчас на двадцати метрах. Гонял программу. Небольшой, пайлап на Европу. Более двадцати связей провёл. Как не изгалялся над программой, не одного сбоя. Правда, Азорские через четыре QSO дали рапорт, ручками поработал немного, рапорт вводил. Увы, чего о ПК сказать не могу, не поспевает чуток.

Интересная работа антенн на скрине. RR33 и IV на 40 – 80 метров. Разница ощутима.

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

**UA3DJY** · 25.12.2018, 14:03

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

Это проблемы версии 2.0 ? Летом на предыдущей проблем не было.

Сбой есть только в JTDX 2.0.1-rc115.

**RN9AZ** · 25.12.2018, 14:30

Игорь. А есть ли возможность, работая куча мала, Если зовут несколько станций, отвечая всем, если корреспондент припозднился с ответом. И даёт рапорт через 3 4 QSO ввести небольшую память переданных рапортов. Чтобы не вводить их вручную. Было бы намного удобнее работать в пайлап. И ручки свободны. Игорь это хотелка, извени.

**EW4TT** · 25.12.2018, 15:04

Название: 0.jpg
Просмотров: 847

Размер: 163.2 Кб

Что означают эти скобки в позывных и почему окно закрасилось ?

**RX1AG** · 25.12.2018, 15:22

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

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

Беру назад свои слова о большой нагрузке проца Р4 прогой JTDX.
У меня было неправильно выставлено ДЕКОДИРОВАНИЕ. Нужно было поставить ШИРОКОПОЛОСНОЕ-БЫСТРОЕ. Конечно, когда стояло ГЛУБОКОЕ, проц Р4 не справлялся с нагрузкой в цикле приема и "залезал" декодировать в цикл передачи.
Параметры по загрузке проц Р4 программами JTDX WSJT при равных установках прибл одинаковы. Скрины ниже

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

**R2PU** · 25.12.2018, 15:45

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

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

Можно чуть дополнить ? (реально всё больше перехожу в разряд читателей - но рискну).

Помимо мониторинга загрузки ЦП желательно (впрочем каждый решает сам) посмотреть ещё и latency (задержки) , тот же DPC Latency Checker бесплатен и запускается без установки.
Там всё просто\наглядно (вплоть до цветовой градации "зелёный-жёлтый-красный")

Скажу более того : иногда можно до бесконечности "вылизывать" ОС , а в итоге найти в совершенно другом месте (с трудом - но нашёл пост более чем годовой давности - неоднократное "вылизывание" ОС и апгрейды компа , а в итоге пришлось разбираться с функционалом BIOS материнки , только после этого latency удалось снизить с 1000-2000us до 30-50us ) - в итоге сразу пропали "рывки" звука , сбои декодирования и попутно "скачки" времени (пост писался применительно к последнему)

Как итог : системник в котором десятилетний Intel L5430 воткнутый в десятилетнюю GA-P35-DS3 + 6Gb DDR2 RAM (2+2+1+1 примерно тех же годов) без "торможений" трудится и по сей день (картинка под спойлером, специально ушёл на 20м где сейчас "месится" по 30 и более станций за цикл декодирования)

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

Win7 SP1 64bit , JTDX 2.0.1 rc117 (deep\auto\AutoSeq2) + JT Alert 2.12.9 + там же лог , антивирус , NmeaTime , лог и браузер с несколькими вкладками и далее по списку (вплоть до того что этот же системник параллельно трудится ещё и NAS в домашней локалке) - ни малейших "торможений" JTDX (ну если очень сильно придираться - то алерт отображает позывные спустя секунду-две что не сильно критично для меня).
+иногда ко всему этому миксту софтов дополнительно запускаются ещё и HDSDR c SDR приёмником (во время FT8 теста была очееень большая надежда что мы наконец выйдем за рамки привычного "десятки станций работают в полосе 3000 Гц" , равно как и сия надежда не оставляет меня по сей день) , даже в таком варианте - вполне комфортная работа на 10ти летнем ЦП и чипсете без "торможений" и прочей нечисти.
----------------
Какие там i3 и i5 , нет не слышали - древний Socket 775 наше всё ))).
Равно как и монитор 17" 1280*1024 (у кого там "не влезает" JT Alert ? - могу сделать скрин с ноута - там вообще 13.3" 1024*768 и всё как то "влезло") , равно как и понимание того что если у меня что-то не работает\тормозит то это не вина автора софта - и кроме меня самого мне никто не поможет.
Всем добра , mniDX (глядя на скрин забитый EU station верится с трудом - но пусть) и с наступающим. 73!

**UA3DJY** · 25.12.2018, 17:02

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

Сценарий который встретил Виталий UA3ALE - он проводил QSO с таким специальным позывным и декодировал сообщение RR73, но софт поискав в оперативной памяти соответствие хэш нашел недавно бывший в эфире позывной R2AE хэш которого совпадает с хэшем позывного UA3ALE.
В результате декодер выдал сообщение R2AE S511NNN RR73 которое AutoSeq у Виталия явно не ожидал после получения рапорта от корреспондента.

Ассоциацию позывного с хэшем в версии протокола FT8v2 в WSJT-X перенесли в модуль упаковки/распаковки сообщений, при этом не сделали проверку на наличие позывного корреспондента с окна DX Call в этом сообщении, факта проведения QSO с этим позывным и в этом случае приоритет проверки принятого хэша с позывным пользователя программы. Результат налицо, сейчас чтобы в JTDX устранить такое поведение программы придется дублировать сравнение хэша для уже распакованного сообщения с неправильным позывным с позывным пользователя и при выполненнии указанных выше критериев подменять неправильно распакованный позывной позывным пользователя.

Этот сбой будет устранен в следующей версии WSJT-X и поскольку работа с таблицей хэшей идет в модуле упаковки/распаковки сообщений то в JTDX этот сбой будет устранен после выпуска новой версии WSJT-X.

Сообщение от разработчика(английский):

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

**UA3DJY** · 25.12.2018, 17:14

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

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

Что означают эти скобки в позывных и почему окно закрасилось ?

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

Сообщение на передачу генерится из текстовых сообщений в окнах Tx1...Tx6 и упаковщик сообщений понимает что надо использовать хэш вместо позывного на основании этих скобок.
Если в декодированных сообщениях мы эти скобки убрали то в сообщениях предназначенных для передачи увы не можем.