Я бы вместо СOM2 сделал другой порт. COM2 на компах тоже вроде к "железным" относится... Из-за этого может не идти...
Вид для печати
Я бы вместо СOM2 сделал другой порт. COM2 на компах тоже вроде к "железным" относится... Из-за этого может не идти...
Стоит "галка" PTT и CW одним портом.
- - - Добавлено - - -
Вложение 318773
То, что программа виртуальных портов так назначила еще ничего не значит... Попробуйте эту пару поменять и убрать СOM2 из этого списка.
У Вас еще COM11 есть. Можно попробовать разнести CW PTT. Соответственно сняв галку в настройках Радио.
Ну и тогда еще, как вариант, попробовать CW через порт CAT. Настройки не подскажу.
Ну и уж извините, посоветую приобрести продукцию microHam. Например, microKeyerIIII. Забудете все проблемы.
Лично я жду прихода Kenwood 890 и такого устройства. Но это другая тема.
Да, PTT срабатывает.
Раньше, по крайней мере работал. Давно не включал. Проверю с 5MContest.
Пробовал. Не пошло.
Он занят в RigSync. Ведь конечная цель сего действа - настроить работу связки TS-990s+SunSDR2PRO+SDC+LogHX+5MContest.
первые три пункта настроены, LogHX наполовину, до 5М пока ещё не добрался.
- - - Добавлено - - -
Пробовал, не помогло.
To: R0WC
Вы так и не ответили на вопрос, как организована манипуляция CW?
"Стоит "галка" PTT и CW одним портом" это не ответ. Каким кабелем и с какого USB порта компьютера и на какой разъем трансивера подается сигнал для осуществления ключевания? Не PTT, а именно ключевание!
Никогда его не было, и не будет. Это атавизм. Всегда всё работало и без подключения кабеля "к разъёму ТЛГ ключ". К этому разъёму ТОЛЬКО ключ!
Этот вопрос сложнее. Если бы я это знал, как осуществляется ключевание, то не задавал бы вопросов. Теперь по существу и по кабелям (уже писал об этом выше, повторюсь):
1. С разъёма REMOTE трансивера, через "коробочку", идёт кабель на USB разъём компьютера. Это COM4. Раньше манипуляция шла через него.
2. С выхода USB трансивера на вход USB компьютера простым USB кабелем через драйвер Silicon Labs CP210x USB to UART получаем COM5. Только с этим портом заработал RigSync от SDC.
- - - Добавлено - - -
Настораживает следующее:
Вложение 318783
На всякий случай удалил драйвер и переустановил по инструкции (не включая кабель в трансивер)... Всё равно такая надпись. А как его "доустановить", если он самодостаточен и больше не проявляется?
Не совсем так. Что бы работало так, как Вы написали, т.е. без подключения кабеля "к разъёму ТЛГ ключ", необходимо задействовать драйвер Silicon Labs CP210x USB to UART.
Этот драйвер у Вас установлен (COM5), но задействован для RigSync от SDC. Т.е. манипуляции, без отдельного кабеля на разъем KEY и драйвера Silicon Labs CP210x USB to UART для этих целей, не будет.
Опять что-то путаете. Разъём REMOTE трансивера предназначен для других целей, к примеру, управлением УM, но никак для манипуляции CW.
Не имею понятия, что за неизвестная "коробочка", но думаю, что это скорее всего и есть интерфейс для манипуляции CW. Тогда, если Вы хотите использовать для PTT/CW порт COM4, отличный от стандартного для 590S использования порта, созданного при помощи Silicon Labs CP210x USB to UART (COM5), то манипуляцию нужно через "коробочку" заводить на разъем KEY трансивера. По другому, никак. Или, если нет такого желания, то использовать для целей манипуляции COM5. Использование ACC2 не рассматриваю.
Загружаю в свой лог адиф с клаблога, в котором имеется тег <QSL_RCVD:1>Y<QSLRDATE:8>20210810.
После загрузки отметка о получении QSL имеется, но, нет даты в поле DATE. Пожалуйста, подскажите, как сделать, чтобы дата отображалась после загрузки адифа?
Вложение 318794
Я думаю, что это не есть очень хорошее желание, что бы после загрузки с ClubLog, в этих полях были отметки. Дело в том, что эти поля предназначены для бумажных QSL,
а никак для ClubLog, LoTW и т.д. Да, если скачать напрямую с ClubLog адиф файл, то в нем присутствуют теги <QSL_RCVD:1>Y<QSLRDATE:8>. Но не зря, что бы не вносить путаницы по подтверждениям, Алексей убрал эти теги из файла и они не учитываются при синхронизации лога с ClubLog. Конечно, всегда есть возможность что то обойти, но надо подумать, как это отразится для остальной части лога, хотя бы в части статистики по видам подтверждения.
Кто о чем, а я все о пьяном матросе. После установки CW priority в состояние "critical", события от мышки остаются все равно более приоритетными, чем события от телеграфного таймера. И простое перемещение мышки по экрану по-прежнему замедляет телеграф. У меня связка HX-ESDR2 через TCI и свеже-установленная пока еще ничем не испорченная Win10. Средняя загрузка процессора 25%, но степень трезвости матроса от загрузки не зависит. Можно ли тут еще что-нибудь доработать?
Телеграф замедляется, а не рвется. Поэтому я делаю обоснованный вывод о том, что проблема именно на стороне лога, т.е. там, где происходит формирование посылок.
О! Тогда все выше сказанное не имеет смысла - манипуляция CW/PTT работает! Получается только макросы не работают. Это вообще очень странно. Что, на макрос [TX] не переходит на передачу? Очень странно....
Эта настройка влияет только для CW через COM порт. При передаче через TCI не влияет. Передача CW как идет?
Вообще очень странно - перемещение мышки замедлять телеграф не должно ни при каких условиях! Это очень маленькая загрузка системы.