[opendtv] Re: XDS and ATSC
- From: "John Shutt" <shuttj@xxxxxxxxx>
- To: <opendtv@xxxxxxxxxxxxx>
- Date: Mon, 21 May 2007 18:45:46 -0400
----- Original Message -----
From: "John Willkie" <johnwillkie@xxxxxxxxxxxxx>
THE FIRST PERSON WHO CAN PROVE THAT ATSC A/65 PERMITS THE TRANMISSION OF
GPS TIME VALUSS WILL RECEIVE $100 FROM JOHN WILLKIE. THE FIRST PERSON WHO
CAN PROVE THAT ATSC A/65 REQUIRES THE TRANSMISSION OF GPS TIME VALUES WILL
RECEIVE $100.
John, you can please donate my $100 to the charity of your choice. A/65C
states:
"system_time - A 32-bit unsigned integer quantity representing the current
system time as the number of GPS seconds since 00:00:00 UTC, January 6th,
1980. The count of GPS seconds and leap second count shall be accurate and
correct to within plus or minus one second, for a direct main broadcast
signal RF receiving device, as timed at the arrival in the decoder of the
Transport Stream packet carrying the last byte of the CRC. The STT seconds
count should be set to the next second and sent approximately 2T
milliseconds before the seconds count is due to increment, where T
represents the average number of milliseconds between TS packets identified
with the SI base_PID (0x1FFB). If one or more translators and/or repeaters
are in the RF delivery path that introduce processing delays that impact the
overall STT timing accuracy, the STT timing should be adjusted in the
translated/repeated signal.
"GPS_UTC_offset - An 8-bit unsigned integer that defines the current offset
in whole seconds between GPS and UTC time standards. To convert GPS time to
UTC, the GPS_UTC_offset is subtracted from GPS time. Whenever the
International Bureau of Weights and Measures decides that the current offset
is too far in error, an additional leap second may be added (or subtracted),
and the GPS_UTC_offset will reflect the change. "
Clearly, A/65C requires that system_time be expressed as GPS time, and that
a GPS to UTC offset factor also be transmitted. You lose.
This offer expires when/if the ATSC modifies the System Time Table section
of A/65. I need not worry about my bank account: this type of challenge
helps eliminate pockets of ill informed commentary.
I'd worry if I were you.
ATSC A/65 (which I havent read in pertinent part this year, but which I
know much better than Bert and John Shutt) requires stations to transmit
current UTC time as a 32-bit unsigned integer, which I call
"ATSC_seconds." There is also a field in the STT that permits sending an
8-bit unsigned integer that is added to ATSC_seconds to determine GPS
time.
John, you are absolutely wrong, and it is going to cost you $100. You have
it exactly backwards. As stated above, A/65 requires stations to transmit
the current *GPS* time as a 32-bit unsigned integer, which reflects the
current number of *GPS* seconds that has elasped since 00:00 UTC January
6th, 1980. That is the definition of GPS time, not "ATSC_seconds." The
GPS_UTC_offset value is then used to derive UTC from the transmitted GPS
time, and then the resulting UTC is used in conjunction with
daylight_savings (sic), and local UTC offset to calculate local time.
The current GPS_UTC_value is 14. One sign of a bad PSIP implementation is
if the start time of various programs has a second value of 14 (or
whatever the PSIP generator GPS_UTC_offset value is set to). This
incorrect, since program times are always in UTC.
I agree, and I never stated in any of my postings that program times were
given in GPS time. I don't know how you came to that conclusion.
What trips mere mortals is what the 32-bit time value represents. It is
the count of GPS seconds since January 6, 1980. You may note that is the
date that GPS became operational.
The reason the 32-bit value is the count of GPS seconds is a simple one:
ATSC_seconds always have to be continuous and increment by one for each
second elapsed. Counting UPS seconds won't work, since every couple
years, the time count becomes discontinuous for one second when the
GPS_UTC_offset is incremented by one. (This is done because the GMT/UTC
time standard is not as accurate as the one used in GPS.)
I'm sorry, John, but I don't know what UPS seconds are.
I do count GPS seconds, however, and convert to UTC time using
GPS_UTC_offset. However, that aside, this mere mortal knows that UTC time
includes leap seconds periodically so that UTC time remains reasonably in
sync with the rotation of the Earth, which is not stable. As far as I know,
UTC and GPS both use equally stable time references.
So: PSIP NEVER, NEVER, NEVER gives GPS time; it can only use UTC time and
give a value that is used to derive GPS time. (If everything is set
correctly.) To employ a consistent time base, PSIP generators must
provide at least once per second a count of the number of GPS seconds that
have elapsed between UTC January 6, 1980 and the current time in UTC.
I NEVER, NEVER NEVER said that PSIP *GIVES* GPS time. I said PSIP must
*PROVIDE* GPS time to the receiver, along with a GPS to UTC correction
factor. Nothing you have written has this far dispelled me of that notion.
BTW, stations get fined for not having accurate time in their STT. ATSC
A/65 requires an accuracy within one second. I should also note that time
of day from the phone company is not an accurate time reference: it can be
up to 10 seconds off, in my experience. I've checked hundreds, if not
thousands of times.
Ah, John, but the question that was being debated was "can stations be fined
for providing UTC seconds in the system_time variable, and a null value in
the GPS_UTC_offset variable?"
Thus far your musings have not addressed that question.
John
----------------------------------------------------------------------
You can UNSUBSCRIBE from the OpenDTV list in two ways:
- Using the UNSUBSCRIBE command in your user configuration settings at FreeLists.org
- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word
unsubscribe in the subject line.
Other related posts:
