Having looked through countless websites and books, I've learnt loads,
but not what i'm looking for: An algorithm for AM demodulation...  Can
anyone help?

Steve wrote:
> Having looked through countless websites and books, I've learnt loads,
> but not what i'm looking for: An algorithm for AM demodulation...  Can
> anyone help?

demodulation


output =3D lowpass filter ( abs (input) )


Ren=E9

Or

output = sqrt(input^2+HilbertTransform^2(input))

or same as above but with some aproximation of the sqrt(a^2+b^2)

Michal
"Ren�" <username@fel.nl> p�se v diskusn�m pr�spevku news:3f82961f$1@cs1...
Steve wrote:
> Having looked through countless websites and books, I've learnt loads,
> but not what i'm looking for: An algorithm for AM demodulation...  Can
> anyone help?

demodulation


output = lowpass filter ( abs (input) )


Ren�

Ren� <username@fel.nl> wrote in message news:<3f82961f$1@cs1>...
> Steve wrote:
> > Having looked through countless websites and books, I've learnt loads,
> > but not what i'm looking for: An algorithm for AM demodulation...  Can
> > anyone help?
> 
> demodulation
> 
> 
> output = lowpass filter ( abs (input) )
> 
>

This stuff doesn't exactly come naturally to me...
All i have at the mo is a list of numbers, a sampled signal... how do
i get the above to work on a list of numbers? Can anyone point me in
the direction of a C implementation of the above or any other type of
AM demodulation??

p.s. i think in C not maths!! i study for uni maths exams by
converting it all to C and running the program....so if you need to
mention a hilbert trasform can ya give it in C !!!

Hi Steve : when you say sampled , how was it sampled? Is this list a set of
complex numbers or real numbers and what's the spacing between the samples?
Best of Luck - Mike

"Steve" <steven.fox@nuigalway.ie> wrote in message
news:28ce72ef.0310080335.389fd21e@posting.google.com...
> Ren� <username@fel.nl> wrote in message news:<3f82961f$1@cs1>...
> > Steve wrote:
> > > Having looked through countless websites and books, I've learnt loads,
> > > but not what i'm looking for: An algorithm for AM demodulation...  Can
> > > anyone help?
> >
> > demodulation
> >
> >
> > output = lowpass filter ( abs (input) )
> >
> >
>
> This stuff doesn't exactly come naturally to me...
> All i have at the mo is a list of numbers, a sampled signal... how do
> i get the above to work on a list of numbers? Can anyone point me in
> the direction of a C implementation of the above or any other type of
> AM demodulation??
>
> p.s. i think in C not maths!! i study for uni maths exams by
> converting it all to C and running the program....so if you need to
> mention a hilbert trasform can ya give it in C !!!

steven.fox@nuigalway.ie (Steve) wrote in message news:<28ce72ef.0310080335.389fd21e@posting.google.com>...

> p.s. i think in C not maths!! i study for uni maths exams by
> converting it all to C and running the program....so if you need to
> mention a hilbert trasform can ya give it in C !!!

Hmmm... I have two objections 'bout that: First, you rely *way* too much on 
other people's goodwill. Asking for help with your own code is one thing, 
asking someone else to code your stuff up for you is quite another. What 
if I or someone else gave you a code littered with bugs? If you don't know 
why and how the code is supposed to work, you're lost.

Second, DSP relies on maths. If you have problems with the maths, people 
around here are willing to help. Now, I prefer that people at least make 
an effort on their own part. The maths can be tricky at times, but that's
a part of DSP. For better or for worse.

Rune

Rune,

I second your whole e-mail. It seems that people who can spell DSP think
they can do it. What you end up with is code that never worked right in the
first place, and no one knows to fix it.

I worked for a while at a major defense contractor that was working with 10
year old DSP code. No one left understood the DSP code, they just got
follow-on contracts to make more copies run and to improve the GUI.  They
should have made the DSP code work right. Amazingly, since the customer was
dumb and happy, the contractor was not real interested in fixing the code to
improve performance or even in bringing it to the customer's attention.
What a shame.

Steve, if you don't do math, you sure as hell don't do DSP.

Dirk

Dirk A. Bell
DSP Consultant


"Rune Allnor" <allnor@tele.ntnu.no> wrote in message
news:f56893ae.0310081215.ce60b75@posting.google.com...
> steven.fox@nuigalway.ie (Steve) wrote in message
news:<28ce72ef.0310080335.389fd21e@posting.google.com>...
>
> > p.s. i think in C not maths!! i study for uni maths exams by
> > converting it all to C and running the program....so if you need to
> > mention a hilbert trasform can ya give it in C !!!
>
> Hmmm... I have two objections 'bout that: First, you rely *way* too much
on
> other people's goodwill. Asking for help with your own code is one thing,
> asking someone else to code your stuff up for you is quite another. What
> if I or someone else gave you a code littered with bugs? If you don't know
> why and how the code is supposed to work, you're lost.
>
> Second, DSP relies on maths. If you have problems with the maths, people
> around here are willing to help. Now, I prefer that people at least make
> an effort on their own part. The maths can be tricky at times, but that's
> a part of DSP. For better or for worse.
>
> Rune

Steve wrote:
> Ren� <username@fel.nl> wrote in message news:<3f82961f$1@cs1>...
> 
>>Steve wrote:
>>
>>>Having looked through countless websites and books, I've learnt loads,
>>>but not what i'm looking for: An algorithm for AM demodulation...  Can
>>>anyone help?
>>
>>demodulation
>>
>>
>>output = lowpass filter ( abs (input) )
>>
>>
> 
> 
> This stuff doesn't exactly come naturally to me...
> All i have at the mo is a list of numbers, a sampled signal... how do
> i get the above to work on a list of numbers? Can anyone point me in
> the direction of a C implementation of the above or any other type of
> AM demodulation??
> 
> p.s. i think in C not maths!! i study for uni maths exams by
> converting it all to C and running the program....so if you need to
> mention a hilbert trasform can ya give it in C !!!

If you know the math well enough to translate it -- correctly -- to C, 
you don't need much help with DSP. Just translate the detector equations 
to C and voila!

You need the Hilbert transformer only if the carrier isn't sufficiently 
oversampled. There are other ways even then. One is to stuff between the 
samples with zeros, then filter the result so that it represents no 
frequencies that the original sampling frequency won't support. The 
result will be suitable for demodulating by Lowpass(average(absval))) 
because there are sure to be enough points near the peak of the carrier.

The computation may actually tale a little longer than the Hilbert 
method that Kvasnicka described, but the concepts are simpler.

Now get busy translating.

Jerry
-- 
"I view the progress of science as ... the slow erosion of the
  tendency to dichotomize."                    Barbara Smuts, U. Mich.
���������������������������������������������������������������������

"Dirk Bell" <dirkman@erols.com> wrote in message news:<bm215t$np$1@bob.news.rcn.net>...

> I worked for a while at a major defense contractor that was working with 10
> year old DSP code. No one left understood the DSP code, they just got
> follow-on contracts to make more copies run and to improve the GUI.  They
> should have made the DSP code work right. Amazingly, since the customer was
> dumb and happy, the contractor was not real interested in fixing the code to
> improve performance or even in bringing it to the customer's attention.
> What a shame.

<shudder> Those projects are the worst, aren't they... since the project 
makes little if any sense in the first place, just about anything goes, 
which means that just about anyone can make a "contribution"... not a place
for skilled people to be. The trick is to recognize those things as early 
as possible and then get the hell out of there.

As for old code, I am not unfamiliar with code written in relatively 
arcane programming languages (Fortran 66), comprising some 100 variable 
names like "bca", "ycc", "gwack" and the likes (that version of fortran 
had a 6 (8?) character limit on variable names), and where the only 
"documentation" of the code was a two-page prosaic text that only vaugely 
mentioned the basic concept the code was based on, and then only in the 
most general terms. 

I think it should be outlawed to express any opinions whatsoever about 
computer programming, until one have tried to modify or maintain (or even 
compile) that kind of code.

Rune

