Re: [Hamlib-developer] Re: Ten-Tec Models

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

Hi Martin,

About your question on the Orion family, it's up to you (and other Orion
developers) to create new models ID's as you see fit. If the protocol
is strictly identical, it's questionable whether a new ID should be
created. For example there's no Kenwood TH-F6A backend, because there's
already a TH-F7E which is the european version. Please note the frequency
ranges are handled properly though for region 1 and region 2.
The day we will be overwhelmed by TH-F6A owners not finding their
backend, we'll create a new model ID, or find a smarter idea.


Your new question is a lot more serious, indeed. Hamlib IS missing
a ballpark picture. Since year 2000, the project evolved, tried to 
overcome weird radio features, etc. Many API calls were implemented
without proper documentation, most of the time only with rigctl
as an example. I admit, it's tough on the backend developers and
the application developers. Your contribution is very welcome,
and I'm willing to help you (a lot) in writing that tutorial/reference 
of the virtual machine. I guess you'll concentrate first on writing
a document targetted at backend developers. Where do you plan
to write this? In a doxygen container (so it's also published to 
the web later) ? As an SGML file?
I'm not very good at writing documentation, but I'll do my best
answering any questions.

Thanks
-- 
Stephane - F8CFE

On Sun, Feb 26, 2006 at 02:09:47PM -0500, Martin, AA6E wrote:
> I will answer my own question for the moment.  I will add some notes
> to the TenTec README file.  Is this the standard way to communicate
> with the user public?  Better than nothing!  (I think we should
> improve the project web page.  More on this another time.)
> 
> New question: This is a more serious one.  I worked on the Orion
> backend to the point that the basics seem to work on rigctl.  However,
> I really don't understand the complicated (I don't want to say
> baroque!) virtual rig model that we are trying to implement.  
> Specifically, questions like how are multiple VFOs to be handled,
> memories, etc.  Some functions are clearly more appropriate for VHF &
> scanner rigs than for HF transceivers, and probably we should not try
> to implement them.
> 
> All of this info could be deduced from rig.h, the doxygen output,
> etc., but it's opaque to someone who did not "grow up" with the
> project.  An API description is really not enough.
> 
> What would really help me is a tutorial/reference of the virtual
> machine we are trying to create for software implementers.  I know the
> Orion well enough, but I need to know more about the virtual rig into
> which we are trying to squeeze the Orion (and all other rigs).
> 
> Such a document would be a great help to me, for one.   I could try to
> write it, but I would need a lot of help.
> 
> 73, Martin AA6E
> 
> On 2/26/06, Martin, AA6E <mar...@gm...> wrote:
> > Hi, group,
> >
> > I was looking through CVS to see where & how to specify the Ten-Tec
> > model 566 = Orion 2.  It is equivalent (so far as I know) to the TT
> > model 565 = Orion.
> >
> > In most places, this rig is just referred to as "Orion", but
> > internally there is RIG_MODEL_TT565 and the value 1608.
> >
> > All in all, it's not clear where & how to declare the list of model
> > numbers and nicknames that are associated with a particular "rig
> > number".  In this case, 565, 565AT, 566, and 566AT all should go with
> > the Orion backend.
> >
> > I won't lose sleep over this, but maybe someone has a bright idea.
> >
> > 73 Martin AA6E
> > --
> > mar...@gm...
> > http://blog.aa6e.net
> >
> 
> 
> --
> mar...@gm...
> http://blog.aa6e.net