On 2/23/11 5:09 AM, Javier Herrero wrote:
El 23/02/2011 05:53, jimlux escribió:
CCSDS time codes reference NASA 36 bit.. maybe a reference it's in the
back of the CCSDS standard.
First CCSDS.301 issue seems to be January 1987, and references (on the
4th issue, Nov 2010) listed at last page seems not very old. CUC
recommended epoch, as per the standard, is 1 Jan 1958. CUC is longer
than 36 bit (I have met it with 56-bit, but can be different), and no
reference to NASA 36-bit code seems to appear there (except if I've
overlooked it :) )
Last issue can be downloaded here
http://public.ccsds.org/publications/archive/301x0b4.pdf Some older
versions are also available.
Yeah.. I just looked and saw the same. Maybe some other document... I
looked at the deep space 810-005 document, but didn't see it their
either. I'll look when I get to work.
Most of the DSN stuff uses CCSDS formats, although the Time Code
Translator (TCT) boxes at the stations probably can handle NASA36 in
some form. The TCT is what provides all the timing signals in a station
(it also distributes 100 and 10 MHz, and 1pps.. or at least the one in
the rack in the lab downstairs from my office does.. there is,
apparently, some variability in these things.. they're mfrd in small
quantities)
I found a Landsat document from the 80s which mentions that NASA36 and
IRIG-A were recorded on the tapes, but that the NASA36 track wasn't
used. It referenced a Data Format Control Book, Volume 5 (Payload),
which is presumably some Landsat spec. and in fact, I just found
landsat.usgs.gov/documents/L7-DFCB-07_Landsat_D_Payload_DFCB.pdf
If you want to hunt around.. I'd look for documents about the early days
of TDRSS. There might be a reference to a document that defines the
Time-of-Day clock. Back then (and even now), the whole data stream
flows from one box to another to another to another, and timecode is
essential to keep the data from multiple flows lined up. Each box does
one small function (e.g. demodulator, then decoder, then deframing,
decommutation, etc.). It's very, very much driven by legacy
compatibility with analog patch cables for interconnects, etc. (i.e. it
might be done by a digital processor today, but back in the 80s, when
they wanted to replace the analog demodulator, they'd only have the
budget to do just that piece.. so you'd build a digital rack mounted
unit(s) that duplicated the interfaces of the thing you're replacing.
You just don't get the budget to do an end-to-end refit, and for that
matter, figuring out new box level requirements from the top down is a
huge task. Much easier to keep the architecture the same, keep the
interface requirements the same.
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
