[opendtv] Re: Sixty-three TV stations to launch mobile DTV service this year
- From: "John Willkie" <johnwillkie@xxxxxxxxxxxxx>
- To: <opendtv@xxxxxxxxxxxxx>
- Date: Mon, 19 Jan 2009 22:09:20 -0800
Oops, correction.
M/P/H Harris was found to be better overall (aside from vhf) and better when
there was HDTV content in the transport stream. A-VSB seems to have been
better when a large portion of the transport stream was devoted to enhanced
services.
Makes sense, then that M/p/H was approved. I would also suggest reviewing
the IP declarations are here
http://www.atsc.org/policy_documents/patent_statements.php
John Willkie
-----Mensaje original-----
De: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] En
nombre de John Willkie
Enviado el: Monday, January 19, 2009 9:47 PM
Para: opendtv@xxxxxxxxxxxxx
Asunto: [opendtv] Re: Sixty-three TV stations to launch mobile DTV service
this year
Richard;
Have you read the IDOV report? From my recollection, A-VSB did better than
M/P/H, but the difference wasn't all that significant. Somehow, I don't
think that the OMVC decision for m/p/h was done entirely on technical
grounds. (The decision wasn't made by the ATSC, but by the OMVC.)
Heck, there isn't any professional equipment that will receive m/h. And, at
least some of the professional transmission gear appears to be vaporware at
this moment. I am not alluding to Harris. But, I've been googling, and a
friend of mine wanted to see the DTV Interactive transmission/test gear at
CES.
John Willkie
-----Mensaje original-----
De: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] En
nombre de Richard C. Ramsden
Enviado el: Monday, January 19, 2009 7:56 PM
Para: opendtv@xxxxxxxxxxxxx
Asunto: [opendtv] Re: Sixty-three TV stations to launch mobile DTV service
this year
M/H is within the current FCC rules. No approval req.
whatever-VSB failed. The one that was close was A-VSB. It could not
pass the required tests. M/H is the only technology that passed all the
conditions. The whatever-VSB patent holders lost a standards vote.
That IP is pretty much worthless. No recourse (unless you're Microsoft
and have a billion dollars to bribe people with).
Ok, I do work for Harris. But, I have nothing to do with transmission
standards.
There is NO existing consumer equipment that can receive M/H.
John Shutt wrote:
> John,
>
> Well, I guess it would have been better if I also silently assumed
> that FCC approval would be necessary for M/H to be implemented.
>
> My eyes glazed over reading the candidate standard, not having the
> background of you or Bert, but it seems to me that most of the 'secret
> sauce' is creating more training symbols by manipulating the R-S
> encoder, ala A-VSB, and using more FEC for the robust stream. (Plus
> the addition of TDM for low power receivers.) I'm sure that's overly
> simplistic but that's the best my layman's mind can do.
>
> Question: What implications are there for an "M/H aware" main service
> receiver (such as one built into a television or STB) to also use
> these additional training signals for enhanced echo cancellation of
> the main service? It would seem reasonable to me for a broadcaster to
> eventually use M/H simply to convey the additional training symbols
> for next-generation receivers to use, even if there is no actual M/H
> service transmitted.
>
> As for not requiring FCC action, I did note that Candidate Standard
> A/153 does a lot of populating of data fields labeled as "reserved" in
> A/53:2007. Data Field Sync is but one example. Also, Candidate
> Standard A/153 alludes to new uses for reserved A/65C fields. Would
> that practice not run afoul of A/53:2007 and A/65C, as adopted by the
> FCC?
>
> A/53:2007 defines reserved data bits as:
>
> "reserved: This term, when used in clauses defining the coded bit
> stream, indicates that the value may be used in the future for Digital
> Television Standard extensions. Unless otherwise specified within this
> Standard, all reserved bits shall be set to "1"."
>
> A/65C defines reserved fields as:
>
> "reserved - Fields in this PSIP Standard marked "reserved" shall not
> be assigned by the user, but shall be available for future use.
> Decoders are expected to disregard reserved fields for which no
> definition exists that is known to that unit. Each bit in the fields
> marked "reserved" shall be set to one until such time as it is defined
> and supported."
>
> In the eyes of the FCC, A/153 related PSIP fields would not be
> "defined and supported" until they adopt A/153, no?
>
> And E8-VSB, which is part of A/53:2007, also uses the null packet
> identifier PID to "hide" enhanced mode data from legacy receivers.
> Specifically:
>
> "For the purpose for maintaining strict backward compatibility for
> existing receivers, 188-byte packets that contain Enhanced encoded
> data are composed of a 0x47 Sync byte, followed by 3 bytes as defined
> by [1] that contain the null packet designation (PID = 0x1FFF), and
> the 184-byte enhanced segment[.]"
>
> Populating null packets with payloads other than those defined under
> A/53:2007's E8-VSB use may be in issue? I don't know.
>
> Small nits, to be sure, and there may be intellectual property
> concerns as well, unless the E8-VSB and A-VSB patent holders are on
> board with M/H.
>
> Thanks for the education, John.
>
> ----- Original Message ----- From: "John Willkie"
> <johnwillkie@xxxxxxxxxxxxx>
>
>> I read the assertion in the summer in a forum that forbids
>> participants from
>> disclosing communications or deliberations. I (silently) assumed the
>> person
>> was wrong, so I reviewed all the documents I had access to, in the state
>> they were in. I had to conclude that they were correct, and a few
>> nits have
>> been removed since then.
>
>
>
>
>
>
> ----------------------------------------------------------------------
> 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.
----------------------------------------------------------------------
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: