Hi guys,
I posted this topic a few weeks ago on the WSJT-X forum (groups.io) and waited, and waited. Not a single reply..
I definitely miss Mike!
Anyway, here it is. Thanks in advance!
Larry N8KU
Here is my setup:
hardware - IC-7410 - Dell desktop computer/i5-14600/32GB - Hamplus AS-603A "automatic" antenna switch
software - Windows 11 24H2/completely up to date - WSJT-X 2.7 - JTAlert 2.80.4 - Log4OM 2.36.1
CP210x Universal UART driver 11.4 - Hamlib 4.6.2 - Open SSL 3.5.0 (I use WSJT-X only for FT8)
hamlib rig ID #3067
All this (except the AS603A) was working beautifully for years (with much older versions of hamlib and UART driver) until I recently added the antenna switch. By the way, the switch cable is connected ONLY to the radio, using both the "accessory" socket and the "remote" jack. (The cable has two connectors on one end. This is the correct method per Hamplus.) The computer is of course connected to the radio via USB.
So it all works, sort of. I started getting Hamlib errors from WSJT-X. After a lot of fussing with "radio" settings, on both the rig itself and WSJT-X, and eliminating the secondary software (JTAlert & Log4OM) I am still stuck. It will throw these errors anywhere from minutes to hours after starting up WSJT-X. It will do this regardless of whether JTAlert or Log4OM are running, and is unrelated to the steps of completing QSOs. It typically errors out when I am not even near the rig, during receive.
I got a response from the Hamplus guys in Brazil, they basically said "sorry, our product only 'listens' - it would not be trying to send anything to the rig" - which was actually very useful info.
When I try to research the "correct" settings within WSJT-X for the Icom 7410, the posts I have found are all over the map. After many days of trying all possible combinations, here is what I have settled on for now:
Note that the "Test CAT" and "Test PTT" both work. A slightly related problem is that the "Update Hamlib" button has NEVER worked, no matter what - that results in "Error Loading libhamlib-4.dll - TLS initialization failed" I updated to latest hamlib by copying the .dll over to WSJT-X manually.
items tried with no success:
tried different USB port on computer for rig
replaced the USB cable
set Data & Stop to 8 & 1
44/CI-V transceive back to "on"
handshake to none
bits to 8/1
CAT PTT port to COM3
manually update hamlib & openSSL again
If you disconnect the AS-603A does the problem go away? If so, I wonder about some sort of ground loop causing noise and corrupting the data stream. How is the switch powered?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes. With no AS-603A (meaning no control cables, but antennas and power still attached) the problem goes away. It comes with a DC power cable that I can attach directly to the 12V supply.
Everything is grounded using heavy gauge copper cables, to a 4' copper bar that has a 10 foot long 6 gauge cable to a ground rod outside. The service panel is between the two and also connects to the rod (only 3 feet of cable.) No to mention the dozens of ferrites at the radio and computer ends of all cables. Seems to me all of this should only make a difference during transmit - but the problem only happens (90% of the time) during receive.
In the 2 months since I last posted here, I have also tried:
a different (brand new) computer
a different power supply (an identical Alinco DM330MV)
reset the rig to defaults and carefully reconfigured only the two or three items needing set
tried WSJT-X "improved" (it's not for me)
a different interface cable (they make one that doesn't supply pwr via rig DIN connector, it connects to "send" and "CIV" connectors and needs the above 12V cable
2 more versions of Hamlib since then
and finally - Omnirig, which fixes it, but -
I don't like using Omnirig, it is very old code, unsupported and in the end Hamlib should work! It took me quite a while to modify the config file for the 7410 successfully. Getting this straightened out has become another hobby!
Also - one more new and interesting clue: having watched the rig and computer screen for MANY hours - I noticed that even with Omnirig, every once in a while, the relays on the antenna switch will chatter a bit, but no errors.. sometimes, I can see the VFO readout on the rig momentarily (maybe 1/2 second) switch to a frequency of like, ".150 MHz" and of course it turns red because it is out of the band. All gone in a glimpse, and it keeps working. I do believe that this is when it would throw the hamlib errors, but can't prove it because the error is usually minimized, and it keeps decoding. I don't find out until I go to actually make a QSO/use WSJT-X.
This leads me to believe that there is indeed something "noise-related" whether on the power line or being picked up by antennas. My power here (suburban neighborhood) is excellent and in this house full of electronics nothing else has ever had a problem.
I have a IC-7300 laying around that I am going to try to eliminate the rig entirely. It has been interesting to me while studying the nice looking but actually very poor documentation for the switch from Hamplus, that the 7410 is never mentioned as a supported rig, but there are several references to "all Icom" radios.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the feedback, Larry (pun intended or not intended, you decide!).
Not having a 7410 or any later Icom, I am only speculating here. I wonder how isolated the RS-232 line, or other data line in the radio feeding the port the switch listens on, is. I can imagine a scenario where the switch is doing something to the line that corrupts the data. Also, even though they claim it only listens, is it possible it's dumping garbage on the line going to the CPU?
It will be interesting if the 7300 responds in the same way.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Where I am still stuck is, the communication between the antenna switch
and the radio is pure serial - and one direction only, if you can
believe the manufacturer. The protocol (CI-V) is outlined in the Icom
manual. In this case it is only about HF band identification.
But Hamlib only talks to it serial, over USB. They do not have anything
physically in common. If anything is "dumping garbage on the line to the
computer, it has to be the radio itself. Again, in that case, all it is
doing is emulating a more standard (COM) serial port, but in that case
the communication is definitely two-way.
I tried three different drivers for the radio, and ended up with this
one https://www.pololu.com/docs/0j7/all - because it has the best
documentation and is fairly new. But all that I tried worked, except for
not fixing the problem.
Thanks for the feedback, Larry (pun intended or not intended, you
decide!).
Not having a 7410 or any later Icom, I am only speculating here. I
wonder how isolated the RS-232 line, or other data line in the radio
feeding the port the switch listens on, is. I can imagine a scenario
where the switch is doing something to the line that corrupts the data.
Also, even though they claim it only listens, is it possible it's
dumping garbage on the line going to the CPU?
It will be interesting if the 7300 responds in the same way.
Where I am still stuck is, the communication between the antenna switch and the radio is pure serial - and one direction only, if you can believe the manufacturer. The protocol (CI-V) is outlined in the Icom manual. In this case it is only about HF band identification.
But Hamlib only talks to it serial, over USB. They do not have anything physically in common. If anything is "dumping garbage on the line to the computer, it has to be the radio itself. Again, in that case, all it is doing is emulating a more standard (COM) serial port, but in that case the communication is definitely two-way.
I tried three different drivers for the radio, and ended up with one - because it has the best documentation and is fairly new. But all that I tried worked, except for not fixing the problem.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi guys,
I posted this topic a few weeks ago on the WSJT-X forum (groups.io) and waited, and waited. Not a single reply..
I definitely miss Mike!
Anyway, here it is. Thanks in advance!
Larry N8KU
Here is my setup:
hardware - IC-7410 - Dell desktop computer/i5-14600/32GB - Hamplus AS-603A "automatic" antenna switch
software - Windows 11 24H2/completely up to date - WSJT-X 2.7 - JTAlert 2.80.4 - Log4OM 2.36.1
CP210x Universal UART driver 11.4 - Hamlib 4.6.2 - Open SSL 3.5.0 (I use WSJT-X only for FT8)
hamlib rig ID #3067
All this (except the AS603A) was working beautifully for years (with much older versions of hamlib and UART driver) until I recently added the antenna switch. By the way, the switch cable is connected ONLY to the radio, using both the "accessory" socket and the "remote" jack. (The cable has two connectors on one end. This is the correct method per Hamplus.) The computer is of course connected to the radio via USB.
So it all works, sort of. I started getting Hamlib errors from WSJT-X. After a lot of fussing with "radio" settings, on both the rig itself and WSJT-X, and eliminating the secondary software (JTAlert & Log4OM) I am still stuck. It will throw these errors anywhere from minutes to hours after starting up WSJT-X. It will do this regardless of whether JTAlert or Log4OM are running, and is unrelated to the steps of completing QSOs. It typically errors out when I am not even near the rig, during receive.
I got a response from the Hamplus guys in Brazil, they basically said "sorry, our product only 'listens' - it would not be trying to send anything to the rig" - which was actually very useful info.
When I try to research the "correct" settings within WSJT-X for the Icom 7410, the posts I have found are all over the map. After many days of trying all possible combinations, here is what I have settled on for now:
19200 baud
Data bits "Default"
Stop bits "Default"
Handshake "None"
Poll interval 1s
PTT Method "CAT"
Mode "Data/Pkt"
Split Operation "Fake It"
Note that the "Test CAT" and "Test PTT" both work. A slightly related problem is that the "Update Hamlib" button has NEVER worked, no matter what - that results in "Error Loading libhamlib-4.dll - TLS initialization failed" I updated to latest hamlib by copying the .dll over to WSJT-X manually.
items tried with no success:
tried different USB port on computer for rig
replaced the USB cable
set Data & Stop to 8 & 1
44/CI-V transceive back to "on"
handshake to none
bits to 8/1
CAT PTT port to COM3
manually update hamlib & openSSL again
example errors
Hamlib error: read_string_generic called, rxmax=200 direct=1, expected_len=1
read_string_generic(): RX 13 characters, direct=1
0000 fe fe e0 80 03 00 30 31 fe 00 e0 03 fd ......01.....
icom_one_transaction: frm_len=13, frm_len-1=fd, frm_len-2=03
*4:frame.c(503):icom_one_transaction returning(0)
3:frame.c(556):icom_transaction returning(0)
icom.c(1852) trace
set_vfo_curr: vfo=VFOA, curr_vfo=VFOA
set_vfo_curr: curr_vfo now=VFOA
icom.c(9662):set_vfo_curr returning2(0)
icom_get_freq: wrong frame len=7
rig_get_freq(2594): freqMainA=50313000, modeMainA=PKTUSB, widthMainA=3400
rig_get_freq(2594): freqMainB=50012431, modeMainB=PKTUSB, widthMainB=3400
rig_set_cache_freq(171): vfo=VFOA, current_vfo=VFOA
rig_get_band called
2:rig_get_freq: elapsed=41ms
**2:rig.c(2711):rig_get_freq returning(-11) Feature not available
Feature not available
Feature not available
while getting current VFO frequency
Hamlib error: from_bcd called
*7:event.c(615):rig_fire_freq_event entered
Event: freq changed to 163 Hz on currVFO
rig_set_cache_freq(171): vfo=currVFO, current_vfo=VFOA
*7:event.c(649):rig_fire_freq_event returning(0)
**6:icom.c(9246):icom_process_async_frame returning(0)
read_string_generic called, rxmax=200 direct=1, expected_len=1
read_string_generic(): RX 11 characters, direct=1
0000 fe fe e0 80 03 00 30 31 50 00 fd ......01P..
icom_one_transaction: frm_len=11, frm_len-1=fd, frm_len-2=00
5:frame.c(503):icom_one_transaction returning(0)
4:frame.c(556):icom_transaction returning(0)
icom_get_ptt: wrong frame len=4
**3:icom.c(5435):icom_get_ptt returning(-9) Command rejected by the rig
2:rig_get_ptt: elapsed=26ms
2:rig.c(3947):rig_get_ptt returning(-9) Command rejected by the rig
Command rejected by the rig
Command rejected by the rig
while getting PTT state
Timestamp: 2025-06-06T17:17:55.473Z
Hamlib error: read_string_generic called, rxmax=200 direct=1, expected_len=1
read_string_generic(): RX 16 characters, direct=1
0000 fe fe e0 80 03 00 30 31 50 00 3d fe 00 e0 03 fd ......01P.=.....
icom_one_transaction: frm_len=16, frm_len-1=fd, frm_len-2=03
*4:frame.c(503):icom_one_transaction returning(0)
3:frame.c(556):icom_transaction returning(0)
icom.c(1852) trace
set_vfo_curr: vfo=VFOA, curr_vfo=VFOA
set_vfo_curr: curr_vfo now=VFOA
icom.c(9662):set_vfo_curr returning2(0)
icom_get_freq: wrong frame len=10
rig_get_freq(2594): freqMainA=50313000, modeMainA=PKTUSB, widthMainA=3400
rig_get_freq(2594): freqMainB=50012431, modeMainB=PKTUSB, widthMainB=3400
rig_set_cache_freq(171): vfo=VFOA, current_vfo=VFOA
rig_get_band called
2:rig_get_freq: elapsed=32ms
**2:rig.c(2711):rig_get_freq returning(-11) Feature not available
Feature not available
Feature not available
while getting current VFO frequency
Timestamp: 2025-06-06T20:07:45.663Z
Hamlib error: write_block(): TX 7 bytes
0000 fe fe 80 e0 1c 00 fd .......
read_string_generic called, rxmax=200 direct=1, expected_len=1
read_string_generic(): RX 7 characters, direct=1
0000 fe fe 80 e0 1c 00 fd .......
icom_one_transaction: DEBUG retval=7, frm_len=7, cmd=0x1c
read_string_generic called, rxmax=200 direct=1, expected_len=1
read_string_generic(): RX 13 characters, direct=1
0000 fe fe e0 80 1c 00 00 e5 fe 00 e0 03 fd .............
icom_one_transaction: frm_len=13, frm_len-1=fd, frm_len-2=03
*5:frame.c(503):icom_one_transaction returning(0)
4:frame.c(556):icom_transaction returning(0)
icom_get_ptt: wrong frame len=6
*3:icom.c(5435):icom_get_ptt returning(-9) Command rejected by the rig
2:rig_get_ptt: elapsed=25ms
2:rig.c(3947):rig_get_ptt returning(-9) Command rejected by the rig
Command rejected by the rig
Command rejected by the rig
while getting PTT state
Timestamp: 2025-06-06T22:36:41.717Z
Hamlib error: read_string_generic called, rxmax=200 direct=1, expected_len=1
read_string_generic(): RX 9 characters, direct=1
0000 fe fe e0 80 03 00 e0 03 fd .........
icom_one_transaction: frm_len=9, frm_len-1=fd, frm_len-2=03
*4:frame.c(503):icom_one_transaction returning(0)
3:frame.c(556):icom_transaction returning(0)
icom.c(1852) trace
set_vfo_curr: vfo=VFOA, curr_vfo=VFOA
set_vfo_curr: curr_vfo now=VFOA
icom.c(9662):set_vfo_curr returning2(0)
icom_get_freq: wrong frame len=3
rig_get_freq(2594): freqMainA=50313000, modeMainA=PKTUSB, widthMainA=3400
rig_get_freq(2594): freqMainB=50012431, modeMainB=PKTUSB, widthMainB=3400
rig_set_cache_freq(171): vfo=VFOA, current_vfo=VFOA
rig_get_band called
2:rig_get_freq: elapsed=32ms
**2:rig.c(2711):rig_get_freq returning(-11) Feature not available
Feature not available
Feature not available
while getting current VFO frequency
Timestamp: 2025-06-07T01:23:17.894Z
--- new hamlib installed
Hamlib error: from_bcd called
*7:event.c(615):rig_fire_freq_event entered
Event: freq changed to 163 Hz on currVFO
rig_set_cache_freq(171): vfo=currVFO, current_vfo=VFOA
*7:event.c(649):rig_fire_freq_event returning(0)
**6:icom.c(9246):icom_process_async_frame returning(0)
read_string_generic called, rxmax=200 direct=1, expected_len=1
read_string_generic(): RX 11 characters, direct=1
0000 fe fe e0 80 03 00 40 07 07 00 fd ......@....
icom_one_transaction: frm_len=11, frm_len-1=fd, frm_len-2=00
5:frame.c(503):icom_one_transaction returning(0)
4:frame.c(556):icom_transaction returning(0)
icom_get_ptt: wrong frame len=4
**3:icom.c(5435):icom_get_ptt returning(-9) Command rejected by the rig
2:rig_get_ptt: elapsed=28ms
2:rig.c(3950):rig_get_ptt returning(-9) Command rejected by the rig
Command rejected by the rig
Command rejected by the rig
while getting PTT state
Timestamp: 2025-06-07T09:33:30.422Z
Hamlib error: *5:frame.c(145):icom_one_transaction entered
write_block(): TX 7 bytes
0000 fe fe 80 e0 1c 00 fd .......
read_string_generic called, rxmax=200 direct=1, expected_len=1
read_string_generic(): RX 7 characters, direct=1
0000 fe fe 80 e0 1c 00 fd .......
read_string_generic called, rxmax=200 direct=1, expected_len=1
read_string_generic(): RX 10 characters, direct=1
0000 fe fe e0 80 1c 00 00 e0 03 fd ..........
icom_one_transaction: frm_len=10, frm_len-1=fd, frm_len-2=03
5:frame.c(503):icom_one_transaction returning(0)
4:frame.c(556):icom_transaction returning(0)
icom_get_ptt: wrong frame len=3
**3:icom.c(5435):icom_get_ptt returning(-9) Command rejected by the rig
2:rig_get_ptt: elapsed=23ms
2:rig.c(3950):rig_get_ptt returning(-9) Command rejected by the rig
Command rejected by the rig
Command rejected by the rig
while getting PTT state
Timestamp: 2025-06-07T20:46:33.622Z
If you disconnect the AS-603A does the problem go away? If so, I wonder about some sort of ground loop causing noise and corrupting the data stream. How is the switch powered?
Yes. With no AS-603A (meaning no control cables, but antennas and power still attached) the problem goes away. It comes with a DC power cable that I can attach directly to the 12V supply.
Everything is grounded using heavy gauge copper cables, to a 4' copper bar that has a 10 foot long 6 gauge cable to a ground rod outside. The service panel is between the two and also connects to the rod (only 3 feet of cable.) No to mention the dozens of ferrites at the radio and computer ends of all cables. Seems to me all of this should only make a difference during transmit - but the problem only happens (90% of the time) during receive.
In the 2 months since I last posted here, I have also tried:
I don't like using Omnirig, it is very old code, unsupported and in the end Hamlib should work! It took me quite a while to modify the config file for the 7410 successfully. Getting this straightened out has become another hobby!
Also - one more new and interesting clue: having watched the rig and computer screen for MANY hours - I noticed that even with Omnirig, every once in a while, the relays on the antenna switch will chatter a bit, but no errors.. sometimes, I can see the VFO readout on the rig momentarily (maybe 1/2 second) switch to a frequency of like, ".150 MHz" and of course it turns red because it is out of the band. All gone in a glimpse, and it keeps working. I do believe that this is when it would throw the hamlib errors, but can't prove it because the error is usually minimized, and it keeps decoding. I don't find out until I go to actually make a QSO/use WSJT-X.
This leads me to believe that there is indeed something "noise-related" whether on the power line or being picked up by antennas. My power here (suburban neighborhood) is excellent and in this house full of electronics nothing else has ever had a problem.
I have a IC-7300 laying around that I am going to try to eliminate the rig entirely. It has been interesting to me while studying the nice looking but actually very poor documentation for the switch from Hamplus, that the 7410 is never mentioned as a supported rig, but there are several references to "all Icom" radios.
Thanks for the feedback, Larry (pun intended or not intended, you decide!).
Not having a 7410 or any later Icom, I am only speculating here. I wonder how isolated the RS-232 line, or other data line in the radio feeding the port the switch listens on, is. I can imagine a scenario where the switch is doing something to the line that corrupts the data. Also, even though they claim it only listens, is it possible it's dumping garbage on the line going to the CPU?
It will be interesting if the 7300 responds in the same way.
Exactly. I couldn't have said it better.
Where I am still stuck is, the communication between the antenna switch
and the radio is pure serial - and one direction only, if you can
believe the manufacturer. The protocol (CI-V) is outlined in the Icom
manual. In this case it is only about HF band identification.
But Hamlib only talks to it serial, over USB. They do not have anything
physically in common. If anything is "dumping garbage on the line to the
computer, it has to be the radio itself. Again, in that case, all it is
doing is emulating a more standard (COM) serial port, but in that case
the communication is definitely two-way.
I tried three different drivers for the radio, and ended up with this
one https://www.pololu.com/docs/0j7/all - because it has the best
documentation and is fairly new. But all that I tried worked, except for
not fixing the problem.
------ Original Message ------
From "Nate Bargmann" n0nb@users.sourceforge.net
To "[hamlib:discussion]" 25919@discussion.hamlib.p.re.sourceforge.net
Date Fri, 08-01-2025 2:06:12 PM
Subject [hamlib:discussion] Re: hamlib errors w/WSJTX
Exactly. I couldn't have said it better.
Where I am still stuck is, the communication between the antenna switch and the radio is pure serial - and one direction only, if you can believe the manufacturer. The protocol (CI-V) is outlined in the Icom manual. In this case it is only about HF band identification.
But Hamlib only talks to it serial, over USB. They do not have anything physically in common. If anything is "dumping garbage on the line to the computer, it has to be the radio itself. Again, in that case, all it is doing is emulating a more standard (COM) serial port, but in that case the communication is definitely two-way.
I tried three different drivers for the radio, and ended up with one - because it has the best documentation and is fairly new. But all that I tried worked, except for not fixing the problem.