[hpsdr] Call for Comments OzyII

[alex]

i think that the point of the gigabit would be so that in the [near] 
future (following more's law) then there will be computers powerfull enough

> ***** 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.
>
> 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/
>>     
>
> _______________________________________________
> 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/
>
>   


 1248705560.0