SDR I/Q demodulation - how to or source code references wanted

[AA7EJ]

I am in a process of adding SDR software into my home brew rig control program. RX only for now..
I have several source code documents ( Linrad , Flex ) and could use some help in identifying just the I/Q demodulation source code.
I am developing in Windows and having a heck of a time deciphering all this Linux based code.
Basically I would like simple description of what is involved demodulating I/Q signals in software.
So far it looks as FFT is the start and from there it is a largely undocumented woo-doo .

Please – no “use this SDR software...”.

I need just few hints to get me going – I got the audio input all figured out and ready to do some work.
All of the sites I have checked so far have ready to go user software or user groups, no development found, and very few have open source code available.
Thanks for reading.
73 Vaclav AA7EJ

[2E0CHE]

You sound like you want "Signals, Samples and Stuff: A DSP Tutorial" by Doug Smith, KF6DX/7 published in QEX, see http://www.arrl.org/software-defined-radio for a link to the PDFs.

The demodulators in the lib underlying PSDR are quite straightforward in overall architecture, and may be worth a look.

The fft is usually as a precursor to filtering (convolution by an impulse response is faster in the frequency domain), where it is used for both correcting I/Q phase and amplitude errors, and doing the IF bandpass filtering (It also produces the data for the waterfall).

The actual demodulation can be done with just an I/Q analytic pair brought down to baseband... SSB output is just I+Q or I-Q depending on which sideband you want, AM can be either a digital phase locked loop and sync demodulate, or just sqrt (I*I + Q*Q) followed by lowpass to remove the mixing products and highpass to remove the DC offset (The PLL is better, but tricky to code), fm gets fiddly, basically a phase detector and remember that frequency is the rate of change of phase.

It is all in the QEX articles above, and yea, this is one of those areas that get tricky in detail.

HTH.

Regards, Dan.

[AA7EJ]

Thanks Dan,
this is exactly what I was looking for.
I did not know that SSB is "so easy" and right know I am struggling with AM demodulation. Most of my "problems" are in converting the sources I got into Windows MFC. I use MFC because I got lots of UI code I can reuse HI HI.
I'll check the QEX article, thanks.
One stupid question - I am not a FFT wiz and do not get the "conversion points".
I am probably using wrong terminology here.
There must be some optimum - the code I am using is set for 2048.
What is interesting - it looks like most of the open source software came from few smart guys and rest of "us" are just copying it.
But I like to know "why" and that is where I get stuck with some stuff.
I cannot wait to get into this correction stuff and filtering!
Anyway, thanks again.
73 Vaclav AA7EJ

[2E0CHE]

I would be a little bit careful with mixing the DSP and GUI code, you usually want them in separate threads so a window redraw for example cannot cause the audio processing to miss its deadline.
There is usually little reason to use anything past ANSI C or C++ for the bulk of the DSP code, possibly with some intrinsics for vector operations, I really do not see the utility of MFC here, use it in the GUI thread sure, but design to have a clean separation of the two (Shared memory, sockets, whatever).

The number of points in the FFT ties directly to the resolution in the frequency domain, but also to the latency for any given amount of overlap (And you do need some), see also the windowing functions. I highly recommend FFTW rather then writing your own FFT code (Life is too short).

Have fun, it is cool stuff.

Regards, Dan.