[Hamlib-developer] target VFO proposal

[Frank S. <vk...@ix...>]

Hi,


Finally got PC and rig powered up after the
house move (phew ..)


Looking at the latest API in rig.h,
I have come to the conclusion we are missing
something of great importance.

We have not provided a target VFO in the set/get cmd's

For example...should we have this instead..

int rig_set_freq(RIG *rig, freq_t freq, vfo_t vfo);
int rig_get_freq(RIG *rig, freq_t *freq, vfo_t *vfo);

int rig_set_mode(RIG *rig, rmode_t mode, vfo_t vfo); /* select mode */
int rig_get_mode(RIG *rig, rmode_t *mode,vfo_t vfo); /* get mode */

etc..

It seems silly, but without this, we dont have a solid
"target VFO" for the existing commands.

  int (*set_freq)(RIG *rig, freq_t freq); /* select freq */
  int (*get_freq)(RIG *rig, freq_t *freq); /* get freq */

  int (*set_mode)(RIG *rig, rmode_t mode); /* select mode */
  int (*get_mode)(RIG *rig, rmode_t *mode); /* get mode */

etc..

ie: set freq/mode could apply to any VFO, so which
one gets the command.??   Is it really the towards
the  VFO specified in previous last set_vfo() 

For example, my FT747 has separate set_freq and set_vfo cmd's
but the FT847 and others always pass VFO along with
the parameter that is being changed.

It is not good for the frontend end "app" to be
guessing about what VFO the last cmd will target.

This also, requires the backend to "remember"  the
VFO used in the last set_vfo cmd.


So, some decisions.

1. backend must "remember".  This could be part of private data
   This is no big change to frontend API.

/*
 * ft847 - private data
 *
 */

struct ft847_priv_data {
        ..
 	unsigned char active_vfo;
	..
 etc
};

  

2. Frontend API provide API with target VFO as
   an argument shown above.

I think I prefer option (1), otherwise we may
be adding VFO to everything.



Comments please / FS