Running Hamlib 1.2.5, Ubuntu 6.10 and controlling an Icom-706 MkIIg (311)
When using gRig I see S-Meter movement and can read and change freq on the rig for about 30 seconds, then the S-Meter freezes. I can still send frequency command to the radio for a short time, but eventually all communication with the rig fails.
Running Grig in debug results in an endless stream this after the fail.
2006/12/02 07:46:53;;HAMLIB;;3;;read_string: timedout without reading a character
I have tried forcing slower serial bus speeds all the way down to 300baud, but the failure remains.
Here is the output of a typical session in rigctl.
Opened rig model 311, 'IC-706MkIIG'
Backend version: 0.3, Status: Beta
Rig command: f
TX 6 bytes
0000 fe fe 58 e0 03 fd ..X...
RX 6 characters
0000 fe fe 58 e0 03 fd ..X...
RX 11 characters
0000 fe fe e0 58 03 00 00 88 01 00 fd ...X.......
Frequency: 1880000
Rig command: f
TX 6 bytes
0000 fe fe 58 e0 03 fd ..X...
RX 6 characters
0000 fe fe 58 e0 03 fd ..X...
RX 11 characters
0000 fe fe e0 58 03 00 00 88 01 00 fd ...X.......
Frequency: 1880000
Rig command: f
TX 6 bytes
0000 fe fe 58 e0 03 fd ..X...
read_string: timedout without reading a character
TX 6 bytes
0000 fe fe 58 e0 03 fd ..X...
read_string: timedout without reading a character
TX 6 bytes
0000 fe fe 58 e0 03 fd ..X...
read_string: timedout without reading a character
TX 6 bytes
0000 fe fe 58 e0 03 fd ..X...
read_string: timedout without reading a character
get_freq: error = Communication bus error
Rig command: F
Frequency: 1881000
TX 11 bytes
0000 fe fe 58 e0 05 00 10 88 01 00 fd ..X........
read_string: timedout without reading a character
TX 11 bytes
0000 fe fe 58 e0 05 00 10 88 01 00 fd ..X........
read_string: timedout without reading a character
TX 11 bytes
0000 fe fe 58 e0 05 00 10 88 01 00 fd ..X........
read_string: timedout without reading a character
TX 11 bytes
0000 fe fe 58 e0 05 00 10 88 01 00 fd ..X........
read_string: timedout without reading a character
set_freq: error = Communication bus error
Rig command: f
TX 6 bytes
0000 fe fe 58 e0 03 fd ..X...
read_string: timedout without reading a character
TX 6 bytes
0000 fe fe 58 e0 03 fd ..X...
read_string: timedout without reading a character
TX 6 bytes
0000 fe fe 58 e0 03 fd ..X...
read_string: timedout without reading a character
TX 6 bytes
0000 fe fe 58 e0 03 fd ..X...
read_string: timedout without reading a character
get_freq: error = Communication bus error
Rig command: q
rig:rig_close called
rig:rig_cleanup called
Hmm? I've never seen it before. I've never used gRig so I don't know how they access the hamlib. I doubt it is a serial speed problem. It appears that either your rig is not responding to the interface or for some reason hamlib is not seeing what it thinks it should. Is your rig in trancieve or normal mode? What is your physical interface? (CIV converter)?
Does it happen if you don't run gRig first? ie On a newly booted system? Just run rigctl?
Can you access the CVS? We are close to releasing a 1.2.6 version.
I will have to look at the gRig code.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, that is what transcieve mode is designed for. When you make a change on the rig it sends command without expecting ack to other connected rigs to change the same paramenters. It does this at least for frequency and operating mode. I don't know if it does so for other commands. It's not well documented. But in hamlib it also serve the function for asynchronus communication. Hamlib has 3 modes: transcieve (true anynchronus), polled and standard. It is designed to let you control the rig from either the program or the rig. I haven't played much with the transcieve and polled modes, they seem to work with okay in my limited experience. But, both hamilib and the rig need to be in the same mode.
What does gRig expect???? Teh said he had the same problem under windows. I would recommend turning off the transcieve mode to test it under rigctl and windows. (ie turn it off at the radio. The rigctl transcieve command changes what rigctl expects it doesn't change the rig itself).
Who made your serial CIV converter?
AD7AI
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Grig simply executes read/write commands synchronously and does not use the transceive feature at all. That should not cause any problems even with transceive mode ON, since hamlib would simply trash the incoming transceive messages, I suppose.
73
Alex OZ9AEC
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Which Windows programs have you tried. I can recommend the Ham Radio Deluxe program if you haven't tried it. If it doesn't work with windows, that would suggest a hardware problem.
AD7AI
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The capacitor mentioned in a previous responce had been installed backwards. With its polarity reversed, it could not maintain the minimum voltage for RS232 operation. It would charge immediately, but as time went by it slowly bled out till communication ceased. Broke out my soldering iron, reversed the part and all is well.
Ive been running gRig for over an hour now without a hiccup.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am using a serial-CIV converter.
The rig -IS- in tranceive mode.
It happens no matter what order I try diff apps.
And, no, I do not have access (or know how to use) CVS.
On the bright(?) side, I have since found that the rig fails in the same way using a Windows control app.
I am now looking into the possibility that the converter itself is the issue.
I will keep you posted on my results.
--Teh
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Maybe you can find an answer to your problem at the
FAQs of HAMLIB. Please look under:
"- The serial port keeps on getting timeout, the rig works fine under DOS. What's wrong?"
vy 73
Olaf, DL4DZ
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm no expert in ICOM CI-V, but isn't transceive mode something you use when you connect two or more ICOM rigs together? If so, it sound like asynchronous communication between two devices and should be turned OFF when trying to control one transceiver from a computer.
73
Alex OZ9AEC
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Not sure where to start here..
Running Hamlib 1.2.5, Ubuntu 6.10 and controlling an Icom-706 MkIIg (311)
When using gRig I see S-Meter movement and can read and change freq on the rig for about 30 seconds, then the S-Meter freezes. I can still send frequency command to the radio for a short time, but eventually all communication with the rig fails.
Running Grig in debug results in an endless stream this after the fail.
2006/12/02 07:46:53;;HAMLIB;;3;;read_string: timedout without reading a character
I have tried forcing slower serial bus speeds all the way down to 300baud, but the failure remains.
Here is the output of a typical session in rigctl.
------------------------------------------------------------
Opened rig model 311, 'IC-706MkIIG'
Backend version: 0.3, Status: Beta
Rig command: f
TX 6 bytes
0000 fe fe 58 e0 03 fd ..X...
RX 6 characters
0000 fe fe 58 e0 03 fd ..X...
RX 11 characters
0000 fe fe e0 58 03 00 00 88 01 00 fd ...X.......
Frequency: 1880000
Rig command: f
TX 6 bytes
0000 fe fe 58 e0 03 fd ..X...
RX 6 characters
0000 fe fe 58 e0 03 fd ..X...
RX 11 characters
0000 fe fe e0 58 03 00 00 88 01 00 fd ...X.......
Frequency: 1880000
Rig command: f
TX 6 bytes
0000 fe fe 58 e0 03 fd ..X...
read_string: timedout without reading a character
TX 6 bytes
0000 fe fe 58 e0 03 fd ..X...
read_string: timedout without reading a character
TX 6 bytes
0000 fe fe 58 e0 03 fd ..X...
read_string: timedout without reading a character
TX 6 bytes
0000 fe fe 58 e0 03 fd ..X...
read_string: timedout without reading a character
get_freq: error = Communication bus error
Rig command: F
Frequency: 1881000
TX 11 bytes
0000 fe fe 58 e0 05 00 10 88 01 00 fd ..X........
read_string: timedout without reading a character
TX 11 bytes
0000 fe fe 58 e0 05 00 10 88 01 00 fd ..X........
read_string: timedout without reading a character
TX 11 bytes
0000 fe fe 58 e0 05 00 10 88 01 00 fd ..X........
read_string: timedout without reading a character
TX 11 bytes
0000 fe fe 58 e0 05 00 10 88 01 00 fd ..X........
read_string: timedout without reading a character
set_freq: error = Communication bus error
Rig command: f
TX 6 bytes
0000 fe fe 58 e0 03 fd ..X...
read_string: timedout without reading a character
TX 6 bytes
0000 fe fe 58 e0 03 fd ..X...
read_string: timedout without reading a character
TX 6 bytes
0000 fe fe 58 e0 03 fd ..X...
read_string: timedout without reading a character
TX 6 bytes
0000 fe fe 58 e0 03 fd ..X...
read_string: timedout without reading a character
get_freq: error = Communication bus error
Rig command: q
rig:rig_close called
rig:rig_cleanup called
------------------------------------------------------------
That last 'F' command does change the freq of the radio, but it will not read the value back to the computer.
Any clues?
--Teh
Hmm? I've never seen it before. I've never used gRig so I don't know how they access the hamlib. I doubt it is a serial speed problem. It appears that either your rig is not responding to the interface or for some reason hamlib is not seeing what it thinks it should. Is your rig in trancieve or normal mode? What is your physical interface? (CIV converter)?
Does it happen if you don't run gRig first? ie On a newly booted system? Just run rigctl?
Can you access the CVS? We are close to releasing a 1.2.6 version.
I will have to look at the gRig code.
Yes, that is what transcieve mode is designed for. When you make a change on the rig it sends command without expecting ack to other connected rigs to change the same paramenters. It does this at least for frequency and operating mode. I don't know if it does so for other commands. It's not well documented. But in hamlib it also serve the function for asynchronus communication. Hamlib has 3 modes: transcieve (true anynchronus), polled and standard. It is designed to let you control the rig from either the program or the rig. I haven't played much with the transcieve and polled modes, they seem to work with okay in my limited experience. But, both hamilib and the rig need to be in the same mode.
What does gRig expect???? Teh said he had the same problem under windows. I would recommend turning off the transcieve mode to test it under rigctl and windows. (ie turn it off at the radio. The rigctl transcieve command changes what rigctl expects it doesn't change the rig itself).
Who made your serial CIV converter?
AD7AI
Grig simply executes read/write commands synchronously and does not use the transceive feature at all. That should not cause any problems even with transceive mode ON, since hamlib would simply trash the incoming transceive messages, I suppose.
73
Alex OZ9AEC
The converter was built by G8XGG. He has -several- on eBay.
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=320058271114
It is a two transitor type, and does not use the Max232 chip.
I turned the tranceive off, but I still get the same failure. :(
--Teh
Which Windows programs have you tried. I can recommend the Ham Radio Deluxe program if you haven't tried it. If it doesn't work with windows, that would suggest a hardware problem.
AD7AI
It turned out to be a hardware problem.
The capacitor mentioned in a previous responce had been installed backwards. With its polarity reversed, it could not maintain the minimum voltage for RS232 operation. It would charge immediately, but as time went by it slowly bled out till communication ceased. Broke out my soldering iron, reversed the part and all is well.
Ive been running gRig for over an hour now without a hiccup.
In answer to your questions...
I am using a serial-CIV converter.
The rig -IS- in tranceive mode.
It happens no matter what order I try diff apps.
And, no, I do not have access (or know how to use) CVS.
On the bright(?) side, I have since found that the rig fails in the same way using a Windows control app.
I am now looking into the possibility that the converter itself is the issue.
I will keep you posted on my results.
--Teh
Hello Tehrasha,
Maybe you can find an answer to your problem at the
FAQs of HAMLIB. Please look under:
"- The serial port keeps on getting timeout, the rig works fine under DOS. What's wrong?"
vy 73
Olaf, DL4DZ
I saw that bit in the FAQ. Bu the problem it describes appears to be the opposite of mine.
The FAQ talks about failure at first, until the capacitors charge.
My problem is that it works fine at first, and eventually stops.
--Teh
I'm no expert in ICOM CI-V, but isn't transceive mode something you use when you connect two or more ICOM rigs together? If so, it sound like asynchronous communication between two devices and should be turned OFF when trying to control one transceiver from a computer.
73
Alex OZ9AEC