[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] USRP2, is that possible to skip the Ethernet and

From: Malihe Ahmadi
Subject: Re: [Discuss-gnuradio] USRP2, is that possible to skip the Ethernet and pass data through general purpose (physically accessible) inputs to the FPGA?
Date: Fri, 17 Sep 2010 18:48:02 -0600
User-agent: Thunderbird (Windows/20100228)

Hi Nick,
by FPGA image do you mean the .bit file? Thanks,

Nick Foster wrote:

Use the USRP2 card burner utility, located in the UHD host code as
host/utils/usrp2_card_burner_gui.py. It is also installed
to /usr/local/share/uhd/utils/ by default. You may have to run the
program as root.

If you only specify an FPGA image when you run the program, the firmware
image will not be overwritten.


On Wed, 2010-09-15 at 12:27 -0600, Malihe Ahmadi wrote:
I have changed the FPGA code and I have built the bit file for it. I would like to keep the same firmware but just change the FPGA code. What should I do now?


Nick Foster wrote:

Your understanding is basically correct. I misunderstood your request -- I 
didn't realize you had an existing FPGA design you were integrating with the 
USRP2, and figured you were going about things the hard way.

Nothing happens to Ethernet packets between the host transmission and GMII_TX 
-- the USRP2 MAC receives the same data that goes out the host MAC. I was 
trying to say that modulation is typically done in Gnuradio, not in the FPGA, 
and so data on the wire is typically baseband modulated and not a data 
bitstream. If you are implementing the modulation in FPGA you are of course 
free to define the data on the wire however you like.

For your purposes you should be able to take your data straight from the MAC 
and buffer and encode it in whatever way you see fit.


Date: Thu, 2 Sep 2010 18:30:22 -0600
From: address@hidden
To: address@hidden
CC: address@hidden
Subject: Re: [Discuss-gnuradio] USRP2, is that possible to skip the Ethernet 
and pass data through general purpose (physically accessible) inputs to the 

Hi Nick,

I think I should explain my project better. We are developing a physical
layer protocol for an asynchronous packet based transceiver all in
Verilog. The design has been simulated so far using ModelSim. The target
of the project is the VLSI fabrication of this design. Thus all the
signal processing (digital modulation (for now we are interested in BPSK
digital modulation), packetization, spreading, filtering ) has to be
done in FPGA, and it should be as stand alone as possible. The reason we
picked USRP2 was that it was a compact board with RF specification quite
close to our requirements. Our understanding was that we can get one
computer (host) to transmit stream of bits to the USRP2, do the
processing in FPGA and send the data over air, and the second USRP2
would capture the signal and again FPGA would do the processing and
eventually pass the data (through Ethernet) to the second host
(computer). I thought, if I generate a stream of bits in the first host
(TX) and do BPSK modulation and pass them to the USRP2 using Gnuradio,
the two 16 bit I and Q port that I get at the DSP core of the FPGA are
two bytes of that stream of bits and now I can continue with
packetization and the rest of my processing inside FPGA (basically
replacing the interpolation module with my spreading module) and redo
that process at the receiver to retrieve the generated bit stream.
I have already read through the DSP codes inside the FPGA. What I
understand from your email below was that I can't retrieve the bit
stream (generated at the host) in the FPGA and the 16 bits I and Q are
modulated, shaped sample representation of the bit stream. This is a bit
confusing for me because I thought (assuming the host just generates the
bits and does the BPSK modulation) the Ethernet decoder (DP83865) of the
USRP2 is basically compensating (undo-ing) the processing that was
performed on the bits (by Ethernet encoder) right before they leave the
host (computer) so that the Ethernet becomes transparent. If that is not
the case, my only solution is to pass the bit stream to the FPGA using
the debug port!
Would you please let me know which part of my assumption is wrong?

Nick Foster wrote:

Date: Thu, 2 Sep 2010 14:19:54 -0600
From: address@hidden

Actually we are using the USRP2 not for a SDR application, but we are
using it to test our physical layer asynchronous backet based
communication. For that I have to change the FPGA code and remove the
interpolation/decimation and replace it with a spreading scheme.

Assuming your spreading doesn't bring your bandwidth over around 25MHz, you 
should be able to do the spreading operation on the host and transmit the 
spread baseband data to the USRP2 via Gnuradio. The host typically does not 
send unmodulated data to the USRP2; the host side, usually using Gnuradio, 
performs the desired DSP operations on your raw information such as spreading, 
shaping, and modulating, and sends the resulting complex waveform to the USRP2 
as raw 16-bit samples. The USRP2 itself knows nothing about your original 
unmodulated data.

that I need to know exactly what is the nature of data I am receiving at
the FPGA and what is its maximum rate or forget about Ethernet and get a
separate bus for me to pass the data to the FPGA .

The data you are receiving at the FPGA is whatever you send to it -- the 
interpolation rate you pick determines the sample rate the USRP2 will run at. 
The interpolator will handle upsampling the raw samples to match the data rate 
the DACs run at. It's up to you (using Gnuradio) to encode your data into an 
appropriate waveform for your application.

Assuming I want to use Ethernet, let's say I want to send the stream
'0100001', and I pick DBPSK as the modulation. can you please explain
what is the relation of the DBPSK modulated data and "GMII_RXD" input to
the FPGA or "sample" input to the dsp_core_tx? is that FPGA receives 8
bits per symbol sent over Ethernet?

Whatever raw samples you send into gnuradio get sent to the FPGA (I'm 
simplifying here: see the link below for details). The USRP2 itself does not 
know or care that you are using DBPSK or that you are sending '0100001'. It 
sounds like you might have a misconception of exactly what the USRP2 is doing. 
This FAQ is for the USRP1, but the overall description applies also to the 

Also, do you have a ready to use Python code for USRP2 device which
generates for example a SIN wave at the transmitter and captures it at
the receives?

A simple GRC flowgraph would perform this function for you. You can use a 
signal source to feed a USRP2 sink, and then a USRP2 source to feed an FFT sink 
(or whatever sink you like). The parameters for these blocks depend on what 
daughterboards you are using for TX and RX and whether you are using the UHD 
driver or not.


Discuss-gnuradio mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]