Thread: [Hamlib-developer] Tuner frontend functions
Library to control radio transceivers and receivers
Brought to you by:
n0nb
Menu
▾
▴
hamlib-developer
|
From: Nate B. <n0...@ne...> - 2003-03-24 03:45:20
|
I guess I'm dense tonight.
After looking through rig.h I haven't found an obvious candidate such as
rig_set_tuner to turn the auto-tuner on and off. There also should be a
function to start the tuner.
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
|
|
From: Stephane F. <f8...@fr...> - 2003-03-24 08:34:51
|
On Sun, Mar 23, 2003, Nate Bargmann wrote: > After looking through rig.h I haven't found an obvious candidate such as > rig_set_tuner to turn the auto-tuner on and off. There also should be a > function to start the tuner. What about creating RIG_FUNC_TUNE to turn the auto-tuner on and off, and a RIG_OP_TUNE to start the tuner? 73 Stephane |
|
From: Nate B. <n0...@ne...> - 2003-03-24 12:01:52
|
* Stephane Fillod <f8...@fr...> [2003 Mar 24 05:51 -0600]:
> What about creating RIG_FUNC_TUNE to turn the auto-tuner on and off, and
> a RIG_OP_TUNE to start the tuner?
That's what I forgot. State constants.
I'm guessing these will be used in new functions for the purpose, or
will they be used with a set of existing functions?
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
|
|
From: Stephane F. <f8...@fr...> - 2003-03-24 23:15:56
|
On Mon, Mar 24, 2003, Nate Bargmann wrote:
> > What about creating RIG_FUNC_TUNE to turn the auto-tuner on and off, and
> > a RIG_OP_TUNE to start the tuner?
>
> That's what I forgot. State constants.
>
> I'm guessing these will be used in new functions for the purpose, or
> will they be used with a set of existing functions?
rig_set_func(rig, vfo, RIG_FUNC_TUNER, 1); /* enable auto-tuner */
...
rig_set_func(rig, vfo, RIG_FUNC_TUNER, 0); /* disable auto-tuner */
..
rig_vfo_op(rig, vfo, RIG_OP_TUNE); /* "user"-start tune */
..
It's in the cvs repository.
Note (not related):
I've made a cleanup: RIG_FUNC_LMP is gone, use RIG_PARM_BACKLIGHT instead.
Cheers,
Stephane
|
|
From: Nate B. <n0...@ne...> - 2003-03-25 01:06:36
|
* Stephane Fillod <f8...@fr...> [2003 Mar 24 17:16 -0600]:
> rig_set_func(rig, vfo, RIG_FUNC_TUNER, 1); /* enable auto-tuner */
> ...
> rig_set_func(rig, vfo, RIG_FUNC_TUNER, 0); /* disable auto-tuner */
> ..
> rig_vfo_op(rig, vfo, RIG_OP_TUNE); /* "user"-start tune */
> ..
Looks good, Stephane.
> It's in the cvs repository.
Yeah, I finally found the definitions for set/get_func in settings.c, I
now know there are other files around. Doh!
What do you think of a couple of more convenience definitions in rig.h:
#define OFF 0
#define ON 1
Perhpas as well:
#define FALSE 0
#define TRUE 1
I like definitions like these since it makes more human readable code
and doesn't leave a bunch of numeric constants scattered about. Perhaps
they need to be prefixed with RIG_ to avoid conflicting with similar
definitions in other projects. Of course, that rather negates their
convenience...
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
|
|
From: Nate B. <n0...@ne...> - 2003-03-25 03:13:02
|
* 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
|
|
From: Stephane F. <f8...@fr...> - 2003-03-27 23:43:55
|
On Mon, Mar 24, 2003, Nate Bargmann wrote: > 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. absolutely right. This is fixed now, commit should follow. Let me know if there're other flaws or mistakes. > 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. yes, that would be cool, but being too smart add complexity. It's better to keep the KISS approach. > 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. In that case, I would recommand the use of rig_get_channel, with an optimized backend. > The downside of this idea is that only ON/OFF values may be reported. > How would we report multiple AGC values, for instance? rig_get_channel and levels. BTW Nate, your idea of allowing vfo target in rigctl is very good for testing purpose. I took the liberty of extending it to other commands. Just pass "-o" to rigctl when you want to specify the VFO. VFO_CURR will apply otherwise. I've also allocated 'Z' and 'z' to set_xit/get_xit. Cheers, Stephane |
|
From: Nate B. <n0...@ne...> - 2003-03-28 01:18:51
|
* Stephane Fillod <f8...@fr...> [2003 Mar 27 17:45 -0600]:
> absolutely right. This is fixed now, commit should follow. Let me know
> if there're other flaws or mistakes.
Oh, you know me! I'm not afraid to fire off an email. :-)
> yes, that would be cool, but being too smart add complexity.
> It's better to keep the KISS approach.
It was a thought. KISS is best, and this kind of behavior results in a
lot work for the application using Hamlib, which we don't want to do.
> In that case, I would recommand the use of rig_get_channel, with
> an optimized backend.
>
> > The downside of this idea is that only ON/OFF values may be reported.
> > How would we report multiple AGC values, for instance?
>
> rig_get_channel and levels.
Hmmm, another thing to go off and learn...another day!
> BTW Nate, your idea of allowing vfo target in rigctl is very good for
> testing purpose. I took the liberty of extending it to other commands.
> Just pass "-o" to rigctl when you want to specify the VFO. VFO_CURR will
> apply otherwise.
> I've also allocated 'Z' and 'z' to set_xit/get_xit.
Sheepish grin.
I didn't really intend for my private copy of rigctl to get out, but I
had copied it over there for another reason and had forgotten it. That
said, I've been able to exercise my backends with direct VFO access.
The command option is an excellent implementation since both behaviors
are now available.
As well, you may have noticed that I replaced the character for Dumpcaps
and a few others by numbers. The reason is that in my EN_us locale, all
I got on the display was "?" characters. As we go along I'm wondering
if two character commands could be added?
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
|
|
From: Stephane F. <f8...@fr...> - 2003-03-28 22:02:26
|
On Thu, Mar 27, 2003, Nate Bargmann wrote:
> As well, you may have noticed that I replaced the character for Dumpcaps
> and a few others by numbers. The reason is that in my EN_us locale, all
> I got on the display was "?" characters. As we go along I'm wondering
> if two character commands could be added?
These 8bit characters do not display well here too. Actually, they're
only used as unique ID in the array for long format option.
Here follows an example on how to use 'dump_caps' when one-char short command
is not available. Long format-only is okay with seldomly used commands.
(fillods@charybde:tests)$ ./rigctl -vvvvvv
rigctl, Hamlib version 1.1.4cvs
Report bugs to <ham...@li...>
rig:rig_init called
rig: loading backend dummy
dummy: _init called
rig_register (1)
dummy_init called
rig:rig_open called
dummy_open called
dummy_get_vfo called: VFOA
Opened rig model 1, 'Dummy'
Backend version: 0.2, Status: Beta
Rig command: \dump_caps
Caps dump for model 1
Model name: Dummy
Mfg name: Hamlib
Backend version: 0.2
Backend copyright: LGPL
[...]
Cheers,
Stephane
|
|
From: Nate B. <n0...@ne...> - 2003-03-29 00:34:19
|
* Stephane Fillod <f8...@fr...> [2003 Mar 28 16:19 -0600]:
> Rig command: \dump_caps
Yup. Right there in the man page had I bothered to look...
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
|
Thanks for helping keep SourceForge clean.
X