Dirk Bell wrote:
> 
> I worked for a while at a major defense contractor that was working with 10
> year old DSP code. No one left understood the DSP code, they just got
> follow-on contracts to make more copies run and to improve the GUI.  They
> should have made the DSP code work right. Amazingly, since the customer was
> dumb and happy, the contractor was not real interested in fixing the code to
> improve performance or even in bringing it to the customer's attention.
> What a shame.
> 

That is life. Once ago I had the experience similar to yours. I tried to
change the things and I only learned three lessons out of it: 

1. Nobody cares what is inside as long as the overall product
performance is satisfactory. 
2. If the damn thing works somehow, leave it alone.
3. You are not going to gain much for yourself by trying to improve
somebody's lousy piece of work.
 
Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

http://www.abvolt.com

Vladimir Vassilevsky wrote:

> 
> Dirk Bell wrote:
> 
>>I worked for a while at a major defense contractor that was working with 10
>>year old DSP code. No one left understood the DSP code, they just got
>>follow-on contracts to make more copies run and to improve the GUI.  They
>>should have made the DSP code work right. Amazingly, since the customer was
>>dumb and happy, the contractor was not real interested in fixing the code to
>>improve performance or even in bringing it to the customer's attention.
>>What a shame.
>>
> 
> 
> That is life. Once ago I had the experience similar to yours. I tried to
> change the things and I only learned three lessons out of it: 
> 
> 1. Nobody cares what is inside as long as the overall product
> performance is satisfactory. 
> 2. If the damn thing works somehow, leave it alone.
> 3. You are not going to gain much for yourself by trying to improve
> somebody's lousy piece of work.
>  
> Vladimir Vassilevsky
> 
> DSP and Mixed Signal Design Consultant
> 
> http://www.abvolt.com

Actually, succeeding can hurt. While I was in personnel filling out 
papers on the first day in a new job, my boss, his right-hand man, and 
the owner were conferring about running out of ROM room with feature 
creep. A new feature had put them over the top in an 8-K chip, going to 
16 K was an unhappy thought, and there it was. My boss had squeezed out 
all he could, but the code was still six bytes too big. He proposed 
eliminating a seldom-used feature, but that was vetoed. Modifying the 
board to take a bigger ROM was expensive; lots of units were in the 
field. The owner made an unpopular decision: "There's someone new coming 
on board. Let him have a go at the code before we decide."

I knew none of the background. My new boss simply asked me to shrink the 
code as much as I could. I was new to the 8031, but it's a simple if 
ugly machine. By the end of the day, it was comfortable, and I wrote a 
thread tracker -- what in Forth would be called the inner interpreter -- 
that worked, then proceeded to factor the code. I had to get a feel for 
it overall, so nothing much good happened at first (which pleased my 
boss, but he didn't say so). Then it all came in a rush. After five full 
working days, I had enough to report progress and ask for guidance on 
how hard to compress; I had reached what I thought was the point of 
diminishing returns. (We had this conversation in the owner's office. I 
learned later that my boss wanted him to hear first hand how little 
could be done.) I was told that there were at least 200 bytes to be 
shoehorned in if possible, and congratulated on my having found the six 
bytes needed. I reminded my boss that he had instructed me to shrink the 
code as much as possible. There was now, even with the new feature, just 
short of 1 K to spare. I didn't get along with the boss after that.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

Jerry Avins <jya@ieee.org> wrote in message news:<bm748b$c59$1@bob.news.rcn.net>...
> Actually, succeeding can hurt. 

It sure can. For reasons unclear to me, I apparently had gained a
reputation as some sort of "signal processing wizard" amongst the 
people around me when I wrote that PhD thesis of mine. As I have 
commented upon before, I never did anything I don't expect any 
other DSP engineer to be able to if given similar time and resources.

Anyway, after my dissertation I have not been able to find a decent, 
workable project. All those more or less weird things, based more on 
wishful thinking than anything else, seem to come my way. "If anyone 
can do it, Rune can." I am not sure if I ever heard it spoken out, but 
it seems to be the general attitude. It's not fun when I have to tell 
people that I'm only an engineer who uses the rules of maths and physics, 
and not some sort of sorcerer. 

Rune

Rune Allnor wrote:

>                                     ... It's not fun when I have to tell 
> people that I'm only an engineer who uses the rules of maths and physics, 
> and not some sort of sorcerer. 
> 
> Rune

But aren't those the same thing? Many think so!

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

Jerry Avins <jya@ieee.org> wrote in message news:<bmamiu$e2d$3@bob.news.rcn.net>...
> Rune Allnor wrote:
> 
> >                                     ... It's not fun when I have to tell 
> > people that I'm only an engineer who uses the rules of maths and physics, 
> > and not some sort of sorcerer. 
> > 
> > Rune
> 
> But aren't those the same thing? Many think so!

Unfortunately, you're right. The scary thing is *where* I find these 
kinds of thoughts:

- The 40+ years (of experience) senior scientist who wanted to specify
  "60 degrees phase lag between the 20 Hz component and the 80 Hz component"
  in a steady-state multiple-lines narrow-band source. I managed to wave 
  that one off.

- The 10+ years (of experience) seismic processor who found the sound 
  velocity in the bedrock *immediately below* a high-velocity geologic 
  layer by means of refraction seismics. A trivial property of such analysis 
  is that the sound speed must be strictly *increasing* with depth. I found 
  a possible explanation for this measurement which, if correct, could be 
  the key to understand the acoustics of that whole geographical region.

- The head of the Sig Proc department at an international research facility 
  who asked me why I bothered with all that high-res analysis when a 
  simple zero-padding + FFT of my data would resolve the features I was
  looking for. I was very glad *not* to be offered a job on that facility 
  after that meeting.

- The internationally renowned scientist who did not understand why I was 
  so conserned about symmetry properties in the 2D DFT since "it's only 
  the positive frequencies that go into the inverse transform". I was 
  very cautious in how I read his journal articles after that.

- The scientist who was overly concerned about not being able to make 
  computational models that were able to generate as strong Rayleigh waves
  (ground roll) as measured in real life, when analyzing the muzzle blast 
  of heavy artillery. I knew the Rayleigh waves well enough to see other 
  possible excitation mechanisms in that experimental setup. No basic text 
  on Rayleigh waves fail to mention these excitation mechanisms.

- The 40+ years (of experience) scientist who asked for my array processing 
  codes for analyzing arrays with logarithmic element spacing. "If you can't 
  give it out, I'll just pick equidistant elements in the array and use 
  standard FFTs". Anyone are free to try to pick an equidistant subsequence
  of three or more elements out of a series that goes as

    D_n = D_0*K^(n-1)      n=1,2, 3,...

  where K =/= 1.

All these are different people at different facilities, but make mistakes 
I find utterly trivial. "Why bother?" you may ask, "Everybody make mistakes. 
It's not unheard of that even a certain Rune comes with corrections to his 
own posts on comp.dsp". Well, it's a consistent pattern: People who really 
should know better make the most trivial mistakes. The real problem, though, 
is that they evidently are not open to neither accept the mistakes or 
correct them. 

I can only guess, but what I think I may be doing differently that these 
people (that may explain my ridicilous "wizard" reputation), is paying 
attention to detail. To not take anything for granted, not accept something 
as "easy" or "irrelevant" until I've cheked things out. To try to think the 
problem through. To try to find out what others have tried and how those 
attempts went.

But that's what basic engineering training is all about, isn't it?

Rune

Jerry Avins <jya@ieee.org> wrote in message news:<bmamiu$e2d$3@bob.news.rcn.net>...
> Rune Allnor wrote:
> 
> >                                     ... It's not fun when I have to tell 
> > people that I'm only an engineer who uses the rules of maths and physics, 
> > and not some sort of sorcerer. 
> > 
> > Rune
> 
> But aren't those the same thing? Many think so!

Unfortunately, you're right. The scary thing is *where* I find these 
kinds of thoughts:

- The 40+ years (of experience) senior scientist who wanted to specify
  "60 degrees phase lag between the 20 Hz component and the 80 Hz component"
  in a steady-state multiple-lines narrow-band source. I managed to wave 
  that one off.

- The 10+ years (of experience) seismic processor who found the sound 
  velocity in the bedrock *immediately below* a high-velocity geologic 
  layer by means of refraction seismics. A trivial property of such analysis 
  is that the sound speed must be strictly *increasing* with depth. I found 
  a possible explanation for this measurement which, if correct, could be 
  the key to understand the acoustics of that whole geographical region.

- The head of the Sig Proc department at an international research facility 
  who asked me why I bothered with all that high-res analysis when a 
  simple zero-padding + FFT of my data would resolve the features I was
  looking for. I was very glad *not* to be offered a job on that facility 
  after that meeting.

- The internationally renowned scientist who did not understand why I was 
  so conserned about symmetry properties in the 2D DFT since "it's only 
  the positive frequencies that go into the inverse transform". I was 
  very cautious in how I read his journal articles after that.

- The scientist who was overly concerned about not being able to make 
  computational models that were able to generate as strong Rayleigh waves
  (ground roll) as measured in real life, when analyzing the muzzle blast 
  of heavy artillery. I knew the Rayleigh waves well enough to see other 
  possible excitation mechanisms in that experimental setup. No basic text 
  on Rayleigh waves fail to mention these excitation mechanisms.

- The 40+ years (of experience) scientist who asked for my array processing 
  codes for analyzing arrays with logarithmic element spacing. "If you can't 
  give it out, I'll just pick equidistant elements in the array and use 
  standard FFTs". Anyone are free to try to pick an equidistant subsequence
  of three or more elements out of a series that goes as

    D_n = D_0*K^(n-1)      n=1,2, 3,...

  where K =/= 1.

All these are different people at different facilities, but make mistakes 
I find utterly trivial. "Why bother?" you may ask, "Everybody make mistakes. 
It's not unheard of that even a certain Rune comes with corrections to his 
own posts on comp.dsp". Well, it's a consistent pattern: People who really 
should know better make the most trivial mistakes. The real problem, though, 
is that they evidently are not open to neither accept the mistakes or 
correct them. 

I can only guess, but what I think I may be doing differently that these 
people (that may explain my ridicilous "wizard" reputation), is paying 
attention to detail. To not take anything for granted, not accept something 
as "easy" or "irrelevant" until I've cheked things out. To try to think the 
problem through. To try to find out what others have tried and how those 
attempts went.

But that's what basic engineering training is all about, isn't it?

Rune

Rune Allnor wrote:

> Jerry Avins <jya@ieee.org> wrote in message news:<bmamiu$e2d$3@bob.news.rcn.net>...
> 
>>Rune Allnor wrote:
>>
>>
>>>                                    ... It's not fun when I have to tell 
>>>people that I'm only an engineer who uses the rules of maths and physics, 
>>>and not some sort of sorcerer. 
>>>
>>>Rune
>>
>>But aren't those the same thing? Many think so!
> 
> 
> Unfortunately, you're right. The scary thing is *where* I find these 
> kinds of thoughts:
> 
> - The 40+ years (of experience) senior scientist who wanted to specify
>   "60 degrees phase lag between the 20 Hz component and the 80 Hz component"
>   in a steady-state multiple-lines narrow-band source. I managed to wave 
>   that one off.
>

[more scary stories]

> 
> I can only guess, but what I think I may be doing differently that these 
> people (that may explain my ridicilous "wizard" reputation), is paying 
> attention to detail. To not take anything for granted, not accept something 
> as "easy" or "irrelevant" until I've cheked things out. To try to think the 
> problem through. To try to find out what others have tried and how those 
> attempts went.
> 
> But that's what basic engineering training is all about, isn't it?
> 
> Rune

Maybe we need to be wizards to get it right, but I think all it takes is 
recognizing how east it is to be wrong, and finding error embarrassing 
if not shameful (depending on circumstances). I visited friends last 
night who anxiously awaited my arrival because the CD player wouldn't 
work. The drawer wouldn't stay closed. Why me? I had never seen the 
thing. Of course, I fixed it easily. The TV remote was lying next to the 
player and stuck on. Moving it out of the way so I had more room to peek 
was all the fix needed. Do they believe I fixed it by accident? Of 
course not. I went to high school with these people, and they know me to 
have been doing that sort if thing for a long time.

Once I walked into a room filled with strangers, and was immediately 
accosted: "You're an electrical engineer. Please fix the television." I 
did. I replaces the battery in the remote with the cells in my pocket 
flashlight. If course I carry a flashlight; don't you?

Get used to it. By the standards of most of the boobs out there, doctors 
(of all fields), lawyers, CEOs, you ARE a wizard. Grin and bear it.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

Jerry Avins <jya@ieee.org> wrote in message news:<bmbq5f$fs9$1@bob.news.rcn.net>...

> Once I walked into a room filled with strangers, and was immediately 
> accosted: "You're an electrical engineer. Please fix the television." I 
> did. I replaces the battery in the remote with the cells in my pocket 
> flashlight. If course I carry a flashlight; don't you?

In winter, yes. The pockets in my winter coats are large enough to hold
the flashlight as well as the drawing pad and my pencils. My summer jackets
only have room for the drawing kit. And where I am there's the midnight 
sun during summer, so I don't need the flashlight...

Rune

Jerry Avins <jya@ieee.org> wrote in message news:<bmbq5f$fs9$1@bob.news.rcn.net>...

> Once I walked into a room filled with strangers, and was immediately 
> accosted: "You're an electrical engineer. Please fix the television." I 
> did. I replaces the battery in the remote with the cells in my pocket 
> flashlight. If course I carry a flashlight; don't you?

In winter, yes. The pockets in my winter coats are large enough to hold
the flashlight as well as the drawing pad and my pencils. My summer jackets
only have room for the drawing kit. And where I am there's the midnight 
sun during summer, so I don't need the flashlight...

Rune

Rune Allnor wrote:

> Jerry Avins <jya@ieee.org> wrote in message news:<bmbq5f$fs9$1@bob.news.rcn.net>...
> 
> 
>>Once I walked into a room filled with strangers, and was immediately 
>>accosted: "You're an electrical engineer. Please fix the television." I 
>>did. I replaces the battery in the remote with the cells in my pocket 
>>flashlight. If course I carry a flashlight; don't you?
> 
> 
> In winter, yes. The pockets in my winter coats are large enough to hold
> the flashlight as well as the drawing pad and my pencils. My summer jackets
> only have room for the drawing kit. And where I am there's the midnight 
> sun during summer, so I don't need the flashlight...
> 
> Rune

I use my penlight mostly for looking into and under things, although it 
was handy down in the depths of Mammoth Cave when a storm knocked out 
the electricity powering the lights*.

Jerry
_________________________________________
* Before anyone asks, the guides all had flashlights, but we were strung 
out in a narrow serpentine passage, and no light from either end of the 
line came to us near the middle. The little light saved a claustrophobic 
mother from freaking out in front of her pre-teen son.
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

Ren� wrote:

> Steve wrote:
> > Having looked through countless websites and books, I've learnt loads,
> > but not what i'm looking for: An algorithm for AM demodulation...  Can
> > anyone help?
>
> demodulation
>
> output = lowpass filter ( abs (input) )
>
> Ren�

A better way is to recover the original carrier and multiply it back into
the AM and then lowpas filter.
This is so-called synchronous demodulation.To recover the carrier you could
use a PLL or more crudely a hard limiter but the hard limiter is not a great
idea at low SNRs.


Tom

> ... AM demodulation algorithm ... 


Do a google search on "satellite_seminar.pdf."  There will be two
sites that come up.  Click on the princeton site which will download
the pdf document.  Look on page 16 of that pdf document for an AM
demodulation algorithm.  Look on page 17 for a JAVA implementation.

This algorithm works fine, because I have used it; however, you must
consider 1) the input audio signal format to be demodulated and 2) the
sample rate that you demodulate.  Otherwise, your picture will look
like random garbage.

To briefly explain ...
1) I used an 8 bit WAV file to record the weather satellite audio
signal, so I had to subtract 127 from the WAV data before I applied
the AM demodulation algorithm.
2) each line has a visible image and an IR image.  You must consider
your sample rate because you will want to toss some data; otherwise,
your image will be slanted.

After you get this working, you will probably want to use wxsat.

By the way, you really should try to understand the math!  

Ken