[Hamlib-developer] CVS checkin

[Dale E. E. <de...@w-...>]

Nate,

Thanks a lot.  Stephane e-mailed  me a while back an said the "magic
band"
was keeping him pretty busy.  I've sent him some basic files, but now
they
are very obsolete.  At least they will have the two new files inserted
into the
tree and will be buildable (when he gets to it).

My e-mail is strange and I'm just getting set up.  Now that I'm able to
receive
and send on the developer's list I'll keep up on what's going on.

I'd like very much if you'd test out my changes if you'd like.  However,
since
I've made some pretty extensive changes to things like RIG_VFO_* in
rig.h,
rig.c, and rigctl, I'd like the changes to be reviewed before being
checked
directly into CVS.

The gist of the non-ts2k changes are the addition of numerous VFO types.

They are as follows:
           RIG_VFO_AB       // split, RX=VFOA on Main receiver
           RIG_VFO_BA      // split, RX=VFOB on Main receiver
           RIG_VFO_MEM_A    // Memory on Main receiver
           RIG_VFO_MEM_C   // Memory on Sub receiver
           RIG_VFO_CALL_A    // Call channel on Main
           RIG_VFO_CALL_C    // Call channel on Sub
I plan on adding the following:
           RIG_VFO_A_MEM    // split, RX=VFOA, TX=MEMA
           RIG_VFO_B_MEM    // split, RX=VFOB, TX=MEMA
but it requires a little more programming.  (Plus any more that I can.)

The point of these changes is to make it obvious what the exact
state of the rig is.  I can now put the TS-2000 into any of the above
states (first six) plus the normal VFOA, VFOB, VFOC.  Just making
VFOC was a chore without the changes.

A word of caution:  Adding these extra vfo's is really cool in what
you can do, but right now my _get_freq() doesn't work by default.
If this is expected behaviour you could say its broken.  The _get_freq()

now has to do commands to specifically read these other vfo's.
In actuality, it is better since I won't receive VFOA when the rig
is on the sub receiver, or MEMA when MEMC is selected.  Other
developers may have solved this differently or better.

A curious side effect is that treating RIG_VFO_AB as its own VFO,
is that the rig_set_split_freq() doesn't really need to exist, but it
doesn't hurt anything either.  What I'm working towards is being
able to create a rig_set_active( active_t  xcvr ) or similar function
that will set the rig mode (as opposed to transmission mode) such
as satellite, scan,  Main, Sub, etc...  Each 'activated' state the rig
can be in usually has distinct vfo's, transmission modes etc... that
are either required or default.  This is just a higher level of control
than the *_set_vfo() *_set_mode() combinations.  The need for
numerous unique modes for every rig will (hopefully) be elimanted.
Also, software will be able to simulate these modes in some instances.

Finally, if you (or anybody) would like to look at these as I've applied

them to my kenwood/ts2k.c, I'll be happy to make a tarball of the
changes and e-mail them to you directly.  I'd prefer to get a little
more of a consensus before just dropping them into CVS.  Once
I'm a little more confident everybody'll be happy, then they can
get checked into CVS and we'll deal with what happens after
that.

Sorry, I carried on so long.  It would have been easier to say,
"Sure, I'd appreciate it if you'd put them into CVS for me."
but I'd like people to have a chance to yea or nay first.

73's and let me know.  I'm eager to continue on with this stuff.

(By the way, I think I've fixed most, if not all, the problems I've
posted to the group earlier--except the rpcrig which I had to
remove.)

Thank you.

Dale E. Edmons
KD7ENI