[USRP-users] Removing DC offset on USRP B200

Marcus Müller marcus.mueller at ettus.com
Sat Oct 21 19:02:44 EDT 2017


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.mueller at ettus.com <mailto:marcus.mueller at 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.
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171022/32e54763/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: two_tones_grc.png
Type: image/png
Size: 6132 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171022/32e54763/attachment.png>


More information about the USRP-users mailing list