<div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Thanks for the feedback,</div><div>Erik KM2G</div><br><div class="gmail_quote">On Sat, Jun 23, 2012 at 12:52 AM, John Miles <span dir="ltr"><<a href="mailto:jmiles@pop.net" target="_blank">jmiles@pop.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It's actually not that common to use Hilbert transforms in an SDR front end,<br>
because there is usually a better way to turn real data into I/Q complex<br>
data. This is particularly true in an SDR like Mercury where the ADC<br>
performs direct sampling of the RF signal and feeds real data straight into<br>
an FPGA for downconversion to baseband.<br>
<br>
In the FPGA, job #1 is to convert the real data from the ADC to I/Q format,<br>
typically by mixing with the output of a DDS core. Instead of monkeying<br>
with Hilbert transforms and delays, you normally set up the DDS core to<br>
generate both cosine and sine outputs. The result of mixing (multiplying)<br>
the real data from the ADC with the cosine signal from the DDS core is the I<br>
baseband data, while the result of mixing the same real ADC data with the<br>
sine signal is the Q baseband data.<br>
<br>
This can be done either with explicit DDS cores, as might be created by the<br>
FPGA vendor's coregen facility (Xilinx's in particular is awesome), or with<br>
a CORDIC phase rotator as is done in Mercury, which saves FPGA resources.<br>
<br>
To get back to an audio signal, you can use a polar discriminator for FM, a<br>
magnitude calculation for AM, or -- finally -- a Hilbert transform for SSB.<br>
This isn't a case where you are transforming real data to complex, as many<br>
texts suggest is the purpose of the Hilbert transform, but rather a case<br>
where you already have complex data and you want to extract a real USB or<br>
LSB stream, depending on the direction of the phase shift shift provided by<br>
the Hilbert transform. The SSB audio is merely the algebraic sum of the<br>
outputs of the Hilbert transformer in one path and an equivalent delay line<br>
in the other.<br>
<br>
Check out Doug Smith, KF6DX's tutorial articles that were originally<br>
published in QEX. I don't think I've ever seen a more concise explanation<br>
of practically everything you need to know about DSP for radio work.<br>
<br>
Also, the good stuff is not always easy to find, but you can dig up some<br>
excellent slide decks and other tutorial resources are linked on the HPSDR<br>
wiki and <a href="http://openhpsdr.org/resources.php" target="_blank">http://openhpsdr.org/resources.php</a> . Kirk Weedman's Verilog<br>
tutorials are well worth checking out, as they, too, contain some<br>
DSP-related material. Mercury is an amazing resource for coming up to speed<br>
on DSP, as is GNU Radio.<br>
<br>
-- john, KE5FX<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote></div>