[hpsdr] Call for Comments OzyII

[jeff millar]

Henry Vredegoor wrote:
> ***** High Performance Software Defined Radio Discussion List *****
>
>
> Hi Van, All,
>
> Very interesting idea regarding reducing bandwidth between the PC and HPSDR.
>
> I'm still struggling to understand Jeff's model regarding bandwidth versus
> required processing power more completely (this has nothing to do with the
> quality of Jeff's post, witch I find very interesting, but more with my own
> lack of knowledge), but if the model presented by Jeff is somewhat correct,
> then one of the conclusions would be that a bandwidth of say above 50 - 100
> Mbit/sec will increase the costs of an HPSDR system considerably as the cost
> of the PC with the required performance to do this will increase a lot with
> the current setup.
>   
Henry...

I wrote that quickly and didn't expand on a number of points to keep it 
short. If you have questions, ask away! I'll try to explain what I meant 
to say.

As an aside, Van's suggestions may not save compared to traditional 
filter and decimate algorithms. As someone pointed out, the essence of 
compression algorithms is to encode the most important parts of the 
signal and let the less important parts go. MP3 takes advantage of a 
property of the ear where it can't hear weak tones when block by strong 
tones...so just encode the strong tones.

This assumes a lot of knowledge of what's important and what's not 
important...which you don't have when trying to pull a weak signal out 
from under a strong signal.

There is an algorithm called "Multiuser Detection" which attempts to 
model the strong signal and then subtract it from the input, leaving 
just the weak signal. That works well for digital signals and not so 
well for voice. Hmmm...come to think of it, it might work ok for CW.
> For this reason I think and agree with you that maybe our efforts should
> also be aimed at reducing the volume of the transported data sent to the PC
> and offloading the processing in the PC.
>   
Thanks. The almost universal architecture for SDRs that use a high speed 
A/D consists of an FPGA or ASIC to filter and decimate the ADC output 
signal and then passing it onto a general purpose computer. FPGAs have 
about 30 times greater price-performance compared to CPUs, but can only 
implement relatively simple algorithms. This make them a good choice for 
the first stage of filtering and decimation.

ASICs have about a 5X advantage over FPGAs. The problem with ASICs comes 
from not being able to get the one you want. A cell phone chip has a 
very high price performance but only can do one thing.

These ratios remain about the same over time because they're all 
implemented with about the same silicon technology.

One exception to this rule about technology selection may come through 
the use of high performance graphic cards for accelerating signal 
processing. They seem to achieve performance close to an FPGA while 
remaining software programmable.

If you want to read more about technology comparisons between ASIC, FPGA 
and CPU, look for Andre DeHon's PHD thesis from MIT. It's quite readable 
and enlightening. His later work suggested optimizing FPGA like devices 
with more complicated logic elements...which foreshadows what grahics 
cards, Picochip, and Cell Array do today.
> What kind of reduction in bandwidth do you expect by using your suggested
> method?
>   
Someone made the point that the SDR architecture shouldn't worry about 
CPU power because Moore's law will make it available shortly. But, that 
same Moore's law will make for faster faster and wider A/Ds, faster and 
cheaper FPGAs, and more complex signal processing algorithms. The future 
SDR algorithms will probably process signals from multiple antennas 
simultaneously, implement Multi User Detection, new modulation schemes, 
etc. This basically suggests the fundamental architecture of RF filter, 
A/D, FPGA, General Purpose CPU will be with us for some time.

jeff, wa1hco
> Henry.
>
>
>
>   


 1248760340.0