[opendtv] Re: A full explanation of the PSIP time issue.
- From: Ron Economos <k6mpg@xxxxxxxxxxx>
- To: opendtv@xxxxxxxxxxxxx
- Date: Wed, 23 May 2007 15:08:52 -0700
A quick check of the Silicon Valley DTV station times last night:
1) A few were within the 1 second specification.
2) A few were within a minute or two.
3) One PBS station was behind an hour (still on PST?).
4) One station was 6 hours ahead.
5) One station had the correct time, but the date was February.
Perhaps PSIP generators should have GPS receivers built-in?
Ron
johnwillkie wrote:
I said I wasn't going to comment on this, but I realized last night
that I didn't connect a few dots.
First, time representations. Few to none GPS time devices (or any
time devices) output the internal value that they use to calculate
real-time. It's true that the integer value used in system time
tables and the interger value used in GPS tack one another. BUT,
that's irrelevant and likely to confuse, because time is expressed in
just about all contexts as year, month, date, hour, minute, second
(and, if needed, one ore more types of sub-second value representations.)
I have routines that convert flawlessly to and from UTC, GPS and even
local time and ATSC_seconds. I've never even seen a web resource that
does this. (Let's see if someone gets one up before
www.etherguidesystems.com <http://www.etherguidesystems.com/> offers
one.)
At 10:00:00 a.m. this morning (UTC), a clock referenced to UTC would
give 10:00:00 a.m. A clock presenting GPS tme at that same time would
indicate 10:00:14. These are 'time values" in two different time
bases that refer to the same second.
To convert an instantaneous UTC time value to the value transmitted in
system time tables (a 32-bit unsigned integer) one only needs take in
the UTC time value and figure out how many GPS seconds have elapsed
since January 67, 1980 at 00:00:00. To get the value included in STTs
from a GPS source, one first needs to convert the time to UTC and then
perform the same calculation. To say the least, it's inelegant to do
it this way.
And, at the moment when you need to advance the GPS_UTC_offset, using
such a scheme would require you to use the old GPS_UTC_offset value to
convert to UTC, then add in the new GPS_utc_offset value that needs to
be included in the STT.
Then, there's the issue that the STT needs to be created in advance
(best to do so just after the previous STT is transmitted) AND per the
spec, has to carry the value for the NEXT (not the current) second.
So, you are actually creating STTs two seconds (or more) in advance of
need. So, a one second slippage can easily become a two second slippage.
Kinda fund, don't you think, trying to diagnose such issues in real time?
I brought up the issue of stations giving start times for programs
with the start time offset by the GPS_UTC_offset. I've seen this in
practice, and I have a full understanding of how that happens.
First, you start off following bert's 'advice' ad to create System
Time Tables with GPS time values and you transmit GPS_UTC_offset to
zero, in violation of A/65.
But, the 'somewhat' astute Chief engineer will notice, in due course,
that the EPG listings change 14 seconds before the program begins.
This is because you've actually advanced UTC by 14 (the current
GPS_UTC_offset value), so what the receiver clocks shows as 00:00 is
actually 59:46. The receiver knows to advance program listings at the
UTC time, and it assumes that the time base of the encoder is UTC.
So, the listings advance 14 seconds before the show comes on.
The bad work-around to this bad problem is to advance the program
start time by the GPS_UTC_value. Hence, programs are listed to start
at :14 after the hour, even though they actually start at :00.
I've lost count as just how many A/65 violations are involved in the
above scenario: at least three, but I suspect that the count is
closer to a dozen, were I to go through the spec line-by-line.
If only the Engineer compared presented time to a local UTC time
reference and knew that all STTs carry UTC values, the real problem
would be obvious. If only the engineere noted that GPS isn't
referenced in A/65 as an informative or normative document AND the
spec says that all time references are in UTC.
THIS IS A PROBLEM THAT IS COMMON AMONG PBS AFFILIATES!
Indeed, let me put it another way. I have seen stations with bad
times in their STTs, and I have seen stations with bad
GPS_UTC_values. The only stations that I have seen with both those
issues and with program listings advanced by the GPS_UTC_offset value
have ALL been PBS stations. I suspect that it has something to do
with the monolithic way that PBS distributes time and interfaces to
local gear, and the just plain difficulty in understanding ATSC A/65.
There is another consideration. Bad times in System Time tables can,
with some receivers and depending on the offset and the receiver,
prevent viewers from tuning in the offending (but usually only
non-offending) stations. Don't ask me why. But, everytime the local
PBS station in San Diego puts out 'bad enough' times (I have some
'lovely' transport streams from KPBS-DT), local commercial chief
engineers get calls from cable and ota DTV viewers about difficulty or
wierness in tuning in their station. More than a few know by now to
first check the time presented by KPBS-DT.
Other related posts:
