[opendtv] "Knowing" A Specification
- From: "johnwillkie" <johnwillkie@xxxxxxxxxxxxx>
- To: <opendtv@xxxxxxxxxxxxx>
- Date: Thu, 24 May 2007 12:28:03 -0700
1. The first step is knowing that a spec exists.
2. The second step is actually reading the spec.
3. The next step is figuring out how you can use the spec
4. The fourth step is having read the spec so many times that you think
you "grok" it.
If you truly do "grok" the spec, you have achieved the highest level of
non-practical knowledge that a person can acquire of a specification.
Generally, people involved in the writing of a spec will have this
knowledge.
Then, the going gets serious.
5. Write an encoder that takes data from one form and produces the
output contemplated by the spec.
6. Write a decoded that takes the output from step 5 and converts it
back to the original data form.
7. Test these two functions in a daisy-chain form using many if not all
of the values that will be experienced in practice.
Now, you have achieved the middle-tier of "practical" knowledge.
8. Test your encoder against the decoder of another manufacturer who
complies with the same spec.
9. Test your decoder against the encoder of another manufacturer who
complies with the same spec.
10. Perform the closed loop test in 7 using your encoder and their
decoder.
11. Perform the close loop test in 7 using your decoder and their
encoder.
12. If there are any anomalies, then perform the test in 7 using their
encoder and decoder. Compare results, resolve the anomalies.
13. After you've done steps 8-12 with all devices that comply with the
spec, you can say you "know" the specification, and you can mathematically
prove it. Now, it's your responsibility to insist a fix of the unresolved
issues raised by the spec.
Everything else is just conjecture and opinion.
At this point, with PSIP generation, I'm at least at step 10 on PSIP, and
have achieved level 7 on PMCP input/output, with my first test against
another PMCP device being discussed even today. With transport stream t&m,
I'm at least at step 7. Those that wrote the spec are at least at level 4
(some are higher due to their jobs).
Bert is somewhere between step 1 and 2. John Shutt is at least at level 3,
but as relates to STT values, he's not in step 4.
Along the way, I've encountered all sorts of funnies. One was the (yech)
Internet-centric, c++ programmer who wrote the "Simple PSIP" (DOA) code on
spec. He was complaining that there were error messages at the station
testing it, but he insisted that he did everything correctly, so it wasn't
his fault. In other words, he was at step 3 at best.
I asked him how he confirmed his CRC-32 code. He said that it did what was
in the spec. I asked him what "seed value" he used for the CRC-32. He said
he used the 'standard' seed value. (There are about two dozen standard seed
values, but he didn't mean the MPEG-2 seed value, he meant the TCP/IP CRC-32
seed value. In other words, he didn't have CRC-32 working per 13818-1.
Then, I asked him how many other DVB-ASI compliant products or test gear he
had tested against. "Why would I want to do that?"
"Because unless you are planning on engineering every device in the
transmission chain, your product needs to interface with a wide variety of
devices already on the market and which are only now in development, and
each uses at least one publicly-defined interface."
Hel told the guy who tried to put us together that he "couldn't work with
me." I would have worked with him, had I been well paid, with a significant
upfront retainer.
All along in our discussion, John Shutt could have solicited help on my PSIP
list, of which he is a member. I learn quite a bit from that list. A few
years back, while oddly discussing aspects of the system time table, I said
that a PSIP generator had to transmit a System Time Table every 1000 ms.
Adam Goldberg, then of Sharp Labs, corrected me, that it was a STT at least
once in each 1000 ms. Damned if he wasn't right! (Transmitting additional
ones within a second will rub against some "should" language, however.)
So, when presented with someone I can't convince is in error, and being a
few rungs higher up the scale above than the challenger, I told him to
settle the matter by talking to people higher up the scale. It's what I do,
and this exact topic I had previously referred precisely to people higher up
the scale. For me to refer this matter to them would have been me wasting
their time, since I would have asked the same questions as before, and I
would have been given the same answer.
I didn't use all my ammunition: I'm a member of T3/s1, which developed the
PMCP spec used to populate the data within a PSIP generator. The initial
release candidate for that document made no mention of GPS, because it ISN'T
USED IN GENERATING PSIP! (Graham Jones of the NAB was chair of the
subcommittee, and Frederic Grenier of Thomson was the intellectual author of
the rc). There was some back and forth on this because several stations
pointed out that their internal time was GPS, so the language was changed to
acknowledge that UTC or a time specification that can be converted to UTC.
NO MENTION OF GPS, SINCE GPS TIME VALUES CANNOT BE USED DIRECTLY TO CREATE
SYSTEM TIME TABLES. UTC time values can and are used directly to create
system time tables.
To mention GPS in the same breath as STTs is to create the impression that
one can present GPS time to a PSIP generator and have everything work
properly, since "GPS time" is the highest standard. Unfortunately, it would
put your time every precisely 14 seconds ahead of UTC were you to do that.
John Willkie
Other related posts:
