[Hamlib-developer] Re: New modes (was: Re: Addiions for the R-8500 and 750PRO )

[Stephane F. <f4...@fr...>]

David HM Spector wrote:
> >
> >int rig_set_mode(RIG *rig, vfo_t vfo, rmode_t mode, pbwidth_t width);
> >
> >Anyway, it looks like we still lack some "modes".
> > * How would you set Synchronous AM (detection only), aka S-AM ?
> > * How would you set reverse sideband modes, like CW-R and RTTY-R ?

	still no clue?
> 
> One of the problems with having to pass the passband info in
> rig_set_mode (as opposed to creating a new mode) implies that we know
> what those values are for all possible modes as defaults (i.e., set
> mode to FM and passband to X == FM-N for rig model Y ).
> 
  yup, that's exactly the point, and I'm gald you raised it!
  Actually, my latest commit add a new field in the caps, called 'filters'.
  This is a zero terminated array of modes/freqwidth tuples.
  Have a look at icom/ic706.c to have a idea of what it should look
  like for other backends.
  This table contains all the installed filters. Provided the table
  is sorted accordingly, we can agree that the first entry of a given
  mode will tell the PASSBAND_NORMAL filter.
  Why would you ask? because I'm dreaming of a rig_set_mode that is able
  to accept a passband in kHz, or a RIG_PASSBAND_NORMAL arg, which
  would be a kind of macro for the PASSBAND_NORMAL filter in 
  the ordered table...  Is it day dreaming?
  Of course, pbwidth_t would have to be redefined, and RIG_PASSBAND_NORMAL
  et al. be rewritten as some sort of macro. I'll make a code proposal,
  and you'll tell me how you it. An example of the result 
  may look like this:

	/* cool! there's a narrow SSB installed! */
	rig_set_mode(my_rig, RIG_MODE_USB, kHz(1.9));

	/* don't bother with filters, just want to hear some ragchewing :) */
	rig_set_mode(my_rig, RIG_MODE_FM, RIG_PASSBAND_NORMAL);


  rig_set_mode is not an easy one. It has to be versatile, yet simple
  to use for the end user, and the call should map as best as it can
  to the myriad of protocols and weirdo modes.

> This command is good for modifying the functionality once in a mode,
> but I think we would have to add new modes so that the rig-specific
> back-ends can invoke the appropriate interface commands to set the
> mode (which would get the passband and other settings for free).
> 
  Well, this was my first approach, and after couple of week, I was
  still not satisfied with it. Imagine you have "n" basic modes,
  each of them can have 3 passbands, maybe more, and on top of that,
  there are reverse modes. No, this is too much complexity for
  RIG_MODE_ handling at the end user level.
  Also, some modes can have serveral "narrow" modes, like NFM
  and Super-NFM (example AR8200). And what about optional filters?
  IMNSHO, filter list should be defined in caps, and shadowed
  in the rig_state struct (hence my latest commit).

  Do you think my proposal could be OK?  Comments?

  In the mean time, there's some caps->filters to populate,
  set let's do it :)


Cheers,
-- 
Stephane / F4CFE

PS: I'll be out next week (more precisely in DE). Maybe we can think of
    a new release (1.1.1) of Hamlib beginning of march.
PS/2: The PCR1000 backend is in preparation, and it has interresting filters!