Re: [Hamlib-developer] CTCSS

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

Quoting "Dale E. Edmons" <de...@w-...>:

> Another concern was that Hamlib controls tone via a parameter
> call (rig_set_parm()) but CTCSS and DCS each have their own
> functions (rig_set_dcs()).  This is a confusing interface and users
> (plus at least one developer) will complain.  We should move them
> both to the same place.  Either all three are parm's or all three are
> functions.

The 1750 tone burst has to be a RIG_FUNC because it's an on/off setting.
The tone/ctcss, code/dcs could have been a RIG_LEVEL (and actually they were
at the beginning), but they were made separate calls for clarity.

Looking at rig.h, we might have to check consistency, and better specify 
function semantics. For example, about FUNC_TSQL, rig_set_ctcss_sql could have 
suffice.
But it's not that simple. Some rigs allow to turn on/off TSQL, but do NOT
allow to change the tone frequency. Right now, the (poorly documented) API
is designed this way: to activate CTCSS, one has to set the decoding tone 
frequency, and then turn function on:

  rig_set_ctcss_sql(rig, vfo, tone);
  rig_set_func(rig, vfo, RIG_FUNC_TSQL, 1);

It gives the best (IMHO) mapping for existing rigs and combination of supported
features.
Note: some rigs may have rig_set_ctcss_sql but no RIG_FUNC_TSQL, which is
okay with this design.

It's always good to have to argue, it shows loopholes. Here, it looks like a 
RIG_FUNC_TBURST is missing (in my previous idea, the 1750 would have been in 
the ctcss list, but this was a wrong design if you want to use both).

Note: Function semantics are supposed to be documented in doxygen in-source 
code comments (mainly src/rig.c). They are supposed to be the reference.
In the future, rig.c will be split and documentation augmented, especially
for all those RIG_FUNC, RIG_LEVEL, RIG_PARM, etc.

> Since CTCSS and DCS cannot be used at the same time they may
> share the same variable.  Tone on the other hand may be used at
> the same time and should have its own variable.  

Is there a reason why CTCSS and DCS cannot be used at the same time?
Is it because no rig implement it (not a reason)? or because the encodings 
would mess up each other (same frequencies) ? 
It's a bit far fetched, but the mmelter may use 1750 tone burst, tone encoding, 
CTCSS, DCS code encoding and a different DCS code for squelch, all
at the same time. Hence the actual design of the API, which covers all
the cases.

Comments?


Cheers,
Stephane