Forums

your intuition: 16MHz MIPS for tri-band SSB Demod at 44.1 KHz???

Started by Rachel Kips July 7, 2008
Hi!  to expand on the subject briefly: I'm experimenting with mechanical
television a la Baird televisor.  I think it would be neat to encode
three channels of color (YIQ) into one audio channel.  I would like
to use a fairly cheap microcontroller for demodulation because I have
lots of experience with it (Atmel Atmega32).  

Thus far, SSB AM has been the most straightforward approach.  One of
its advantages is that I can place the Y channel in the highest
frequencies (e.g. from 8-22 KHz) and if intermediate equipment
is lossy, it will only mean a loss of high frequency data. 

However, as I meditate on my demodulation code, I'm starting to doubt whether
the chip can handle it.  e.g.  8*8->16 bit multiply requires two clock 
cycles.  How does comp.dsp estimate the likelihood of this working?

Any other recommendations for low cpu digital demod?  for example, 
Does it seem wasteful to have three channels of data?  Would I be
better off with e.g. quadrature modulation?  Which variations would
be most impervious to e.g. mp3 compression?  (e.g. QFSK, QPSK, QAM, etc.)
Which variations are most impervious to loss of response at high
frequencies?

Thanks guys.



 
Drop this idea.

VLV



Rachel Kips wrote:

> Hi! to expand on the subject briefly: I'm experimenting with mechanical > television a la Baird televisor. I think it would be neat to encode > three channels of color (YIQ) into one audio channel. I would like > to use a fairly cheap microcontroller for demodulation because I have > lots of experience with it (Atmel Atmega32). > > Thus far, SSB AM has been the most straightforward approach. One of > its advantages is that I can place the Y channel in the highest > frequencies (e.g. from 8-22 KHz) and if intermediate equipment > is lossy, it will only mean a loss of high frequency data. > > However, as I meditate on my demodulation code, I'm starting to doubt whether > the chip can handle it. e.g. 8*8->16 bit multiply requires two clock > cycles. How does comp.dsp estimate the likelihood of this working? > > Any other recommendations for low cpu digital demod? for example, > Does it seem wasteful to have three channels of data? Would I be > better off with e.g. quadrature modulation? Which variations would > be most impervious to e.g. mp3 compression? (e.g. QFSK, QPSK, QAM, etc.) > Which variations are most impervious to loss of response at high > frequencies? > > Thanks guys. >
Rachel Kips wrote:
> Hi! to expand on the subject briefly: I'm experimenting with mechanical > television a la Baird televisor. I think it would be neat to encode > three channels of color (YIQ) into one audio channel. I would like > to use a fairly cheap microcontroller for demodulation because I have > lots of experience with it (Atmel Atmega32). > > Thus far, SSB AM has been the most straightforward approach. One of > its advantages is that I can place the Y channel in the highest > frequencies (e.g. from 8-22 KHz) and if intermediate equipment > is lossy, it will only mean a loss of high frequency data. > > However, as I meditate on my demodulation code, I'm starting to doubt whether > the chip can handle it. e.g. 8*8->16 bit multiply requires two clock > cycles. How does comp.dsp estimate the likelihood of this working? > > Any other recommendations for low cpu digital demod? for example, > Does it seem wasteful to have three channels of data? Would I be > better off with e.g. quadrature modulation? Which variations would > be most impervious to e.g. mp3 compression? (e.g. QFSK, QPSK, QAM, etc.) > Which variations are most impervious to loss of response at high > frequencies? > > Thanks guys.
Clearly you're continuing some earlier thread that I wasn't monitoring. You may want to study the NTSC standard. Encode luminance on the magnitude, and chrominance on the phase. You'll need a phase reference (which NTSC and PAL video provide as a color burst). NTSC doesn't do it this way, but if you encode one output pixel per cycle of your color carrier, and your color carrier as an integer subharmonic of your sampling rate then your processing tasks get simpler. I _suspect_ that this will take less processor time than your three channels of SSB, but it may still take more processor than you have. Doing it with magnitude-phase like this does maximize your ability to do the decoding with sine demodulation, which will work quite well with an 8-bit sine look-up. Doing things in lock-step with the sampling rate will simplify the code, and hence reduce the required clocks per sample, tremendously. At this point you can only prototype an algorithm, do a cycle count of the code, and see if they fit. I strongly suspect that by jiggling your 'standard' at the same time that you optimize your code you'll come up with something that'll work, at least if you run it on hand-optimized assembly code. And certainly if you can get it working on an AVR, then someone can make it work from a PC and a sound card... -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" gives you just what it says. See details at http://www.wescottdesign.com/actfes/actfes.html
On Jul 8, 4:58 am, Tim Wescott <t...@seemywebsite.com> wrote:
> Rachel Kips wrote: > > Hi! to expand on the subject briefly: I'm experimenting with mechanical > > television a la Baird televisor. I think it would be neat to encode > > three channels of color (YIQ) into one audio channel. I would like > > to use a fairly cheap microcontroller for demodulation because I have > > lots of experience with it (Atmel Atmega32). > > > Thus far, SSB AM has been the most straightforward approach. One of > > its advantages is that I can place the Y channel in the highest > > frequencies (e.g. from 8-22 KHz) and if intermediate equipment > > is lossy, it will only mean a loss of high frequency data. > > > However, as I meditate on my demodulation code, I'm starting to doubt whether > > the chip can handle it. e.g. 8*8->16 bit multiply requires two clock > > cycles. How does comp.dsp estimate the likelihood of this working? > > > Any other recommendations for low cpu digital demod? for example, > > Does it seem wasteful to have three channels of data? Would I be > > better off with e.g. quadrature modulation? Which variations would > > be most impervious to e.g. mp3 compression? (e.g. QFSK, QPSK, QAM, etc.) > > Which variations are most impervious to loss of response at high > > frequencies? > > > Thanks guys. > > Clearly you're continuing some earlier thread that I wasn't monitoring. > > You may want to study the NTSC standard. Encode luminance on the
Forgive me - I am from Europe. I heard NTSC stands for never twice the same colour? Is this right? Isn't PAL German and therefore far superior? Hardy
HardySpicer wrote:
> On Jul 8, 4:58 am, Tim Wescott <t...@seemywebsite.com> wrote: >> Rachel Kips wrote: >>> Hi! to expand on the subject briefly: I'm experimenting with mechanical >>> television a la Baird televisor. I think it would be neat to encode >>> three channels of color (YIQ) into one audio channel. I would like >>> to use a fairly cheap microcontroller for demodulation because I have >>> lots of experience with it (Atmel Atmega32). >>> Thus far, SSB AM has been the most straightforward approach. One of >>> its advantages is that I can place the Y channel in the highest >>> frequencies (e.g. from 8-22 KHz) and if intermediate equipment >>> is lossy, it will only mean a loss of high frequency data. >>> However, as I meditate on my demodulation code, I'm starting to doubt whether >>> the chip can handle it. e.g. 8*8->16 bit multiply requires two clock >>> cycles. How does comp.dsp estimate the likelihood of this working? >>> Any other recommendations for low cpu digital demod? for example, >>> Does it seem wasteful to have three channels of data? Would I be >>> better off with e.g. quadrature modulation? Which variations would >>> be most impervious to e.g. mp3 compression? (e.g. QFSK, QPSK, QAM, etc.) >>> Which variations are most impervious to loss of response at high >>> frequencies? >>> Thanks guys. >> Clearly you're continuing some earlier thread that I wasn't monitoring. >> >> You may want to study the NTSC standard. Encode luminance on the > > Forgive me - I am from Europe. I heard NTSC stands for never twice the > same colour? Is this right? > Isn't PAL German and therefore far superior? >
PAL came about because the French and German engineers had to agree on something, and is therefore obscure _and_ complicated. PAL does a better job of rendering color, but it's harder to implement a system to the standard. NTSC makes it harder to render color, but it hit the market about 10 years earlier than PAL. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" gives you just what it says. See details at http://www.wescottdesign.com/actfes/actfes.html
HardySpicer wrote:
> On Jul 8, 4:58 am, Tim Wescott <t...@seemywebsite.com> wrote: >> Rachel Kips wrote: >>> Hi! to expand on the subject briefly: I'm experimenting with mechanical >>> television a la Baird televisor. I think it would be neat to encode >>> three channels of color (YIQ) into one audio channel. I would like >>> to use a fairly cheap microcontroller for demodulation because I have >>> lots of experience with it (Atmel Atmega32). >>> Thus far, SSB AM has been the most straightforward approach. One of >>> its advantages is that I can place the Y channel in the highest >>> frequencies (e.g. from 8-22 KHz) and if intermediate equipment >>> is lossy, it will only mean a loss of high frequency data. >>> However, as I meditate on my demodulation code, I'm starting to doubt whether >>> the chip can handle it. e.g. 8*8->16 bit multiply requires two clock >>> cycles. How does comp.dsp estimate the likelihood of this working? >>> Any other recommendations for low cpu digital demod? for example, >>> Does it seem wasteful to have three channels of data? Would I be >>> better off with e.g. quadrature modulation? Which variations would >>> be most impervious to e.g. mp3 compression? (e.g. QFSK, QPSK, QAM, etc.) >>> Which variations are most impervious to loss of response at high >>> frequencies? >>> Thanks guys. >> Clearly you're continuing some earlier thread that I wasn't monitoring. >> >> You may want to study the NTSC standard. Encode luminance on the > > Forgive me - I am from Europe. I heard NTSC stands for never twice the > same colour? Is this right? > Isn't PAL German and therefore far superior?
You left out SECAM. NTSC stands for National Television Standards Committee, the body that defined the standard. PAL stands for Phase Alternation Line. Under it, the meaning of the phase-sensitive color information is inverted from line to line so that a steady phase error is canceled on the average over two lines. By the time the standard was implemented, receiver phase errors were so small that it didn't matter. The superior quality of PAL lies in the greater number of lines and consequent greater bandwidth dedicated to a single channel. The broadcast TV band supports more channels under NTSC than under PAL. Engineering involves tradeoffs. Why do you think that whatever is German is better? Herrenvolk? Jerry -- Engineering is the art of making what you want from things you can get. &#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;