[USRP-users] Removing DC offset on USRP B200

mleech at ripnet.com mleech at ripnet.com
Mon Oct 16 12:55:34 EDT 2017


A quick note from the other Marcus. 

The UHD library is NOT a DSP library.  If you need to "do things to my
signal", you'll need to do that outside of UHD itself, which is really
just a driver API for the hardware. 

This is the domain of software systems like Gnu Radio, or if you're
doing this in FPGA-land (not really recommended for B2xx, since the
FPGAs aren't big enough), coding in Verilog with ISE, using whatever DSP
libraries you can integrate into the FPGA. 

On 2017-10-16 12:42, Oliver Wayne via USRP-users wrote:

> Hi Marcus, 
> 
> How do i produce a sum of multiple tones using the uhd libraries? tx_waveforms.cpp lets me set a center frequency with uhd::tune_request_t tune_request(LO_freq), but what I want is to see an output A1*sin(f1*t + phi1) + A2 * sin(f2*t + phi2) + ... 
> 
> Along similar lines, how do I change the amplitudes and phases of each waveform from the uhd libraries?  
> 
> When you say fiddle with the iq corrections, I can do that from within radio_legacy.v, correct? 
> 
> Thanks for the help, I'm fairly new to SDR.  
> 
> On Sat, Oct 14, 2017 at 8:30 AM, Marcus Müller via USRP-users <usrp-users at lists.ettus.com> wrote:
> 
> Hi Oliver, 
> 
> haven't quite thought through an understanding of what you're currently doing, but: 
> 
> Since the FPGA image already comes with a convenient-to-use DUC - why not just produce a constant, and tune digitally to a non-zero frequency? That way, the CORDICs inside the duc_chain will simply generate your sine for you, presumably at a much higher resolution than your 1024 element sine table, for free. 
> 
> To test: use your PC to send a constant, use a uhd.tune_request_t(LO_frequency+tone_frequency, tone_frequency). 
> 
> If there's still a LO leakage on the output, you can manually fiddle with the IQ corrections inside the AD9361. 
> 
> Best regards, 
> 
> Marcus
> 
> On 12.10.2017 02:23, Oliver Wayne via USRP-users wrote: 
> 
> Hello, 
> 
> I've implemented a DDS signal on the USRP device. In radio_legacy.v, I input get_tx_I and get_tx_Q as my I and Q channels. 
> 
> always @(posedge radio_clk) begin tx[31:16] <= (run_tx) ? get_tx_I[31:16] : tx_idle[31:16]; // I channel tx[15:0] <= (run_tx) ? get_tx_Q[31:16] : tx_idle[15:0]; // Q channel end These are 32 bit registers and I calculate the value of get_tx_I and get_tx_Q in external modules. Currently I use 10 bit registers in my sine lookup table, so something like 
> 
> sine[0] = 340; 
> sine[1] = 342; 
> ... 
> And I sum several of these sine terms, then set get_tx_I(Q) equal to their sum. The problem is this has a DC offset, which means that that the local oscillator signal also shows up in my spectrum, which I don't want. When I try to kill the DC offset, so I write 
> 
> sine[0] = 0; 
> sine[1] = 1; 
> ... 
> 
> Then I still get a local oscillator term, but also get garbage in the spectrum. What's the optimal way to remove a DC offset? I was not sure whether I should explicitly write out the negative value as two's complement in the lookup table, or use something like https://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#a263ab7f0364c03e8a6e330c546769e4f [2]. 
> 
> thanks 
> 
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [1]
> 
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [1]

_______________________________________________
USRP-users mailing list
USRP-users at lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com 

Links:
------
[1] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[2]
https://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#a263ab7f0364c03e8a6e330c546769e4f
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171016/0365d20f/attachment-0002.html>


More information about the USRP-users mailing list