Re: [Hamlib-developer] IC-736 backend status and converter power

[Chuck H. <n2...@am...>]

ci-v interfaces have the transmit and receive are tied together on the ci-v
side.  Because of this they echo the commands sent to it back to the computer
(with or without a radio connected)

The reason your getting a RIG_BUSERROR is because hamlib is not seeing the
echo.

That can be caused by several things
1. wrong serial port
2. wrong interrupt
3. problems with ci-v interface
4. radio causing problems on ci-v bus
   (shorted, constant voltage, constant collisions)

One way to check these might be to disconnect the radio from the ci-v bus, and 
either check for a different hamlib error, or see if characters echo in your
favorite serial program.  You might also try disconnecting the radio to see if
there are any changes.

For some reason I couldn't view the URL you gave http://www.g3vgr.co.uk/civ.htm
so I'm not sure if the circuit your using is using a serial driver chip or
something else.

However, if your trying to drive the chip using power from the serial port I
would check the voltages your getting and make sure enough is making it to the
chip.

I started off trying to power my interface from the serial port and decided
after a little checking to power it externally since at least one of my
serial ports was putting out +5 volts and after a diode (in case the pin went
negative) and a voltage regulator (in case the pin was a +12 volts) I wasn't
going to have enough power to drive the chip (because it wasn't a low voltage
chip, it wanted about +5 volts)

I also had a problem where it would work on one computer but not the other and
I finally traced it down to the fact that I mis-read the chip docs and put caps
where this chip wanted jumpers so it was putting out about +-.6 volts.

The RS-232 spec says that:
+3 to +15 is mark
-3 to -15 is space (or is the other way around)
+3 to -3 is undefined

back in the old days things tended to use +12 and -12 to drive the lines and
you could run cables all over the place.  These days many things use +5 and -5
to drive the lines because they assume the things connected are going to be
close by and because it's cheaper.  However this gives you less power to work
with if your trying to power something from the serial port.

I've also included part of an email I sent when I was working on cleaning up
some of the icom error handling.  It probably should end up as part of the
documentation sometime.  However right now it is sort of icom specific.  I'm
not sure where it would go.

Feel free to ask if you have any more questions or problems.

---

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)

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