[hpsdr] DSP theory, interpreting IQ streams as audio, and way too much math - is this a good approach?

[John Miles]

It's actually not that common to use Hilbert transforms in an SDR front end,
because there is usually a better way to turn real data into I/Q complex
data.  This is particularly true in an SDR like Mercury where the ADC
performs direct sampling of the RF signal and feeds real data straight into
an FPGA for downconversion to baseband.  

In the FPGA, job #1 is to convert the real data from the ADC to I/Q format,
typically by mixing with the output of a DDS core.  Instead of monkeying
with Hilbert transforms and delays, you normally set up the DDS core to
generate both cosine and sine outputs.  The result of mixing (multiplying)
the real data from the ADC with the cosine signal from the DDS core is the I
baseband data, while the result of mixing the same real ADC data with the
sine signal is the Q baseband data.  

This can be done either with explicit DDS cores, as might be created by the
FPGA vendor's coregen facility (Xilinx's in particular is awesome), or with
a CORDIC phase rotator as is done in Mercury, which saves FPGA resources.

To get back to an audio signal, you can use a polar discriminator for FM, a
magnitude calculation for AM, or -- finally -- a Hilbert transform for SSB.
This isn't a case where you are transforming real data to complex, as many
texts suggest is the purpose of the Hilbert transform, but rather a case
where you already have complex data and you want to extract a real USB or
LSB stream, depending on the direction of the phase shift shift provided by
the Hilbert transform.  The SSB audio is merely the algebraic sum of the
outputs of the Hilbert transformer in one path and an equivalent delay line
in the other.

Check out Doug Smith, KF6DX's tutorial articles that were originally
published in QEX.  I don't think I've ever seen a more concise explanation
of practically everything you need to know about DSP for radio work.  

Also, the good stuff is not always easy to find, but you can dig up some
excellent slide decks and other tutorial resources are linked on the HPSDR
wiki and http://openhpsdr.org/resources.php .  Kirk Weedman's Verilog
tutorials are well worth checking out, as they, too, contain some
DSP-related material.  Mercury is an amazing resource for coming up to speed
on DSP, as is GNU Radio.

-- john, KE5FX
 

> -----Original Message-----
> From: hpsdr-bounces at lists.openhpsdr.org [mailto:hpsdr-
> bounces at lists.openhpsdr.org] On Behalf Of Erik Anderson
> Sent: Friday, June 22, 2012 11:47 PM
> To: David McQuate; albertson.chris at gmail.com
> Cc: hpsdr at lists.openhpsdr.org
> Subject: Re: [hpsdr] DSP theory, interpreting IQ streams as audio, and way
too
> much math - is this a good approach?
> 
On Fri, Jun 22, 2012 at 10:38 PM, David McQuate <mcquate at sonic.net> wrote:

> ***** High Performance Software Defined Radio Discussion List *****
>
>
>  The nice thing about an IQ stream is that it's already a complex
> (analytic) function.  When you have only a single stream of samples, like
> right out of an ADC, then you might need the Hilbert transform.
>
> Usually, at least when digitizing the RF from an antenna, there are
> thousands of signals.  You'll want to be selective.  Apply a band-pass
> filter, and do a digital down-conversion by multiplying by sin & cos of a
> digital LO.  This brings the selected signal down to baseband.  Since the
> bandwidth has been limited by the filter, you have many more samples than
> you need, so you can decimate, just tossing out all but every Nth sample.
> At this point you might have an audio signal you can listen to.
>
> Dave
> WA8YWQ
>

What you are describing here almost sounds like what Mercury is already
doing for me, although I recognize that with a wider bandwidth signal I
could take the stream and tune multiple stations simultaneously.  I've been
assuming that the IQ stream I'm getting from Metis consists of a chunk of
bandwidth ranging from -192 KHz through +192 KHz (or whatever the sample
rate is) with the selected frequency translated to the middle at baseband (
0 Hz ), in other words that it is a complex signal but NOT an analytic one
(is my assumption wrong?).  I was curious as to whether Hilbert could be
used on a complex input signal as a highpass filter (to get rid of the
negative frequencies), combined with perhaps a lowpass FIR filter (to get
rid of the frequencies outside a certain distance from 0 Hz ).

As for the FFT, I'm actually rigging the wiring up for it now.  While I did
realize that you could "flip" into frequency domain, "edit" the signal,
then "flip" back, I hadn't realized that this was the primary means of
filtering in HPSDR, or that you could do those two operations quickly
enough often enough for it to work as an acceptable audio translation.  I
was originally planning on using an FFT for a waterfall display where
response time and CPU load weren't as critical (possibly looking into
offloading it into OpenCL, possibly exploring use of overlapping windows
and higher resolution).  Is FFT really that fast, and how does it compare
to say a complex-input 35th order FIR filter, performance-wise? (that FIR
filter is an example in the library book I'm reading)

I'm just realizing that the slowest speed Metis puts out ( 48 Ksps ) is
within the range of audio cards, so if I could convert the IQ stream to
real (again a misunderstanding of what Hilbert does?) I may not even need
to decimate it...

Thank you for the quick responses,
Erik KM2G


 1340437927.0