Hi Oliver, yep, GNU Radio is just discrete signals, just like in an FPGA – but with software buffers between software functions :)
That especially means that this is all complex baseband – so, to represent 20 MHz (= 0.5 MHz · 40), i.e. -10 to +10 MHz, you just need a sample rate of 20 MS/s. 6MS/s is really not that much (and fits easily through USB2's link rate, so no advantage having USB3 below ca 8 MHz at all), so I'm surprised you see underflows! How are you generating the signal you send to your USRP sink? GNU Radio comes with a relatively elegant Polyphase Channelizer / Multichannel Synthesizer, which is pretty CPU-efficient; I've done things like receiving all the FM broadcast band (87 MHz – 107 MHz -> center frequency = 97 MHz, sample rate 20 MHz) to my laptop, channelizing it there to (up to all possible) 150 kHz channels at a 100 kHz grid, and made an "arbitrary patch panel" reasignment with the "Polyphase Channelizer" -> [many ugly crossconnections] -> "Polyphase Synthesizer" and a relatively steep prototype filter; that pushed my laptop a bit, but didn't overload it, but the thing was unmanageable as graphical flow graph, and so I had to code it in Python, which made it unsuitable as a demo case for new users. Something I noticed but a few hours before a talk ... fun times. So, let's talk about your system and your flow graph to find the bottlenecks. Best regards, Marcus On 19.10.2017 17:42, Oliver Wayne wrote: > Hi Marcus, > > On your advice I went through the first few chapters of the gnuradio > tutorial, and started experimenting again with my device. as best I > understand (please correct me if this is wrong), my signal sources > must be less than half the sample rate for the signals to be > well-resolved. The trouble is, even with a USB 3.0 connection, I end > up with a max sample rate of about 6M, which limits the frequencies I > can mix in. Eventually I want to mix in 40 frequencies spaced by about > 0.5MHz, so I would need a much larger sample rate than this, and I > don't know how to achieve this. If I set the sample rat e higher, I > get a garbage spectrum and I get repeated underflows. how should I > resolve this? > > thanks > > On Tue, Oct 17, 2017 at 5:54 PM, Marcus Müller > <marcus.muel...@ettus.com <mailto:marcus.muel...@ettus.com>> wrote: > > Hi Oliver, > > even just considering the time it takes to synthesize a single > image for the B200's FPGA, not counting time needed to learn where > to put your Verilog: Avoid doing things in the FPGA as far as > possible. The 20 minutes it costs to go through the first two or > three chapters of the GNU Radio Guided Tutorials[1] will pay for > themselves before your computer can even say "place&route". > Obviously, you've already figured out where to integrate your DDS, > but I'd still maintain that at such modest rates as 5 or 10MS/s, > there's no reason to have a fixed purpose implementation in the > FPGA when you could just as well do it flexibly in software on the > host. That's my "here's two tones at 2.4 GHz" example. It took me > about as long to crop the image to this size as it took me to > design this transmitter in the GNU Radio companion. Could have > just as well written it in Python or C++ in nearly the same time :) > > Two tones generated in software > > > Anyway, I'm absolutely still not convinced you can get rid of the > DC offset you're seeing with DSP at all – are you sure it's in the > signal you're sending to the AD936x, or is it maybe more of an > analog artifact? > > Best regards, > > Marcus > > [1] http://tutorials.gnuradio.org > > > On 17.10.2017 03:06, Oliver Wayne wrote: >> How would I then include negative numbers on the Verilog side to >> kill the offset? I'm a bit more comfortable with fpga design than >> with SDR, so for testing purposes I'd prefer to do it that way. > >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
