Re: [Hamlib-developer] Tuner frontend functions

[Nate B. <n0...@ne...>]

* Stephane Fillod <f8...@fr...> [2003 Mar 24 17:16 -0600]:
 
>     rig_set_func(rig, vfo, RIG_FUNC_TUNER, 1);	/* enable auto-tuner */

In looking at the docs and the code for rig_set_func and its companion
rig_get_func, there is some minor confusion.  In both function
declarations, func is a type setting_t, which is a long long int, and
status is an int.  So far, so good.  While the rig_set_func docs talk
about using status to pass a 1 or 0 (activate, de-activate the
function), the rig_get_func talks about setting bits and the inference
is that status is a bit map analog of setting_t, which currently isn't 
possible.

However, this does raise an interesting thought.  If status were also
type setting_t, then multiple functions could be set in one call to
rig_set_func.  For example, if func is set to RIG_FUNC_TUNER, then
checking bit 30 of status would reveal the requested action.  Likewise,
the application could send an or'ed func value consisting of
RIG_FUNC_TUNER|RIG_FUNC_NB and the backend would need to test status
bits 30 and 1 for the resulting rig command.

Conversely, rig_get_func could return multiple bit values in status.
The Yaesu rigs, at least, return a number of flag bytes with one
command.  It seems to me that the computer running Hamlib can sort
through multiple flags and assemble a bitmap much faster than repeated
polls through the library to the rig.  This increases efficiency.

The downside of this idea is that only ON/OFF values may be reported.
How would we report multiple AGC values, for instance?

73, de Nate >>

-- 
 Wireless | Amateur Radio Station N0NB          | "We have awakened a
 Internet | n0...@ne...               | sleeping giant and
 Location | Bremen, Kansas USA EM19ov           | have instilled in him
  Amateur radio exams; ham radio; Linux info @  | a terrible resolve".
             http://www.qsl.net/n0nb/           | - Admiral Yamamoto