Amplitude modulation in scilab

usp=sharing

usp=sharing

usp=sharing

usp=sharing

Start by making sure that you have an integer number of cycles in each signal. If everything is evenly divisible by 10kHz, then a 10us interval should work, assuming sufficient sampling rates.

So I know I'm going to get a bunch of those "Get a DSP book". But since I'm going to be working on an AM radio, I decided I would like to understand the mixing process better and demonstrate it in software in a burn before you learn way.

with both sampling rate and and found the results quite interesting.

domain, but I expected them to have equal amplitudes. I assume the decreasing amplitude is an artifact of the low sampling rate.

account for memory shortage, I got what I wanted. 58 sin waves with equal amplitude.

start getting more noise in the amplitudes of the sin waves. For example here with a time of 100 us.

even at only half the previous time window 50 us and even with a 400M samples per second rate, much higher than nyquist.

to study further. One possibility with relatively short time windows is that you don't have enough time to capture all the information in the signal that it can't yet be approximated with a sin wave in the discreet domain. Another possibility is that may be there has to be some relation that needs to be maintained between time window and sampling rate. Don't know.

Yes, it's a "windowing" issue. A short observation of a sine wave chops up cycles and makes the FFT erratic, and essentially broadens the apparent spectral lines. One fix is to just observe the waveform over many, many cycles, lots of samples. Another thing to do is apply a "windowing function" that tapers off the amplitudes at both ends of the sample set, to avoid abrupt chopping of the sinewaves; that helps some. But to get repeatable, narrow spectral lines you need a long observation period.

google "fft windowing"

then another step of down-conversion and demodulation. I have no idea how to do digital filtering in scilab yet but I'll find out.

hints.

Why not post it to this newsgroup, instead of that Javascript ridden hell?

You are absolutely right. I will look into some other alternative that shares files as files.

Here is the code:

/////////////////////// // Program Constants

start_freq = 550e3; // starting frquency = 550 kHz end_freq = 1700e3; // end frequency = 1700 kHz freq_spacing = 20e3; // channel spacing = 20 kHz t_end = 1e-2; // last time sample = 10 us amplitude = 1; sample_rate = 4e6; random_phase = 1; fftplot = 1; nf = 20000 // number of frequency samples to plot

///////////////////////

// create time variable

time = 0:1/sample_rate:t_end; szt = size(time, '*');

// create station frequencies spaced by 20khz frq = start_freq:freq_spacing:end_freq; // transpose frq = frq'; szf = size(frq, '*');

//phase = (2*%pi/szf):(2*%pi/szf):2*%pi; phase = 2*%pi*rand(1,szf); phase = phase' phase_matrix = random_phase*phase*ones(1,szt);

// time frequency matrix, one row for each frequency and time is in columns time_freq = amplitude*sin((2*%pi*frq*time)+phase_matrix);

// sum all the sinusoids composite = sum(time_freq,:);

// Now calculate and plot FFT if fftplot then N = szt; y = fft(composite); f=sample_rate*(0:(N/2))/N; n=size(f,'*'); clf() if nf=0 then nf = n end plot(f(1:nf),abs(y(1:nf))) end

//////////////////////////////////////////////////

Thanks.

Unfortunately it runs my scilab out of memory. I'll see whether I can translate it into octave code.

hell?

Well, not everybody here has scilab. It does not help much for a google grouper trying to post graphics.

Fred, if you want a wake up call try scilab.org itself with a recent version of firefox.

Reccomendation for M. Hamed, get pan (news client and email client) and use eternal-september for free posting. I think that they do carry alt.binaries.schematic.electronic (abse or a.b.s.e in common parlance).

?-)

I hardly ever use scilab, preferring octave, mainly because it makes a better fist of running matlab stuff. What I asked for wasn't graphics, but scilab code, ie. text.

No thanks, I climbed off the upgrade bandwagon aeons ago. Too many dependency changes.

Seconded.

I'm currently trying to go through "The scientist and engineer's guide to d sp". Most of these DSP books try to include very little mathematics and I f eel this takes away from my understanding. I am thinking I should go for a Signals and Systems book for a better groundwork then move to DSP (except t hat it takes a long time this way :( ).

Back in my school days we had a Signal Analysis course and the book was Sig nal Analysis by Papoulis. It was a bit difficult to follow back then but it would probably be easier now. Can't find a good copy though.

I'm not sure what the standard bible would be nowadays for Signal Analysis books.

Thanks. I'll check it out.

hell?

google

OK.

So not the point i wanted to make, that site is a script and cookie laden hell. I quit instead of getting a download.

and

parlance).

the

everything

to dsp". Most of these DSP books try to include very little mathematics and I feel this takes away from my understanding. I am thinking I should go for a Signals and Systems book for a better groundwork then move to DSP (except that it takes a long time this way :( ).

And you are correct on the low math aspect. Perhaps taking a senior or graduate level course at a local uni or online would appropriate.

Signal Analysis by Papoulis. It was a bit difficult to follow back then but it would probably be easier now. Can't find a good copy though.

Search engines are your friend. Is this the book you mean:? <

Analysis books.

and

parlance).

On Apr 30, 10:44 pm, "M. Hamed" wrote:

ll?

ares files as files.

ot

ns

I don't use Scilab [I think that was its name] after a giant battle with them over accuracy. They essentially told me tough.

After floundering for a few years, I discovered octave and have NOT changed again. I do EXTENSIVE DSP work and octave not only predicted, but taught me, a great deal about what was going on. During DSP development after trying a process of manipulation in octave, it was a piece of cake to write C/C++ real-time code to do the same thing. As you know, battling code errors is enough to take on, not trying to design the DSP processing at the same time.

Either you have to make certain you have a complete set of cycles for each waveform in your FFT window, else you 'scatter' the energy of non matching sinusoid into adjacent segments. Like 30% in one and 70% in the next one, which makes your display look ghastly - but it is correct by mathematical definitions. So...if you make the FFT window of time match ALL waves THEN you'll get your expected results. If impossible to match, you can use a window. Think of the window as gently sliding into the data and then gently sliding back out, so the 'accidental' abrupt start and stop of your window over the waveforms just doesn't happen. There are two very effective windows to use. go to TI's ap note on their incredible ADS1282 24 bit data acquisition system. They use a window that is a great compromise between preserving energy and injecting noise into adjacent segments. In the interim, I simply use an 'adjusted' hanning window which is fairly easy and doesn't 'splatter' the energy around. Note, I said Hanning, not Hamming. The shape of the hanning window is one cycle of a cos wave, starts at zero goes to amplitude of 2, then returns to zero and is EXACTLY the length of your FFT window. Octave provides that as a supplied function so it's easy to use, but you can construct one mathematically for your needs. Just keep in mind that whatever window you use you MUST make the area under that window equal to one, else you'll shift the amplitudes of your FFT, losing quantified answers, only getting qualified answers.

Be FAR easier to talk in octave, rather than Scilab.