[opendtv] Re: A full explanation of the PSIP time issue.

  • From: "Paul Freeman" <paul@xxxxxxxxxxxxx>
  • To: <opendtv@xxxxxxxxxxxxx>
  • Date: Thu, 24 May 2007 17:04:45 -0500

Hi John,

 

I think the reason for sending the GPS_UTC_offset is so that the receiver
can correctly determine the time of day for purposes such as displaying a
channel banner and for labeling the columns on an EPG grid display with the
correct start times. (I believe) the STT times are expressed in GPS and (we
both believe) EIT start times are also expressed in GPS within the PSIP
data. But the user wants to see these in times displayed in their local
time. So the receiver must first convert the transmitted GPS times to UTC
time by subtracting the GPS_UTC_offset, and then adjust the UTC time for the
local time zone and local daylight savings time status. Without transmitting
the GPS_to_UTC offset, the receiver would be displaying the wrong values in
the channel banner and grid guide.

 

  _____  

From: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] On
Behalf Of johnwillkie
Sent: Thursday, May 24, 2007 4:55 PM
To: opendtv@xxxxxxxxxxxxx
Subject: [opendtv] Re: A full explanation of the PSIP time issue.

 

Yes, I meant to correct that.  EIT times are GPS time, and I erroneously
stated otherwise in this thread.

 

However, that just begs the point.

 

PSIP provides time of day, EPG and time for EPG events.  

 

Since the time in EITs are GPS, and - a false notion - the STT is GPS, just
why is the GPS_UTC_value transmitted in the system time table?    And, IT'S
REQUIRED TO BE ACCURATE!

 

It isn't needed; TV sets and receivers have no need for UTC (in this
argument).  And, I can find no other circumstance in PSIP where 8 bits of
unneeded data is required to be transmitted, let alone where unneeded data
is required to have a value other than '1' in each bit position.

 

Now, that GPS_UTC_offset value is required in the actual PSIP time scenario,
to correct the transmitted UTC to GPS.

 

Once again, all this becomes obvious once you do the coding of just a PSIP
encoder.

 

John Willkie

 

  _____  

De: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] En
nombre de Paul Freeman
Enviado el: Thursday, May 24, 2007 1:46 PM
Para: opendtv@xxxxxxxxxxxxx
Asunto: [opendtv] Re: A full explanation of the PSIP time issue.

 

I am having a hard time concluding from the A/65C spec how the system_time
field in the STT is anything other than GPS time. I do not see how the
conclusion has been reached that this field represents UTC time, and so far
have been unable to understand the arguments that have been presented in
favor of the syste_time field representing UTC time.

 

But I have seen some of the posts claim that the EIT information is UTC
time, and nobody has refuted that yet. However, from my reading of the spec,
even though the EITs change at 12:00, 3:00, 6:00, and 9:00 UTC time (not GPS
time), the actual start times listed in the EITs are themselves expressed in
GPS time. That is, the "start_time" field in the EIT is described on page 44
of A/65C as "A 32-bit unsigned integer quantity representing the start time
of this event as the number of GPS seconds since 00:00:00 UTC, January 6,
1980".

Other related posts: