[time-nuts] seeking a time/clock software architecture

[Magnus Danielson]

On 24/09/11 00:21, Jim Lux wrote:
> On 9/23/11 2:24 PM, Chris Albertson wrote:
>> On Fri, Sep 23, 2011 at 12:32 PM, Jim Lux<jimlux at earthlink.net> wrote:
>>> On 9/23/11 10:50 AM, Chris Albertson wrote:
>>
>>> Yes, in the general case, but in the spacecraft case, I think we're more
>>> concerned about smoothness and such over time spans of days, maybe
>>> weeks and
>>> months.
>>>
>>> More about establishing time correlation between multiple
>>> radios/spacecraft
>>> in a constellation, for instance.
>>
>> I think better to have your system be usable in the "real world" and
>> then the spacecraft to use "real world" standards when it can. If it
>> can handle the ful general case then it will work in the spacecraft
>> too. So Chinese lunar calenders are a good mental exercise. At any
>> rate piece wise 2nd order polynomial will work in all cases I can
>> think of because you can always make the pieces really small if need
>> be to the point where it becomes a table look up.
>
> hmm.. 2nd order for time, or 2nd order for rate (3rd order for time). I
> keep thinking it would be nice to have the derivative of rate be
> continuous (although I confess I can't think of anything beyond gut feel
> for that). Maybe for all the "common cases" that's sufficient for a
> "predict into the future for a reasonable time"
>
>
>
>
>>
>> Spacecraft spend a fair amount of time on the ground in testing.
>> People swap out parts. I work in telemetry and you should see the
>> database of tens of thousands of polynomial functions that must be
>> used to process data. from say a DeltaIV. It's not only clocks but
>> dozens of sensors that get changed out in the months preceding launch.
>
>
> Yes.. And there's no standard form that I've been able to discern for
> how those polynomials are specified. It's
> vehicle/spacecraft/instrument/software tool specific.
>
> So if you're writing a program to handle it automatically, you need to
> code up something special each time. These days, we get telemetry
> calibration in forms like .pdf files generated from a word document,
> plots from Matlab, Excel spreadsheets in some unique form, various and
> sundry import/export files from whatever program they're using to
> process telemetry, and so forth. There was an effort a few years back to
> try and standardize "mission data systems" but I don't know that it ever
> really worked. The cost to write those custom ingest routines is small
> in the context of a $150M mission every couple or three years.
>
> (maybe there is a standard for this.. I know there is a IEEE standard
> for sensor calibration data.. I should take a look at it again.)

Once you pulled data out of telemetry or whatever, putting it in XML 
form according to a DTD fitting your needs should not be too hard, and 
further processing should not take too much effort to extract data.

Essentially what RINEX does, but without the XML wrapper.

Cheers,
Magnus