| Summary: | Some devices offer too many / odd sample rates | ||
|---|---|---|---|
| Product: | PulseView | Reporter: | Soeren Apel <soeren> |
| Component: | Other | Assignee: | 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
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. |