On Tue, Mar 29, 2005, Martin, AA6E wrote:
> I understand the numbers coming from the Orion pretty well, but I
> don't have a clear notion how the granularities list describes them.
> The API provides raw numbers, right? And I suppose the list is trying
> to give clues to the application how to interpret them, yes? It would
> have been easier to convert to standardized formats and scaling in the
> backend, perhaps. If these are just clues for the apps, is there a
> simple way to verify them?
The API provides raw numbers (eg. RAWSTR) and standardized formats
(eg. PREAMP). You guessed well, this is in order to help the application
interpret them, and be as much as possible a generic interface.
Please note some raw numbers cannot be easily standardized, as they can
originate from A/D converter, and calibration should take place.
Besides, some standardized numbers still need granularity, for
example to know how many possible values they have within the scale,
etc.
To verify granularities, dumpcaps of rigctl should check invalid ones,
so the backend maintainer can fix them.
> What happens if some or all of the levels are not defined in the
> granularities list? Do applications croak, or are there "reasonable"
> defaults?
As of now, there's no documented code of practice. But the idea is if
the whole granularity struct is filled with 0, then the application
should not use it. Instead, they should bug the backend developer to
have it fixed..
> I have read a couple of earlier messages on this subject, but it's all
> vague for me still. It would be good to have a "cookbook" description
> of how to implement the granularities for typical situations.
> IDX_builtin must be a masterpiece of design, but it's not intuitive to
> this humble programmer!
Yes, the cookbook is definitely a must have. Right now, we can read
rigctl.c source code, or real applications from the apps.html list.
Patches of code snippets in doxygen format are of course welcome ;-)
Thanks
--
Stephane
|
