Re: [Hamlib-developer] Filter list

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

On Wed, Nov 06, 2002, Ken Koster wrote:
> OK, whats the magic incantation that determines the correct order for 
> filters listed in the filter list?  I know that the first one mentioned for a
> given mode determines what is considered 'normal' but what determines
> what is used for narrow and wide?

The same goes for narrow and wide. So the first one in the list is the
normal filter (as returned by rig_passband_normal), then the first
filter that is below the normal filter if the narrow filter (as returned
by rig_passband_narrow) and you guessed already for the wide filter.
Have a look at src/rig.c to understand how normal/narrow/wide are used.

> The documentation is anything but helpful here.  The comment in the code
> reads "remember, order matters" but no where is this explained in detail.

This is one task to complete before 1.1.4: document rig.h data
structures using doxygen.

> Also, the Ten-Tec Pegasus 550 has 34 different filters, all available for a
> any mode, but rig.h has an upper limit of 16 for FLTLSTSIZ.  Can anyone see
> any reason why this shouldn't be increased?  

Pretty simple: memory consumption. 8 bytes per element (even on non-used), 
multiplied by number of models.
Now, it's still acceptable to bump FLTLSTSIZ to 34. But what if the
MoonMelter YZZ.1 has 38? Maybe would it be better to use some list pointer,
like the ctcss_list. We keep source compatibility, and make it
flexible for big list. What do you think?

While we're at it, what about chan_list, rx/tx_range_list, tuning_steps..?

Note: some rigs have free form bandwidth, i.e. near Hertz resolution.
For these ones, we may have to rely on a new RIG_LEVEL or put a special
value in the filter_list (for example tuning_steps.width = 0) to tell 
that the bandwidth can be set from the minimal bandwidth in the list 
to the highest bw in the list for the given mode.
The same should go also for the struct tuning_step_list.


This is all about API definition, so everyone has to be heard.
Comments welcome.

Stephane