So as far as using Verilog goes, how would I remove the offset (as described in the original post)?
I don't think I can use gnuradio because the sample rate maxes out at around 5 Msps (if I try to push past this, I get "The total sum of rates exceeds the maximum capacity of the connection), so for sidebands spaced at around 1-2 MHz with an 80 MHz center frequency this does not seem to work. Or am I misunderstanding how to use this? Right now, on Gnuradio I have Signal source --> Throttle --> USRP Sink Center frequency 80 MHz, signal source frequency 1 MHz. On Mon, Oct 16, 2017 at 12:55 PM, <mle...@ripnet.com> wrote: > 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@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 >> <https://maps.google.com/?q=tx%5B31:16&entry=gmail&source=g>] <= >> (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_1mult >> i__usrp.html#a263ab7f0364c03e8a6e330c546769e4f. >> >> thanks >> >> _______________________________________________ >> USRP-users mailing >> listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> >> >> _______________________________________________ >> USRP-users mailing list >> USRP-users@lists.ettus.com >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> >> > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com