Some devices (e.g. the ChronoVu LA8) offer a lot of sample rates that have questionable use for the user: 8, 8.333, 8.695, 9.090, 9.523, 10, 10.526, 11.111, 11.764, 12.5MHz and similar.
PV shouldn't show all of those in the drop-down and it needs to be figured out how to make the in-between values still can be made available in a sensible way.
IIUC there is support for either an explicit list of rates, or alternatively
a spec that consists of min and max and step. Current UI controls could
provide the corresponding presentation to users that is most appropriate
(selection from a combo box, or spinner box?).
The rates listed above seem to result from a base clock and a range of
dividers. Which doesn't match the equidistant stepping above, but could become
a third alternative for presentation to and adjustment by users.
Another approach is taken in some drivers: Although the hardware in theory
provides a wide range of choices, the driver API just suggests a (sane) subset
of those choices would be available.
Some hardware may not match either of the above three alternatives, since
it implements support for a combination, that cannot get expressed by one of
the approaches, or any set of constraints that is easy to communicate or
document. Compare asix-sigma: It's either exactly 200MHz, or exactly 100MHz,
or 50MHz divided by an integer in the range from 1 to 256 (inclusive). Try
to express that in one dialog, or pass that across the driver API ... The
"list of typical rates" approach works well there.
There was another report (that I can't find right now) which suggests that
users shall be able to specify any rate in somewhat free form, and after data
acquisition (or at the time of adjustment) the application shall query the
driver which specific rate is (would be) used. This shall work with arbitrary
constraints, while they still remain hidden in the driver and need not cross