[Hamlib-developer] API list of modes

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

Hi there!

Let's close the issue of modes.
To sum up, we have already CW, AM, USB, LSB, RTTY and FM, and we agreed 
to not create NAM (narrow), WAM (wide), et al. since there can be
several narrow filters, etc.  Hence the filter list will be part
of capabilities, and rig_set_mode will require the desired
filter to be specified (in Hz) as an argument. A value of 0 for this arg
will have to be interpreted by backends as the "normal" passband.
This means the death of RIG_PASSBAND_WIDE, RIG_PASSBAND_NARROW.
If all this does not look very clear, don't worry, I'll come up with
a code samples as soon as all the caps->filters are populated (mandatory).
If you think this proposal sucks or could be improved, well, just let me know.

OK, I'm here today to question about WFM, CW-R, RTTY-R.

(1) WFM, after arguing back-and-forth, I think I'd settle
    with makeing it different thant FM. I'm not an expert in modulation,
    and my understanding is that WFM is NOT just a FM circuitry
    with a huge wide filter. I'm also thinking of it on the end-user
    point of view (e.g. virtual rig GUI). So I'd vote for RIG_MODE_WFM.
    What do you think?

(2) reverse sideband
    Sure, we could add another argument to rig_set_mode (and rig_get_mode)
    to specify a broken-down mode definition. But reverse sideband
    only applies to 2 modes (please confirm), so we might get away
    with RIG_MODE_CWR and RIG_MODE_RTTYR. Any thought?
    Do you known any other funky modes, like SyncAM and stuff like that?
    We have to think about that, because in the future, the API will be
    frozen, and it won't be allowed to create a new argument to rig_set_mode
    to keep compatibility (a new #define is OK though).

Comments?

-- 
Stephane