[Hamlib-developer] Improved Icom error checking
Library to control radio transceivers and receivers
Brought to you by:
n0nb
|
From: Chuck H. <n2...@am...> - 2002-03-17 09:19:56
|
As promised, here is my ideas for improved error checking for icom_transaction
and icom_decode.
To make it easier for the user to distinguish between problems, I added two new
error codes (Do you have any better ideas?):
RIG_BUSERROR
This means something is wrong talking on the CI-V bus.
(such as transmitted characters did not echo)
If this is received at program startup, it probably means the computer is not
talking on the CI-V bus. (wrong serial port, problems with CI-V interface)
RIG_BUSBUSY
Detected collision on CI-V bus.
I also used existing error codes:
RIG_ETIMEOUT
Timeout talking to the radio.
If this is received at program startup, it probably means there is a problem
talking to the radio. (wrong speed, no power to radio, radio not on CI-V,
radio did not recognize the command)
RIG_EPROTO
Something else unexpected happened
In doing my quick testing:
1. With the radio off, I got a RIG_ETIMEOUT
2. With the power removed from the CI-V interface, I got a RIG_BUSERROR
3. I caused some collisions and got a RIG_BUSBUSY, see attached traces
Due to the number of changes to icom_transaction, I included a the entire
replacement routine. If you want a patch instead, let me know.
I also included a patch that includes the changes to icom_decode, and adding
of the error codes.
Take a look at them and see what you think.
I also noticed my C formating is a bit different then is currently in hamlib,
I fix that if you want.
Also attached are a couple of traces I got while trying to cause collisions:
1. A collision and the stuff around it.
2. A protocol error that didn't get flagged as a collision. (Extra character
got stuck in the received frame) Not sure if we care right now.
Things I noted looking at these and other traces:
1. SA_sigioaction gets called for each received character in icom_transaction
and is ignored due to hold_decode. I assume this won't cause too much
of a performance problem.
2. sa_sigioaction is getting called once after each icom_transaction with no
characters in the input buffer and icom_decode then times out.
(Maybe icom_decode needs to pass a flag to read_string to set the timeout
to zero for the first character?)
3. The collision character gets sent quite a few times when a collision occurs.
4. The radio attempts to resend the frame that caused the collision, but
sometimes another character ends up in the input buffer before it.
(Maybe we should ignore characters before the FE in the frame?)
5. If I turn the dial even fairly slowly, you get stuck in icom_decode enough
that the main program doesn't run at all.
This may be partially caused by the fact that my CI-V bus is currently at
1200 bps. At 1200 bps, a frequency change tranceive frame takes about a
1/10th of a second to be received.
Maybe getting individual characters and processing them with a state
machine would help.
Since it's not really bothering me right now, I'll leave it alone for now.
But I'll take a look at it if someone else is interested.
(My main program is just dealing with this one radio right now, and it
recovers fairly quickly after you stop turning the knob)
---
This trace got a collision:
Processing command 3: 'set_freq' '435.177068'
TX 12 bytes
0000 ff fe fe 08 e0 05 68 70 17 35 04 fd ......hp.5..
sa_sigioaction: activity detected
RX 1 characters
0000 fc .
problems with rig_set_freq
x = -14
ERROR: rig_set_freq 'Communication bus collision'
Start poll
sa_sigioaction: activity detected
icom: icom_decode called
RX 1 characters
0000 fc .
icom: icom_decode saw a collision
pn = -1
Start poll
sa_sigioaction: activity detected
icom: icom_decode called
RX 10 characters
0000 f8 08 e0 05 68 70 17 35 04 fd ....hp.5..
icom_decode: CI-V 0x8 called for 0x5!
icom_decode: tranceive cmd unsupported 0x68
sa_sigioaction: activity detected
icom: icom_decode called
RX 1 characters
0000 fc .
icom: icom_decode saw a collision
sa_sigioaction: activity detected
icom: icom_decode called
RX 1 characters
0000 fc .
icom: icom_decode saw a collision
pn = -1
Start poll
sa_sigioaction: activity detected
icom: icom_decode called
RX 1 characters
0000 fc .
icom: icom_decode saw a collision
pn = -1
Start poll
sa_sigioaction: activity detected
icom: icom_decode called
RX 11 characters
0000 fe fe 00 08 00 00 52 17 35 04 fd ......R.5..
Rig 0x8050a78 changed freq to 435175200 Hz
passed xslot = 0
On slot 1: 'radio_freq_event 435.175200
---
This trace got a RIG_EPROTO:
Processing command 3: 'set_freq' '145.941951'
TX 12 bytes
0000 ff fe fe 08 e0 05 50 19 94 45 01 fd ......P..E..
sa_sigioaction: activity detected
sa_sigioaction: activity detected
sa_sigioaction: activity detected
sa_sigioaction: activity detected
sa_sigioaction: activity detected
sa_sigioaction: activity detected
sa_sigioaction: activity detected
sa_sigioaction: activity detected
sa_sigioaction: activity detected
sa_sigioaction: activity detected
sa_sigioaction: activity detected
RX 13 characters
0000 fe f9 fe fe 08 e0 05 50 19 94 45 01 fd .......P..E..
problems with rig_set_freq
x = -8
ERROR: rig_set_freq 'Protocol error'
Start poll
sa_sigioaction: activity detected
icom: icom_decode called
RX 6 characters
0000 fe fe e0 08 fb fd ......
icom_decode: tranceive cmd unsupported 0xfb
sa_sigioaction: activity detected
icom: icom_decode called
RX 11 characters
0000 fe fe 00 08 00 00 15 94 45 01 fd ........E..
Rig 0x8050a78 changed freq to 145941500 Hz
passed xslot = 0
On slot 1: 'radio_freq_event 145.941500
'
|