[Hamlib-developer] hamlib_ts2k

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

Stephane,

The RIG_CHFLAG_SKIP would be prefered.  Either
is needed but not both (unless you are giving me the
RIG_CHFLAG_LOCK so I can use it as READONLY--
hi).

See my response to Robert for more info on READONLY.

The 1750Hz item is a menu option and will be treated as
such unless otherwise notified.  (Again, see my reply to
Robert for more info.)  The "one-shot" is not standard
on my rig  (U.S./Canada version) but is a menu option.

Ignoring the 1750Hz there are three unique tone types:
    1) Tone, 2)CTCSS, 3) DCS.
In my area only 1) is used and 2) and 3) are not, at least
to my limited knowledge.  I have used CTCSS on my
HT to operate my rig via remote control, but if you
accidently enable CTCSS on an actual repeater, you
will not be able to talk on it.  There is no 1750 Hz
activation (again, to my limited knowledge).

Yes, the "Programmable Memories" are different.
The manual only lists the command.  I don't think
it may be accessed via the panel.

The name rig_set_pm() would be wrong but it would
be okay to have ts2k_set_pm().  Maybe we could
write rig_set_state() or rig_set_setup() or even
rig_set_conf() if rig_set_menu() replaces your
previous.

Later, it may be required to backup PM[0:5] and it
would be done (by some application) as follows:
    for( pm=0, pm<=5; pm++) {
    rig_set_conf(rig, pm);
    rig_save_channel(rig, RIG_CTRL_MAIN);
    rig_save_channel(rig, RIG_CTRL_SUB);
    rig_get_menus(rig, MENU_FIRST, MENU_LAST);
    rig_set_menu(rig, MENU_B);
    rig_get_menus(rig, MENU_FIRST, MENU_LAST);
     }
Or something very close to this.

I have begun working on the Menu stuff as it is
important to the user.  I haven't even tried compiling
anything so far but I think I'm on the right track.
Much input will be needed and appreciated.

I don't know what all will be needed for the menu
API.  The backend may need to initialize stuff
which can be called with the mmelter_init().
I've anticipated Hamlib's complete lack of know-
ledge of Menu items and suggest rig_menu_list()
which will return a char * to the menu items
description.  See my ts2k_menu.h if you find
the time.  The ts2k_menu.c is not very far and
will change.  The application will do something
like the following to change a menu item:
    rig_get_menu(rig, MENU(12));
    fprintf(menu, "%s: ", rig_menu_list(rig, MENU(12)) );
     /* read user response and set value */
    rig_set_menu(rig, MENU(12),  value);
Or something vaguely like this.  The application
should be able to setup its own complete menus
so the user may browse the entire set.  I think
we're thinking along the same lines.


My work on the TS440 stopped after I said it
was similar to existing stuff.  I saw you had
some stuff for it and got busy with other stuff.
The same goes with the kenwood_transaction().

P.C.T. is very cool but completely useless if
only the rig can access it.  The user can use
the panel until other things are sorted out.

rig_save_channel() should work as you suggested
but I'll have to see what you write or show you
what I write.  As long as the backend can take
over, life is good.  Any of the channel() stuff
should have a channel_t.  The called function
should always be passed the needed values
of chan_t, or vfo_t, or both in this struct or
as parameters.  The backend can't guess
and setting them in the rig may be the wrong
thing to do.  If needed, the backend can set
them in the rig (or if generic_save_channel()
is called).

Sorry for running on so long again.

73's

Dale
kd7eni