Re: [Hamlib-developer] hamlib_ts2k

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

Quoting "Dale E. Edmons" <de...@w-...>:
> 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.

Good, I'm happy to see you'll use the 'branch_ts2k' on sourceforge. 
This way, everyone can see how the ts2k goes, view easily the difference
with the trunk (cvs rdiff -r ts2k_branch -r HEAD hamlib), etc.
And sooner or later, we'll have to merge.

> 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.

Let's say that until we know what it does really, hence how to design
the API for it, we'll put it aside.

> 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,

So we'll have a bit field with RIG_CHFLAG_LOCK and RIG_CHFLAG_SKIP, ... 
other idea anyone?

>     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!)

IMHO, a READONLY flag would live on the behalf of the user application, 
not Hamlib. Hamlib only tries to map existing feature of rigs.

> 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.

Hmm, looks like a problem of vocabulary. Here's what I see:

- on emitting side, tone in CTCSS "standard" -> ctcss_tone
- on receiving side, the CTCSS tone that opens the squelch -> ctcss_sql
- on emitting side, tone in DCS "standard" -> dcs_tone
- on receiving side, the DCS tone that opens the squelch -> dcs_sql

Besides 1750Hz tone burst (which is one shot), is there any other?

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

To be more precise, MTYPE describes available and accessible memories 
by rig_get_channel/rig_get_channel and rig_get_mem/rig_set_mem.


>     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'm not familiar with "Programmable Memories" concept. Anyway, I start
to grasp the idea thanks your explanations. To me, we will have to create
new calls in the API, something like rig_set_pm/rig_get_pm, or whatever
with better names. The reason is a channel_t cannot cover the need to 
describe the main's and sub VFO, and all parameters.
Actually, the pm struct looks like a set of channel_t.

In fact, rig_save_channel and rig_restore_channel only address the current VFO,
hence the channel_t parameter. So we need rig_set_pm/rig_get_pm and a pm_t
(with better names, feel free to suggest), and these functions would
save the entire state of the rig.

I take also a mental note to add the ability to channel_t to store the content 
of the "Menu" (see below).

>     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.

To me, the "Menu" are nothing else than a huge list of parameters that Hamlib 
won't be able to account with RIG_LEVEL/RIG_PARM, among the number of rigs.
I have a better view now, and my proposal of rig_[sg]et_conf is not good.
But I was close. Let's create 2 new calls, rig_set_menu/rig_get_menu that 
works exactly like rig_set_conf/rig_get_conf (same data structures), 
and also a mean to browse the list of these "extra" non-standard parameters.
I'll make a proposal, and we'll see if it covers the needs of the
various rigs we have in the wild.

>     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.

Allow me to be a bit conservative on this one. The idea is good, but until 
we have the protocol specifications for such a memory, let's focus
on others first.


> 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? [snip]

Okay, I see your point, and you're right. 
rig_save_channel/rig_restore_channel were more like internal use calls,
much in the idea of generic_save_channel/generic_restore_channel.
But let's make them evolve.
What about adding a vfo_t paramter (only for VFO usage, not memory) to 
rig_save_channel/rig_restore_channel, plus the ability to call the backend 
implementation if any, as you suggested?


Thanks very much for taking time to discuss,
we're making good progress on the API.

Cheers,
Stephane


PS: Have you done already the TS440? I have the caps done here, ready to commit.