Bug 898

Summary: Some devices offer too many / odd sample rates
Product: PulseView Reporter: Soeren Apel <soeren>
Component: OtherAssignee: Nobody <nobody>
Status: CONFIRMED ---    
Severity: normal CC: Gerhard.Sittig
Priority: Normal    
Version: unreleased development snapshot   
Target Milestone: ---   
Hardware: All   
OS: All   

Description Soeren Apel 2017-02-25 18:49:44 CET
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.
Comment 1 Gerhard Sittig 2018-02-04 13:25:14 CET
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 
the API.