100% поддерживаю эту версию! Что-то разработчики не досмотрели. Если что-то случилось бы с Omni Rig, ну, драйвер слетел или еще что-то, то и другие программы, использующие его, тоже не работали бы. Да и сразу у многих такое вряд ли могло случиться. Говоря словами персонажа из мультфильма "Трое из Простоквашино"Цитата:
Сообщение от VA3LLZ
...-Это только гриппом все вместе болеют, а с ума сходят поодиночке".
"Сразу у многих" - это СКОЛЬКО ЧЕЛОВЕК? :)Цитата:
Сообщение от RX4CD
Если у десятка пользователей и "слетело", а у остальных сотен все нормально,
то наверное как раз в тему Вашей цитаты... :)
Для начала обратите внимание, какой именно OmniRig используете. Откуда он?
Из дистрибутива лога, или напрямую скачан у автора??? Были случаи, когда в
дистрибутивах логов он, скажем так, не совсем правильный был...
А Игорь как раз в исходники CAT (насколько я знаю) никаких изменений не вносит...
PS И так форум с конкретной темой больше похож на курсы по ликвидации безграмотности... :)
Хоть укажите какую (34ю, 68ю или 69ю), а то точно, как в мультике...Цитата:
Сообщение от RX4CD
Новая WSJT вышла, установил, поработал... хорошо, только привыкли уже к фильтрам, и др. фичам JTDX.
Но работает стабильно! Не нравится только управление частотой RX - TX, если бы тоже как в JTDX - перешёл бы (хотя имею и 6 ядер, и 8 Гб).
Уж очень много вариантов, и везде свои но!
P.S. - в смысле много разных настроек, и AutoSeq, и Misk и других...
Верю, что доработается и упростится, но смотрю некоторые работают на MSHV!!! Не понимаю...
и компютер обновить, почти как трансивер по деньгам (особо у нас)...
"а сколько той жизни?" сказал мой друг после инсульта, вопрос очень широк философски, и жизненно.
Пока хочется, пока и живём!
Так он и создан для этого. Если уже "грамотный", то чего тут делать?,Цитата:
Сообщение от R0JF
Добрый день. Все время работаю с OmniRig и ни разу проблем не было. Чего и Вам желаю!
Если Вы в EQF выключаете управление трансивером, т.е. ставите Rig type NONE, то управление передается OmniRig. Значит проблема в нем. Посмотрите откуда он запускается. Их (OmniRig), может быть несколько на Вашем компьютере и все с разными настройками. Попробуйте обновить Rigini для своего трансивера.Цитата:
Сообщение от RX4CD
Если компьютер "самостоятельно"перенастраивается на другой COM порт, то однозначно, какой то программой это порт ему присвоен. И не обязательно что это может быть JTDX. Может быть Вы недавно подключали какое либо устройство к USB порту. Вот настройки и сохранились.
Что бы не дать компютеру видеть ненужные запускаемой программе порты, снимите галочку Serial Enumerator (Обнаружение устройств Plug-and-Play) в свойствах порта COM1. Ни WSJT, ни JTDX никакого отношения не имеют к настройкам вашего компьютера. Что Вы установили, то программа и "скушала"
[QUOTE=UA1OMZ;1442507]2. "Убедительно ВСЕМ просить Игоря, сделать режим AutoSeq"№" аналогичный режимам call first в JTDX v.34 или AutoSeq + call 1st в wsjt-x."
Согласен на все 1000%.
Тестировал различные версии выше JTDX v.34
по прежнему убежден-самая стабильная версия JTDX v.34.Все остальные "от лукавого"-кому как повезло с PC и различным софтом.
И еще о загрузке процессора.
Если вы заметили странную "тормознутость" компьютера при работе JTDX, то обязательно проверьте компьютер на подозрительные запущенные процессы.
Дело в том, что в последнее время набирает популярность распространения браузерного майнера, который добывает криптовалюту без ведома пользователя, используя мощности вашего процессора и видеокарты.
К сожалению, только на антивирусы здесь полагаться не стоит. Разработчики антивирусного программного обеспечения, как правило, программы Майнеры считают не зловредными. В лучшем случае они входят в выделенную категорию Riskware — ПО, которое само по себе легально. Но мощности вашего компьютера они отберут прилично! На днях у товарища, не связанного с радио, отловил пару таких процессов. После их удаления, загрузка процессора пришла в норму.
попробуйте пожалуйста AutoSeq1 в версии 18.1.0.70_5Цитата:
Сообщение от UA1OMZ
собранный софт 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 доработан на вызов первого позвавшего но с полным декодированием/обработкой всех сигналов и сменой сообщения в том числе во время передачи.
А чего их искать. Самый известный случай – попытка разработчиков μTorrent таким образом дополнительно заработать на пользователях внедрив в софт скрытый майнер EpicScale. Ну и у всех остальных клиентов (bittorrent и т. д.) этой группы возможно присутствие такого майнера, ведь клиент всегда подключён к сети, очень удобный майнинг для создателей.Цитата:
Сообщение от EU1FQ
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!
прошу прощения за флуд у модераторовЦитата:
Сообщение от RK1NA
Сюда на форум заходят разные люди, тестеры и профессионал в вашем лице, и те кто сов7 о цифре не имеет никакого представление, начиная работать digi
Им еще далеко до совершенства и понятие о САТы, Омнириги, Ригэкмперты и в вашем случае виртуальные COM порты, для них, из области фантастики, поэтому они и задают вопросы здесь сталкиваясь с определенными проблемами.
А кто им поможет как не мы с вами (вы как профессионал я как любитель) проработавшие уж с десяток лет разными цифровыми модами?
Лопатить 1000ми страниц форума, тоже не вариант.
создавать 10ки форумов как настроить САТы, Омнириги, Ригэкмперты? :s11:
автору писАть мануалы с картинками? :s11: тоже смешно... ему есть чем заняться
у нас ветка форума --- работа с тестовым софтом а не круг постоянных и грамотных тестеров,
которые все знают и про САТ не спрашивают... д
и разницы нет любитель ты или профессионал (прогу пишут для всех:s11:), главное результат
а он есть, люди интересуются программой, работают в эфире и наслаждаются жизнью...
может я в чем то и не прав, думаю меня поправят
Ну во-первых ОГРОМАДНЕЙШЕЕ СПАСИБО, Игорь, что обратили внимание. Протестировал режим AutoSeq1, работает адекватно, как и call first в JTDX v.34,Цитата:
Сообщение от UA3DJY
т.е. всегда отвечает на сообщение декодированное уже в момент передачи и автоматически изменяет передаваемое сообщение на нужное в зависимости от ситуации.
Вот фрагмент работы AutoSeq1 в версии 18.1.0.70_5 Вложение 205247
видно, как в одном QSO данный режим дважды выручил, не дав сорваться ни одной передаче, вовремя поменяв сообщения на нужные!!!!!!!!
Но вылезли три явные бяки:
1. В конце связи зачем-то начинает второй раз передавать RR73, но в течении 3-5 секунд меняет его на CQ.
Вложение 205250 Вложение 205251 Вложение 205252
это в режиме TX/RX Split, а в режиме TX=RX начинает второй раз передавать RR73, но в течении 3-5 секунд просто прекращается передача.
Автоматическое или ручное сохранение QSO на эту бяку не влияет.
2. Трижды во время CQ прерывалась передача и до окончания периода ни одна кнопка управления передачей не откликалась. (не было ни в одной версии)
3. TX watchdog выскакивал пару раз и делал неактивным Enable TX прямо посредине QSO, такого тоже вроде не было ни в одной версии, TX watchdog всегда давал закончить связь.
завершением QSO является получение сообщения 73 от корреспондента либо неполучение повторного RR73 сообщения если корреспондент использует RR73, файл ALL.TXT Вам покажет когда было декодировано сообщение 73 либо когда закончилось декодирование интервала в случае ожидания повторного RR73: до или после начала передачи, изменение 18.1.0.70_5 в AutoSeq1 не ускорило работу процессораЦитата:
Сообщение от UA1OMZ
Что предшествовало обрыву передачи CQ? кусок файла ALL.TXT пожалуйста, посмотрим кодЦитата:
Сообщение от UA1OMZ
для сценария продолжительного CQ смотрите ниже
TX watchdog таймер перезапускается при использовании кнопок мышки в основном окне интерфейса, какой режим внесения QSO в лог Вы используете? Возможно добавим перезапуск таймера при ручном внесении в лог или при использовании приглашения внести в лог. В случае продолжительного CQ когда Вас не зовут увеличивайте значение TX watchdog таймера в настройках закладки Settings->General.Цитата:
Сообщение от UA1OMZ
Первичная причина проблем в настоящем дизайне AutoSeq JTDX, который не рассчитан на работу с совсем медленными процессорами.Цитата:
Сообщение от UA1OMZ
В версии 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 завершено?