Thread: [Hamlib-developer] rig not supporting target VFO
Library to control radio transceivers and receivers
Brought to you by:
n0nb
|
From: Stephane F. <f4...@fr...> - 2001-01-03 19:47:13
|
Hi there,
Remember the issue with target VFO?
Let's say the current VFO of the rig is VFO A. But for example, you want
to change the frequency of *VFO B*, while keeping VFO A active.
Some rigs can do that (Kenwoods, some Yeasus, etc.)
My concern here is for rigs that are not able to do that,
hence the following scenario:
set_vfo VFO_B
set_freq
set_vfo VFO_A /* or whatever it was */
In order to factorize some code, this could be done by the frontend.
I've coded it, but before commiting, I'd like to have your comments.
Backends will have to specify a new caps->targetable_vfo capability.
Also, the current VFO of the rig will be stored in state.current_vfo.
Then wrappers will look like the following:
int rig_set_mode(RIG *rig, vfo_t vfo, rmode_t mode, pbwidth_t width)
{
int retcode;
vfo_t curr_vfo;
if (!rig || !rig->caps)
return -RIG_EINVAL;
if (rig->caps->set_mode == NULL)
return -RIG_ENAVAIL;
if (rig->caps->targetable_vfo || vfo == RIG_VFO_CURR ||
vfo == rig->state.current_vfo)
return rig->caps->set_mode(rig, vfo, mode, width);
if (!rig->caps->set_vfo)
return -RIG_ENTARGET;
curr_vfo = rig->state.current_vfo;
retcode = rig->caps->set_vfo(rig, vfo);
if (retcode != RIG_OK)
return retcode;
retcode = rig->caps->set_mode(rig, vfo, mode, width);
rig->caps->set_vfo(rig, curr_vfo);
return retcode;
}
And so on. It's pretty much copy/paste for every Hamlib API calls that
accept a VFO target.
Any comments? Maybe the code needs some :-)
--
Stephane
|
|
From: Frank S. <vk...@ix...> - 2001-01-04 02:31:03
|
Stephane Fillod wrote:
>
> Hi there,
>
> Remember the issue with target VFO?
Yep,
> Backends will have to specify a new caps->targetable_vfo capability.
> Also, the current VFO of the rig will be stored in state.current_vfo.
Yes, I was doing this in the FT-xxx backends, but it does belong
up front .
> Then wrappers will look like the following:
>
> int rig_set_mode(RIG *rig, vfo_t vfo, rmode_t mode, pbwidth_t width)
> {
> int retcode;
> vfo_t curr_vfo;
>
> if (!rig || !rig->caps)
> return -RIG_EINVAL;
>
> if (rig->caps->set_mode == NULL)
> return -RIG_ENAVAIL;
>
> if (rig->caps->targetable_vfo || vfo == RIG_VFO_CURR ||
> vfo == rig->state.current_vfo)
> return rig->caps->set_mode(rig, vfo, mode, width);
>
> if (!rig->caps->set_vfo)
> return -RIG_ENTARGET;
> curr_vfo = rig->state.current_vfo;
> retcode = rig->caps->set_vfo(rig, vfo);
> if (retcode != RIG_OK)
> return retcode;
>
> retcode = rig->caps->set_mode(rig, vfo, mode, width);
> rig->caps->set_vfo(rig, curr_vfo);
> return retcode;
> }
>
Looks ok :)
TODO: Handle retcode properly when we fail.
As 1 frontend call now maps to "n" backend (BE) calls, we need
to know which BE call fails.
> And so on. It's pretty much copy/paste for every Hamlib API calls that
> accept a VFO target.
Good.
>
> Any comments? Maybe the code needs some :-)
>
Well the hamlib project is bigger now, so there's hope :)
--
Cheers / Frank
73's de vk3fcs & km5ws
|
|
From: Frank S. <vk...@ix...> - 2001-01-06 06:20:46
|
Stephane Fillod wrote:
>
<snip>
>
> int rig_set_mode(RIG *rig, vfo_t vfo, rmode_t mode, pbwidth_t width)
> {
> int retcode;
> vfo_t curr_vfo;
>
> if (!rig || !rig->caps)
> return -RIG_EINVAL;
>
> if (rig->caps->set_mode == NULL)
> return -RIG_ENAVAIL;
>
> if (rig->caps->targetable_vfo || vfo == RIG_VFO_CURR ||
> vfo == rig->state.current_vfo)
> return rig->caps->set_mode(rig, vfo, mode, width);
>
> if (!rig->caps->set_vfo)
> return -RIG_ENTARGET;
> curr_vfo = rig->state.current_vfo;
^
|
+--------- what is initial value ?
If _set_mode called on a rig that has targetable_vfo = 0, then
we send #%$ if no VFO has been set.
TODO: Think of initial values. This was in backend for my FT747,
but now its a frontend responsibility (or app ?)
Should we change it change this to
int rig_set_mode(RIG *rig, vfo_t vfo, rmode_t mode, pbwidth_t width)
{
int retcode;
vfo_t curr_vfo;
if (!rig || !rig->caps)
return -RIG_EINVAL;
if (rig->caps->set_mode == NULL)
return -RIG_ENAVAIL;
if (rig->caps->targetable_vfo || vfo == RIG_VFO_CURR ||
vfo ==
rig->state.current_vfo)
return rig->caps->set_mode(rig, vfo, mode,
width);
if (!rig->caps->set_vfo)
return -RIG_ENTARGET;
#if 1
if (rig->state.current_vfo = NULL)
return -RIG_ENCURRVFO;
#endif
curr_vfo = rig->state.current_vfo;
retcode = rig->caps->set_vfo(rig, vfo);
if (retcode != RIG_OK)
return retcode;
retcode = rig->caps->set_mode(rig, vfo, mode, width);
rig->caps->set_vfo(rig, curr_vfo);
return retcode;
}
The frontend initially sets rig->state.current_vfo = ZNULLVFO
during initialsation.
Comments ??
--
Cheers / Frank
73's de vk3fcs & km5ws
|
|
From: Frank S. <vk...@ix...> - 2001-01-06 06:26:04
|
Frank Singleton wrote:
> #if 1
> if (rig->state.current_vfo = NULL)
> return -RIG_ENCURRVFO;
> #endif
>
Oops!!
#if 1
if (rig->state.current_vfo == NULL)
return -RIG_ENCURRVFO;
#endif
--
Cheers / Frank
73's de vk3fcs & km5ws
|
|
From: Stephane F. <f4...@fr...> - 2001-01-08 19:32:28
|
Frank Singleton wrote:
> > if (!rig->caps->set_vfo)
> > return -RIG_ENTARGET;
> > curr_vfo = rig->state.current_vfo;
> ^
> |
> +--------- what is initial value ?
>
> If _set_mode called on a rig that has targetable_vfo = 0, then
> we send #%$ if no VFO has been set.
>
Looking at rig_init, rig->state.current_vfo should be correctly
initialized if get_vfo is implemented in the backend (not very common),
otherwise it is set to RIG_VFO_CURR.
The current code should work fine, provided rig->caps->set_vfo ignores
RIG_VFO_CURR (which is the expected -undocumented- behaviour).
And as soon as a rig_set_vfo is done, the question is gone.
Forcing a rig_set_vfo(RIG_VFO_A) in rig_open has some drawbacks anyway.
>
> curr_vfo = rig->state.current_vfo;
> retcode = rig->caps->set_vfo(rig, vfo);
|
this one is defined (!= RIG_VFO_CURR)
> if (retcode != RIG_OK)
> return retcode;
>
> retcode = rig->caps->set_mode(rig, vfo, mode, width);
> rig->caps->set_vfo(rig, curr_vfo);
|
this may be RIG_VFO_CURR,
but it doesn't matter.
> return retcode;
> }
>
> Comments ??
>
Actually, you did find a buglet in my code. Consider the following
app:
rig_init()
rig_open()
rig_set_vfo()
rig_do_some_stuff()
...
rig_close()
/* VFO manually changed */
rig_open() <-- this time current_vfo is not reset!
rig_do_some_other_stuff()
...
well, it's not a big issue and it's easily fixable. We just have to
take care of the "preferences" that can be initialized on the way..
--
Stephane
|