-
08.01.2017, 13:22
#3856
Координатор темы
Сообщение от UA0YAS
Если комп очень старый, какие цифры нужно ставить в Advanced? Стоит 2 2 3, до конца минуты не успевает декодировать.
Для совсем слабого процессора 1-2-1, если другие софты не грузят процессор и декодирование не вписывается в приемный интервал то переход на софт WSJT-X.
-
08.01.2017, 13:26
#3857
Standart Power
Вот небольшая статистика
Вложение 179131
Больше просто не влазеет.
-
08.01.2017, 13:36
#3858
I am who I am
Попробую WSJT-X поставить, для проверки
Сообщение от UA3DJY
на форуме каждый второй пользователь успешно использует несколько софтов и VSPE, не спешите опускать руки
Поэтому и странно. У меня тоже весь имеющийся софт работает через VSPE…
Попробовал небольшой эксперимент. Все проги закрыл, в этом случае при запуске JTDX все хорошо, САТ работает, при повороте валкодера изменение частоты отображается в программе, на передачу включается.
Стоит только запустить что-угодно (пробовал HRD или N1MM) — тут же САТ в JTDX отваливается. Кружок рядом с диапазоном меняется так: зеленый-оранжевый-зеленый-красный. После этого пишет «Rig Control Error» и предлагает переконфигурировать интерфейс. Если в момент запуска программы-«конкурента за порты» нахожусь в JTDX на вкладке Setting-Radio, то текст ошибки чуть другой: «Rig failure» и в подробностях «Hamlib error: Communication bus collision while getting current VFO».
При этом у программы-конкурента (или нескольких их) никаких «коллизий» не происходит, все в порядке и работает.
Видимо, все таки дело в каком-то «особенном» способе работы с портами у JTDX Сообщение от R0JF
Да все допилено, раз у Вас одного не работает… У всех-то нормально…
Даже не знаю, спросить ли — а настройки порта совпадают? Скорость, четность,
стоп-биты…Я бы из принципа нашел причину. От админа никакие приложения, работающие с
портом не запущены? Порт система не «усыпляет» для снижения энергопотребления?Совпадают. Не усыпляют. И т.д.
Исходите из того, что JT-65 HF, HRD, N1MM — все работают без проблем вместе.
А то, что у других все работает — может, дело в конкретной конфигурации.
У меня Win 10 Home 64bit, VSPE 0.938.4.846Последний раз редактировалось RU6B; 08.01.2017 в 13:43.
73! Сергей, RU6B
-
08.01.2017, 13:38
#3859
Координатор темы
Сообщение от RA9XQ
Странно, а я думал что оператор должен сам подбирать значения из соображения производительности своей системы и времени чтобы уложится в тот лимит который ему предоставлен. Я уложился в 10-ти секундный интервал и как некоторые не жду декода ещё и в следующем периоде. В чём криминал?
Я попытался понять как определялась эквивалентность установок WSJT-X и JTDX. В том что JTDX ест намного больше ресурсов сомнений нет, это преднамеренно заложено в дизайн — использовать все что имеется, или с каждой вложенной в железо копейки получить отдачу.
Но на каждой машине свои ресурсы и софт WSJT-X их не полностью использует. При переходе с одного ядра на два и более начинает работать многопоток и снижается время декодирования.
Сказать что софт JTDX непригоден если ему не соответствует железо будет некорректно, примерно как отказаться от цифрового телевидения из-за большого парка ламповых телевизоров, более того, в будущих версиях буду усложнять функционал чтобы в JTDX можно было полностью использовать и самое современное железо.
-
08.01.2017, 13:44
#3860
Координатор темы
Сообщение от RU6B
пишет «Rig Control Error» и предлагает переконфигурировать интерфейс. Если в момент запуска программы-«конкурента за порты» нахожусь в JTDX на вкладке Setting-Radio, то текст ошибки чуть другой: «Rig failure» и в подробностях «Hamlib error: Communication bus collision while getting current VFO».
Вот теперь разговор становится предметным. Вы пробовали в JTDX вместо Hamlib выставить/использовать OmniRig?
И тот и другой софт для JTDX внешний, и сбой идет вне JTDX.
-
08.01.2017, 13:55
#3861
Standart Power
Сообщение от UA3DJY
Софт JTDX работает независимо от диапазона, для какого функционала Вы хотите активировать Enable VHF/UHF/Microwave features?
Чтобы полноценно использовать софт на УКВ Вам придется создать самому или найти в Интернете УКВ файл CALL3.TXT.
Софт WSJT-X 1.7 наверно отличается от JTDX возможностью изменения частоты передатчика через CAT следуя за приемом при эффекте Доплера, точный функционал надо смотреть в документации на WSJT-X.
Да, хочу активировать. А файл CALL3 который тут есть разве не подходит?
-
08.01.2017, 13:55
#3862
I am who I am
Сообщение от UA3DJY
Вы пробовали в JTDX вместо Hamlib выставить/использовать OmniRig?
И тот и другой софт для JTDX внешний, и сбой идет вне JTDX.Где-бы еще найти этот выбор?
Туплю, наверное, но ни в одной из программ (HRD и N1MM) никаких Hamlib, OmniRig не ставил отдельно. Может, они там где-то глубоко интегрированы, но кроме выбора порта и его параметров — больше ничего не нужно было.
А если Hamlib, OmniRig у меня не установлено (не уверен), то как же тогда JTDX работает «в одиночестве» нормально, через тот же VSPE?
-
08.01.2017, 13:59
#3863
Very High Power
Сообщение от RU6B
Где-бы еще найти этот выбор?
Там где прописан FT-2000
И попробуйте в свойствах виртуального порта снять галочку «Обнаружение устройств Plug fnd Play. Помогает при запуске других программ использующих виртуальные порты
-
08.01.2017, 14:01
#3864
Координатор темы
Сообщение от RU6B
Где-бы еще найти этот выбор?
У Вас COM5, 4 это виртуальные порты. Если выставлены существующие (особенно в CAT Control), то естественно будет конфликт с другим софтом, где используются такие же порты. К одному порту может одновременно подключится только одна программа. Для развода и используют виртуальные. В других программах тоже выбираются виртуальные, тогда конфликта не должно быть.
-
08.01.2017, 14:05
#3865
Сообщение от UA3DJY
-24дБ файлы плохо показывают чувствительность софта, поэтому для тестов я использую -25дБ файлы, результаты и условия тестирования публикую как на форуме так и в комплекте с исходным кодом.
Чувствительность думаю не самое главное хоть и немаловажно, стабильность, отсутствие ошибок в работе имеет ни чуть не меньшее значение. Тестироваться должно на всём, на низких, на высоких, с шагом 1-2-3 и т.д. и очень плохо что всё одному. Разные системы, разное железо — нужны тестеры. Я понимаю когда тебя облизывают это приятно но ещё нужна и реальная помощь.
Теперь про Advanced, если что то может негативно повлиять то не стоит ли жестко ввести блокировку значений, ведь программа рассчитана на широкий круг пользователей и это надо учитывать и принимать меры по защите от необдуманных действий. Пойду посмотрю что за файлы лежат а то я тут вопил, дайте то на чём тестите, хочу честно проверить для себя. И как говорил RK1NA довно пора иметь шапку на каждой странице где будет ссылка на всё необходимое. Сообщение от UA3DJY
. у Вас поломан файл JTDX.INI, такое сообщение Hint декодер дать не может: 0073-25 0.0 2200 # W9XYZ UA3DJY CF00
Файл ini создавался самой программой, я её первый раз загружаю если не считать когда она ломала файл для WSJT-X. В девственно чистый продукт только внёс настройки и всё.
Последний раз редактировалось RC2SC; 08.01.2017 в 14:13.
73! Владимир (RC2SC)
-
08.01.2017, 14:10
#3866
Standart Power
]Вот небольшая статистика
пришлось удалить
-
08.01.2017, 14:10
#3867
Координатор темы
Сообщение от UR6EF
Да, хочу активировать. А файл CALL3 который тут есть разве не подходит?
я и спрашиваю — для чего Вы его хотите активировать? В файле CALL3.TXT есть заголовок с информацией о содержании, в том файле что я создал используются данные со спотов КВ диапазонов + диапазон 6 метров.
УКВ файл CALL3.TXT как то видел на svn репозитарии WSJT-X и в его заголовке был позывной автора из Германии. На форуме немало пользователей работающих на УКВ, кто то может знать где его взять.
-
08.01.2017, 14:20
#3868
Very High Power
Сообщение от RU6B
Где-бы еще найти этот выбор?
А конфиг VSPE можно глянуть?
73! Игорь R0JF ex. RA0JF (Дядя Фёдор)
-
08.01.2017, 14:25
#3869
I am who I am
Сообщение от RU6B
Попробую WSJT-X поставить, для проверки
Поставил. Есть небольшая разница — в настройках в выпадающем меню выбора портом мои виртуальные порты присутствуют.
Но при работе других программ — ошибки те же… Сообщение от US-E-12
У Вас COM5, 4 это виртуальные порты. Если выставлены существующие (особенно в CAT Control), то естественно будет конфликт с другим софтом, где используются такие же порты. К одному порту может одновременно подключится только одна программа. Для развода и используют виртуальные. В других программах тоже выбираются виртуальные, тогда конфликта не должно быть.
Вы с VSPE знакомы? Там есть понятие «сплиттер», к одному виртуальному порту допускается неограниченное количество подключений. И с этим несколько лет прекрасно работают другие программы СОВМЕСТНО.
Сообщение от EU1FQ
Там где прописан FT-2000
И попробуйте в свойствах виртуального порта снять галочку «Обнаружение устройств Plug fnd Play. Помогает при запуске других программ использующих виртуальные портыПробовал выбрать Hamlib, OmniRig — безрезультатно. Может, у меня «это» и не установлено? И зачем? Все ведь работает, пока только JTDX запщена.
Странно, что при выборе «Yaesu FT-2000» в тексте ошибки упоминается Hamlib: «Hamlib error: Communication bus collision while getting current VFO».И в очередной раз: JT65-HF 0.9.96.0, HRD, N1MM (это то, что на данный момент установлено) — работают совместно, хоть все сразу. Почему для JTDX нужно искать проблему «на стороне»? Полагаю, вопрос в ней или в каких-то модулях, ею используемых…
-
08.01.2017, 14:29
#3870
Задался сегодня целью и связал при помощи VSPE и omnirig : JTDX v17.4 и LogHX3, обмен логами также настроился без проблем.
Win 10 Pro x64.
Сообщение от UA0YAS
- Печать
Страницы: 1 … 24 25 [26] 27 28 … 128 Вниз
Тема: WSJTX (Прочитано 377294 раз)
EW1CD и 1 Гость просматривают эту тему.
На скрине
Спасибо Владимир!
Записан
Друзья! Что-то у меня не идёт WSJT-X. На передачу по САТ не включается, частота не выставляется. Два вечера бился. Вроде как всё выставлено нормально. Постоянно горит красный кружок ( рядом с диапазоном) и выдаёт Rig Control Error. Выставляю трансивер или 9100 или 7100 — ни с одним не работает. Управление по РТТ нужно как-то выставлять если управляешь по САТ?
Записан
Владимир.Ex UA1ABM since 1973 г. RW1AY since 1999 г.
QRA: Питер — KO59CU , Дача (Новгород.обл.) — KO68NJ
Записан
Леонид………….Псков
только фиг знает как она декодирует. весь вечер с ra6lc гоняли так ничего и не добились какой бы сигнал ни был а показывает -30 в qra. а jt65 вроде работает.
короче если на луне то ничего не примеш пока будеш тыкать декодировать и бубном трясти. хотел автор чето изобрести новое а получилась ливерная колбаса какя то. так
и пошел спать вчера с какой неудовлетворенностью.
Записан
Друзья! Что-то у меня не идёт WSJT-X
С двумя СОМ-портами работает программа так, как на снимке. Один для САТ (младший), второй для РТТ (старший). У меня в ноутбуке управление через USB Dual Interface.
UPD1: В трансивере проверьте установку Baud Rate.
А если OmniRig используете — проверьте задержки.
UPD2: Если Omni Rig используете и Win8, попробуйте его запускать от имени администратора.
Под Win XP OmniRig со всеми программами ОК работал, а вот с Win8 только от Администратора почему-то (например JT65hf — не показывал частоту).
« Последнее редактирование: 08 Октябрь 2016, 18:07:04 от R3LW »
Записан
73! Михаил.
только фиг знает как она декодирует. весь вечер с ra6lc гоняли так ничего и не добились какой бы сигнал ни был а показывает -30 в qra. а jt65 вроде работает.
Программа работает нормально. Есть декоды до -27 дБ. Только недавно с RM1W работали.
Покажите скрин Вашей программы с водопадом. Будет понятнее вопрос.
UPD: Принимаемый сигнал должен находиться в зелёной зоне F Tol.
« Последнее редактирование: 08 Октябрь 2016, 17:47:44 от R3LW »
Записан
73! Михаил.
R3LW, здравствуйте! В чате Вас нет, жаль.
Прямо сейчас со мной можете QRA64?
« Последнее редактирование: 08 Октябрь 2016, 17:46:22 от UT9UR, Аркадий »
Записан
4xYU7EF-13M; ( ех UT5ER).
только фиг знает как она декодирует. весь вечер с ra6lc гоняли так ничего и не добились
Дмитрий, мой позывной R6LC. Я вчера уснул с чувством «глубого удовлетворения». От UA3WM принял несколько декодов от -31 до -24!
Записан
GE, Аркадий.
Прошу прощения, У меня дома сейчас ремонт заканчивается, трансивер на табуретке, антенны КВ и УКВ не коммутируются и не вращаются — только на 350 градусов направление. Завтра вручную поверну на Вас, попробуем. Чат есть, но обстановка пока не подходящая, неудобно там быстро общаться 
Записан
73! Михаил.
Михаил, не страшно. Только что пробовал с Владимиром, UA3WM, QSO получилось, но не могу сказать, как R6LC Александр «с чувством «глубого удовлетворения». Непонятные моменты есть. Первое-это без видимых причин то не было декода, то вдруг появился!
2. Я работал 5Вт, Владимир-думаю, на тр-р, я принимал от -15 до -7ДБ, Владимир меня-30 и -32.
3. Расстояние у нас -451км. Идет дождь.
4. Версия 1.7.0 rc1-r7163.
Чему научился: надо кликами кнопок мышки подогнать красную скобку на спектране на трек сигнала, это улучшает декод. Надо еще поиграть.
« Последнее редактирование: 08 Октябрь 2016, 18:35:44 от UT9UR, Аркадий »
Записан
4xYU7EF-13M; ( ех UT5ER).
не работает почему-то если в settings выбран ts-2000
У меня работает с ts-2000.
Вижу и вы разобрались.
Записан
144MHz — 2x10HV
432MHz — 4x16H
Тарелька 95см для QO-100 и 5 Ватт.
Димитрий.
Управление по РТТ нужно как-то выставлять если управляешь по САТ?
Владимир, для управления по САТ и с помощью OmniRig сделайте такие установки. Выбираете не тип трансивера, а OmniRig и управление РТТ Port: через САТ, как на снимке.
UPD1: При первом запуске программы в моде QRA64 нет возможности выбора частоты в окошке рядом с кружком. Её надо установить, как по ссылке:
http://forum.vhfdx.ru/wsjt/wsjtx/165
Сообщение #174
UPD2: Ещё заметил на Вашем скрине, что не поставлена «птичка», как показал Владимир UA3WM в сообщении #374 http://forum.vhfdx.ru/wsjt/wsjtx/360
Сделайте ширину водопада от Start 300 Гц до 3000 Гц и кнопкой Bins/Pixel=5. Можно растянуть.
В программе установите F Tol=1000 для начала. Когда увидите сигнал, можно сделать меньше.
« Последнее редактирование: 08 Октябрь 2016, 20:37:31 от R3LW »
Записан
73! Михаил.
сделайте такие установки.
Владимир здравствуйте, хотелось бы уточнить……
вопросы показаны на «скрине»
« Последнее редактирование: 09 Октябрь 2016, 10:08:10 от Anatolij »
Записан
DL8RCB ex UW9EZ
GM, Анатолий.
Я вижу цитата моя, а обращение к Владимиру — отвечу. Это окно активно только при выборе моды JT9+JT65. Тогда над водопадом появляется разделительная линия между JT9 и JT65, у Вас она будет на отметке 2400 Гц.
Записан
73! Михаил.
To DL8RCB: Анатолий, всё верно. Это окошко активно только при включенной моде JT65+JT9, и показывает выше какой частоты декодируются сигналы JT9
Записан
- Печать
Страницы: 1 … 24 25 [26] 27 28 … 128 Вверх
I just installed V2.2.2 64 bit for WIN10 on my computer.
When I start it up I get Rig Control Error every time and it crashes quite often.
Occasionally I also get HAMLIB error.
I know this has been reported numerous times.
However, I do not use HAMLIB and I also do not use rig control at all. I use only RTS on COM1.
Under Radio in Setup Radio has been set to None.
Is there a bug here or I am missing something.
I never had any problems with WSJT-X before at all.
73 de LA3PU Svein
Bill Somerville
On 24/08/2020 13:48, Svein Henriksen
wrote:
I just installed V2.2.2 64 bit for WIN10 on
my computer.When I start it up I get Rig Control Error
every time and it crashes quite often.Occasionally I also get HAMLIB error.
I know this has been reported numerous times.
However, I do not use HAMLIB and I also do
not use rig control at all. I use only RTS on COM1.Under Radio in Setup Radio has been set to
None.Is there a bug here or I am missing
something.I never had any problems with WSJT-X before
at all.73 de LA3PU Svein
Hi Svein,
please report the full rig control error, including details. For
your convenience yo can copy the full error message details to the
Windows clipboard by hitting Ctrl+C while the message window has
keyboard focus (do not attempt to select the text, it is not
necessary). Note that PTT control via RTS or DTR does use the
Hamlib library built into WSJT-X, it’s use is not restricted to
just CAT control or frequency etc..
If you are getting a program crash without any error message;
then there should be an entry in the Windows Event Log, the
details of the log entry maybe helpful in diagnosing the issue.
73
Bill
G4WJS.
Arnold Lausevich <nk9o@…>
Com ports maybe reassigned?
Sent from my Samsung Galaxy , an AT&T LTE smartphone
toggle quoted message
Show quoted text
——— Original message ———
From: Svein Henriksen <la3pu@…>
Date: 8/24/20 7:48 AM (GMT-06:00)
To: main@WSJTX.groups.io
Subject: [WSJTX] Rig Control error
I just installed V2.2.2 64 bit for WIN10 on my computer.
When I start it up I get Rig Control Error every time and it crashes quite often.
Occasionally I also get HAMLIB error.
I know this has been reported numerous times.
However, I do not use HAMLIB and I also do not use rig control at all. I use only RTS on COM1.
Under Radio in Setup Radio has been set to None.
Is there a bug here or I am missing something.
I never had any problems with WSJT-X before at all.
73 de LA3PU Svein
Arnold,
Thanks for the tip but not so. This is a computer with a completely clean WIN install running nothing but WSJT-X and Logger32.
The COM1 is only used for RTS for the time being and nothing else is connected.
73 de LA3PU Svein
toggle quoted message
Show quoted text
From: main@WSJTX.groups.io <main@WSJTX.groups.io> On Behalf Of Arnold Lausevich
Sent: mandag 24. august 2020 15:00
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] Rig Control error
Com ports maybe reassigned?
Sent from my Samsung Galaxy , an AT&T LTE smartphone
——— Original message ———
Date: 8/24/20 7:48 AM (GMT-06:00)
Subject: [WSJTX] Rig Control error
I just installed V2.2.2 64 bit for WIN10 on my computer.
When I start it up I get Rig Control Error every time and it crashes quite often.
Occasionally I also get HAMLIB error.
I know this has been reported numerous times.
However, I do not use HAMLIB and I also do not use rig control at all. I use only RTS on COM1.
Under Radio in Setup Radio has been set to None.
Is there a bug here or I am missing something.
I never had any problems with WSJT-X before at all.
73 de LA3PU Svein
On Mon, 2020-08-24 at 15:28 +0200, Svein Henriksen wrote:
Arnold,
Thanks for the tip but not so. This is a computer with a completely
clean WIN install running nothing but WSJT-X and Logger32.
The COM1 is only used for RTS for the time being and nothing else is
connected.
Which of WSJT-X or Logger32 is using the com port and
talking to the radio?
They cannot both use the same com port
simultaneously,
because then one program might get a response to a
command sent by the other program, and get confused.
If you want both
programs to do rig control, the best
way is to go through a program like hamlib rigctld or
flrig, and have that program be the only one that has
the com port open.
—
All Rights Reversed.
I am very well aware of that.
The COM port only controls the radio PTT via RTS. I do not control the radio via CAT from any of the programs.
But now it has been working perfectly all day.
Could be something that happens after startup. I will have to see if it recurs.
I only installed the new computer yesterday.
73 de LA3PU Svein.
toggle quoted message
Show quoted text
——Original Message——
From: main@WSJTX.groups.io <main@WSJTX.groups.io> On Behalf Of Rik van Riel
Sent: mandag 24. august 2020 19:33
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] Rig Control error
On Mon, 2020-08-24 at 15:28 +0200, Svein Henriksen wrote:
Arnold,
Thanks for the tip but not so. This is a computer with a completely
clean WIN install running nothing but WSJT-X and Logger32.
The COM1 is only used for RTS for the time being and nothing else is
connected.
Which of WSJT-X or Logger32 is using the com port and talking to the radio?
They cannot both use the same com port
simultaneously,
because then one program might get a response to a command sent by the other program, and get confused.
If you want both
programs to do rig control, the best
way is to go through a program like hamlib rigctld or flrig, and have that program be the only one that has the com port open.
—
All Rights Reversed.
Bill,
This morning everything started up without problems and has worked for some QSOs without failing.
But just now, a few minutes after finishing a QSO on FT8, the POPUP window appears.
Rig Error: Do you want to configure the radio interface?
On pressing Details: it says: HAMLIB error: IO error while opening connection to the rig.
Pressing retry and it goes back to working normally.
There is only one COM port (COM1) ant it is used for PTT with RTS.
No rig connected and in setup rig is set to none.
Nothing connected to any of the USB ports.
The WSJT-X is V2.2.2.
On the old computer I was running 2.2.0. Setup the same. Only one COM port and nothing else connected.
I never had this, or any other, problem while using this.
Maybe I need to roll back to 2.2.0.
I seam to remember having read similar reports with regard to HAMLIB on the reflector after the release of 2.2.2.
Is the old versions available on Princeton and any special precautions if rolling back?
Any other suggestions?
73 de LA3PU Svein
toggle quoted message
Show quoted text
From: main@WSJTX.groups.io <main@WSJTX.groups.io> On Behalf Of Bill Somerville
Sent: mandag 24. august 2020 14:54
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] Rig Control error
On 24/08/2020 13:48, Svein Henriksen wrote:
I just installed V2.2.2 64 bit for WIN10 on my computer.
When I start it up I get Rig Control Error every time and it crashes quite often.
Occasionally I also get HAMLIB error.
I know this has been reported numerous times.
However, I do not use HAMLIB and I also do not use rig control at all. I use only RTS on COM1.
Under Radio in Setup Radio has been set to None.
Is there a bug here or I am missing something.
I never had any problems with WSJT-X before at all.
73 de LA3PU Svein
Hi Svein,
please report the full rig control error, including details. For your convenience yo can copy the full error message details to the Windows clipboard by hitting Ctrl+C while the message window has keyboard focus (do not attempt to select the text, it is not necessary). Note that PTT control via RTS or DTR does use the Hamlib library built into WSJT-X, it’s use is not restricted to just CAT control or frequency etc..
If you are getting a program crash without any error message; then there should be an entry in the Windows Event Log, the details of the log entry maybe helpful in diagnosing the issue.
73
Bill
G4WJS.
Bill Somerville
On 25/08/2020 18:46, Svein Henriksen
wrote:
Bill,
This morning everything started up without
problems and has worked for some QSOs without failing.But just now, a few minutes after finishing a
QSO on FT8, the POPUP window appears.Rig Error: Do you want to configure the radio
interface?On pressing Details: it says: HAMLIB error:
IO error while opening connection to the rig.Pressing retry and it goes back to working
normally.There is only one COM port (COM1) ant it is
used for PTT with RTS.No rig connected and in setup rig is set to
none.Nothing connected to any of the USB ports.
The WSJT-X is V2.2.2.
On the old computer I was running 2.2.0.
Setup the same. Only one COM port and nothing else connected.I never had this, or any other, problem while
using this.Maybe I need to roll back to 2.2.0.
I seam to remember having read similar
reports with regard to HAMLIB on the reflector after the release
of 2.2.2.Is the old versions available on Princeton
and any special precautions if rolling back?Any other suggestions?
73 de LA3PU Svein
Hi Svein,
that sounds like RFI problems, does it only happen during QSOs on
one band? Does reducing your transmitter power improve the
situation?
As you say nothing is connected to your PC USB ports I assume
this is a real serial port, you could try some ferrite clip on
chokes at the PC end of the serial cable, or maybe just re-routing
the serial cable to the rig. What interface are you using for the
RTS to PTT switching, and where does it draw power from?
73
Bill
G4WJS.
I had that problem once.
I believe you are getting RF back into
the computer on one (or more) of your lines.
Put some ferrite cores on all the cables and
see if that helps.
73 – Mike
kb0qgt
toggle quoted message
Show quoted text
From: main@WSJTX.groups.io <main@WSJTX.groups.io> On Behalf Of Bill Somerville
Sent: Tuesday, August 25, 2020 12:52 PM
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] Rig Control error
On 25/08/2020 18:46, Svein Henriksen wrote:
Bill,
This morning everything started up without problems and has worked for some QSOs without failing.
But just now, a few minutes after finishing a QSO on FT8, the POPUP window appears.
Rig Error: Do you want to configure the radio interface?
On pressing Details: it says: HAMLIB error: IO error while opening connection to the rig.
Pressing retry and it goes back to working normally.
There is only one COM port (COM1) ant it is used for PTT with RTS.
No rig connected and in setup rig is set to none.
Nothing connected to any of the USB ports.
The WSJT-X is V2.2.2.
On the old computer I was running 2.2.0. Setup the same. Only one COM port and nothing else connected.
I never had this, or any other, problem while using this.
Maybe I need to roll back to 2.2.0.
I seam to remember having read similar reports with regard to HAMLIB on the reflector after the release of 2.2.2.
Is the old versions available on Princeton and any special precautions if rolling back?
Any other suggestions?
73 de LA3PU Svein
Hi Svein,
that sounds like RFI problems, does it only happen during QSOs on one band? Does reducing your transmitter power improve the situation?
As you say nothing is connected to your PC USB ports I assume this is a real serial port, you could try some ferrite clip on chokes at the PC end of the serial cable, or maybe just re-routing the serial cable to the rig. What interface are you using for the RTS to PTT switching, and where does it draw power from?
73
Bill
G4WJS.
Bill,
I do not think it is RFI. Nothing has changed since I ran V2.2.0 and even with 1 KW.
So far it has been on 20m because I only done a few QSOs and they have been on that band.
The COM port is an RS232 9 pin D-Sub plug on the computer.
Last time it happened by itself a couple of minutes after a QSO was finished.
And the first time it happened was when I started the program. No transmitting going on at all.
The COM port on the old computer was also an RS232 9 pin D-sub by the way.
So can I roll back to 2.2.0?
I will check on the server.
73 de LA3PU Svein
toggle quoted message
Show quoted text
From: main@WSJTX.groups.io <main@WSJTX.groups.io> On Behalf Of Bill Somerville
Sent: tirsdag 25. august 2020 19:52
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] Rig Control error
On 25/08/2020 18:46, Svein Henriksen wrote:
Bill,
This morning everything started up without problems and has worked for some QSOs without failing.
But just now, a few minutes after finishing a QSO on FT8, the POPUP window appears.
Rig Error: Do you want to configure the radio interface?
On pressing Details: it says: HAMLIB error: IO error while opening connection to the rig.
Pressing retry and it goes back to working normally.
There is only one COM port (COM1) ant it is used for PTT with RTS.
No rig connected and in setup rig is set to none.
Nothing connected to any of the USB ports.
The WSJT-X is V2.2.2.
On the old computer I was running 2.2.0. Setup the same. Only one COM port and nothing else connected.
I never had this, or any other, problem while using this.
Maybe I need to roll back to 2.2.0.
I seam to remember having read similar reports with regard to HAMLIB on the reflector after the release of 2.2.2.
Is the old versions available on Princeton and any special precautions if rolling back?
Any other suggestions?
73 de LA3PU Svein
Hi Svein,
that sounds like RFI problems, does it only happen during QSOs on one band? Does reducing your transmitter power improve the situation?
As you say nothing is connected to your PC USB ports I assume this is a real serial port, you could try some ferrite clip on chokes at the PC end of the serial cable, or maybe just re-routing the serial cable to the rig. What interface are you using for the RTS to PTT switching, and where does it draw power from?
73
Bill
G4WJS.
Thanks for the tip but even if it is RFI, which I do not believe it is, it should not trigger the program in this manner since I am NOT using CAT control of the rig at all.
73 de LA3PU Svein
toggle quoted message
Show quoted text
From: main@WSJTX.groups.io <main@WSJTX.groups.io> On Behalf Of ks_univ_nut
Sent: tirsdag 25. august 2020 20:26
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] Rig Control error
I had that problem once.
I believe you are getting RF back into
the computer on one (or more) of your lines.
Put some ferrite cores on all the cables and
see if that helps.
73 – Mike
kb0qgt
On 25/08/2020 18:46, Svein Henriksen wrote:
Bill,
This morning everything started up without problems and has worked for some QSOs without failing.
But just now, a few minutes after finishing a QSO on FT8, the POPUP window appears.
Rig Error: Do you want to configure the radio interface?
On pressing Details: it says: HAMLIB error: IO error while opening connection to the rig.
Pressing retry and it goes back to working normally.
There is only one COM port (COM1) ant it is used for PTT with RTS.
No rig connected and in setup rig is set to none.
Nothing connected to any of the USB ports.
The WSJT-X is V2.2.2.
On the old computer I was running 2.2.0. Setup the same. Only one COM port and nothing else connected.
I never had this, or any other, problem while using this.
Maybe I need to roll back to 2.2.0.
I seam to remember having read similar reports with regard to HAMLIB on the reflector after the release of 2.2.2.
Is the old versions available on Princeton and any special precautions if rolling back?
Any other suggestions?
73 de LA3PU Svein
Hi Svein,
that sounds like RFI problems, does it only happen during QSOs on one band? Does reducing your transmitter power improve the situation?
As you say nothing is connected to your PC USB ports I assume this is a real serial port, you could try some ferrite clip on chokes at the PC end of the serial cable, or maybe just re-routing the serial cable to the rig. What interface are you using for the RTS to PTT switching, and where does it draw power from?
73
Bill
G4WJS.
It is RF from the transmitted signal possibly.
Make sure you have good grounds on everything and
move the computer further from the coax lines,
and reroute the lines away from them as well,
if you haven’t already.
I had my flat screen too close to the radio setup
one time and every time I transmitted on 75 meters
it would turn on and off or change the input or some other
crazy thing. I was getting RF into the remote control
circuitry. Regrounded everything and placed the computer
monitor (flat screen) further away and took care of the problem.
Good luck tracking it down.
73 – Mike
kb0qgt
toggle quoted message
Show quoted text
From: main@WSJTX.groups.io <main@WSJTX.groups.io> On Behalf Of Svein Henriksen
Sent: Tuesday, August 25, 2020 02:48 PM
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] Rig Control error
Thanks for the tip but even if it is RFI, which I do not believe it is, it should not trigger the program in this manner since I am NOT using CAT control of the rig at all.
73 de LA3PU Svein
I had that problem once.
I believe you are getting RF back into
the computer on one (or more) of your lines.
Put some ferrite cores on all the cables and
see if that helps.
73 – Mike
kb0qgt
On 25/08/2020 18:46, Svein Henriksen wrote:
Bill,
This morning everything started up without problems and has worked for some QSOs without failing.
But just now, a few minutes after finishing a QSO on FT8, the POPUP window appears.
Rig Error: Do you want to configure the radio interface?
On pressing Details: it says: HAMLIB error: IO error while opening connection to the rig.
Pressing retry and it goes back to working normally.
There is only one COM port (COM1) ant it is used for PTT with RTS.
No rig connected and in setup rig is set to none.
Nothing connected to any of the USB ports.
The WSJT-X is V2.2.2.
On the old computer I was running 2.2.0. Setup the same. Only one COM port and nothing else connected.
I never had this, or any other, problem while using this.
Maybe I need to roll back to 2.2.0.
I seam to remember having read similar reports with regard to HAMLIB on the reflector after the release of 2.2.2.
Is the old versions available on Princeton and any special precautions if rolling back?
Any other suggestions?
73 de LA3PU Svein
Hi Svein,
that sounds like RFI problems, does it only happen during QSOs on one band? Does reducing your transmitter power improve the situation?
As you say nothing is connected to your PC USB ports I assume this is a real serial port, you could try some ferrite clip on chokes at the PC end of the serial cable, or maybe just re-routing the serial cable to the rig. What interface are you using for the RTS to PTT switching, and where does it draw power from?
73
Bill
G4WJS.
Disregard Svein,
I didn’t read your reply to Bill
before I posted. My Bad.
73 – Mike
kb0qgt
toggle quoted message
Show quoted text
From: main@WSJTX.groups.io <main@WSJTX.groups.io> On Behalf Of ks_univ_nut
Sent: Tuesday, August 25, 2020 04:04 PM
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] Rig Control error
It is RF from the transmitted signal possibly.
Make sure you have good grounds on everything and
move the computer further from the coax lines,
and reroute the lines away from them as well,
if you haven’t already.
I had my flat screen too close to the radio setup
one time and every time I transmitted on 75 meters
it would turn on and off or change the input or some other
crazy thing. I was getting RF into the remote control
circuitry. Regrounded everything and placed the computer
monitor (flat screen) further away and took care of the problem.
Good luck tracking it down.
73 – Mike
kb0qgt
Thanks for the tip but even if it is RFI, which I do not believe it is, it should not trigger the program in this manner since I am NOT using CAT control of the rig at all.
73 de LA3PU Svein
I had that problem once.
I believe you are getting RF back into
the computer on one (or more) of your lines.
Put some ferrite cores on all the cables and
see if that helps.
73 – Mike
kb0qgt
On 25/08/2020 18:46, Svein Henriksen wrote:
Bill,
This morning everything started up without problems and has worked for some QSOs without failing.
But just now, a few minutes after finishing a QSO on FT8, the POPUP window appears.
Rig Error: Do you want to configure the radio interface?
On pressing Details: it says: HAMLIB error: IO error while opening connection to the rig.
Pressing retry and it goes back to working normally.
There is only one COM port (COM1) ant it is used for PTT with RTS.
No rig connected and in setup rig is set to none.
Nothing connected to any of the USB ports.
The WSJT-X is V2.2.2.
On the old computer I was running 2.2.0. Setup the same. Only one COM port and nothing else connected.
I never had this, or any other, problem while using this.
Maybe I need to roll back to 2.2.0.
I seam to remember having read similar reports with regard to HAMLIB on the reflector after the release of 2.2.2.
Is the old versions available on Princeton and any special precautions if rolling back?
Any other suggestions?
73 de LA3PU Svein
Hi Svein,
that sounds like RFI problems, does it only happen during QSOs on one band? Does reducing your transmitter power improve the situation?
As you say nothing is connected to your PC USB ports I assume this is a real serial port, you could try some ferrite clip on chokes at the PC end of the serial cable, or maybe just re-routing the serial cable to the rig. What interface are you using for the RTS to PTT switching, and where does it draw power from?
73
Bill
G4WJS.
Bill,
Just now I worked 8 JA on 20m with a full 1 KW without problem. Then on the 9th QSO it pops up again. So high power, low power same problem.
So RFI it is not.
I found the install file for v2.2.0 on my old computer so I will try that later today.
Higher polling seamed to help some as it took longer for the problem to appear, but this is way to inconclusive.
toggle quoted message
Show quoted text
On 25 Aug 2020, at 19:52, Bill Somerville <g4wjs@…> wrote:
On 25/08/2020 18:46, Svein Henriksen
wrote:Bill,
This morning everything started up without
problems and has worked for some QSOs without failing.But just now, a few minutes after finishing a
QSO on FT8, the POPUP window appears.Rig Error: Do you want to configure the radio
interface?On pressing Details: it says: HAMLIB error:
IO error while opening connection to the rig.Pressing retry and it goes back to working
normally.There is only one COM port (COM1) ant it is
used for PTT with RTS.No rig connected and in setup rig is set to
none.Nothing connected to any of the USB ports.
The WSJT-X is V2.2.2.
On the old computer I was running 2.2.0.
Setup the same. Only one COM port and nothing else connected.I never had this, or any other, problem while
using this.Maybe I need to roll back to 2.2.0.
I seam to remember having read similar
reports with regard to HAMLIB on the reflector after the release
of 2.2.2.Is the old versions available on Princeton
and any special precautions if rolling back?Any other suggestions?
73 de LA3PU Svein
Hi Svein,
that sounds like RFI problems, does it only happen during QSOs on
one band? Does reducing your transmitter power improve the
situation?As you say nothing is connected to your PC USB ports I assume
this is a real serial port, you could try some ferrite clip on
chokes at the PC end of the serial cable, or maybe just re-routing
the serial cable to the rig. What interface are you using for the
RTS to PTT switching, and where does it draw power from?73
Bill
G4WJS.
Bill,
It definitely looks like it helps to set the polling frequency higher. I have set it to 30 seconds. The problem then comes much more seldom.
When it does it is often immediately after I double click on a station to answer a CQ call and seconds before the RTS line and hence the transmitter is even activated. So it definitely has nothing to do with RFI.
Now any computer has a few mV of noise on the comport lines. In my case only the RTS line is even connected.
So if it is noise that occasionally triggers it this means that HAMLIB and / or WSJ-X (due to the way it has been integrated) is polling the com line for a radio that is not configured and not connected.
So this is definitely a bug. When Radio: None has been configured there should be no polling
Can you mention this to the HAMLIB people perhaps, or should I? How do I eventually contact them?
I will now try and install a couple of 100 nF capacitors from pins 2 and 3 to pin 5. I see on the oscilloscope that this attenuates the noise present. Its only a few mV and this is way below the threshold on an RS232 line so it could be pulses occurring now and then due to some WIN thingy and 100 nF may not be enough so I am dubious that this will help. But I think it should not be this way anyway.
73 de LA3PU Svein.
toggle quoted message
Show quoted text
From: main@WSJTX.groups.io <main@WSJTX.groups.io> On Behalf Of Bill Somerville
Sent: tirsdag 25. august 2020 19:52
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] Rig Control error
On 25/08/2020 18:46, Svein Henriksen wrote:
Bill,
This morning everything started up without problems and has worked for some QSOs without failing.
But just now, a few minutes after finishing a QSO on FT8, the POPUP window appears.
Rig Error: Do you want to configure the radio interface?
On pressing Details: it says: HAMLIB error: IO error while opening connection to the rig.
Pressing retry and it goes back to working normally.
There is only one COM port (COM1) ant it is used for PTT with RTS.
No rig connected and in setup rig is set to none.
Nothing connected to any of the USB ports.
The WSJT-X is V2.2.2.
On the old computer I was running 2.2.0. Setup the same. Only one COM port and nothing else connected.
I never had this, or any other, problem while using this.
Maybe I need to roll back to 2.2.0.
I seam to remember having read similar reports with regard to HAMLIB on the reflector after the release of 2.2.2.
Is the old versions available on Princeton and any special precautions if rolling back?
Any other suggestions?
73 de LA3PU Svein
Hi Svein,
that sounds like RFI problems, does it only happen during QSOs on one band? Does reducing your transmitter power improve the situation?
As you say nothing is connected to your PC USB ports I assume this is a real serial port, you could try some ferrite clip on chokes at the PC end of the serial cable, or maybe just re-routing the serial cable to the rig. What interface are you using for the RTS to PTT switching, and where does it draw power from?
73
Bill
G4WJS.
Bill Somerville
Hi Svein,
WSJT-X, using Hamlib, opens the COM
port being used for PTT control via RTS or DTR even though the
port is not used for RS-232 CAT control. It the o/s reports the
port as not available. or other related errors, then Hamlib and
consequently WSJT-X reports that error. Is anything else connected
to that serial port? Have you check the physical connections used
for PTT control?
73
Bill
G4WJS.
On 27/08/2020 11:10, Svein Henriksen
wrote:
toggle quoted message
Show quoted text
Bill,
It definitely looks like it helps to set the
polling frequency higher. I have set it to 30 seconds. The
problem then comes much more seldom.When it does it is often immediately after I
double click on a station to answer a CQ call and seconds before
the RTS line and hence the transmitter is even activated. So it
definitely has nothing to do with RFI.Now any computer has a few mV of noise on the
comport lines. In my case only the RTS line is even connected.So if it is noise that occasionally triggers
it this means that HAMLIB and / or WSJ-X (due to the way it has
been integrated) is polling the com line for a radio that is not
configured and not connected.So this is definitely a bug. When Radio: None
has been configured there should be no pollingCan you mention this to the HAMLIB people
perhaps, or should I? How do I eventually contact them?I will now try and install a couple of 100 nF
capacitors from pins 2 and 3 to pin 5. I see on the oscilloscope
that this attenuates the noise present. Its only a few mV and
this is way below the threshold on an RS232 line so it could be
pulses occurring now and then due to some WIN thingy and 100 nF
may not be enough so I am dubious that this will help. But I
think it should not be this way anyway.73 de LA3PU Svein.
On 25/08/2020 18:46, Svein Henriksen wrote:
Bill,
This
morning everything started up without problems and has worked
for some QSOs without failing.But
just now, a few minutes after finishing a QSO on FT8, the
POPUP window appears.Rig
Error: Do you want to configure the radio interface?On
pressing Details: it says: HAMLIB error: IO error while
opening connection to the rig.Pressing
retry and it goes back to working normally.There
is only one COM port (COM1) ant it is used for PTT with RTS.No
rig connected and in setup rig is set to none.Nothing
connected to any of the USB ports.The
WSJT-X is V2.2.2.On
the old computer I was running 2.2.0. Setup the same. Only one
COM port and nothing else connected.I
never had this, or any other, problem while using this.Maybe
I need to roll back to 2.2.0.I
seam to remember having read similar reports with regard to
HAMLIB on the reflector after the release of 2.2.2.Is
the old versions available on Princeton and any special
precautions if rolling back?Any
other suggestions?73
de LA3PU SveinHi Svein,
that sounds like RFI problems, does it only happen during QSOs
on one band? Does reducing your transmitter power improve the
situation?As you say nothing is connected to your PC USB ports I assume
this is a real serial port, you could try some ferrite clip on
chokes at the PC end of the serial cable, or maybe just
re-routing the serial cable to the rig. What interface are you
using for the RTS to PTT switching, and where does it draw power
from?73
Bill
G4WJS.
Bill,
Only the RTS pin and pin 5(GND) are connected. Nothing else is connected to the computer at all besides audio in and out. I made the cable myself and yes it is screened. It goes to a control box where it drives an OPTOCOUPLER. So it is galvanically isolated from the radio. Since I did not have the problem on the previous computer at all, it is likely some timing difference between the two with respect to the comport responding then. Such differences must surely be taken into account in software.
So could be that HAMLIB is too quick to report if it does not detect the comport immediately.
73 de LA3PU Svein
toggle quoted message
Show quoted text
From: main@WSJTX.groups.io <main@WSJTX.groups.io> On Behalf Of Bill Somerville
Sent: torsdag 27. august 2020 13:06
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] Rig Control error
Hi Svein,
WSJT-X, using Hamlib, opens the COM port being used for PTT control via RTS or DTR even though the port is not used for RS-232 CAT control. It the o/s reports the port as not available. or other related errors, then Hamlib and consequently WSJT-X reports that error. Is anything else connected to that serial port? Have you check the physical connections used for PTT control?
73
Bill
G4WJS.
On 27/08/2020 11:10, Svein Henriksen wrote:
Bill,
It definitely looks like it helps to set the polling frequency higher. I have set it to 30 seconds. The problem then comes much more seldom.
When it does it is often immediately after I double click on a station to answer a CQ call and seconds before the RTS line and hence the transmitter is even activated. So it definitely has nothing to do with RFI.
Now any computer has a few mV of noise on the comport lines. In my case only the RTS line is even connected.
So if it is noise that occasionally triggers it this means that HAMLIB and / or WSJ-X (due to the way it has been integrated) is polling the com line for a radio that is not configured and not connected.
So this is definitely a bug. When Radio: None has been configured there should be no polling
Can you mention this to the HAMLIB people perhaps, or should I? How do I eventually contact them?
I will now try and install a couple of 100 nF capacitors from pins 2 and 3 to pin 5. I see on the oscilloscope that this attenuates the noise present. Its only a few mV and this is way below the threshold on an RS232 line so it could be pulses occurring now and then due to some WIN thingy and 100 nF may not be enough so I am dubious that this will help. But I think it should not be this way anyway.
73 de LA3PU Svein.
On 25/08/2020 18:46, Svein Henriksen wrote:
Bill,
This morning everything started up without problems and has worked for some QSOs without failing.
But just now, a few minutes after finishing a QSO on FT8, the POPUP window appears.
Rig Error: Do you want to configure the radio interface?
On pressing Details: it says: HAMLIB error: IO error while opening connection to the rig.
Pressing retry and it goes back to working normally.
There is only one COM port (COM1) ant it is used for PTT with RTS.
No rig connected and in setup rig is set to none.
Nothing connected to any of the USB ports.
The WSJT-X is V2.2.2.
On the old computer I was running 2.2.0. Setup the same. Only one COM port and nothing else connected.
I never had this, or any other, problem while using this.
Maybe I need to roll back to 2.2.0.
I seam to remember having read similar reports with regard to HAMLIB on the reflector after the release of 2.2.2.
Is the old versions available on Princeton and any special precautions if rolling back?
Any other suggestions?
73 de LA3PU Svein
Hi Svein,
that sounds like RFI problems, does it only happen during QSOs on one band? Does reducing your transmitter power improve the situation?
As you say nothing is connected to your PC USB ports I assume this is a real serial port, you could try some ferrite clip on chokes at the PC end of the serial cable, or maybe just re-routing the serial cable to the rig. What interface are you using for the RTS to PTT switching, and where does it draw power from?
73
Bill
G4WJS.
Bill Somerville
Hi Svein,
Hamlib does close a serial port used
just for PTT when PTT is reset, the intent is to allow other
applications to also key the radio so long as they do the same.
The port is held open while PTT is set as an attempt to do so
exclusively. The whole arrangement is supposed to emulate a
«wired-OR» physical connection without each application requiring
a separate serial port.
I’m not sure any of that helps here,
except it might explain why the error happens when it does, i.e.
it may be happening on a PTT set after a period with the PTT reset
during which something happens that makes reopening the serial
port impossible.
Serial ports in an idle state can
become active if they receive data or if certain control lines are
set (e.g. RI). I now you state that nothing is connected to the
serial port, nevertheless this may be a clue. I see you are
running on Windows, I’m not even sure if Windows Desktop systems
respond to login attempts on serial ports, if it were Linux I
would suggest making sure the serial port login handler was
disabled for that serial port.
73
Bill
G4WJS.
On 27/08/2020 15:48, Svein Henriksen
wrote:
toggle quoted message
Show quoted text
Bill,
Only the RTS pin and pin 5(GND) are
connected. Nothing else is connected to the computer at all
besides audio in and out. I made the cable myself and yes it is
screened. It goes to a control box where it drives an
OPTOCOUPLER. So it is galvanically isolated from the radio.
Since I did not have the problem on the previous computer at
all, it is likely some timing difference between the two with
respect to the comport responding then. Such differences must
surely be taken into account in software.So could be that HAMLIB is too quick to
report if it does not detect the comport immediately.73 de LA3PU Svein
Hi Svein,
WSJT-X, using Hamlib, opens the COM port
being used for PTT control via RTS or DTR even though the port
is not used for RS-232 CAT control. It the o/s reports the
port as not available. or other related errors, then Hamlib
and consequently WSJT-X reports that error. Is anything else
connected to that serial port? Have you check the physical
connections used for PTT control?73
Bill
G4WJS.On 27/08/2020 11:10, Svein Henriksen wrote:
Bill,
It
definitely looks like it helps to set the polling frequency
higher. I have set it to 30 seconds. The problem then comes
much more seldom.When
it does it is often immediately after I double click on a
station to answer a CQ call and seconds before the RTS line
and hence the transmitter is even activated. So it definitely
has nothing to do with RFI.Now
any computer has a few mV of noise on the comport lines. In my
case only the RTS line is even connected.So
if it is noise that occasionally triggers it this means that
HAMLIB and / or WSJ-X (due to the way it has been integrated)
is polling the com line for a radio that is not configured and
not connected.So
this is definitely a bug. When Radio: None has been configured
there should be no pollingCan
you mention this to the HAMLIB people perhaps, or should I?
How do I eventually contact them?I
will now try and install a couple of 100 nF capacitors from
pins 2 and 3 to pin 5. I see on the oscilloscope that this
attenuates the noise present. Its only a few mV and this is
way below the threshold on an RS232 line so it could be pulses
occurring now and then due to some WIN thingy and 100 nF may
not be enough so I am dubious that this will help. But I think
it should not be this way anyway.73 de LA3PU Svein.
On
25/08/2020 18:46, Svein Henriksen wrote:Bill,
This
morning everything started up without problems and has
worked for some QSOs without failing.But
just now, a few minutes after finishing a QSO on FT8, the
POPUP window appears.Rig
Error: Do you want to configure the radio interface?On
pressing Details: it says: HAMLIB error: IO error while
opening connection to the rig.Pressing
retry and it goes back to working normally.There
is only one COM port (COM1) ant it is used for PTT with RTS.No
rig connected and in setup rig is set to none.Nothing
connected to any of the USB ports.The
WSJT-X is V2.2.2.On
the old computer I was running 2.2.0. Setup the same. Only
one COM port and nothing else connected.I
never had this, or any other, problem while using this.Maybe
I need to roll back to 2.2.0.I
seam to remember having read similar reports with regard to
HAMLIB on the reflector after the release of 2.2.2.Is
the old versions available on Princeton and any special
precautions if rolling back?Any
other suggestions?73
de LA3PU SveinHi Svein,
that sounds like RFI problems, does it only happen during
QSOs on one band? Does reducing your transmitter power improve
the situation?As you say nothing is connected to your PC USB ports I assume
this is a real serial port, you could try some ferrite clip on
chokes at the PC end of the serial cable, or maybe just
re-routing the serial cable to the rig. What interface are you
using for the RTS to PTT switching, and where does it draw
power from?73
Bill
G4WJS.
Bill,
Understand all that but as you indicated, that does not help any.
As long as Radio has been configured to None, HAMLIB should simply open the COMPORT and toggle the RTS on and off.
So it is definitely a bug/anomaly/misconceived functionality there that should be fixed.
Or even better, WSJT-X should not go via HAMLIB when no radio is configured but rater control the RTS directly. That is a simple matter to achieve.
So how do I contact the HAMLIB guys?
73 de LA3PU Svein
toggle quoted message
Show quoted text
From: main@WSJTX.groups.io <main@WSJTX.groups.io> On Behalf Of Bill Somerville
Sent: torsdag 27. august 2020 17:06
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] Rig Control error
Hi Svein,
Hamlib does close a serial port used just for PTT when PTT is reset, the intent is to allow other applications to also key the radio so long as they do the same. The port is held open while PTT is set as an attempt to do so exclusively. The whole arrangement is supposed to emulate a «wired-OR» physical connection without each application requiring a separate serial port.
I’m not sure any of that helps here, except it might explain why the error happens when it does, i.e. it may be happening on a PTT set after a period with the PTT reset during which something happens that makes reopening the serial port impossible.
Serial ports in an idle state can become active if they receive data or if certain control lines are set (e.g. RI). I now you state that nothing is connected to the serial port, nevertheless this may be a clue. I see you are running on Windows, I’m not even sure if Windows Desktop systems respond to login attempts on serial ports, if it were Linux I would suggest making sure the serial port login handler was disabled for that serial port.
73
Bill
G4WJS.
On 27/08/2020 15:48, Svein Henriksen wrote:
Bill,
Only the RTS pin and pin 5(GND) are connected. Nothing else is connected to the computer at all besides audio in and out. I made the cable myself and yes it is screened. It goes to a control box where it drives an OPTOCOUPLER. So it is galvanically isolated from the radio. Since I did not have the problem on the previous computer at all, it is likely some timing difference between the two with respect to the comport responding then. Such differences must surely be taken into account in software.
So could be that HAMLIB is too quick to report if it does not detect the comport immediately.
73 de LA3PU Svein
Hi Svein,
WSJT-X, using Hamlib, opens the COM port being used for PTT control via RTS or DTR even though the port is not used for RS-232 CAT control. It the o/s reports the port as not available. or other related errors, then Hamlib and consequently WSJT-X reports that error. Is anything else connected to that serial port? Have you check the physical connections used for PTT control?
73
Bill
G4WJS.On 27/08/2020 11:10, Svein Henriksen wrote:
Bill,
It definitely looks like it helps to set the polling frequency higher. I have set it to 30 seconds. The problem then comes much more seldom.
When it does it is often immediately after I double click on a station to answer a CQ call and seconds before the RTS line and hence the transmitter is even activated. So it definitely has nothing to do with RFI.
Now any computer has a few mV of noise on the comport lines. In my case only the RTS line is even connected.
So if it is noise that occasionally triggers it this means that HAMLIB and / or WSJ-X (due to the way it has been integrated) is polling the com line for a radio that is not configured and not connected.
So this is definitely a bug. When Radio: None has been configured there should be no polling
Can you mention this to the HAMLIB people perhaps, or should I? How do I eventually contact them?
I will now try and install a couple of 100 nF capacitors from pins 2 and 3 to pin 5. I see on the oscilloscope that this attenuates the noise present. Its only a few mV and this is way below the threshold on an RS232 line so it could be pulses occurring now and then due to some WIN thingy and 100 nF may not be enough so I am dubious that this will help. But I think it should not be this way anyway.
73 de LA3PU Svein.
On 25/08/2020 18:46, Svein Henriksen wrote:
Bill,
This morning everything started up without problems and has worked for some QSOs without failing.
But just now, a few minutes after finishing a QSO on FT8, the POPUP window appears.
Rig Error: Do you want to configure the radio interface?
On pressing Details: it says: HAMLIB error: IO error while opening connection to the rig.
Pressing retry and it goes back to working normally.
There is only one COM port (COM1) ant it is used for PTT with RTS.
No rig connected and in setup rig is set to none.
Nothing connected to any of the USB ports.
The WSJT-X is V2.2.2.
On the old computer I was running 2.2.0. Setup the same. Only one COM port and nothing else connected.
I never had this, or any other, problem while using this.
Maybe I need to roll back to 2.2.0.
I seam to remember having read similar reports with regard to HAMLIB on the reflector after the release of 2.2.2.
Is the old versions available on Princeton and any special precautions if rolling back?
Any other suggestions?
73 de LA3PU Svein
Hi Svein,
that sounds like RFI problems, does it only happen during QSOs on one band? Does reducing your transmitter power improve the situation?
As you say nothing is connected to your PC USB ports I assume this is a real serial port, you could try some ferrite clip on chokes at the PC end of the serial cable, or maybe just re-routing the serial cable to the rig. What interface are you using for the RTS to PTT switching, and where does it draw power from?
73
Bill
G4WJS.
I’m an extremely green WSJT-X user, but the problem described here sounds close to a (radio) issue I’m having. I’m using WSJT-X with an IC706MKIIG. The rig control is set to None, with PTT set to RTS. I’m facing a PTT problem where the Transmit mode either fails to work, or the mode relay audibly rattles between Transmit and Receive.
I haven’t fixed the problem yet, but have ordered RF chokes to cover the relevant computer cables to the radio. Hope this helps. Shout-out to customer service rep «SHOLTO» at West Mountain Radio for the patient assistance.
73, Ed Goto, KD9OZD
toggle quoted message
Show quoted text
On Fri, Aug 28, 2020, 02:23 Svein Henriksen <la3pu@…> wrote:
Bill,
Understand all that but as you indicated, that does not help any.
As long as Radio has been configured to None, HAMLIB should simply open the COMPORT and toggle the RTS on and off.
So it is definitely a bug/anomaly/misconceived functionality there that should be fixed.
Or even better, WSJT-X should not go via HAMLIB when no radio is configured but rater control the RTS directly. That is a simple matter to achieve.
So how do I contact the HAMLIB guys?
73 de LA3PU Svein
Hi Svein,
Hamlib does close a serial port used just for PTT when PTT is reset, the intent is to allow other applications to also key the radio so long as they do the same. The port is held open while PTT is set as an attempt to do so exclusively. The whole arrangement is supposed to emulate a «wired-OR» physical connection without each application requiring a separate serial port.
I’m not sure any of that helps here, except it might explain why the error happens when it does, i.e. it may be happening on a PTT set after a period with the PTT reset during which something happens that makes reopening the serial port impossible.
Serial ports in an idle state can become active if they receive data or if certain control lines are set (e.g. RI). I now you state that nothing is connected to the serial port, nevertheless this may be a clue. I see you are running on Windows, I’m not even sure if Windows Desktop systems respond to login attempts on serial ports, if it were Linux I would suggest making sure the serial port login handler was disabled for that serial port.
73
Bill
G4WJS.On 27/08/2020 15:48, Svein Henriksen wrote:
Bill,
Only the RTS pin and pin 5(GND) are connected. Nothing else is connected to the computer at all besides audio in and out. I made the cable myself and yes it is screened. It goes to a control box where it drives an OPTOCOUPLER. So it is galvanically isolated from the radio. Since I did not have the problem on the previous computer at all, it is likely some timing difference between the two with respect to the comport responding then. Such differences must surely be taken into account in software.
So could be that HAMLIB is too quick to report if it does not detect the comport immediately.
73 de LA3PU Svein
Hi Svein,
WSJT-X, using Hamlib, opens the COM port being used for PTT control via RTS or DTR even though the port is not used for RS-232 CAT control. It the o/s reports the port as not available. or other related errors, then Hamlib and consequently WSJT-X reports that error. Is anything else connected to that serial port? Have you check the physical connections used for PTT control?
73
Bill
G4WJS.On 27/08/2020 11:10, Svein Henriksen wrote:
Bill,
It definitely looks like it helps to set the polling frequency higher. I have set it to 30 seconds. The problem then comes much more seldom.
When it does it is often immediately after I double click on a station to answer a CQ call and seconds before the RTS line and hence the transmitter is even activated. So it definitely has nothing to do with RFI.
Now any computer has a few mV of noise on the comport lines. In my case only the RTS line is even connected.
So if it is noise that occasionally triggers it this means that HAMLIB and / or WSJ-X (due to the way it has been integrated) is polling the com line for a radio that is not configured and not connected.
So this is definitely a bug. When Radio: None has been configured there should be no polling
Can you mention this to the HAMLIB people perhaps, or should I? How do I eventually contact them?
I will now try and install a couple of 100 nF capacitors from pins 2 and 3 to pin 5. I see on the oscilloscope that this attenuates the noise present. Its only a few mV and this is way below the threshold on an RS232 line so it could be pulses occurring now and then due to some WIN thingy and 100 nF may not be enough so I am dubious that this will help. But I think it should not be this way anyway.
73 de LA3PU Svein.
On 25/08/2020 18:46, Svein Henriksen wrote:
Bill,
This morning everything started up without problems and has worked for some QSOs without failing.
But just now, a few minutes after finishing a QSO on FT8, the POPUP window appears.
Rig Error: Do you want to configure the radio interface?
On pressing Details: it says: HAMLIB error: IO error while opening connection to the rig.
Pressing retry and it goes back to working normally.
There is only one COM port (COM1) ant it is used for PTT with RTS.
No rig connected and in setup rig is set to none.
Nothing connected to any of the USB ports.
The WSJT-X is V2.2.2.
On the old computer I was running 2.2.0. Setup the same. Only one COM port and nothing else connected.
I never had this, or any other, problem while using this.
Maybe I need to roll back to 2.2.0.
I seam to remember having read similar reports with regard to HAMLIB on the reflector after the release of 2.2.2.
Is the old versions available on Princeton and any special precautions if rolling back?
Any other suggestions?
73 de LA3PU Svein
Hi Svein,
that sounds like RFI problems, does it only happen during QSOs on one band? Does reducing your transmitter power improve the situation?
As you say nothing is connected to your PC USB ports I assume this is a real serial port, you could try some ferrite clip on chokes at the PC end of the serial cable, or maybe just re-routing the serial cable to the rig. What interface are you using for the RTS to PTT switching, and where does it draw power from?
73
Bill
G4WJS.
Содержание
- wsjx rig control error #981
- Comments
- IO error IO error while opening connection to rig
- Hamlib error: IO error while opening connection to rig (FT-991A) #175
- Comments
- Footer
- Ham Radio Control Libraries Discussion
- Library to control radio transceivers and receivers
- Forums
- Hamlib cannot connect to TS-680S on COM1
- Hamlib error: IO error while opening connection to rig (FT-991A) about hamlib HOT 4 CLOSED
- Comments (4)
- Related Issues (20)
- Recommend Projects
- React
- Vue.js
- Typescript
- TensorFlow
- Django
- Laravel
- Recommend Topics
- javascript
- server
- Machine learning
- Visualization
- Recommend Org
- Microsoft
wsjx rig control error #981
Hello=
PC is Ubuntu 22.04
Trying to connect CubicSDR v0.2.7 to wsjtx v2.6.0 rc5,
using hamlib NET rgctl ver 4.3.1-1 build 2cd hamlib
settings in both wsjtx and cubicsdr are
here is the error from WSJTX:
Hamlib error: rig_set_conf called
rig_confparam_lookup called for 1073741854
rig_set_conf: ptt_type=’None’
rig_token_lookup called for no_xchg
rig_confparam_lookup called for no_xchg
1:rig.c(807):rig_open entered
rig_settings_get_path: path=/home/dan/.config/hamlib_settings
rig_settings_load_all: settings_file (/home/dan/.config/hamlib_settings): No such file or directory
rig_open: cwd=/home/dan
rig_open: /home/dan/hamlib_settings does not exist
rig_open: async_data_enable=0, async_data_supported=0
rig_open: using network address 127.0.0.1:4532
network_open: hoststr=127.0.0.1, portstr=4532
connect to 127.0.0.1:4532 failed, (trying next interface): Network error 111: Connection refused
network_open: failed to connect to 127.0.0.1:4532
rig_open: rs->comm_state==tr0?=0
1:rig.c(1013):rig_open returning(-6) IO error
IO error
IO error
while opening connection to rig
ver 4.3.1-1 build 2cd hamlib
Cubic sdr-
control port set for 127.0.0.1:4532, this is a manual entry, error is I/O error (openfailed?)
NOt sure of Cubic sdr is set or not correctly.any help appreciated, thanks Dan KC2STA
The text was updated successfully, but these errors were encountered:
Источник
Hamlib error: IO error while opening connection to rig (FT-991A) #175
Since two days I get errors after starting WSJT-X (version 2.1.0) running on my Win10 PC which is connected to my FT-991A.
I am using this configuration already since 2 months without any problems. The mentioned problem started last sunday after I made a QSO in the mode C4FM. I tried to start WSJT-X again but got a error message HAMLib could not read the mode. In the first place I was not aware the this probably had to do with the C4FM-mode I selected on my FT-991a. So after some try and error I reset my config in WSJT-X and reconfigured it. Still the same error message refering to HAMLib. So I decided to remove HamLib and reinstalled it with version 3.3.
All com-ports and as well as the audio interface work properly. And are not reinstalled. Als Windows does not show any disconnection of the comports. No hardware has been changed. USB cable is OK and provided with several RF beads MIX31.
I googled and found more same problems that rever to this HamLib IO error.
Please help!
73’s PA3VOS
The text was updated successfully, but these errors were encountered:
Hi Mike,
I turned off C4FM when I got this error message. But that was to late. Before I did that I already reset the settings accidentely. So from that point the.problems started to get worse. I reinstalled the latest version of HamLib. I am working with Windows 10 not with Umbuntu or a Raspberry Pi. So I need a windows exacutable.
Was a hardware problem so closing.
© 2023 GitHub, Inc.
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Источник
Ham Radio Control Libraries Discussion
Library to control radio transceivers and receivers
Forums
Hamlib cannot connect to TS-680S on COM1
Hello,
I’m trying to use hamlib to control a Kenwood TS-680S on serial port COM1.
I’ve verified that the rig responds directly to Kenwood commands like if; using HyperTerminal and PuTTY on COM1
However hamlib doesn’t enter interactive mode and responds with an error:
rig.c(972):rig_open return
rig_open: error = Communication timed out
I’m using Hamlib 4.1 on Windows 10
command line is rigctl -m 2024 -r COM1 -s 4800
I can send debug info if needed.
Many thanks for any help.
Pete F5VGH
Please send debug.
And send some screen shots from your hyperterminal too.
Mike W9MDB
Hello,
I’m trying to use hamlib to control a Kenwood TS-680S on serial port COM1.
I’ve verified that the rig responds directly to Kenwood commands like if; using HyperTerminal and PuTTY on COM1
However hamlib doesn’t enter interactive mode and responds with an error:
rig.c(972):rig_open return
rig_open: error = Communication timed out
I’m using Hamlib 4.1 on Windows 10
command line is rigctl -m 2024 -r COM1 -s 4800
I can send debug info if needed.
Many thanks for any help.
Pete F5VGH
Hamlib cannot connect to TS-680S on COM1
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/hamlib/discussion/25919/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
On 14/02/2021 16:42, Pete Howe wrote:
Hello,
I’m trying to use hamlib to control a Kenwood TS-680S on serial port COM1.
I’ve verified that the rig responds directly to Kenwood commands like if; using HyperTerminal and PuTTY on COM1
However hamlib doesn’t enter interactive mode and responds with an error:
rig.c(972):rig_open return
rig_open: error = Communication timed out
I’m using Hamlib 4.1 on Windows 10
command line is rigctl -m 2024 -r COM1 -s 4800
I can send debug info if needed.
Many thanks for any help.
Pete F5VGH
try adding -Cserial_handshake=Hardware to the command line options.
Hi Mike and Bill,
Many thanks for your replies. I added -C serial_handshake=Hardware to the
command line and confirm that interactive mode is accessed. The commands f,
F, t, T and m work as expected.
M ? returns the list of supported modes, however M LSB doesn’t change the
mode (no response from Rig command:). Are there any other commands that I
should verify?
In WSJT-X, when trying to use the Hamlib CAT interface, I selected Hardware
Handshake but I still got a rig failure IO error message «rig.c(745):rig_open
return while opening connection to rig». Please let me know how I should
proceed to enable hamlib to make the rig connection with programs like
WSJT-X and Log4OM.
Many thanks,
Pete
On Sun, Feb 14, 2021 at 6:06 PM Bill Somerville bsomervi@users.sourceforge.net wrote:
On 14/02/2021 16:42, Pete Howe wrote:
Hello,
I’m trying to use hamlib to control a Kenwood TS-680S on serial port COM1.
I’ve verified that the rig responds directly to Kenwood commands like if;
using HyperTerminal and PuTTY on COM1
However hamlib doesn’t enter interactive mode and responds with an error:
rig.c(972):rig_open return
rig_open: error = Communication timed out
I’m using Hamlib 4.1 on Windows 10
command line is rigctl -m 2024 -r COM1 -s 4800
I can send debug info if needed.
Many thanks for any help.
Pete F5VGH
try adding -Cserial_handshake=Hardware to the command line options.
Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/hamlib/discussion/25919/
make sure only one application is accessing the CAT serial port at any
one time.
On 14/02/2021 20:02, Pete Howe wrote:
Hi Mike and Bill,
Many thanks for your replies. I added -C serial_handshake=Hardware to the
command line and confirm that interactive mode is accessed. The commands f,
F, t, T and m work as expected.
M ? returns the list of supported modes, however M LSB doesn’t change the
mode (no response from Rig command:). Are there any other commands that I
should verify?
In WSJT-X, when trying to use the Hamlib CAT interface, I selected Hardware
Handshake but I still got a rig failure IO error message «rig.c(745):rig_open
return while opening connection to rig». Please let me know how I should
proceed to enable hamlib to make the rig connection with programs like
WSJT-X and Log4OM.
Many thanks,
Pete
On Sun, Feb 14, 2021 at 6:06 PM Bill Somerville bsomervi@users.sourceforge.net wrote:
On 14/02/2021 16:42, Pete Howe wrote:
Hello,
I’m trying to use hamlib to control a Kenwood TS-680S on serial port COM1.
I’ve verified that the rig responds directly to Kenwood commands like if;
using HyperTerminal and PuTTY on COM1
However hamlib doesn’t enter interactive mode and responds with an error:
rig.c(972):rig_open return
rig_open: error = Communication timed out
I’m using Hamlib 4.1 on Windows 10
command line is rigctl -m 2024 -r COM1 -s 4800
I can send debug info if needed.
Many thanks for any help.
Pete F5VGH
try adding -Cserial_handshake=Hardware to the command line options.
Run rigctld and have WSJT-x use «Hamlib NET rigctl». Log4OM will also connect to rigctld.
You can test rigctld with «rigctl -m 2»
If you add «-vvvvv -Z >log.txt 2>&1» to the rigctld line you can send the log.txt to me if you notice any bugs.
Mike W9MDB
Hi Mike and Bill,
Many thanks for your replies. I added -C serial_handshake=Hardware to the
command line and confirm that interactive mode is accessed. The commands f,
F, t, T and m work as expected.
M ? returns the list of supported modes, however M LSB doesn’t change the
mode (no response from Rig command:). Are there any other commands that I
should verify?
In WSJT-X, when trying to use the Hamlib CAT interface, I selected Hardware
Handshake but I still got a rig failure IO error message «rig.c(745):rig_open
return while opening connection to rig». Please let me know how I should
proceed to enable hamlib to make the rig connection with programs like
WSJT-X and Log4OM.
Many thanks,
Pete
On Sun, Feb 14, 2021 at 6:06 PM Bill Somerville bsomervi@users.sourceforge.net wrote:
On 14/02/2021 16:42, Pete Howe wrote:
Hello,
I’m trying to use hamlib to control a Kenwood TS-680S on serial port COM1.
I’ve verified that the rig responds directly to Kenwood commands like if;
using HyperTerminal and PuTTY on COM1
However hamlib doesn’t enter interactive mode and responds with an error:
rig.c(972):rig_open return
rig_open: error = Communication timed out
I’m using Hamlib 4.1 on Windows 10
command line is rigctl -m 2024 -r COM1 -s 4800
I can send debug info if needed.
Many thanks for any help.
Pete F5VGH
try adding -Cserial_handshake=Hardware to the command line options.
Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/hamlib/discussion/25919/
Hamlib cannot connect to TS-680S on COM1
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/hamlib/discussion/25919/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
Many thanks for your replies Mike and Bill. WSJT-x and hamlib are now
working correctly. I’m going to try running rigctld and will let you know.
73,
Pete
On Sun, Feb 14, 2021 at 11:35 PM Michael Black mdblack98@users.sourceforge.net wrote:
Run rigctld and have WSJT-x use «Hamlib NET rigctl». Log4OM will also
connect to rigctld.
You can test rigctld with «rigctl -m 2»
If you add «-vvvvv -Z >log.txt 2>&1» to the rigctld line you can send the
log.txt to me if you notice any bugs.
Mike W9MDB
On Sunday, February 14, 2021, 02:02:55 PM CST, Pete Howe f5vgh@users.sourceforge.net wrote:
Hi Mike and Bill,
Many thanks for your replies. I added -C serial_handshake=Hardware to the
command line and confirm that interactive mode is accessed. The commands f,
F, t, T and m work as expected.
M ? returns the list of supported modes, however M LSB doesn’t change the
mode (no response from Rig command:). Are there any other commands that I
should verify?
In WSJT-X, when trying to use the Hamlib CAT interface, I selected Hardware
Handshake but I still got a rig failure IO error message
«rig.c(745):rig_open
return while opening connection to rig». Please let me know how I should
proceed to enable hamlib to make the rig connection with programs like
WSJT-X and Log4OM.
Many thanks,
Pete
On Sun, Feb 14, 2021 at 6:06 PM Bill Somerville
bsomervi@users.sourceforge.net wrote:
On 14/02/2021 16:42, Pete Howe wrote:
Hello,
I’m trying to use hamlib to control a Kenwood TS-680S on serial port COM1.
I’ve verified that the rig responds directly to Kenwood commands like if;
using HyperTerminal and PuTTY on COM1
However hamlib doesn’t enter interactive mode and responds with an error:
rig.c(972):rig_open return
rig_open: error = Communication timed out
I’m using Hamlib 4.1 on Windows 10
command line is rigctl -m 2024 -r COM1 -s 4800
I can send debug info if needed.
Many thanks for any help.
Pete F5VGH
try adding -Cserial_handshake=Hardware to the command line options.
Источник
Hamlib error: IO error while opening connection to rig (FT-991A) about hamlib HOT 4 CLOSED
N0NB commented on January 15, 2023
PA3VOS commented on January 15, 2023
Hi Mike,
I turned off C4FM when I got this error message. But that was to late. Before I did that I already reset the settings accidentely. So from that point the.problems started to get worse. I reinstalled the latest version of HamLib. I am working with Windows 10 not with Umbuntu or a Raspberry Pi. So I need a windows exacutable.
mdblack98 commented on January 15, 2023
Was a hardware problem so closing.
- FTDX5000 EX103 behavior
- QRP-Labs QDX IF command parsing buggy HOT 14
- Report errno message along with appropriate ERR returns
- TS-870S timeout on Linux
- FT-991 timeout on Linux
- ICOM ID-5100 — rigctl Get Frequency command failing
- ICOM ID-5100 — rigctld Get Power status command failing HOT 1
- ICOM ID-5100 — rigctl Set Frequency command is failing.
- Can’t change CM108 GPIO using ptt_bitnum
- Icom ID-5100 get/set mode not correct
- KX2 power calculation fails HOT 8
- FTDX3000 EX039 error
- RPI OS update seems to break hamlib HOT 7
- Building hamlib while hamlib is installed fails the build HOT 5
- Would like #defines with exact hamlib version number
- Timing on NRD-535 is too small HOT 1
- FT-710 does not work on 60M with WSJT-X HOT 1
- Linux set_powerstat 0 fails to reopen HOT 1
- TS-450 powerstat failing
- Hamlib-4.5.4 fails to build
Recommend Projects
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
TensorFlow
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
Recommend Topics
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
server
A server is a program made to process requests and deliver data to clients.
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Visualization
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Recommend Org
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Источник
-
Summary
-
Files
-
Reviews
-
Support
-
Mailing Lists
-
Git ▾
- WSJT-X
- WSPR
- WSPR-X
- WSJT
- Echo
- FMT
- MAP65
- MAP65IQ
- WSJT-X Superbuild
- More…
-
Old SVN
Menu
▾
▴
|
From: Bill Somerville <g4…@cl…> — 2014-08-04 17:34:49 |
On 02/08/2014 04:48, jeff millar wrote: > Hi Bill... Hi Jeff, replying off list ... > > I had some time after work and was able to create a log file showing > the error clearly. OK, well it seems that there is no response to the very first CAT command sent after PTT is asserted. The first response is a simple echo of the command sent since the C-IV bus is one-wire and outgoing commands are read back in. I can't get any useful information from the log other than that so I think we need to try some experiments with your set up. Can you set "PTT Method" to "VOX" (don't change the rig), this will allow the program to go through the motions of transmitting without actually engaging PTT on the rig. Carry out the same test as before and send me the wsjtx_trace.log file again please. If there is no error; click "Tune" again to return to RX mode and terminate the program. Sorry this is taking so long to diagnose. > > jeff, wa1hco 73 Bill G4WJS. > > On 08/01/2014 08:11 AM, Bill Somerville wrote: >> On 01/08/2014 12:28, jeff millar wrote: >>> Hi Bill... >> Hi Jeff, >>> >>> Thanks for the ideas. I'm off to vacation for a week and will not >>> have access to the desktop or radio for that time. I will try your >>> debugging build next weekend. >> OK, enjoy the break, we can pick this up later. >>> >>> The input level is reported and control with pulse audio volume >>> control or the pull down audio control on the top bar. I'm watching >>> the slider position for Input Audio and stepping the code. one more >>> click on "step into" causes the input level go from about 20% to 100%. >> The audio controls do work on my VM so I will see if I can reproduce >> that behaviour. >> >> That line of code is emitting a Qt signal and in this case it is >> crossing a thread boundary so it is not a simple function call that >> is going on. QtCreator may not follow that signal to any connected >> slots in the target thread(s), I don't use QtCreator for debugging so >> I'm not 100% sure on the mechanics. If I can reproduce it; I will set >> break points on the target slots and see if I can track down what is >> happening here. >> >> If it were the signal emission in the MainWindow constructor; then it >> is quite possible that the previous line is the one that is causing >> the issue you see. The previous line is emitting another signal which >> is starting the audio input stream, again via an inter-thread signal >> to slot connection. It is quite possible that the target thread >> doesn't run and dequeue the message until the line you cite runs. You >> can trace this in debug by setting a break point on SoundInput::start >> which is the target slot of the MainWindow::startAudioInputStream >> signal. Then step through that to see what line causes the level reset. >> >> This probably boils down to the fact that Qt creates a new stream >> (and stream name) for every audio connection and the we have no >> control of the stream name. This means that levels set via the system >> or pavucontrol are not remembered between runs. You will probably >> have to set the RX level via the WSJT-X level slider rather than the >> system. IIRC the slider in WSJT-X doesn't change the stream slider, >> we do our own gain processing on the audio received. I would think >> that given two different digital level controls (pulseaudio and ours) >> in series; it is probably best to have one or the other at 0dB anyway >> as each stage of attenuation is likely to introduce artefacts so only >> using one of them is best. >> >> We have raised an issue report to Qt on this but AFAIK no one has >> picked it up and submitted a fix. On Windows since 7 the levels are >> associated with the executable name that set them. In pulseaudio the >> levels are associated with the stream name so not being able to set >> the stream name is IMHO a Qt defect. >>> >>> jeff, wa1hco >> Hope this helps & 73 >> Bill >> G4WJS. >>> On 08/01/2014 05:10 AM, Bill Somerville wrote: >>>> On 01/08/2014 04:42, jeff millar wrote: >>>> Hi Jeff, >>>> >>>> Sorry you are having some issues with the current WSJT-X code. >>>>> First problem: Most of the time, when starting a transmission or >>>>> using the Tune button, WSJTX throws a "Rig Control Error Hamlib >>>>> error: Invalid parameter while getting current VFO frequency". >>>>> This occurs about 1 sec after starting a transmission. But >>>>> sometimes it runs ok for a while without throwing errors. The >>>>> Test CAT button doesn't show a problem. I can browse the bands >>>>> with the band select button without seeing the problem. >>>> So I can see what is going on here can you build a version that has >>>> CAT diagnostics enabled. Details of a way to do that are in this >>>> posting: >>>> >>>> https://sourceforge.net/p/wsjt/mailman/message/32650244/ >>>> >>>> Once built; run the application to reproduce the issues then close >>>> it. The file wsjtx_trace.log is created in the directory that the >>>> binary was in. Compress and send me that file (directly is probably >>>> best) and I'll have a look at what is going on. >>>> >>>> >>>>> >>>>> Second problem: Whenever WSJTX starts up it somehow resets the >>>>> input level to 100%. I traced this down to this line in >>>>> mainwindow.cpp >>>>> >>>>> Q_EMIT initializeAudioOutputStream (m_config.audio_output_device >>>>> (), AudioDevice::Mono == m_config.audio_output_channel () ? 1 : 2, >>>>> m_msAudioOutputBuffered); >>>>> >>>>> any ideas? >>>> That line is the initialisation of the audio output stream, that >>>> has to be done before it can be used. That should only effect TX >>>> audio so I am surprised that it is having any impact on RX audio. >>>> Unfortunately I only have Linux on a VM and the audio drivers for >>>> the VM do not support input audio so I cannot debug this issue here. >>>> >>>> When you say "resets input level to 100%" where are you seeing that? >>>>> >>>>> jeff, wa1hco >>>>> >>>>> I'm running WSJTX, r1.4, r4224 on Ubuntu 14.04. Hamlib is V3.0. >>>>> IC-746PRO. PTT method by RTS. >>>>> >>>>> Application output from qtcreator... >>>>> >>>>> ig_set_conf: serial_handshake='None' >>>>> >>>>> rig_set_conf: ptt_pathname='/dev/ttyUSB1' >>>>> >>>>> rig_set_conf: ptt_type='RTS' >>>>> >>>>> rig:rig_open called >>>>> >>>>> read_string(): Timed out 0.200237 seconds without reading a >>>>> character. >>>>> >>>>> read_string(): Timed out 0.200235 seconds without reading a >>>>> character. >>>>> >>>>> read_string(): Timed out 0.200244 seconds without reading a >>>>> character. >>>>> >>>>> read_string(): Timed out 0.200218 seconds without reading a >>>>> character. >>>>> >>>>> rig:rig_close called >>>>> >>>>> rig:rig_close called >>>>> >>>>> rig:rig_cleanup called >>>>> >>>>> QDialog::exec: Recursive call detected >>>>> >>>>> Got a buffer underflow! >>>>> >>>>> Got a buffer underflow! >>>>> >>>>> Got a buffer underflow! >>>>> >>>>> Got a buffer underflow! >>>>> >>>>> >>>> The only issue I see with that output is the read_string() time >>>> outs which implies that the CAT module is not getting any response >>>> from the rig from a command sent to it at some point, the >>>> diagnostic trace should help with that too. >>>> >>>> 73 >>>> Bill >>>> G4WJS. > > > ------------------------------------------------------------------------------ > Infragistics Professional > Build stunning WinForms apps today! > Reboot your WinForms applications with our WinForms controls. > Build a bridge from your legacy apps to the future. > http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk > > > _______________________________________________ > wsjt-devel mailing list > wsjt-...@li... > https://lists.sourceforge.net/lists/listinfo/wsjt-devel |
View entire thread