RE: [Discuss-gnuradio] USRP2, is that possible to skip the Ethernet and pass data through general purpose (physically accessible) inputs to the FPGA?

[Nick Foster]

Malihe,

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.

Nick


----------------------------------------
> 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 
> FPGA?
>
> 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?
>
> Thanks,
> Malihe
> Nick Foster wrote:
> > Malihe,
> >
> >
> >> 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.
> >
> >
> >> for
> >> 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 USRP2:
> > http://gnuradio.org/redmine/wiki/gnuradio/UsrpFAQ
> >
> >
> >> 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.
> >
> > Nick
> >
> >
>