Quoting "Dale E. Edmons" <de...@w-...>:
> Tone:
> My argument is *for* adding. My reasoning was simple: the manual
> states, "You cannot use DCS with the Tone or CTCSS functions".
> (page 36) Even though I may independently set all three frequencies,
> I can *only* enable one. It made sense to me, since it seemed you
> didn't want to add the variable for Tone, that we could at least split
> the two existing variables into RX/TX and *assume* that would
> suffice.
Note: I assume that for you, "Tone" is the tone encoding, not to be mistaken
with the 1750Hz tone burst.
Okay, it's not because the ts2k can enable *only* one at a time
(ie. DCS and tone/CTCSS mutually exclusive), that Hamlib API
must be this restrictive.
Until proved wrong, current API covers the ts2k, plus the mmelter
(which supports both CTCSS and DCS at same time).
The only information missing in the caps is how "1750 tone burst",
CTCSS and DCS are eventually exclusive.
Then the side effect will be that when setting DCS for example,
it will disable CTCSS if previously set, etc.
In other words, for the ts2k, just implement set&get for ctcss_tone/ctcss_sql,
dcs_tone/dcs_sql (note that dcs_tone/dcs_sql are identical, setting one
sets the other for this rig), and set_func/get_func RIG_FUNC_TBURST.
If you don't know/see how to implement this, just let me do it.
It's breaking simple.
> ts2k.c:
> testing right now. (I've threw a testvfo.c into tests/. Its simple
> but fun to watch all the modes changing and is a great quick check.)
Just a reminder. You will have to convince me if you want
*everything* of your new VFO scheme to be merged in the trunk.
What I dislike:
- CTRL_SCAN, CTRL_SAT, etc. irrelevant for the current API design
- the VFO_AB and such (split are not to be handled here),
vfo_t is complex enough.
What I like though (i.e. may be merged after discussion):
- the CALL channel that can be seen as a VFO (not true on some rigs
that can only see it as a memory channel)
- RIG_VFO_TEST macro, that tell you if it's a vfo or mem.
Cheers,
Stephane
|
