🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: uk.tech.digital-tv
Article #137

Re: Using an FM-Carrier for the Y [Luminance] Signal -- how to relieve the bandwidth issue?

#137
From: Green Xenon [Radium]
Date: Fri, 28 Sep 2007 00:11
122 lines
7797 bytes
On Sep 26, 2:03 pm, dpl...@radagast.org (Dave Platt) wrote in 
http://groups.google.com/group/uk.tech.digital-tv/msg/a9872fef8b5bfab4 :

 > In article <46faa23a$0$7443$4c368...@roadrunner.com>,
 > Green Xenon [Radium] <gluceg...@excite.com> wrote:

 > >QAM/multiple-level-QM/constellation-modulation are examples of exotic
 > >modulation techniques that allow you to
 > >transmit/receive the most amount
 > >of information while using the least amount of bandwidth. To further
 > >prevent excessive usage of bandwidth while maintaining signal
 > >efficiency, the baud should be no more than 1-symbol-per-second while
 > >the amounts of bits-per-symbol conveyed should be the most that is
 > >physically and mathematically-possible.

 > Mathematically, there's essentially no problem.  All you need to do is
 > use a symbol representation which has enough discrete states to carry
 > the desired amount of information.
 >
 > The problem here is "physically".  Your proposal is very far out
 > beyond the point of physical realizability.
 >
 > Video-grade luminance carries a lot of information.  Just for grins,
 > let's say that it's the equivalent of a megabit per second - you can
 > get tolerable video at that bit rate using MPEG-2 or MPEG-4
 > compression of typical images.  [An uncompressed/uncoded analog video
 > image requires a *lot* more bandwidth than this... maybe the
 > equivalent of 20-50 megabits per second?]
 >
 > So, if you want only one symbol per second (one baud) to keep the
 > bandwidth down, you have to be able to transmit 1 megabit of
 > information in that one symbol.  That requires that the symbol
 > representation include
 >
 >          1,000,000
 >         2
 >
 > different states.  That is, the sender has to be able to choose from
 > among 2-to-the-millionth-power different voltages or RF levels (or QAM
 > or other constellation states), and the recipient needs to be able to
 > successfully distinguish between all of these states in order to
 > recover the megabit of information.
 >
 > If you look at this in terms of the voltage being transmitted, it
 > means that the difference in voltage between any two adjacent states
 > must be large enough to be measured reliably.  That would mean that
 > the _maximum_ voltage needs to be 2-to-the-millionth times higher.
 >
 > If we want to ease the problem somewhat, we could use a QAM encoding,
 > with 2^1000 different amplitudes and 2^1000 different phases.
 >
 > Even if you do that, the signal resolution you need is incredibly far
 > beyond what's physically possible.  If you ran the entire system in a
 > bath of liquid helium (to keep the thermal noise level of all the
 > components down to a minimum), and you set the minimum voltage
 > difference between two states to something just barely above the
 > remaining thermal noise level ...
 >
 > ... then the maximum voltage level produced by your transmitter will
 > still be billions of billions of billions of billions times (billions
 > *of* billions, not billions *and* billions) higher. It wouldn't just
 > burn out the transmitter... it would (if physically realizable) blow
 > everything in the solar system into incandescent plasma as soon as you
 > turned it on.

Can�t the maximum voltage be set to be low enough not to cause any 
damage/injury to anyone/anything?

Also, couldn�t the temporal and spatial frequencies of the luminance 
signal be downshifted prior to QM conversion so that not so many bits 
are required?

It�s possible to downshift the frequencies of an audio signal without 
low-pass-filtering or changing the speed at which it is played-back. 
Couldn�t the equivalent be done with the temporal and spatial 
frequencies of a luminance signal?

 > >If the original luma is transmitted on an FM carrier, the resulting
 > >deviations in the frequency of the FM wave will be excessive. If the
 > >QAM/multiple-level-QM/constellation-modulation
 > >equivalent of the luma is
 > >transmitted, the resulting frequency-deviations will be significantly
 > >smaller and hence use a lot less bandwidth.

 > Don't bet on it.  Remember that the abrupt transitions between QAM
 > states create a sudden discontinuity in the signal... which introduces
 > higher-frequency components or sidebands in your encoded luma signal.
 > These luma sidebands, once FM-modulated onto the carrier, will cause
 > RF sidebands out quite some distance.  That's one of the gotchas of
 > FM... it creates sidebands which appear *further* away from the
 > carrier frequency than the maximum carrier deviation!
 >
 > In short, there's no free lunch.  For *any* given baseband signal
 > (straight, QAM-encoded, or whatever), an FM-modulated carrier will
 > *always* produce sidebands which go out as broadly as an AM carrier or
 > further, and will *never* take up less spectrum than an AM carrier
 > with the same baseband information.
 >
 > In other words, no matter what coding tricks you can think up to try
 > to make FM video narrower than AM, you'll lose, because you can apply
 > the same coding tricks to the input of an AM modulator.

Is there any thing that could be done to the QM signal so that the 
resulting FM sidebands won�t be excessive?

In an FM carrier, the neutral frequency results when there is no 
modulation signal. The FM carrier changes according to the modulator. If 
the modulator voltage it positive, the FM carrier�s frequency increases. 
When the modulator voltage becomes negative, the carrier�s frequency 
decreases. On a graph of the modulator signal, the x-axis is where the 
voltage is neutral. Above the x-axis, the voltage is positive. Below the 
x-axis, the voltage is negative. The further from the x-axis the voltage 
goes, the more broad the sidebands will be.

To prevent the sidebands from getting too broad, the QM signal needs to 
have all to voltages shifted closer to the x-axis. This means the device 
receiving the QM signals on the other end needs to be more sensitive to 
differences in voltages.

Thus it would help if the physical voltage difference between what is 
interpreted as 1 or 0 be much smaller. The smaller the change in 
voltage, the less extreme the resulting FM sidebands.
Technical Details
Message-ID: <46fc4458$0$16496$4c368faf@roadrunner.com>
Path: arc1-ca.pugleaf.net!g2news2.google.com!news2.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!nx01.iad01.newshosting.com!newshosting.com!post02.iad01!roadrunner.com!not-for-mail

Show Full Headers
Complete Article Headers
X-Google-Thread: f928c,9d8320c16fbdcf84
X-Google-Thread: 1133a5,9d8320c16fbdcf84
X-Google-Thread: 115947,9d8320c16fbdcf84
X-Google-Thread: 1118be,7e05cb8426dfb96
X-Google-Thread: ffcae,7e05cb8426dfb96
X-Google-Thread: 107cee,7e05cb8426dfb96
X-Google-Thread: f508e,9d8320c16fbdcf84
X-Google-Thread: f7d8a,9d8320c16fbdcf84
X-Google-Thread: fdad6,9d8320c16fbdcf84
X-Google-Attributes: gidf928c,gid1133a5,gid115947,gid1118be,gidffcae,gid107cee,gidf508e,gidf7d8a,gidfdad6,public,usenet
X-Google-Language: ENGLISH,CP1252
Path: arc1-ca.pugleaf.net!g2news2.google.com!news2.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!nx01.iad01.newshosting.com!newshosting.com!post02.iad01!roadrunner.com!not-for-mail
Date: Thu, 27 Sep 2007 17:11:39 -0700
From: "Green Xenon [Radium]" <glucegen1@excite.com>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b) Gecko/20050217
MIME-Version: 1.0
Newsgroups: uk.tech.digital-tv,rec.video.production,uk.media.tv.misc,sci.electronics.components,uk.tech.broadcast,sci.electronics.misc,aus.radio.broadcast,ba.broadcast,alt.radio.broadcasting
Subject: Re: Using an FM-Carrier for the Y [Luminance] Signal -- how to relieve
 the bandwidth issue?
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 122
Message-ID: <46fc4458$0$16496$4c368faf@roadrunner.com>
Organization: Road Runner High Speed Online http://www.rr.com
NNTP-Posting-Host: 75.84.20.87
X-Complaints-To: abuse@rr.com