Re: [Hamlib-developer] Orion questions

[Stephane F. <f8...@fr...>]

On Mon, Mar 28, 2005 at 11:04:02AM -0500, Martin, AA6E wrote:
> The Orion (tt565) doesn't behave very well on its serial port.  The
> error rate is fairly high, depending on what else its uP is being
> asked to do.  Also, its responses are not all fixed length. I now see
> that the TenTec interaction is set up for fixed-length read
> operations, and it times out if you ask for a higher byte count.  At
> present, the Orion module seems to time out on all read operations! 
> However, the responses are correct as far as I know.

Have a look at kenwood/kenwood.c:kenwood_transaction() for an example
of variable length return. Basically, it makes use of src/iofunc:read_string().

> To do better for the Orion (verification, error retry, etc.), I may
> want to bring in much of the serial I/O into orion.c.  The question I
> have is whether this is going to break anything significant --
> especially, portability.  I don't claim to understand all the
> subleties.  Any thoughts?  (Of course portability is not much help if
> the code is broken...)

There's no need to bring special serial I/O code. Anyway, you can't do
much but retry, and insert some pauses to not overwhelm the uP.
Have a look at tt538_transaction() in jupiter.c, or icom_transaction()
in icom/frame.c for an example.

If you do need to have some kind of new I/O function, try to not bring
non portable code in backends. Either use existing functions from
frontend, or create a new one, that is generic.

> If I do this, I will be ignoring some parts of the rig capabilities
> mechanism, like I/O delays.  How important is it to refer everything
> to the official capabilities structure instead of building into Orion
> backend?  Seems to me these are equivalent locations for logic of any
> particular rig.  The main advantage may be that it helps the cross-rig
> maintainers to find the peculiarities of each rig in one data object,
> and it helps many backends to look the same.  That philosophy may
> break down if one rig has too much "personality".

It helps the application developper and the final user. Some backends
simply ignore the settings if they are no applicable. Backends with too
much "personality" have it implemented with set_conf settings
(TOKEN_BACKEND).

-- 
Stephane

PS: don't forget to complain against Ten-Tec about buggy firmwares