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

Well, that might be the case.

 

I've been silent for a few days because the circuit breaker tripped the
other night and it caused a key file in WindowsXP to get bollixed up
(happens about 1 time in 150-200 power fails)

 

It took nine hours to get the hard drive up and running again, without any
data loss.  Then, you have to reload all the XP updates (currently, I've
loaded 83, but there are at least 50 more to come).

 

However, during the four-hour "error checking" routine (it's a 500 gb hard
drive), I was able to do a spot check of my code against the times in Annex
D, and I wasn't happy with the result. :off by 12 seconds.

 

I now have to do a full audit of the time calculation code.  I'd previously
done this extensively - and have electronic and printed results to show for
it - but I can't remember and have no proof that I did this again AFTER I
took the VB6 code (more than 200 lines for time calculations) and
transverted it into .net code.  

 

I do know that in tests at KYES-DT, my customer has asserted that the time
is correct.  But, I haven't audited the network time source to make sure
there that it is doing UTC time or GPS time.

 

So, I have to "redo from start."

 

My audits are zero-based and complete.  I have never seen a case where I
audited code against a spec that, upon completion, the code didn't comply
with the spec.  And, in at least one case, I tried to find "the error" in
audited code, but I ended up proving that it was a downstream device that
was causing the problem.  We took it out of the chain, and everything
worked.  Even after I took out four months of corrections.

 

No, not exactly overthinking: if it's incorrent.  Not enough conformance
testing.

 

I'll keep everyone posted, but the detail will be posted to my PSIP list
(John S is a member.)  

 

For the moment, I've decided to treat this as a bug report from a paying
customer:  Get to the bottom of it, and decide it the problem is customer
perception, my understanding of the spec, or my implementation of it in
code.  The initial thought, after the spot-check, is that it's somewhere
among the latter two items, but I won't know until I can devote clear
head-time to the audit.

 

When it comes to PSIP/PSI, there is no such thing as over-thinking.
Otherwise prospects or customers ask you too many questions that you can't
answer quickly.

 

And, sorry if my attitude about discounting opinions of others who haven't
rendered the spec into code rattles some.  When I talk to customers, the
thoughts of third parties less knowledgeable than I don't come up.  It's:
does your system work, does it comply fully with the spec, and will it
interface to my plant.  For the first two items, all that matters is my code
and the spec.  (now, if you guys were available at 3:00 a.m. (when I did my
spot-check .)

 

John Willkie

 

P.S.  If I only know how many updates to XP SP2 it took befote Windows Media
Player 9 becomes Media Player 11.  I kind of got used to the album display .


 

  _____  

De: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] En
nombre de John Golitsis
Enviado el: Friday, May 25, 2007 8:03 AM
Para: opendtv@xxxxxxxxxxxxx
Asunto: [opendtv] Re: A full explanation of the PSIP time issue.

 

John, I think you've so over-thought this that you've tied it in knots.  I
know about THIS much (holding two fingers tightly together) of PSIP, but it
seems perfectly clear to me.  You transmit GPS time and the correction
factor, and the RECEIVER deals with the rest.  YOUR side (the transmit side)
seems pretty straightforward.  It's the receiver side that's required to
manage the details.  The correction factor is a simple variable.  If you
want to know UTC time, you subtract the variable.  EPG data must be in GPS
seconds since any calculations to UTC time occurs in the receiver.  If YOU
are doing the calculation on the transmit side, the receiver calculations
will lead to incorrect results.

 

 

On 24-May-07, at 7:33 PM, johnwillkie wrote:

Other related posts: