[opendtv] Re: A full explanation of the PSIP time issue.
- From: "johnwillkie" <johnwillkie@xxxxxxxxxxxxx>
- To: <opendtv@xxxxxxxxxxxxx>
- Date: Wed, 23 May 2007 17:56:00 -0700
I wish!
Unfortunately, GPS won't solve all problems, or in some cases will create
more.
In at least one case I know of, a station can't use GPS time because the
distance from the closest point it controls in the building to the closest
receive point exceeds the number of feet of antenna lead-in permitted
between the electronics and the antenna. Then, there is the distance
between this point and the zero-timed master control, and the time delay
involved (which can at least be figured.)
Some networks and distributors give time in UTC, others in GPS.
So much simpler to give me some type of a click once per second with the
year, month, date, hour, minute and second expressed as integer values, and
give me an integer to convert the time value to UTC. The master clock at
the station needs to be more accurate than the clock in the PSIP generator.
To have two GPS time standards might work in the case where the PSIP
generator is at the tx site and the master clock is at the studio, but
otherwise it's likely to be 'too many chefs.'
Also, nobody has asked for that in the field. But, I've been ready for some
time .
Aside from my "understanding" (or lack thereof) on STT an time values, I
came up with a simple paradigm:
If the PSIP generator is operating, the clock on the front panel increments
once per second to give the current utc (and local) time values. The same
code that advances this clock display had, immediately before, created the
next STT, and is the same timing loop that tells the application when to
fire off a particular packet. If the clock is frozen, the application is
frozen. If the clock advances, the program is working. The only fuzziness
at this point is the latter point: I've never seen the clock fail to
advance, nor have I seen the application freeze.
There is absolutely no excuse for time being 6 hours ahead, one hour behind
or being off by days.
Most likely, the station with the one hour behind time is a computer
application running on a non-dedicated computer and the internal clock in
the computer was set to PST but with the "dst change" box unchecked. There
is no "S" or "D" in STT times: it's all UTC. Kinda hard to get that across
in all corners.
If you want to have fun, Ron, check the daylight savings time bits in the
STTs. The only value permitted at this time is to set DS_day to zero,
DS_hour to zero, and DS_status to one. I find half the transport streams I
look at have these values set incorrectly. (Wisconsin, Arizona don't follow
DST, so DS_status should be equal to '0.'
John Willkie
_____
De: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] En
nombre de Ron Economos
Enviado el: Wednesday, May 23, 2007 3:09 PM
Para: opendtv@xxxxxxxxxxxxx
Asunto: [opendtv] Re: A full explanation of the PSIP time issue.
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
Other related posts:
