[Kst] Re: CDF datasource debugging ?

[Nicolas.Brisset at eurocopter.com]

On Monday 12 July 2004 19:18, Barth Netterfield wrote:
> The concept of 'frames' is this.
> In a given data source is is possible that not all variables have been
> sampled at the same rate.  But it is often the case (and we assume) that:
>         i) all variables/vectors in the data source start at the same time
> and cover the same period.
>         ii) all sample rates are an integer multiple of some lower rate.
>  We will call this lower rate the 'frame rate'.
>
> eg: BOOMERANG files have 3 sample rates:
>         1) detectors sampled at 60Hz,
>         2) pointing sensors sampled at 10Hz,
>         3) housekeeping sampled at 5Hz.  
> So for BOOMERANG, we declare the frame rate to be 5Hz.  The detector fields
> have 12 samples per frame, pointing fields have 2 samples per frame, and
> housekeeping fields have 1 sample per frame.
Thanks for the explanation, that surely clarifies things (may I suggest you 
copy & paste this text to devel-docs/datasources.txt ?) :-)

> The datasource needs to figure these things out from the actual file for
> each field (eg, I assume this info will be encoded in CDF files).
The CDF lib allows you to know how many records there are for a given 
variable. The sampling time is not directly encoded, but in my case I know 
where to look for the time corresponding to each value, and I guess in 
general people will know what their data is.

> [...] The starting times are
> assumed to be the same for all vectors, 
That's the case for me, and probably for most files.

> and the samples are assumed to be 
> evenly distributed through the frame. 
That's just the problem I have. In the data I'm using (you may look at a 
typical example in the .cdf file I sent recently), there are "blocks" which 
you can imagine as groups of columns. In each group, the first column gives 
the cycle number of the recording computer in which the variables in the 
following columns were measured, but it is NOT evenly spaced. It is not a 
"hard" real-time environment, and records may come one cycle earlier or 
later :-(
That makes it very difficult to implement the scheme you describe, and I'd 
much prefer to return the biggest number of records for the whole file in 
frameCount(), 1 in samplesPerFrame(...), and handle the fact that some 
variables have less points in readField() by returning 0 (or -1) when asked 
for values beyond the last available for this field, treating it as a sort of 
error. It means that X=INDEX will not be consistent in my case, but if I use 
the right cycle for X then things will be OK. Do you foresee any problem with 
this approach ?

Thanks for your help,

Nicolas