[opendtv] Re: A full explanation of the PSIP time issue.
- From: "johnwillkie" <johnwillkie@xxxxxxxxxxxxx>
- To: <opendtv@xxxxxxxxxxxxx>
- Date: Thu, 24 May 2007 16:11:12 -0700
But you skipped a step. If you started with a UTC time base, and subtracted
it from a current UTC time, when did you do the conversion to GPS of your
resulting 32-bit value?
You are subtracting it from GPS at the end (only works with EIT start
times), but to get there you need to add a value to UTC (remember the STT
calculations all involve UTC) to get UPS time.
I'm not saying that this is easy to understand; I'm saying I have tried ALL
the possibilities and I know that only one way works, and it's consistent
with the spec.
To convert GPS time to UTC, you subtract GPS_UTC_offset. To convert UTC to
GPS, you add GPS_UTC_offset. It's when and if you need to do this which is
at stake, and if you don't do it, you are left with time denoted in the
original time base.
Let me bring up something from my 7th and 8th grade math classes: the
commutative value of addition and subtraction. If it subtract one GPS value
from another, the answer is denoted in GPS and I can get the later time by
adding the result to the lower value. If I do the same with UTC values, the
answer is in UTC values. I use GPS_UTC_offset to convert between the two.
If I don't do that add/subtract, I am left with a value denoted in the
original time base.
If the spec said that you start with a GPS time value and that the 32-bit
integer is the number of UTC seconds that have elapsed, I would reverse what
I say about UTC time. But, it says the opposite.
It's always important to know when you are making assumptions about a spec.
If you are making assumptions, you are probably doubly in error. Initially,
I assumed upon a facile reading of the spec, that STTs were calculated using
GPS, but I was in error and I was misled by assuming that the "number of GPS
seconds since" meant the resulting value was in GPS. Even then, I wondered
just what the GPS_UTC_offset value was used for. When I reversed my
thinking, everything fell into place.
And, I did mention that I've done this on encode and decode, and I've
checked both against what other implementations of encoders and decoders do?
Since it would involve exposing too much of my source code, I cannot provide
mathematical proof absent a non-disclosure agreement., but I HAVE
MATHEMATICAL PROOF.
Opinions are unavailing against proof, unless the opinion comes from someone
clearly more knowledgeable than I, and even then we would have to dissect my
proof.
John Willkie
_____
De: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] En
nombre de Paul Freeman
Enviado el: Thursday, May 24, 2007 2:54 PM
Para: opendtv@xxxxxxxxxxxxx
Asunto: [opendtv] Re: A full explanation of the PSIP time issue.
If anyone has Mark Eyer's PSIP book "PSIP: Program and System Information
Protocol", they can see an example of how time in the STT is represented on
page 150 at the bottom of the page. The following few lines of text are from
Mark's example:
Current time of day (UTC): 1:00 P.M., December 30, 2001;
.
The System Time Table indicates the following parameters for the current
time of day:
GPS seconds = 693,752,413, or 0x2959D25D
GPS to UTC offset (count of leap seconds) = 13.
Now, you can go to the following web site to find a "days between dates"
calculator:
http://www.convertit.com/Go/ConvertIt/Calculators/Date_and_Time/Date_Time_Di
ff_Calc.ASP
When I plug in the number of days between January 6, 1980 and December 30,
2001, I get "8029 days".
So there are 8029 x 24 = 192696 hours between midnight January 6, 1980 UTC
and midnight December 30, 2001 UTC. Add 13 hours to get to the current time
of 1:00 PM on December 30, 2001 and we have 192709 hours. Converting to
seconds gives 192709 x 60 x 60 = 693,752,400 seconds. Thus, this would be
the number of seconds between 00:00:00 January 6, 1980 UTC and 13:00:00
December 30, 2001 UTC if we never had to worry about leap seconds. However,
the value in Mark's example STT is 13 seconds ahead of this time. This means
that, at the time of the example, we have had 13 leap seconds, and the
GPS_to_UTC offset of 13 should be subtracted from the system_time field in
the STT to convert the system_time from GPS seconds to UTC.
Other related posts:
