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

[RX4CD]

У меня недавно, момент я не зафиксировал, тоже начались проблемы с OmniRig. Я читаю форум и все больше убеждаюсь, что проблема кроется в программе JTDX. До этого на разных компах и в разных Windows-ах OmniRig работал как часы. Где-то чего-то поломалось. Это моё мнение.

100% поддерживаю эту версию! Что-то разработчики не досмотрели. Если что-то случилось бы с Omni Rig, ну, драйвер слетел или еще что-то, то и другие программы, использующие его, тоже не работали бы. Да и сразу у многих такое вряд ли могло случиться. Говоря словами персонажа из мультфильма "Трое из Простоквашино"
...-Это только гриппом все вместе болеют, а с ума сходят поодиночке".

[R0JF]

100% поддерживаю эту версию! Что-то разработчики не досмотрели. Если что-то случилось бы с Omni Rig, ну, драйвер слетел или еще что-то, то и другие программы, использующие его, тоже не работали бы. Да и сразу у многих такое вряд ли могло случиться. Говоря словами персонажа из мультфильма "Трое из Простоквашино"
...-Это только гриппом все вместе болеют, а с ума сходят поодиночке".

"Сразу у многих" - это СКОЛЬКО ЧЕЛОВЕК?

Если у десятка пользователей и "слетело", а у остальных сотен все нормально,
то наверное как раз в тему Вашей цитаты...

Для начала обратите внимание, какой именно OmniRig используете. Откуда он?
Из дистрибутива лога, или напрямую скачан у автора??? Были случаи, когда в
дистрибутивах логов он, скажем так, не совсем правильный был...

А Игорь как раз в исходники CAT (насколько я знаю) никаких изменений не вносит...

PS И так форум с конкретной темой больше похож на курсы по ликвидации безграмотности...

[UR4UM]

100% поддерживаю эту версию!

Хоть укажите какую (34ю, 68ю или 69ю), а то точно, как в мультике...
Новая WSJT вышла, установил, поработал... хорошо, только привыкли уже к фильтрам, и др. фичам JTDX.
Но работает стабильно! Не нравится только управление частотой RX - TX, если бы тоже как в JTDX - перешёл бы (хотя имею и 6 ядер, и 8 Гб).
Уж очень много вариантов, и везде свои но!

P.S. - в смысле много разных настроек, и AutoSeq, и Misk и других...

Верю, что доработается и упростится, но смотрю некоторые работают на MSHV!!! Не понимаю...
и компютер обновить, почти как трансивер по деньгам (особо у нас)...
"а сколько той жизни?" сказал мой друг после инсульта, вопрос очень широк философски, и жизненно.
Пока хочется, пока и живём!

[RA3DND]

И так форум с конкретной темой больше похож на курсы по ликвидации безграмотности...

Так он и создан для этого. Если уже "грамотный", то чего тут делать?,

[R3OZ]

Добрый день. Все время работаю с OmniRig и ни разу проблем не было. Чего и Вам желаю!

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

[EU1FQ]

.... В настройках лога выключаю управление трансивером, т.е. освобождаю СОМ-порт. Запускаю JTDX - САТ не работает. Окно частоты красное. Тест САТ не проходит. РТТ не работает. Раньше все тесты проходили. Начал копать и обнаружил, что JTDX перенастраивает Omni Rig на СОМ5 (!), которого у меня никогда не было. Вручную ставлю в Omni Rig СОМ1. Нажимаю CAT TEST - снова появляется COM5. Почему? Загадка до сих пор не разгадана.

Если Вы в EQF выключаете управление трансивером, т.е. ставите Rig type NONE, то управление передается OmniRig. Значит проблема в нем. Посмотрите откуда он запускается. Их (OmniRig), может быть несколько на Вашем компьютере и все с разными настройками. Попробуйте обновить Rigini для своего трансивера.
Если компьютер "самостоятельно"перенастраивается на другой COM порт, то однозначно, какой то программой это порт ему присвоен. И не обязательно что это может быть JTDX. Может быть Вы недавно подключали какое либо устройство к USB порту. Вот настройки и сохранились.
Что бы не дать компютеру видеть ненужные запускаемой программе порты, снимите галочку Serial Enumerator (Обнаружение устройств Plug-and-Play) в свойствах порта COM1. Ни WSJT, ни JTDX никакого отношения не имеют к настройкам вашего компьютера. Что Вы установили, то программа и "скушала"

[RU6YJ]

[QUOTE=UA1OMZ;1442507]2. "Убедительно ВСЕМ просить Игоря, сделать режим AutoSeq"№" аналогичный режимам call first в JTDX v.34 или AutoSeq + call 1st в wsjt-x."

Согласен на все 1000%.
Тестировал различные версии выше JTDX v.34
по прежнему убежден-самая стабильная версия JTDX v.34.Все остальные "от лукавого"-кому как повезло с PC и различным софтом.

[EU1FQ]

И еще о загрузке процессора.
Если вы заметили странную "тормознутость" компьютера при работе JTDX, то обязательно проверьте компьютер на подозрительные запущенные процессы.
Дело в том, что в последнее время набирает популярность распространения браузерного майнера, который добывает криптовалюту без ведома пользователя, используя мощности вашего процессора и видеокарты.
К сожалению, только на антивирусы здесь полагаться не стоит. Разработчики антивирусного программного обеспечения, как правило, программы Майнеры считают не зловредными. В лучшем случае они входят в выделенную категорию Riskware — ПО, которое само по себе легально. Но мощности вашего компьютера они отберут прилично! На днях у товарища, не связанного с радио, отловил пару таких процессов. После их удаления, загрузка процессора пришла в норму.

[UA3DJY]

2. Убедительно ВСЕМ просить Игоря, сделать режим AutoSeq"№" аналогичный режимам call first в JTDX v.34 или AutoSeq + call 1st в wsjt-x.

попробуйте пожалуйста AutoSeq1 в версии 18.1.0.70_5

собранный софт https://cloud.mail.ru/public/EA1p/aoZEkfakn

исходный код https://cloud.mail.ru/public/MsUL/jj2Dcmf33

кодовые суммы
File name: JTDX-18.1.0.70_5-win32.exe
MD5: AB6C5F325AE018BC6C4E25FAABBB0EF9
SHA-1: 9EF48F7243EEFB116A41B4C56108842FF8E0DF98
SHA-256: A6561F6D7CA77B0DC2D6FC3911B2470A8D0A7FE075BF18F254AF1CAAA563D39C
SHA-512: 5F06CD9C42E3953FFA515B2FC05F52555F871F70B6076651C7657E5F566BDA8F83F79E 7DDA5D65CC9EC6151F387D90659F8C9D806F85DB58F47B0F51E5ABCC2D
RIPEMD: 9074B41A988689DF166E7D608C942309887C3348

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

[US-E-12]

Майнеры считают не зловредными. В лучшем случае они входят в выделенную категорию Riskware — ПО, которое само по себе легально. Но мощности вашего компьютера они отберут прилично! На днях у товарища, не связанного с радио, отловил пару таких процессов. После их удаления, загрузка процессора пришла в норму.

А чего их искать. Самый известный случай – попытка разработчиков μTorrent таким образом дополнительно заработать на пользователях внедрив в софт скрытый майнер EpicScale. Ну и у всех остальных клиентов (bittorrent и т. д.) этой группы возможно присутствие такого майнера, ведь клиент всегда подключён к сети, очень удобный майнинг для создателей.

[R0JF]

18.1.0.70_5 Linux version (compiled in Ubuntu 16.04LTS) from original sources files by UA3DJY

Binary only: https://cloud.mail.ru/public/N91S/Cqp85122L

64-bit deb-package: https://cloud.mail.ru/public/Fbbh/pFgLW1muD

32-bit deb-package: https://cloud.mail.ru/public/CmZ5/LEZLa1G4m

73!

[R3HH]

Могу предположить что есть круг постоянных и грамотных тестеров.
Они про САТ не спрашивают.
Пора бы АВТОРУ сделать для таких людей "полузакрытый" сайт, в смысле тему.
А то тут САТы, Омнириги, Ригэкмперты и все с претензиями (хотелками) к АВТОРУ.
Есть на QRZ примеры открытых тем в которых первое сообщение на любой страничке
это предупреждение о том чем здесь занимаются.
В данном случае красным и большими буквами - публикуемые здесь версии находятся в разработке. Их использование - ваш риск.
Типа этого.

прошу прощения за флуд у модераторов

Сюда на форум заходят разные люди, тестеры и профессионал в вашем лице, и те кто сов7 о цифре не имеет никакого представление, начиная работать digi
Им еще далеко до совершенства и понятие о САТы, Омнириги, Ригэкмперты и в вашем случае виртуальные COM порты, для них, из области фантастики, поэтому они и задают вопросы здесь сталкиваясь с определенными проблемами.

А кто им поможет как не мы с вами (вы как профессионал я как любитель) проработавшие уж с десяток лет разными цифровыми модами?

Лопатить 1000ми страниц форума, тоже не вариант.

создавать 10ки форумов как настроить САТы, Омнириги, Ригэкмперты?
автору писАть мануалы с картинками? тоже смешно... ему есть чем заняться

у нас ветка форума --- работа с тестовым софтом а не круг постоянных и грамотных тестеров,
которые все знают и про САТ не спрашивают... д

и разницы нет любитель ты или профессионал (прогу пишут для всех), главное результат
а он есть, люди интересуются программой, работают в эфире и наслаждаются жизнью...

может я в чем то и не прав, думаю меня поправят

[UA1OMZ]

попробуйте пожалуйста AutoSeq1 в версии 18.1.0.70_5
AutoSeq1 доработан на вызов первого позвавшего но с полным декодированием/обработкой всех сигналов и сменой сообщения в том числе во время передачи.

Ну во-первых ОГРОМАДНЕЙШЕЕ СПАСИБО, Игорь, что обратили внимание. Протестировал режим AutoSeq1, работает адекватно, как и call first в JTDX v.34,
т.е. всегда отвечает на сообщение декодированное уже в момент передачи и автоматически изменяет передаваемое сообщение на нужное в зависимости от ситуации.
Вот фрагмент работы AutoSeq1 в версии 18.1.0.70_5
видно, как в одном QSO данный режим дважды выручил, не дав сорваться ни одной передаче, вовремя поменяв сообщения на нужные!!!!!!!!

Но вылезли три явные бяки:
1. В конце связи зачем-то начинает второй раз передавать RR73, но в течении 3-5 секунд меняет его на CQ.

это в режиме TX/RX Split, а в режиме TX=RX начинает второй раз передавать RR73, но в течении 3-5 секунд просто прекращается передача.
Автоматическое или ручное сохранение QSO на эту бяку не влияет.

2. Трижды во время CQ прерывалась передача и до окончания периода ни одна кнопка управления передачей не откликалась. (не было ни в одной версии)

3. TX watchdog выскакивал пару раз и делал неактивным Enable TX прямо посредине QSO, такого тоже вроде не было ни в одной версии, TX watchdog всегда давал закончить связь.

[UA3DJY]

Но вылезли три явные бяки:
1. В конце связи зачем-то начинает второй раз передавать RR73, но в течении 3-5 секунд меняет его на CQ.

это в режиме TX/RX Split, а в режиме TX=RX начинает второй раз передавать RR73, но в течении 3-5 секунд просто прекращается передача.
Автоматическое или ручное сохранение QSO на эту бяку не влияет.

завершением QSO является получение сообщения 73 от корреспондента либо неполучение повторного RR73 сообщения если корреспондент использует RR73, файл ALL.TXT Вам покажет когда было декодировано сообщение 73 либо когда закончилось декодирование интервала в случае ожидания повторного RR73: до или после начала передачи, изменение 18.1.0.70_5 в AutoSeq1 не ускорило работу процессора

2. Трижды во время CQ прерывалась передача и до окончания периода ни одна кнопка управления передачей не откликалась. (не было ни в одной версии)

Что предшествовало обрыву передачи CQ? кусок файла ALL.TXT пожалуйста, посмотрим код

для сценария продолжительного CQ смотрите ниже

3. TX watchdog выскакивал пару раз и делал неактивным Enable TX прямо посредине QSO, такого тоже вроде не было ни в одной версии, TX watchdog всегда давал закончить связь.

TX watchdog таймер перезапускается при использовании кнопок мышки в основном окне интерфейса, какой режим внесения QSO в лог Вы используете? Возможно добавим перезапуск таймера при ручном внесении в лог или при использовании приглашения внести в лог. В случае продолжительного CQ когда Вас не зовут увеличивайте значение TX watchdog таймера в настройках закладки Settings->General.

[UA3DJY]

Ну во-первых ОГРОМАДНЕЙШЕЕ СПАСИБО, Игорь, что обратили внимание. Протестировал режим AutoSeq1, работает адекватно, как и call first в JTDX v.34,
т.е. всегда отвечает на сообщение декодированное уже в момент передачи и автоматически изменяет передаваемое сообщение на нужное в зависимости от ситуации.

Но вылезли три явные бяки...

Первичная причина проблем в настоящем дизайне AutoSeq JTDX, который не рассчитан на работу с совсем медленными процессорами.

В версии 18.1.0.34 в алгоритм было заложено что факт передачи сообщения RR73/73 является окончанием QSO, что не есть правильно с точки зрения корреспондента, поскольку он QSO еще не завершил при передаче оператором RR73/73 и мог это сообщение просто не декодировать.

Такой неправильный подход корректировался следующим сценарием: "если корреспондент не получил от меня RR73/73 то он снова передаст рапорт или RRR, и в этом случае AutoSeq JTDX повторит либо рапорт либо сообщение RR73/73, исходя из повторно принятого сообщения". То есть считалось что отсутствие декодированного 73 от корреспондента является сбоем в декодировании а корреспондент это сообщение якобы "передал", значит если переданное корреспондентом сообщение не декодировано то QSO завершено. Такой подход приводил к тому что в лог нередко попадали QSO незасчитанные корреспондентом, например когда частота была заблокирована более мощным сигналом или изменилось прохождение. Оператор не видя повторов сообщений тоже считал что QSO завершено, что не всегда было истиной.

После версии 18.1.0.34 дизайн AutoSeq был изменен, считается что QSO завершено если от корреспондента получено сообщение 73, либо не получено от него повторное RR73 (для укороченной последовательности). Поэтому принципиально окончание декодирования интервала и на слабых процессорах как ни крути мы получаем либо повторную передачу сообщений либо смену сообщения на ходу.

С точки зрения AutoSeq FT8 вариант последовательности RRR+73 позволяет избежать части сбоев по сравнению с укороченным вариантом RR73, именно по этой причине команда WSJT ранее считавшая в JT65/JT9 что сообщение RRR завершает QSO поменяла свою точку зрения и сделали в FT8 более длинную последовательность RRR+73.

Как обрабатывает такие варианты WSJT-X на Вашем процессоре, меняет ли сообщение RR73 на ходу на сообщение CQ при позднем декодировании?

И если WSJT-X не декодировал финальное 73 от корреспондента (совсем не декодировал или не декодировал до начала интервала передачи), он переходит на передачу общего вызова считая что QSO завершено?