[time-nuts] seeking a time/clock software architecture
jimlux at earthlink.net
Fri Sep 23 22:21:40 UTC 2011
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
>> 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.)
More information about the time-nuts