[opendtv] Re: Forwarded on behalf of Bob Miller - 3 posts
- From: "Allen Le Roy Limberg" <allimberg@xxxxxxxxxxxx>
- To: <opendtv@xxxxxxxxxxxxx>
- Date: Mon, 15 May 2006 09:22:48 -0400
McDonald's technique requires no change from current standards, so legacy
receivers are unaffected. The fact that 8VSB symbols are pretty much
randomized allows signature analysis of blocks of 4000 to 5000 symbols for
determining dynamic echoes. Ordinary data are used to calculate channel
impulse response (CIR).
A-VSB, on the other hand, introduces known symbol sequences into the
auxiliary fields of selected data packets, which reduces the amount of data
that is usefully received by legacy DTV receivers and by robust DTV
receivers, as well.
Al
----- Original Message -----
From: "Tom Barry" <trbarry@xxxxxxxxxxx>
To: <opendtv@xxxxxxxxxxxxx>
Sent: Sunday, May 14, 2006 3:49 AM
Subject: [opendtv] Forwarded on behalf of Bob Miller - 3 posts
> Tom,
>
> I made these three post today and am getting bounce messages. I tried to
> re subscribe but Freelist says I am already subscribed. I wonder if
> others are having problems.
>
> Could you post these for me?
>
> Bob Miller
>
>
> Subject:
> Re: [opendtv] Re: Thomson readies solutions for U.S. Digital TV
> broadcast transition
> From:
> Bob Miller <bob@xxxxxxxxxx>
> Date:
> Sat, 13 May 2006 14:10:57 -0400
> To:
> opendtv@xxxxxxxxxxxxx
> Message-ID:
> <44662131.6030004@xxxxxxxxxx>
> User-Agent:
> Mozilla Thunderbird 1.0.6 (Windows/20050716)
> X-Accept-Language:
> en-us, en
> MIME-Version:
> 1.0
> References:
> <20060513012958.48597.qmail@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
> <000f01c676a1$dfdaaba0$b67c94ce@cq85e>
> In-Reply-To:
> <000f01c676a1$dfdaaba0$b67c94ce@cq85e>
> Content-Type:
> text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding:
> 7bit
>
> Allen Le Roy Limberg wrote:
>
> > A-8VSB has a number of proposed uses beyond trying to intrude a new
> and more
> > robust data pipeline into the ATSC 8VSB signal. A-8VSB introduces
known
> > symbols into the auxiliary fields of packets in the MPEG-2 transport
> stream.
> >
> > The trellis coding system in the original 8VSB signal standard does
> not have
> > predetermined parity bit at start of data fields. An aspect of A-VSB
is
> > solving this problem.
> > A-8VSB can also be used to insert known symbols periodically into data
> > fields to provide additional training signals for the adaptive
> equalizer to
> > improve performance under dynamic multipath conditions. I am unaware
> of any
> > effort having been made to determine whether this is better than four-
or
> > five-thousand-symbol signature analysis using DFT techniques for
handling
> > dynamic multipath, as proposed some years ago by Doug McDonald, the
> patent
> > for which should soon issue. Doug's technique does not chew up data
> > capacity or intrude into packet structure like A-8VSB would.
> >
> >
> But Doug's technique would make all current receivers obsolete, the
> ultimate sin, I believe. The saving grace for A-VSB is that while
> current receivers cannot receive the robust signal they can still
> receive the non robust signal. That is E-VSB and A-VSB both only
> obsolete part of the spectrum for current receivers while also throwing
> a chunk away not available to either current receivers or new fangled
> A-VSB receivers.
>
> > E-8VSB and A-8VSB have some similar problems in trying to intrude a
> new and
> > more robust data pipelines into windows in conventional
MPEG-2-compatible
> > data packets. There is over 10% overhead for the headers and R-S
parity
> > bytes of those packets. The systems were developed by receiver
> designers,
> > who pretty much ignored transmitter and broadcaster problems in
providing
> > the more robust data pipelines.
> >
> > The problems of how to assemble programs that combine ordinary MPEG-2
> data
> > and robust data have been ignored by the receiver designer types of
> > engineer. Little or no thought has been given to ad insertion,
switching
> > between local and remote sources of program material, etc.
> >
> > The transport stream multiplexers for both systems involve many, many
> data
> > packets. Providing suitable transport stream multiplexers is a
> formidable
> > impediment to transmitter design. Any practical robust transmission
> scheme
> > needs to replace small groups of data segments with chunks of robust
data
> > which chunks are independent of each other.
> >
> > The original request for proposals issued by ATSC had looked for a
> > backward-compatible robust transmission scheme that would "put training
> > wheels" on the existent 8VSB data packets. E-8VSB and A-8VSB do not
> beef up
> > the existent 8VSB data packets, but displace them with different
> independent
> > transmission schemes. So long as legacy receivers could continue to
> receive
> > the reduced number of remaining 8VSB data packets without disruption,
> many
> > pretended that the goal of backward-compatibility was met by a
> proposal such
> > as E-8VSB.
> >
> > E-8VSB cuts code rate to one half or one quarter of original 8VSB
> code rate.
> > This means that you cannot transmit 720p HDTV in robust format. Many
> then
> > pretended that transmitting just audio and maybe some critical data in
> > robust format was okay. The whole concept of transmitting robust data
> > independent of HDTV programming began to emerge when no proposal was
> made to
> > cut code rate less severely and accept whatever most improvement that
> would
> > be available to HDTV reception. The somewhat definite original
business
> > plan to gather more eyeballs for the principal broadcast was apparently
> > abandoned, and no definite new direction has been forthcoming from
ATSC.
> >
> > I had been looking at the original "training wheels" concept using
> half code
> > rate when Bert Manifredi commented that a (16, 8) linear block code
> seemed
> > like a lot of overkill on coding. Glenn Reitmeier at NBC advised that
> > broadcast engineers would be very reluctant to ever accept halved
> code rate,
> > even if legacy DTV receivers could usefully receive the robust
> > transmissions.
> >
> > It seems to me now that the original "training wheels" concept can be
> > implemented without a great deal of difficulty for 720p HDTV, by
reducing
> > 8VSB code rate only a third using (12, 8) linear block coding of each
> data
> > byte in the 207-byte Reed-Solomon codes. This means each pair of data
> > segments containing MPEG-2-compliant data packets is accompanied by a
> > segment of (12, 8) LBC parity bits. A transport stream multiplexer
that
> > opens holes for segments of parity bits is relatively easy to design.
> The
> > (12, 8) linear block coding can correct some data bytes, but also
locates
> > errors for the 207-byte Reed-Solomon codes. Error location permits
> the use
> > of a known alternative RS-decoding algorithm that doubles the
> > error-correcting capability of the (207, 187) RS codes to 20 bytes per
> > codeword. The (12, 8) linear block coding I have contemplated is Gray
> > coding followed by shortened (15, 11) Hamming coding followed by Gray
> > decoding, which would actually be implemented in ROM.
> >
> >
> And is this possible without throwing out all current receivers? Any
> "improvement" in 8-VSB that would obsolete current receivers is
> basically the same as a new modulation and if contemplated it seems that
> all possible modulations should be considered. If we are going to take
> the hit we might as well get the best. Obviously the new proposed
> improved 8-VSB would be considered on an equal and fair basis and if
> superior should be chosen.
>
> Bob Miller
>
> > Maybe someone can suggest better "training wheels" coding that
> reduces 8VSB
> > code rate only a third. But IMHO "training wheels" coding sure looks
> like a
> > more promising route to follow than trying to pack a new data stream
into
> > windows in MPEG-2 packets.
> >
> > Al Limberg
> >
> >
> >
>
>
>
>
> Subject:
> Re: [opendtv] Re: Thomson readies solutions for U.S. Digital TV
> broadcast transition
> From:
> Bob Miller <bob@xxxxxxxxxx>
> Date:
> Sat, 13 May 2006 17:10:33 -0400
> To:
> opendtv@xxxxxxxxxxxxx
> Message-ID:
> <44664B49.1050308@xxxxxxxxxx>
> User-Agent:
> Mozilla Thunderbird 1.0.6 (Windows/20050716)
> X-Accept-Language:
> en-us, en
> MIME-Version:
> 1.0
> References:
> <20060512191925.43995.qmail@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
> <00c301c675ff$f664cfb0$63eb0a23@JohnS>
> In-Reply-To:
> <00c301c675ff$f664cfb0$63eb0a23@JohnS>
> Content-Type:
> text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding:
> 7bit
>
> John Shutt wrote:
>
> > The drawback of E-VSB is that it doesn't directly address multipath.
> It lowers S/N for the robust stream, but doesn't lower multipath
> susceptibility.
> >
> > The core technology of A-VSB is that a fixed data pattern is
> dispersed before the R-S encoder and interleaver in such a way that it
> comes out of the transmitter as a contiguous block in a known pattern.
> This hunk of contiguous data can be used by a specially designed
> receiver as an extended series of training signals to better track
> dynamic multipath. Doing this requires control of the multiplexer, R-S
> encoder, data interleaver, and 8-VSB modulator as a unit, instead of
> separate building blocks.
> >
> > A-VSB also includes the 1/2 or 1/4 rate Turbo modes for
> portable/mobile use, that still eat away 2 or 4 standard bits for every
> robust bit as does E-8VSB. A-VSB also time slices the robust data, ala
> DVB-H, for lower battery consumption. The additional pseudo data
> training signals allow this.
> >
> > The neat thing is that new receivers can find the 120 newly created
> fixed data pattern "SRS" supplemental training signals per VSB frame for
> enhanced dynamic multipath tracking, while existing receivers simply
> ignore these otherwise meaningless data packets. You do pay a payload
> price, however, so the magic "19.4 for HD and not a bit less" means we
> can't use any of this.
> >
> > Hey, if we were able to do HD in 13.4 Mbps and mobile in 1.5 Mbps, we
> would have adopted DVB-T 6 years ago!
> >
> > John
> >
> Hey, we could do HD in less than 13.4 Mbps and SD in 1.5 Mbps six years
> ago. We proposed to do just that using ON2 and DVB-T. We were also
> proposing non real time delivery to always on receivers with large hard
> drives which could record all programming/data from one or two channels.
> Our basic premise was that storage cost would drop to almost nothing and
> that codecs like ON2's VP4 would continue to improve so we wanted to
> also use a chip like the Equator that would allow for changes.
>
> In 2002 when Aloha won most of the MSA spectrum for channels 54 and 59
> we suggested they use it to do the above which they derided since
> obviously their plan to use this spectrum for two way Internet was best.
> I suggested to them and all other owners of 54 and 59 that that was a
> very poor use of the spectrum, that they would discover that and in the
> end they or someone would use this spectrum to broadcast DTV or what
> would pass as DTV to mobile devices. Seems they have learned that lesson
> or part of it. Still believe that DVB-H is wrong and that DVB-T or T2
> will be the best modulation. Not that DVB-H users will fail but I have a
> problem with it since it seems designed to solve a problem, battery
> life, that is best addressed by other than modulation solutions. And it
> is cell phone centric which again is not the best or only market long
> term. Mobile/portable/fixed devices are the market. Of course in talking
> to Qualcomm and Verizon we emphasized cell phone.
>
> Using 700 MHz spectrum that you purchased for Internet access seems a
> bad idea to me then and now since I believed/believe that Congress and
> the FCC will be/are under incredible pressure from the success of WiFi
> to allocate more and more spectrum for the free use of wireless
> Internet. Viola they did/are and even now plan on allowing the use of
> unused DTV spectrum including that above 51 I presume for WiFi and its
> ilk. Lots of spectrum (45 Mbps in NYC or more?) and all for free while
> Aloha is trying to sell a premium service on purchased channels 54 and
> 59 (12 MHz). I suggested to them that they would get Iridiumed. So now
> they will demo digital TV for mobile devices. They are probably still
> just speculators hoping for someone to bite and have no intention to
> build out. Such a build out must be daunting to such a recent mobile DTV
> convert IMO.
>
> I still predict that broadcasters on channels below 51 will lobby for a
> change to a new modulation to be able to compete with mobile DTV
> operators. Can A-VSB efficiently use all 6 MHz to compete with such
> mobile operators? If OTA is only HD and a bit of simulcast on a robust
> channel it still dies IMO. Not the best use of this spectrum. Channels
> above 51 will out compete OTA below 52. Congress will sell off channels
> below 51. May take awhile. Just more waste of time and spectrum.
>
> Bob Miller
>
>
>
> Subject:
> Re: [opendtv] Re: Thomson readies solutions for U.S. Digital TV
> broadcast transition
> From:
> Bob Miller <bob@xxxxxxxxxx>
> Date:
> Sat, 13 May 2006 18:05:48 -0400
> To:
> opendtv@xxxxxxxxxxxxx
> Message-ID:
> <4466583C.8000907@xxxxxxxxxx>
> User-Agent:
> Mozilla Thunderbird 1.0.6 (Windows/20050716)
> X-Accept-Language:
> en-us, en
> MIME-Version:
> 1.0
> References:
> <20060513012958.48597.qmail@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
> In-Reply-To:
> <20060513012958.48597.qmail@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
> Content-Type:
> text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding:
> 7bit
>
> Richard Hollandsworth wrote:
>
> > The addition of more powerful coding, even it's simple data repeats,
> can't help but combat multipath....only a fraction of the bits need to
> be successfully received.
> > Antenna Diversity also can provide significant resistance to multipath.
> >
> > Although I share your displeasure with allocating much less than
> about 15-19 Mbps for HD channels,
> > in a couple years there will be a glut of (mosty UHF) transmitters
> looking for revenue streams.....
> > If the technology pans out, why wouldn't distribution of non-real
> time HD-DVD programs (ala Moviebeam) and real-time SD programs (ala
> USDTV) to simple indoor antennas via E-8VSB be viable alternatives???
> >
> >
> I will insert my rant here if you don't mind.
>
> Seems ironic that you assume a "glut" of UHF spectrum in the US while in
> DVB-T countries such as the UK an "ala USDTV" Freeview is still going
> bonkers with receiver sales actually accelerating from already very high
> numbers and UHF spectrum prices increasing logarithmically as pay
> channels go back to ad supported on Freeview and come off SKY.
>
> I know it is because we are so different that our OTA is virtually dead
> but sooner or later 8-VSB OTA DTV in the US will be competing with DVB-H
> and T and the truth will out. Mobile DTV using other modulations will
> grow faster than even what is happening in the UK and the demand for a
> change in modulation and codec for channels below 52 by broadcasters
> will come.
>
> Bob Miller
>
> > holl_ands
> >
> > ======================================
> > John Shutt <shuttj@xxxxxxxxx> wrote: The drawback of E-VSB is that it
> doesn't directly address multipath. It lowers S/N for the robust
> stream, but doesn't lower multipath susceptibility.
> >
> > The core technology of A-VSB is that a fixed data pattern is
> dispersed before the R-S encoder and interleaver in such a way that it
> comes out of the transmitter as a contiguous block in a known pattern.
> This hunk of contiguous data can be used by a specially designed
> receiver as an extended series of training signals to better track
> dynamic multipath. Doing this requires control of the multiplexer, R-S
> encoder, data interleaver, and 8-VSB modulator as a unit, instead of
> separate building blocks.
> >
> > A-VSB also includes the 1/2 or 1/4 rate Turbo modes for
> portable/mobile use, that still eat away 2 or 4 standard bits for every
> robust bit as does E-8VSB. A-VSB also time slices the robust data, ala
> DVB-H, for lower battery consumption. The additional pseudo data
> training signals allow this.
> >
> > The neat thing is that new receivers can find the 120 newly created
> fixed data pattern "SRS" supplemental training signals per VSB frame for
> enhanced dynamic multipath tracking, while existing receivers simply
> ignore these otherwise meaningless data packets. You do pay a payload
> price, however, so the magic "19.4 for HD and not a bit less" means we
> can't use any of this.
> >
> > Hey, if we were able to do HD in 13.4 Mbps and mobile in 1.5 Mbps, we
> would have adopted DVB-T 6 years ago!
> >
> > John
> >
>
>
>
>
>
> ----------------------------------------------------------------------
> 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: