Re: [Discuss-gnuradio] USRP Dynamic Range and 8 Bit Problem

[Firas Abbas]

Hi Matt,

Kindly, see my comments below:

> Matt Ettus <address@hidden> wrote:
>
> Firas, 
>
> Thanks for doing these tests.  See my comments inline.

> Hi Matt, Don
>
> I did the tests. We definitely have improvement in USRP SFDR by more
> than 3 dB. I did the tests as follows :
>
> 1) Test Setup:
>
> a) Using USRP Rev 4.5 with Basic-RX  board.
> b)  Using high accuracy function generator.
> c) Using decimation rate =8, and gain =0.
> d) Using single tone (The SFDR is usually tested using single tone).
> e) Using two frequencies 250KHz and 5250KHz. This is because I
> noticed  a large difference in USRP SFDR between DDC frequency =0 and
> DDC frequency  = 5MHz (for example).

Your are welcome. USRP is really great and we thank you for
 inventing it.

> The tones that you see on the 250 kHz measurements are harmonics.  They  
> could be generated in the USRP, but they could also be there on your  
> signal generator.  Can you take a look at your sig gen on a spectrum  
> analyzer to check if you still see the harmonics?

I don't see any harmonics from signal generator using spectrum analyzer.

> f) Using tone power levels of (+4dBm) which gives about 1Volt P-P into
> ADC (according to AD9862 data sheets, this analog input signal gives
> best THD performance) and (+8 dBm) slightly below the saturating level
> which produces about 2Volt P-P into the ADC (according to AD9862 data
> sheets, this analog input signal gives best Noise performance).
> g) Using Intel Core2D PC with Ubuntu 7.10.
> h) Using gnuradio 3.1.1.
> i) Using usrp_fft.py.
>
>
> 2) Prepared USRP FPGA Work :
>
> a) The first  FPGA rbf file (usrp_std_0.rbf) was generated by
> modifying only the cordic.v file.
>
> b) The second FPGA rbf file (usrp_std_1.rbf) was generated by
> modifying the cordic.v and the cic_dec_shifter.v files.
>
> c) The third FPGA rbf file (usrp_std_2.rbf) was generated by modifying
> the adc_interface.v and the cic_dec_shifter.v files.
>
> See the files at:
> http://rapidshare.com/files/79109257/Files_Differences.tar.gz
> http://rapidshare.com/files/79109346/all_fpga_rbf.tar.gz
> http://rapidshare.com/files/79109391/Worked_files.tar.gz

> When you make the following change: 
> -   rx_dcoffset #(`FR_ADC_OFFSET_0)  
rx_dcoffset0(.clock(clock),.enable(dco_en[0]),.reset(reset),.adc_in({adc0[11],adc0,3'b0}),.adc_out(adc0_corr), 
> +   rx_dcoffset #(`FR_ADC_OFFSET_0)  
rx_dcoffset0(.clock(clock),.enable(dco_en[0]),.reset(reset),.adc_in({adc0[11],adc0,4'b0}),.adc_out(adc0_corr), 
>
> You need to take into account that the input to rx_dcoffset is only 16  
> bits.  So in the second line, you are really sending in {adc0,4'b0}  
> since the top repeated sign bit will be cut off.  This block takes an  
> average of the DC offset and subtracts it form the signal.  This can  
> cause an overflow if the signal is close to clipping and the DC offset  
> is nonzero. The best thing to do here would be to make the rx_dcoffset  
> block clip instead of
 wrap around.  That would save a digit here. 

Actually, I'm weak when it concern working with FPGA and verlog. All what I did was implementing Don W. suggestions.
If you tell me where and what to change, I can do it and test it again. I think as you can see from the graphs (and Don expected this also) the changes in the adc_interface.v was better than the work done in the cordic.v but because of the level problem (at 8dBm), I ignored it.


> Also be careful with the values in cic_dec_shifter, since each one is  
> used at only one decimation rate.  You need to test all the ones that  
> change.

I tested from decimation 8 to decimation 256. All worked fine.

> 3) Test results:
>
> Note 1:
> I used in my tests the original rbf file std_2rxhb_2tx.rbf ,
> usrp_std_1.rbf and usrp_std_2.rbf  FPGA files (usrp_std_0.rbf was not
> used).
>
> Note 2:
> Let us assume that I have eye reading error by about (1dB - 2dB)!!!!.
>
> Note 3:
> See test results at :
> http://rapidshare.com/files/79109205/Tests.tar.gz
>
> a) The generated rbf file by modifying the cordic.v and the
> cic_dec_shifter.v files (usrp_std_1.rbf) gave us more SFDR than the
> original FPGA file by about 7 dB in case of input signal 5250KHz and
> level=+8dBm as shown in graphs. I tested this rbf file for all input
> signal levels (from -90dBm to +13 dBm) and for all decimations (8 to
> 256). It is working fine and great and should  be used all the time
> instead of the original rbf file.
>
> b) The generated rbf file by modifying the adc_interface.v and the
> cic_dec_shifter.v files (usrp_std_2.rbf) was not good as expected.
>
>        Although it gave us more SFDR than the original FPGA file by
> about 5 dB in case of input signal 5250KHz and level 4dBm as shown in
> the graphs, but the FPGA got crazy when the input signal level was
> 8dBm as shown n the graphs (I think the cordic was overflowed).
>       When the FPGA  went crazy, I reduced the input signal gradually
> by 1dB steps until I reached  input signal =+4dBm then it worked back
> normal. Thus, the file is working good only and only if the input
> signal is equal or below 4dBm.
>
>
> I think we should send this work as a patch to gnuradio to enhance our
> fantastic USRP device.

> I agree that the results do look better.  My concern is overflow when  
> both I and Q are used.  If you can try all of these with
 max-strength  
> signals on both I and Q at the same time, I would be more than happy to  
> include the final results in the standard build of the FPGA. 

Actually we are using I & Q (The DDC out is complex as you know) and the FFT used in usrp_fft.py is complex FFT.
However, If you prefer, I can repeat all the tests using DBSRX board, or please suggest what tests you would like me to do.


> Thanks for doing all this investigation, 
> Matt

Best Regards,

Firas A.