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

[Erik Anderson]

Thank you for the responses so far.  I do appreciate the research pointers,
I've found information relatively scattered so far (or perhaps from a
limited point of view?).  I think I may have found (and printed out) the
tutorial article series by KF6DX that was mentioned and intend to read
through it later.

A quick comment about the power of the "modern PC", things have gotten a
lot more varied since CPUs have apparently hit their limit a few years
ago.  I'm working on the first laptop I've ever bought, which is at least
twice as powerful as the previous desktop I used but greatly underpowered
when compared to my current desktop.  Even after the patch necessary to get
KK to even run on my netbook it takes at least 80% CPU while receiving.
 And I just read here last week of a report that someone just bought a
computer (the currently-popular Raspberry PI) that couldn't run FFT at all
(although that's likely beyond hope for any DSP by this point, no OpenCL on
that powerful a video chip?).  I do still have the power of my desktop
which could likely run circles around this, but I'm also looking to explore
more portable options.

Thanks for the feedback,
Erik KM2G

On Sat, Jun 23, 2012 at 12:52 AM, John Miles <jmiles at pop.net> wrote:

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/attachments/20120624/72396e29/attachment-0004.htm>