Не пойму почему в Serial Port было выставлено Omni Rig1.... Это ставится в RIG....Вот настройки мои...работает и в связке с UR5EQF и автономно JTDX....Вложение 205193
Не пойму почему в Serial Port было выставлено Omni Rig1.... Это ставится в RIG....Вот настройки мои...работает и в связке с UR5EQF и автономно JTDX....Вложение 205193
Нечто подобное было и у меня.
При инсталяции OmniRig он прописался куда ему надо по умолчанию. В панели все программы появился(сь закладка) OmniRig.
Закройте все прораммы, использующие его и просто запустите OmniRig. Выставите там порт который Вам нужен. Да, скорость
лучше ставить 9600 и поиграться RTS DTR - LOW Poll 100 Time 100
RA3QH - Да, правильно указали на мою ошибку. Сделал в RIG, а написал неправильно.
RA1WU - я пробовал все скорости обмена, что есть в настройках. Разницы нет никакой. У вас трансивер ICOM. У меня YAESU. Настройки отличаются. OmniRig у меня установлен на компьютере с момента покупки. А это уже лет 8-9. Все работало прекрасно. Этот сбой в работе я связываю с JTDX. 100%!! Надо смотреть в программе. Более ранние версии работали на "УРА". А теперь и старые версии не работают ((. Даже WSJT-X 1.18.0 Надо бы попробовать JT65-hf. Эта совсем древняя версия этой программы. Интересно, что получиться.
P.S. Сейчас установил JT65-hf. Запустилась, как и раньше, из "Внешних программ" UR5EQF. Частота отображается. на передачу встает автоматом. Все работает. Вот так!
Может, наконец-то, Игорь что-то скажет по этому поводу? Не у меня одного такая проблема.
У меня похожая, но несколько иная история.
Возился с настройками по всякому... То одно не идет, то другое.. Сейчас использую с компом переходник USB-COMx4. Настройки прог JTDX WSJT-x, по сути одинаковые. На СОМ12 - РТТ, на СОМ15-САТ. Нажимаю на ТЕСТ САТ- она превращается в зеленую. Значит САТ ОК. Жму ТЕСТ РТТ- она становится красная!. Значит не ОК? А вот, и нет... РТТ отлично работает, все переключает . Такие чудеса в прогах...
Нужно отметить, что этот переходник не любит, даже очень малые, наводки ВЧ. Чуть тюнером не подстроишь- слетают СОМ порты. Поэтому, приходится вещать на 50ватт макс. Частенько, этого не хватает...:s8:
Если вы работаете с JTDX через EQF, то его нужно запускать через интерфейс (JTDXInterface). В интерфейсе поставьте птички в настройках JTDX - ControlOmniRig и Freq from JTDX. В настройках JTDX поставьте вместо омнириг данные своего трансивера и данные настройки САТ своего трансивера. При запуске интерфейса омнириг отключится и трансивер будет управляться через СОМ порт (САТ). РТТ настройте либо через САТ либо через второй СОМ порта (RTS).
У меня Yaesu-450D. Проблем нет.
У меня нет и не было никогда никаких виртуальных переходников. В моем компьютере есть два физических СОМ-порта. СОМ1 для САТ-системы, СОМ2 для CW манипуляции. Мне этого вполне хватает. Поэтому и не тороплюсь менять компьютер на новый. Его тактовой частоты процессора, 2,9Ггц при 320 Ггб ПЗУ и 2Ггб оперативки вполне хватает для работы в "цифре". Ну, может, иногда, не хватает второй звуковухи. Но это дело поправимое.
Вот мои настройки
Вложение 205207
Вложение 205208
[QUOTEP.S. Сейчас установил JT65-hf. Запустилась, как и раньше, из "Внешних программ" UR5EQF. Частота отображается. на передачу встает автоматом. Все работает. Вот так!
Может, наконец-то, Игорь что-то скажет по этому поводу? Не у меня одного такая проблема.
Последний раз редактировалось RX4CD; Сегодня в 20:28.][/QUOTE]
У меня вот-так и всё работает без проблем
Вложение 205209
Здравствуйте, уважаемые. Хочу добавить "каплю дегтя в бочку меда". Активно тестил(около 500 QSO в неделю) последнии версии JTDX в FT8, периодически откатываясь на 34 версию.
В режимах AutoSeq1 и 2 при работе на CQ (загруженность диапазона 15-20 станций и более) не происходит автоматического ответа 9 станциям из 10 зовущим сплитом, приходиться жать на нужные макросы вручную.
Но это ведь не нормально, особенно для автоматического режима. Причины Игорь объяснял, не успевает декодировать(за 2 секунды!) да начала передачи, хотя декодирование продолжается и в момент передачи.
Почему бы не сделать изменение сообщения в момент передачи, как это реализовано в режимам "call first" в JTDX v.34 и в режиме "AutoSeq + call 1st" в wsjt-x. Сейчас многие, почти 50% вызывают именно сплитом,
поэтому для меня лично и для моих друзей р/любителей данные режимы являются как бы помягче сказать - не состоятельными, ну или не совсем пригодными для использования.
В режиме AutoSeq3 на лицо навязывание использования самых мощных достижений науки(процессоров).
Ну это вы наверно и сами заметили, какая началась суета вокруг процессов и процессоров на форуме с появлением AutoSeq3.
При тестировании AutoSeq3 на моем "железе"Вложение 205211 (загруженность диапазона 15-20 станций и более) при работе на CQ
программа смогла автоматически ответить с первого раза в среднем только 1 станции из 10,
остальным приходилось отвечать вручную или можно подождать второго цикла автоматического ответа. Что тоже не устраивает многих даже с машинами выше среднего уровня.
И вот вам еще один существенный минус режимов AutoSeq 1,2 и 3 - если при отказе автоматики, не отвечать вовремя на сообщения вручную, то одно и тоже сообщение будет передаваться как минимум дважды,
т.е. происходит увелечение времени QSO и что самое актуальное - засорение эфира ненужными повторными сообщениями, а популярность FT8 и насыщенность диапазонов станциями и так растет с каждым днем.
Может уже и сами стали замечать - вроде станция идет громко, а сообщения передает по два раза, как-будто не принял с первого раза.)
Кстати и при работе на поиск есть недостатки - вам могут ответить не на той частоте, где вы ожидали или поменять частоту в процессе QSO и опять автоматика не справиться.
Какие я вижу решения:
1. Пока использовать 34-ую сборку, в режиме call first - он работает, как режим AutoSeq + call 1st в программе wsjt-x. Если кто-то из новичков еще не пробовал, объясню, как это работает:
Любое сообщение переданное для вас и декадированное уже в в момент вашей передачи(после 2 сек. отведенных на прием),
немедленно обрабатывается и ваше сообщение в зависимости от ситуации автоматически меняется на нужное и идет адекватный ответ,
причем он будет 100% декодирован корреспондентом, если это произошло в первой половине вашей передачи, а это целых 6,5 секунд, именно эти 6,5 секунд не используются для маневра в последних версиях в режимах autoseq 1,2 и 3.
Например вы работаете на "CQ". Вас вызывает RM1O. Позывной декадирует только на 3 секунде, а у вас уже передаётся новое сообщение "CQ",
автоматика моментально в момент передачи сообщение "CQ" меняет на рапорт для RM1O и он уже в этом периоде примет от Вас рапорт. И не надо никаких мощных процессоров и не надо ждать окончания декадирования всех сообщений на диапазоне.
2. Убедительно ВСЕМ просить Игоря, сделать режим AutoSeq"№" аналогичный режимам call first в JTDX v.34 или AutoSeq + call 1st в wsjt-x. Хотя это уже неоднократно делали(просили) и такое ощущение,
что кто-то имеет эксклюзивные права на этот режим, но не Игорь. (((
Ну и ещё пару слов в поддержку внедрения(возвращения) следящего "Eable TX"(как в 34 версии). Например вы кого-то дозываетесь в сторонке сплитом.
Дали один вызов и ждете. Интересующий вас оператор, закончил QSO, ответил Вам, а у Вас автоматически включается "Eable TX" и автоматически проводится связь.
Мне дак очень нравиться эта функция, а ещё она позволит также снизить плотность сигналов на участке.
Будет меньше постоянно вызывающих станций, а постоянно они вызывают только потому что-бы был постоянно включен "Eable TX", что бы автоматика не пропустила ответ, а так позвал разок и ожидаешь...
Игорь, не принимайте в штыки, ничего личного, но если на великолепно реализованный JT65 в JTDX вы буквально (в хорошем смысле) подсадили почти весь мир, то в FT8 в JTDX на сегодня просматривается какая-то дискриминация что-ли...
То RM1O....Александр...не знаю почему у вас так, но у меня во 2-м режиме сплитом 9 из 10 нормально схватывает и связь идет в "автомате"....3-й режим не использовал т.к считаю свой комп неподходящим по параметрам для этого....Вложение 205212
в данный момент 68-ю версию использую....режим 2+4 тоже никаких нареканий....
При работе на CQ??? Сомневаюсь... Может загруженность диапазона маленькая - меньше 10 станций, тогда с нашим "железом" может и возможно декодирование и формирование сообщения за 2 секунды. Согласен, когда уже "схватило" и зеленая скобка указала частоту корреспондента, тогда уже связь проходит без проблем, т.к. декодирование в участке зеленой скобки идет первоочередно, если только корреспондент не решил сменить частоту... ) В 34 версии у Вас будет всегда 10 из 10!
Не хочу категорично это утверждать ,но периодически устанавливаю новую последнюю версию,тестирую для себя конечно и выполнив все действия по удалению возвращаюсь на стабильную 034. 10 из 10! Понимаю что идет громадная работа по усовершенствованию и доводке новых версий и их тестирование командой.Если что то у меня явное "вылазит" докладываю здесь в теме и ожидаю стабильной полной версии.Отвлекать не нужно ,а только помогать.Большая благодарность Игорю и команде!
ну на 80 так не бывает...менее 10:s7: около 20...я не 500 связей провел на этой версии...меньше,были как мне показалось проблеммы,но оказалось что мне надо матчасть было изучать тщательнее:s7: долго сидел на 48-й,сейчас 68-я и откатываться не буду,все пока устраивает...это конечно только мое мнение и написал то что сам наблюдал во время работы,в днях активности ARCK активно звали....
У меня недавно, момент я не зафиксировал, тоже начались проблемы с OmniRig. Я читаю форум и все больше убеждаюсь, что проблема кроется в программе JTDX. До этого на разных компах и в разных Windows-ах OmniRig работал как часы. Где-то чего-то поломалось. Это моё мнение.