[hpsdr] Call for Comments OzyII

[Henry Vredegoor]

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.

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.

What kind of reduction in bandwidth do you expect by using your suggested
method?

Henry.




> -----Original Message-----
> From: hpsdr-bounces at lists.openhpsdr.org 
> [mailto:hpsdr-bounces at lists.openhpsdr.org] On Behalf Of L. Van Warren
> Sent: maandag 27 juli 2009 3:55
> To: hpsdr at lists.openhpsdr.org; qs1r at yahoogroups.com
> Subject: [hpsdr] Call for Comments OzyII
> 
> 
> ***** High Performance Software Defined Radio Discussion List *****
> 
> One problem with decimation is that by taking every nth sample, useful
> information is being thrown away. A better algorithm is 
> sample averaging
> which can be implemented in powers of 2 stages on a pipleline 
> DSP or FPGA.
> This has dramatic effects on both signal to noise ratio and 
> image rejection.
> The benefits of oversampling apply.
> 
> The opposite argument (interpolation) applies to sampling 
> ADC's. A signal
> sampled in the time domain can be quantized by slope as well as
> instantaneous level. Signal levels and slopes could be 
> encoded floating
> point numbers rather than n-bit sequences and there is work 
> being done in
> this area by the gnu-radio project on the software side.
> 
> The next step after that is adaptive sampling in time, using 
> more samples
> where the signal is changing rapidly and fewer where it is 
> not. This reduces
> the bandwidth required to transmit the sampled representation 
> of the signal
> for a given quality.
> 
> One could FFT the signal BEFORE transmission, transmit the 
> FFT coefficients
> as numbers and then do the reconstruction on the receive side.
> 
> This is the sort of thing I am hoping to see. 
> 
> 
> Van / AE5CC / wdv.com
> 
> _______________________________________________
> HPSDR Discussion List
> To post msg: hpsdr at openhpsdr.org
> Subscription help: 
> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org
> HPSDR web page: http://openhpsdr.org
> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/


 1248703205.0