[Hamlib-developer] hamlib_ts2k

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

Stephane:

1) hamlib_ts2k:    I had already stated I wouldn't commit into hamlib,
    but only to hamlib_ts2k.  Maybe you are just repeating your
previous?
    Thanks for setting this up!  Yes, I'll review the CVS as what I've
been
    using is an old doc and there are newer more readable ones out now.

    I have my own CVS repository set up.  Thanks for your concern about
    overwriting stuff though.  I also keep regular tarball backups.  I'm
only
    a little paranoid.

2) RIG_RPT_SHIFT_1750:  Yes, this is the Europe style 1750Hz and I
    only know how to turn it on.  The ts2k displays '+" for
RIG_RPT_PLUS,
    '-' for RIG_PRT_MINUS, and '=' to use the European 1750 style.
    Since I don't know of any repeater that uses this, I can't test or
confirm.
    For what it's worth, it is the "os3;" command with menu  44 on.
    (TS-2000 Instruction Manual pages: 33, 131)  Easiest for me is for
this
    to just go away, but I figured some Non-(U.S.A./Canada) Ham
    would complain eventually.  Entirely your call as this don't affect
me.

3) channel->lock:    This was one of my first changes to rig.h.  I
    like the channel->flag better.  Please allocate something like
    RIG_CHFLAG_LOCK or some such to set it with (even a bit field
    will do if you want to go that far.  More specifically it is a
"skip"
    during "group scan" for any memory having this True.  Also,
    nice would be a READONLY bit to prevent Hamlib from over-
    writing certain memories (my group 9 is emergency/rescue and
    is not to be touched!)

4) tone_t tone; On my HT and the TS2K the CTCSS and Tone are
    separate and set individually.  However, only one may be enabled,
    but both may be read and will yield different values if set
differently.
    Calling this CTCSS is like calling SSB, AM.  Similar functions,
    different critters.  Your call.

5) RIG_MTYPE_*:  As I understand it, the MTYPE describes available
    and accessible memories for a rig.  The Setup is what I intended for

    Kenwood's "Programmable Memories".  There are 0-5 available
    which a simple view would be to say the rig has its own
    rig_save_channel() which saves 1) Main VFO's, 2) Sub VFO,
    (as well as the memory pointers I believe) and 3)Both of the Menus
    (A and B).  What I'm calling Menu (we use menus on the rig to
    change them) you are calling conf.  I use P.M. 0 ,MenuA as my
    VHF and repeater setups, whereas P.M. 0, MenuB is my HF
    and simplex setups.  I haven't defined (my) uses of PM's 1-5
    yet.  In rig.h I defined RIG_MTYPE_MENU for MenuA/B,
    RIG_MTYPE_SETUP for P.M.'s 0-5.

    The PM's save everything excluding Memories (mem, tmp, sat,
    pct).  So, yes, they save frequencies, but also modes, shifts, menu
    options (A and B) etc...

    I added RIG_MTYPE_PCT for the Packet Cluster Tune feature.
    These are very similar to Temporary Memory but are only set
    by receiving P.C.T. data.  I have not found any simple, clean, or
    easy way to read this since only the panel may select these.  Thus,
    I have recently found they are not accesible to software.  It is
very
    cool but the code for this isn't currently available.  I'm hoping to

    upgrade my rig's embedded software and see if this is fixed, but I
    doubt it.

6) EXCLUDE():    This macro is my compulsion to simplify things
    that get repeated.  (This is why I wrote the ts2k memory backup,
    restore and setup routines in the first place.)  If useful, keep it,

    otherwise discard it.

Hope this helps.

Sorry I can't easily copy previous messages.  I use different stuff
for send and receive and have to transfer by hand and that isn't
going to change.

7)  Only two question have come up recently.  Why does
    src/rig.c::rig_save_channel()/rig_restore_channel()  try to
    handle the rig directly?  Should this not be like all others and
    simply check valid parameters call the backend?  It may be
    nice to provide this "feature" for those who don't want to
    write it or whatever.  Wouldn't it be much better and more
    correct (as well as more standard) to rename this to a
    pseudo but functional backend and call it?  My suggestion
    would be generic_save_channel(), generic_restore_channel().
    If the backend's pointer for this function is NULL or to "generic"
    call the generic, otherwise, call the correct Backend function.

8) Within the backend I call other backend functions.  Originally,
    I used ts2k_get_mode() or whatever.  I have changed over
    to calling rig_get_mode() which allows different modules to
    be used (e.g. kenwood_get_mode() -vs- ts2k_get_mode())
    within a single backend.  I presume this is correct and better
    than assuming it is actually a TS-2000 using the functions.

    I've started noting which routines may be *only* for the ts2k.


Sincerely,

Dale E. Edmons, KD7ENI