hamlib-developer

[Hamlib-developer] CTCSS

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

Nate,

Thanks.  After I RTFM yet again I finally found the part I'd been
missing.  Tone is what I transmit (usually to a repeater) and both
CTCSS and DCS are what I receive/decode.  1750Hz is an once
only burst transmitted to a repeater to open the squelch (European).

Got it.  The manual says in fine print, "You can select a tone
frequency independent of a CTCSS frequency."  So I can TX
using tone=103.5Hz and receive using CTCSS=88.5Hz.  The
1750Hz is a menu item which may be turned on/off.  This all may
seem of dubious value but I think it is primarily indended for use
with a handheld while controlling the TS2K remotely (It's nice
walking around talking on a HT through the base rig.  Kind of
like a portable phone or cell phone--bleh!)  Either that or for
cross-band repeater operation.  I've only played with it a little
but it was fun!

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.

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.  (How come I'm
always on the other side disagreeing with everyone?!)   :)

73's all.  Thanks for the information and patience!

Dale
KD7ENI

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