[opendtv] Re: XDS and ATSC
- From: John Willkie <johnwillkie@xxxxxxxxxxxxx>
- To: opendtv@xxxxxxxxxxxxx
- Date: Tue, 22 May 2007 17:10:11 -0700 (GMT-07:00)
>John, we were not talking about EITs, ETTs, or any other tables or variables
>other than the STT variable <system_time> and it's associated variable
><GPS_UTC_offset>. How you assumed we were talking about Electronic Program
>Guide start times is beyond me.
I am not confused, but you seem to be. ONE of the purposes of the STT is to
tell the viewer's
EPG when to change the displayed program: when the new one starts.
ALL TIMES IN A/65 ARE EXPRESSED AS UTC. Concentrate on that sentence. There
is no work-around. Repeat
as necessary.
>
>Perhaps you leapt to that incorrect conclusion when you read my post that
>said in part:
>
>"The ATSC standard expects stations to broadcast GPS time, and broadcast a
>GPS offset to UTC time."
No, I'm not confused by anything you've written on this topic. Please provide
me with any evidence (like quoting from the
spec) that leads you to believe that 'the ATSC' standard expects stations to
broadcast GPS time. Hint: they standard says only the contrary: that all
times are expressed in UTC.
>
>Note the use of the singular "time" not the plural "times." Not like you at
>all John to miss such an obvious thing. I asserted yesterday and still
>assert today that we are required to transmit GPS time and a GPS offset to
>UTC time, exactly as I stated. The two parameters in PSIP are STT
><system_time> and STT <GPS_UTC_offset>.
>
Not unlike you to concentrate on irrelevant. You are stimply re-asserting your
ignorance. The standard gives NO HINT that you are to transmit GPS. You start
with UTC January 6, 1980. You add the number of seconds that have elapsed.
You end up with UTC. To convert to GPS, you also provide the number of seconds
to ADD to UTC to derive GPS.
Anything beyond that is not based on the spec, and aside from that, requires
you to interpret something. And, you do so in error.
It's a crying shame, by the way, that your vendor provided you with a
sub-standard device and permits you to have an erroneous understanding of
something so simple as time. You should ask for this mattr to be referred to
Rick Chernock or Gomer Thomas at Triveni Digital.
>> Note, the EITs change on UTC, not GPS.
>>
>> You also might want to refer to section 7 in Annex D. "GPS Time."
>>
>> Note this sentence at the end of the first paragraph. "UTC is the time
>> source we use to set our clocks."
>
>Again, not relevant to either what Bert and I were discussing, nor to the
>$100 challenge you issued so confidently yesterday.
>
What you and Bert were discussing was the erroenous notion -- one that you
cannot base in the spec -- that all times in PSIP are GPS time. You might
want to actually read the spec (including annex A and relevant portions of
Annex D.)
>> Following graf: "UTC can be directly computed from the count of GPS
>> seconds since January 6, 1980, by
>> subtracting from it the count of leap seconds that have occurred since the
>> beginning of GPS time.
>> In the months just following January 1, 1999, this offset was 13 seconds."
>
>And the offset is now 14 seconds. Again, not relevant to your $100
>challenge.
Sure it is. If all PSIP time is in GPS seconds, just why does this value need
to be transmitted? To derive UTC? Kind of funny then, that the spec says
otherwie. You see, it's because in some cases, UTC needs to be conveted into
GPS. But, if GPS is the PSIP time spec, just why would the conversion have to
be made to UTC? Why isn't this discussed in the spec, where the contrary is
discussed?
>
>> Two paragraphs later: "GPS time is used to represent future times because
>> it allows the receiver to compute the time
>> interval to the future event without regard for the possible leap second
>> that may occur in the
>> meantime. Also, if UTC were to be used instead, it wouldn’t be possible to
>> specify an event time
>> that occurred right at the point in time where a leap second was added.
>> UTC is discontinuous at
>> those points."
>
>Aha! By your own admission, GPS time is used. We are making progress, and
>this is further argument in my favor that we are required to transmit GPS
>time and a GPS to UTC offset correction factor, exactly as I stated to Bert,
>and exactly what you challenged was not true yesterday. Again putting your
>$100 at peril.
>
False, and it's just so bert-like to grasp onto hanging straws as you drop.
Let's say we have a herd of 100,000 rabbits, and four rabbits were born each
second. We could note the passage of time by taking the number of current
rabbits, subtract 100,000, and dived the result by four. The figure we ended up
with would never be the number of rabbits in the herd, it would just be the
delta.
Last time I checked, GPS time wasn't transmitted as deltas, but as a discrete
time stamp. Therefore, ATSC seconds are not only a different time base than
GPS seconds, a different signallling scheme is used.
Ask yourself another simple question. At the exact moment that ATSC_seconds
was equal to 1, what was the GPS time? YOU CAN"T KNOW, NLESS YOU KNOW THE
GPS_UTC_offset at that moment. IIRC, it was about 8. That's why your scheme
is broken. But, if you follow the text that ATSC_seconds is the number of
seconds that have elapsed since 00:00:00 on Jan 6, 1980, you don't need to do
any GPS_UTC correction at the end, since the time is presented (as is stated
clearly in the text) in UTC
>> You could also search A/65 for GPS references and for UTC references and
>> see how they come up.
>>
>> You appear to be confused because the counting is of GPS seconds -- as I
>> touched upon and which is explained in more detail in A/65. If the
>> counting had been done any other way, one would need to keep a table of
>> the UTC time offsets past and future before doing any time calculations.
>> This system is so much more elegant!
>>
>> I was asking for you or others to point me to text in A/65 that permits or
>> requires the transmission of GPS time values in System Time Tables. Not
>> values that can be used to adjust the transmitted UTC to GPS. You didn't
>> give me such information, but apparently thought that I didn't understand
>> this are VERY WELL.
>
>John, some simple yes or no questions:
>
>Is the variable <system_time> in the System Time Table? Yes.
>
>Does the variable <system_time> represent the number of GPS seconds that
>have elapsed since 00:00:00 UTC January 6th, 1980? Yes.
>
So, you end up with a UTC value? why do you think the answer is in GPS time?
>Is then the variable <system_time> GPS time? Yes.
>
NO! You haven't read, or failed to understand, the text.
>Therefore, is the statement "A/65 permits or requires the transmission of
>GPS time values in System Time Tables" true? Yes.
>
Set your damn station to GPS time, I'll file a complaint with the FCC, and
we'll see what happens! Let me know when you've done it. It shouldn't cost you
much more than $10,000 in attorney's fees and FCC fines. Worst case for me:
the FCC issues clarifying language so even you understand what is in the spec.
Best case for you: you learn the truth. Worst case: no pay raises for a few
years.
>Q.E.D. You lose your $100 challenge.
Have you even thought about emailing aallison@xxxxxxx? I could use the fine
against WKAR as a marketing material. In other words, I dare you.
I still want to know what time you signalled for DST change. No FCC fine
there, as best I can tell, as Annex A is informative, not normative. (Then,
there's the fact that Annex A isn't listed in the main body of the text, which
violates one or more sections of the Federal Administrative Procedure Act, but
hey!)
John, you may have a journeyman's knowledge of various things in digital
broadcasting. I have a very deep knowledge of PSIP/PSI, and I've learned from
many mistakes over the past 6 years.
And, I just love dealing with the various time bases in a transport stream: NPT
(normal play time); ATSC_seconds, SMPTE time code in video packets, the time
based used in ACAP/OCAP (also a second counter, though with a different base
time), the PTS/DTS time base and the more accurate PCR/STC time base upon which
they are based.
I also have a 'pretty good' sense of which are unneeded, which are free-running
with regards to the others, and which can (or should) be derived from another.
I may know little to nothing about the compression layer and how to get analog
signals into digital packets, but I tend to have the transport layer covered.
Here's one thing I've learned trying to interpret specs: don't read ANYTHING
beyond what's in the text, and if in doubt, try to make a case for and against
all possibilities. I've spent the better part of a week doing just that on STT
mathematics; once on the transmit side, another on the receive time. I suspect
you've spent much less time in A/65 than have I.
When I compared my understanding of this against the experts, the experts tell
me I have the correct understanding of how to calculate time for inclusion in
System Time Tables. Would it help you if I contacted Matt Goldman (the third
credited author of A/65) and asked him if you are correct of I am? Will you
accept three out of three? If so, why not two out of three?
Boy, the trouble John Shutt will go through for $100 (in a battle he couldn't
win) is (I hope) overmatched by my trouble in defending the bank account. :-)
John Willkie
>
>> Let me prove the point.
>>
>> We change to daylight savings time in the U.S. at 2.:00 a.m.; most
>> recently in March. Daylight savings time changes are signaled in the STT,
>> with a field for the month, date and hour.
>>
>> What is the actual value of DS_hour that WKAR transmitted in the 30 (or so
>> days) before March 11? If it was 2:00, that was incorrect, since what you
>> are supposed to signal is the UTC time when your DST status changes, so
>> the value should have been 'closer' to 10:00 a.m.
>
>All of this is very informative but tangent to the challenge you so hastily
>conceived yesterday. The point is that A/65 requires the transmission of
>GPS time, and requires so specifically in the System Time Table variable
><system_time>.
>
>As to your DST example, may I suggest you read Annex A of A/65C dated 2
>January 2006. I think you will find it very informative, especially the
>opening paragraph which reads in part:
>
>"In order to convert GPS into local time, the receiver needs to store a time
>offset (from GPS to local time) in local memory and an indicator as to
>whether daylight savings is observed."
>
>Oh dear, there's that nasty phrase "GPS time" again, bringing you ever
>closer to placing your $100 in the hands of the charity of your choice.
>
>> And, A/65 won't help you with this one: as I've pointed out to Mark Eyer,
>> the A/65 language is effectively misleading, since it would lead the
>> misinformed to simply put in "2" even though DST changes don't occur at
>> that hour. Ever wonder why the maximum value of this field is 18 and not
>> 24? How many hours are there between Greenwich, England and the
>> International Date Line if your travel is in the direction of the Sun?
>> (That's my only conjecture in this posting.)
>
>Again, Annex A of A/65C should be most enlightening reading for you. A "2"
>would indeed be the proper integer to use for the <DS_hour> nibble of the
><daylight_savings> variable, according to A/65C Annex A which specifically
>describes that nibble to represent:
>
>"DS_hour - This 8-bit unsigned integer field indicates the local hour at
>which the transition into or out of daylight savings time is to occur
>(0-18). This usually occurs at 2 a.m. in the U.S."
>
>Note the phrase "local hour" and think about it's significance. If the
>variable instead were to represent the UTC time that the change occurs as
>you assert, how could viewer A in the Eastern time zone, and viewer B in the
>Central time zone, both served by the same broadcaster, both have their
>clocks change at the proper time? Using your method, the broadcaster would
>have to transmit "22" for viewer A, and simultaneously transmit a "23" for
>viewer B, assuming a Standard Time to Daylight Time transition, or "21" for
>viewer A and "22" for viewer B, assuming a transition from Daylight Time to
>Standard Time.
>
>Specifying the "local" time that the change takes effect allows the
>broadcaster to transmit a "2" no matter which time zone the viewer lives in,
>and no matter which way the transition occurs. It leaves the details to the
>local receiver to change the clock at the appropriate local hour.
>
>Not part of your $100 challenge, but I put it out there anyway.
>
>> To sum it up: you missed that the not-so-simple sentence fragment
>> "representing the current system time as the
>> number of GPS seconds since 00:00:00 UTC, January 6th, 1980." REPRESENTS
>> UTC TIME, NOT GPS TIME! GPS seconds, as I pointed out in my first posting
>> on this thread, merely provides a continuous count of seconds since that
>> UTC time reference point to the moment in question.
>
>To sum up my rebuttal: You missed the very straightforward point that I was
>discussing the requirement by the ATSC to transmit GPS time.
>
>I have demonstrated that the ATSC, in standard A/65C, requires broadcasters
>to transmit the number of GPS seconds that have elapsed since 00:00:00 UTC,
>January 6th, 1980, and to also transmit the International Bureau of Weights
>and Measures designated GPS to UTC correction factor (a.k.a. "leap
>seconds.")
>
>Further, I think you and I agree that in order to arrive at UTC time at the
>receiver, you must take the GPS time that is conveyed in the STT variable
><system_time>, apply the GPS to UTC correction factor (currently 14)
>conveyed in the STT variable <GPS_UTC_offset> in order to arrive at the
>current number of UTC seconds that have elapsed since 00:00:00 UTC, January
>6th, 1980.
>
>Then the receiver converts those number of UTC seconds that have transpired
>since 00:00:00 January 6th, 1980 into a UTC time and day. Finally, the
>receiver will apply the user supplied local time zone offset from UTC, along
>with the user supplied variable of observing Daylight Savings Time, to
>create a local time that is used to express Electronic Program Guide start
>times on the EPG for the viewer's enjoyment.
>
>> I am right, as confirmed by two of the (three? four?) authors of A/65 (I
>> can check with one of the other authors, if that will help), and you are
>> in a position to learn.
>
>I hope I never stop learning, and I hope you never stop teaching. However,
>your challenge:
>
>"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."
>
>Has been proven to my satisfaction beyond any doubt, and none of your
>arguments have addressed my assertions.
>
>If however, as I suspect, you thought the discussion referred to GPS times
>in the EPG, then I can understand your confusion and you can keep your
>money.
>
>On the other hand, if it is still your contention that somehow the STT
>variable <system_time>, taken by itself, with no modifications, in any way
>represents UTC, then you are still incorrect, and need to re-consult your
>ATSC sources for additional clarification because clearly you will not
>believe anything I have told you today.
>
>> I could go on (and on) on this topic for some time and space. Let me put
>> it this way: I spent som much time on this that I know that I am right
>> without talking to anybody else: I coded all the possibilities on the
>> transmit and client side. THE ONLY way to implement time and HAVE IT WORK
>> is the way I've outlined it. NONE OF THE OTHER POSSIBILITIES WORK.
>
>For that I will take you at your word, since I have never coded a PSIP
>generator, and the closest I have ever come is some BASIC in High School,
>and some 8086 machine language and FORTRAN in college.
>
>> PSIP isn't easy to understand, and the time aspects are some of the most
>> difficult to understand.
>
>Again, judging by the difficulties Triveni and others have in creating a
>working and stable PSIP generator, I wholeheartedly agree with you, and I'm
>sure you've come closest to achieving the goal of the quintessential PSIP
>generator.
>
>Regards,
>
>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.
>
----------------------------------------------------------------------
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:
