[opendtv] Re: A full explanation of the PSIP time issue.
- From: "johnwillkie" <johnwillkie@xxxxxxxxxxxxx>
- To: <opendtv@xxxxxxxxxxxxx>
- Date: Sun, 27 May 2007 15:42:23 -0700
Well, I can accept that our differences start with your nub.
But, that's not the end of it. Your station bought a PSIP generator that
you aren't happy with now. Yet, despite the well-documented experiences of
virtually every other user, you bought it without a maintenance contract and
now have uncorrectable bugs. (Different that the "somewhat corrected bugs"
that you get with the maintenance contract.)
You said that my price was too high. Yet, I don't recall any price
dickering in our discussions. My first customer gave me a take it or leave
it price that was a fraction of my list price and I accepted it, as long as
the price remained confidential.
Now, you are talking with another vendor. I suspect that is DTV
innovations, and I wish you well. I have had only initial discussions with
Myers about Pro-track, but I didn't find them to be the most interested in
providing interface details in advance of a customer need, and I would be
leery at this point agreeing to providing an interfacing application for a
set price.
I have only written four log/automation interfaces at this point: PMCP,
Harris MCAS, Wide Orbit and the very weird log system used at KYES. Let me
say that doing the interface to a traffic/log system isn't rocket science,
but getting the interface details can be 'tough.' (I've never had any
problem, and Wide Orbit gave me their details about four years ago.)
What is the problem is that it looks at this moment that I'm the only person
in North America who is actually writing PSIP generation applications. If
you don't believe me, ask Chris Knectel the name of his developer.
The industry is full of firms that want to defend their proprietary
interfaces (Myers, Triveni, Moto) to transport streams traffic/automation
data. These interfaces increase the cost of ownership and maintenance.
There are also savvy firms in the field -- Harris immediately comes to mind
-- that have come to realize that there is MORE money to be made by using
industry-standard interfaces.
PMCP is one of those interfaces. I support it directly. Triveni has never
released or announced a PMCP-complaint product (save that GuideBuilder will
download schedule data via PMCP.) DTV Innovations offers it as an option,
and Thomson's Pearl supports it, although I probably won't know the extent
for a couple of more days.
You've already made a decision that you are unhappy with involving a PSIP
generator. If you don't purchase a PMCP-compliant PSIP generator, you are
likely to be unhappy again in short order, unless you plan on NEVER offering
ACAP/OCAP or other data broadcasting.
If your traffic system vendor doesn't offer a PMCP interface this year, they
will likely be alone. Virtually every vendor that I've talked to plans to
have theirs operational this year, and it was a short list for those that
didn't currently offer one.
There is a compatible XML schema that will also become important in coming
years. It's called BXF, and Chris Lennon of Harris is the chair of the
SMPTE S-22 data exch group that has been developing it for the last few
years.
BXF and PMCP work together. With BXF, all the data necessary to control
transmission of programs and spots is in an XML schema; with PMCP, all the
data needed to create PSIP or data broadcasting 'signalling' is contained in
a single XML schema.
So, pardon me if I'm off 2 or 7 or 14 seconds on a theoretical calculation
involving a date more than 27 years in the past. I don't have nor will I
take the time to debate how many angels can dance on the head of a pin.
Perhaps I am off -- although I haven't seen any evidence on point -- in my
calculations involving system_time. I'll get to the bottom of it, and
without referring to the GPS spec.
I tend to distill it down to "trying to do the right job" and not merely
"doing the job well." Whatever you do, buy the maintenance contract. The
spec changes from time to time, and if your implementation of A/65 doesn't
permit change, you are hobbling yourself. And, it's nice to have the
advantage(s) of whatever development efforts the companies put towards
existing customers.
Buying the most expensive and least reliable PSIP generator on the market
and not getting a maintenance contract isn't "doing the right job" nor is it
"doing the job well."
I only have myself to blame for my mistakes, and when a customer tells me
something appears wrong, I quickly get to the bottom of it, and propose (or
implement, if it's within my purview) a real fix.
I don't blame hardware vendors (I chose them, after all), and I've expended
serious efforts to try to prevent garbage from going into my systems. My
list prices are less than Triveni, but more than other competitors. Let me
highlight that again: the most expensive units on the market are the least
realiable, but large companies that like doing business only with large
companies buy the turds again and again, I guess because the marketing
drones say "all the problems are fixed."
Caveat emptor!
John Willkie
P.S. I'm not soliciting business at this point from PBS stations that use
Myer's Pro-Track. Last time I checked, either Triveni listed them as a
partner, or they listed Triveni. Let them live with one another, at least
until I've tested my implementation to their interface.
-----Mensaje original-----
De: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] En
nombre de John Shutt
Enviado el: Friday, May 25, 2007 6:58 AM
Para: opendtv@xxxxxxxxxxxxx
Asunto: [opendtv] Re: A full explanation of the PSIP time issue.
John,
Here is the nub of the differences between you and me. In my world you were
not off by 2 seconds, you were off by 7.
First of all, an "epoch" date for GPS means that on that date both clocks
were synchronized to the same time. "Time zero" if you wish. So on 6
January 1980, 00:00:00 UTC, the GPS time was also 6 January 1980, 00:00:00
GPS. If you don't believe that then all I can do is point you yet again to
the definition of GPS time on the National Institute of Standards and
Technology website that you will again refuse to read because you object to
it as a "secondary source" and therefore not reliable.
If, as you assert, that GPS time is offset from UTC time by all leap seconds
that have been observed prior to 6 January 1980, 00:00:00 UTC in addition to
all of the ones observed after, then ask yourself this question: Why is the
current GPS to UTC offset 14 seconds? We can both agree that the current GPS
to UTC offset is 14 seconds?
By using your assumption that GPS time was 00:00:09 when UTC time was
00:00:00 on 6 January 1980, the current GPS to UTC offset should be 23,
because there have been 23 leap seconds observed in UTC since the first one
was inserted on 23:59:59 30 June 1972.
Is the GPS to UTC offset 23 seconds? No, it is 14 seconds. Many places on
the web confirm that fact. Why is it 14 seconds and not 23, John? Because
on 6 January 1980, GPS time and UTC time were the same, and since then there
have been 14 additional leap seconds observed in UTC, and those are the only
ones that concern GPS time.
In addition to the definition of GPS time from the NIST, I also gave you a
reference (at the bottom of my response to your Challenge) to a website with
a JavaScript clock that showed the current time in UTC, GPS, TAI (Atomic
time), and Loran C time, based on your PC's clock. From that website, you
can see that the author of that program also thought that GPS time is
currently 14 seconds ahead of UTC time. Working backwards from now to 6
January 1980, 14 leap seconds have been observed in UTC, so of we subtract
those 14 seconds of offset, we come to find that GPS time and UTC time were
identical on 6 January 1980, not 9 seconds offset.
However, as I said previously to you, please continue to labor under your
understanding of GPS time because in the end it doesn't matter. The
<system_time> variable in the STT is expressed as the number of GPS seconds
that have elapsed between GPS epoch and the current moment. The EIT
variable <start_time> is also conveyed as the number of GPS seconds that
have elapsed between GPS epoch and the program start time.
You are of course absolutely correct that the integer time value, in GPS or
UTC, is never expressed in the form MM.DD.YYYY HH.MM.SS, anywhere in STT or
EIT, and because of that it doesn't matter what you think GPS time should
read at any given moment, nor what I think is should read. It doesn't
matter if you call the values contained in <system_time> and <start_time>
UTC times and I call them GPS times. All that matters is that your PSIP
generator need to spit out the correct values for <system_time>,
<start_time> and the hundreds and hundreds of other values required for
PSIP, and your software does it extremely well. The fruits of your labor
speaks volumes.
I must say, John, that after reading A/65C, I am truly in awe of any one
person who could write code that can keep track of all the crap that has to
go into PSIP, and do so flawlessly every few milliseconds. The MGT, STT,
RTT, TVCT, rotating EITs and ETTs, etc. It boggles my puny mind that any
one person could "grok" all of that and end up not only with a working
product, but with his sanity intact. And you have done it not once, but
several times as you had to recreate your work from scratch through a nasty
hard drive crash, as I recall. It is a monumental task that I know I could
never even begin to duplicate. I respect you for your accomplishments,
John, and I'm sorry to have angered you.
Regards,
John
----- Original Message -----
From: "johnwillkie" <johnwillkie@xxxxxxxxxxxxx>
To: <opendtv@xxxxxxxxxxxxx>
Sent: Thursday, May 24, 2007 10:23 PM
Subject: [opendtv] Re: A full explanation of the PSIP time issue.
> So, I was off by 2 seconds on a 27 year old time value. Franky, I
> couldn't
> remember if it was 7, 8 or 9, and I didn't care to look it up, because GPS
> representations of time are irrelevant to STT time, although the count of
> GPS seconds is important.
>
> Less worse than being off 14 seconds now.
>
> So, starting on July 1, 1991, you couldn't code STTs using GPS time
> displays, and you can't now. This is before the grand alliance was even
> formed, so you are tending now to support my view?
>
> John Willkie
----------------------------------------------------------------------
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:
