Re: [Hamlib-developer] Orion questions

[Mike M. <mm...@UD...>]

Martin,

I've been adding code to jupiter.c (and have another update I need to
add).  And I've also noticed that the Jupiter has a high error rate.  I
actually wrote a hack of a subroutine that tries up to 3 times for each
request, just in case, and it still doesn't take care of the problem all
of the time.

There is a very good chance I'll be selling my Jupiter shortly, though,
so my jupiter.c contributions will be coming to an end if that happens.

Mike  AB3AP

Martin, AA6E wrote on 03/28/05 11:04 ET:
> 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.
> 
> 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...)
> 
> 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".
> 
> If there are other Ten-Tec developer/maintainers out there -- do the
> other TT backends have similar problems?  I hesitate to program for
> platforms I do not have in house.  (Not that that stops some folks
> around here! :-)
> 
> I would appreciate some Group Think on these questions.
> 
> 73