Malihe,
Please look here for schematics.
http://www.ettus.com/download
Nick
On Fri, 2010-10-29 at 10:36 -0600, Malihe Ahmadi wrote:
> Can anybody help me with this? I need a full schematics of RFX2400,
> the one available on gnuradio's site is not complete!
>
> -------- Original Message --------
> 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:
> Thu, 28 Oct 2010 20:00:53 -0600
> From:
> Malihe Ahmadi
> <ahmadina@ualberta.ca>
> To:
> Nick Foster <nick@ettus.com>
>
>
> Hi Nick,
>
> I actually changed the nsgpio module so that io_tx_06 and io_rx_06 have
> fix value and the board is always configured as full duplex but yet the
> pin 8 (ENOP, on and off switch for RF output) of the U101( AD8349, the
> modulator) is switching on and off and I don't know which signal is
> controlling it (b/c it is not shown in the schematics). Can you please
> send me the complete schematics of RFX2400 or tell me how to control pin
> ENOP of the U101?
>
> Thanks,
> Malihe
> Hi Nick,
>
> I had few interesting observation yesterday.
> First of all, I followed what you recommended, stock FPGA and firmware
> image and the sin wave at TX. looking at the GRC's FFT, I realized that
> the 1.1MHz spike is there but not always, it is choppy, I see either the
> spike or white noise! with this setup, I was probing different points on
> the RFX2400 db and I found in (please look at the schematic) in U209 pin
> 1 is always 0 and pin 2 is always 1, but in U202 pin 1 is sometime 0 and
> sometime 1 and pin 2 is its complement. that means TX/RX is not always
> derived with RF_TX! (and I think that is exactly why the source is
> choppy and the received signal is choppy ...). Also looking at pin 8
> (ENOP, on and off switch for RF output) of the U101( AD8349, the
> modulator), I found that pin is sometime 0 and sometime 1 (it seems it
> follows the same pattern as pin 2 of U202), but I can't find what signal
> is controlling that pin on the schematics?! do you know which signal it
> is? thus my understanding is that the firmware is not translating the
> full duplex configuration on the GRC to the correct values on U202 and
> 101. I'd like to take the control of those signals (io_tx_06 and
> io_rx_o6 and whatever else) out of the firmware and fix them in FPGA
> code and see what happens! but first Id' like to know your comments on
> these observations.
>
> Thanks,
> Malihe
>
> On 26/10/2010 7:12 PM, Nick Foster wrote:
> > Malihe,
> >
> > Please run the USRP2 with a stock FPGA and firmware image. Modify your
> > GRC flowgraph so the transmit frequency is 2.451GHz, and the receive
> > frequency is 2.450GHz with gain 50. Instead of a constant source, use a
> > complex sine wave source of amplitude 0.3 and frequency 100kHz. You
> > should see a spike at 1.1MHz on your GRC FFT and your spectrum analyzer
> > should show a spike at 2.4511MHz. Please let me know what your results
> > are. It is impossible to determine if the problem is the USRP2 or not
> > while you are running your custom FPGA code.
> >
> > Nick
> >
> > On Tue, 2010-10-26 at 17:38 -0600, Malihe Ahmadi wrote:
> >> Hi Nick,
> >>
> >> When I was talking about the spectrum, I didn't mean the FFT, I meant
> >> the spectrum analyzer we have in the lab, and I can see the spectrum of
> >> RF1 output which is a carrier at 2.45GHz with some data on top of it. on
> >> the FFT though, I believe the spike is just the carrier detected in the
> >> RX path and it seems there is no significant signal coming in on top of
> >> that!
> >> I captured those ADC and DAC plots more than few minutes after I turned
> >> on the board and run the GRC.
> >> I actually run the same GRC with two antenna, one connected to RF1 and
> >> the second one connected to RF2, yet I am capturing the exact same data
> >> from ADC and DAC.
> >> here is the new experiment I am running and it made me even more
> >> suspicious to the RX path (the reason I am running this experiment is
> >> that the DAC gets a continuous non zero flow of data and it lasts enough
> >> for the receiver to settle as you said it is required) :
> >> I am generating a 16 bit counter that counts from 0 to 2^16-1. this
> >> counter is connected to the dac_a while dac_b is always zero. I did this
> >> experiment with both antenna and also terminated RF1 and RF2 and their
> >> result was the same.In both cases the ADC data (_a and _b) is very
> >> small, then I increased the RX gian to 60dB and yet the ADC data has no
> >> relation with the DAC data (actually with 60dB gain, it seems to be an
> >> amplified white noise!). Then I decided to check some points on the
> >> board itself. I looked at the pin 16 of the AD834X and I could see the
> >> saw tooth wave. then I looked at pin 8 and 22 of the AD8347 and they are
> >> both constantly high with very small bump at some points! That seems not
> >> right to me!
> >>
> >> Thanks,
> >> Malihe
> >> Nick Foster wrote:
> >>> Malihe,
> >>>
> >>> Your USRP2 is fine, just as your GRC image shows. That FFT isn't showing
> >>> your TX spectrum, it's showing your RX spectrum from the USRP2 source.
> >>> Here's how it works. There are two things wrong -- first, you aren't
> >>> waiting long enough for the receiver to settle, like I told you to do
> >>> before. Your ADC plot is a big spike because it's just been initialized
> >>> and tuned. Wait a whole 100ms after starting the streaming and after
> >>> tuning before you take a plot of received data, so your receiver can
> >>> tune and settle. This of course means your DAC signal will have to last
> >>> long enough for your receiver to settle, as well. Second, you have
> >>> roughly 60dB of loss between your TX and RX, and so your RX amplitude
> >>> will probably be less than 100 counts (assuming you have 0dB RX gain
> >>> setting). This is fine for receiving, but if you are just looking at the
> >>> absolute raw ADC data with a vertical scale of 30000 you of course won't
> >>> see a thing.
> >>>
> >>> --n
> >>>
> >>> On Mon, 2010-10-25 at 20:19 -0600, Malihe Ahmadi wrote:
> >>>
> >>>> Hi Nick,
> >>>> I thought I should just add the Chipscope to your original FPGA code to
> >>>> test the ADC data, that way I am sure I didn't break anything. on the
> >>>> board I am terminating both RF1 and Rf2 and counting on the leakage as
> >>>> you said. I have a snapshot of the grc I am running attached and also
> >>>> three plots of the ADC and DAC data separately and also one with ADC and
> >>>> DAC on top of each other. as you can see the ADC data is always like a
> >>>> noise which means the RX RF path is not working (I think TX RF path is
> >>>> ok because I can see the TX output spectrum). Do you agree with me? Do
> >>>> you think I am not configuring the RX properly?
> >>>> How do you guys test the board functionality? id there a simple test I
> >>>> can do? any test points I need to monitor?
> >>>> I am stock and I can't do anything now! I really need some help ...
> >>>>
> >>>> Thanks,
> >>>> Malihe
> >>>> Nick Foster wrote:
> >>>>
> >>>>> It's sort of a weird way to look at the data... one thing I would
> >>>>> suggest is that it can take up to 50ms for ADC data to settle after
> >>>>> initializing the USRP2 due to daughterboard tuning, so if this data is
> >>>>> captured right on initialization it could be seeing transients left over
> >>>>> from tuning.
> >>>>>
> >>>>> On Thu, 2010-10-21 at 17:48 -0600, Malihe Ahmadi wrote:
> >>>>>
> >>>>>
> >>>>>> Hi Nick,
> >>>>>>
> >>>>>> I am testing the ADC data to see if what I get makes sense. in FPGA, the
> >>>>>> DAC data is connected to a 16 bit counter, which runs at dsp clock rate
> >>>>>> and has a reset, and the ADC output is connected to Chipscope. in GRC, I
> >>>>>> am instantiating an USRP2 sink and also a USRP2 source, and their gain
> >>>>>> is both 0dB, LO frequency of both of them is 2.45GHz and LO offset is
> >>>>>> default. on the board, I am terminating both RF1 and Rf2 (thus I am just
> >>>>>> counting on the leakage, and assume the leakage is enough to trigger the
> >>>>>> receiver). Attached are two ADC and DAC shots captured by Chipscope.
> >>>>>> you can see whether the counter is in reset (all zeros) or not, ADC data
> >>>>>> is almost always zeros with random large spikes! does this make sense to
> >>>>>> you? and if so, do you have any explanation for it?
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Malihe
> >>>>>>
> >>>>>>
> >>>>>> Nick Foster wrote:
> >>>>>>
> >>>>>>
> >>>>>>> On Wed, 2010-10-20 at 12:24 -0600, Malihe Ahmadi wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> which host code does the initialization of ADC/DAC/LO?
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>> Okay, I was a little wrong before, sorry -- some of the low-level
> >>>>>>> initialization routines are in firmware in the old USRP2 code that ships
> >>>>>>> with Gnuradio. I'm much more familiar with the newer UHD driver, which
> >>>>>>> does all the initialization on the host side. In the older code (which
> >>>>>>> you're using), the DAC initialization is done in
> >>>>>>> gnuradio/usrp2/firmware/lib/ad9777.c. The host code commands that
> >>>>>>> initialization in gnuradio/usrp2/host/lib/usrp2_impl.cc.
> >>>>>>>
> >>>>>>> The USRP2 does not do any significant ADC initialization, as we use the
> >>>>>>> default settings. The only significant ADC control done by the host is
> >>>>>>> to power it up.
> >>>>>>>
> >>>>>>> I'm not really sure what your approach is right now to getting the
> >>>>>>> registers set. Are you planning on writing your own host code,
> >>>>>>> transport, and firmware, or are you planning on modifying existing host
> >>>>>>> code to change the existing settings?
> >>>>>>>
> >>>>>>> If you use the UHD drivers, much of the custom initialization that you
> >>>>>>> need to do can probably be accomplished from a C++ program that
> >>>>>>> interfaces through UHD, instead of modifying the host code itself. UHD
> >>>>>>> allows you to access much deeper into the driver than the old USRP2
> >>>>>>> drivers.
> >>>>>>>
> >>>>>>> Nick
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> Nick Foster wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> The ADC and DAC are not initialized at all on startup until the host
> >>>>>>>>> code initializes them; the FPGA does no initialization of the ADC or
> >>>>>>>>> DAC. The CORDIC is set by registers but should default to 0Hz. See
> >>>>>>>>> cordic.v.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Tue, 2010-10-19 at 19:22 -0600, Malihe Ahmadi wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Can you also tell me which file contains the value of center frequency
> >>>>>>>>>> (both Tx and RX) and DAC IF frequency which the board is programed with
> >>>>>>>>>> right after power up?
> >>>>>>>>>> Nick Foster wrote:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> nsgpio
> >>>>>>>>>>>
> >>>>>>>>>>> On Tue, 2010-10-19 at 18:35 -0600, Malihe Ahmadi wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> Regarding Q2, which FPGA module keeps the setting of GPIO pins?
> >>>>>>>>>>>> Nick Foster wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>> On Tue, 2010-10-19 at 15:56 -0600, Malihe Ahmadi wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Hi Nick,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Q1: I have programed the FPGA with my own transmitter + receiver logic
> >>>>>>>>>>>>>> +Chipscope. Then I powered up the board, while there is an antenna
> >>>>>>>>>>>>>> connected to RX port (on the RFX2400 db) and TX/RX port (on the RFX2400
> >>>>>>>>>>>>>> db) is connected to spectrum analyzer.I am driving DAC inputs (both a
> >>>>>>>>>>>>>> and b) with all zeros (so there is no spectrum)and monitoring the ADC
> >>>>>>>>>>>>>> input using Chipscop. What I see is that the ADC is passing FPGA 14 bit
> >>>>>>>>>>>>>> data which is covering pretty much the full range (all the bits are
> >>>>>>>>>>>>>> actively changing). where did ADC got this data from? any idea?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> If you have an antenna connected to the RFX2400, and you are seeing ADC
> >>>>>>>>>>>>> data, I'm guessing you're picking up some RF. Please note that the ADC
> >>>>>>>>>>>>> is using two's-complement format, so all the bits will change on a zero
> >>>>>>>>>>>>> crossing.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Q2: on the first page of RFX2400, there is a table with 5 columns, I am
> >>>>>>>>>>>>>> interested in configuring the db board so that it is "Full duplex TX and
> >>>>>>>>>>>>>> Rx", how do I do that? (how do I set A1 B1 A2 B2 to be "0101")?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> If you are using the Gnuradio drivers or UHD, the daughterboard driver
> >>>>>>>>>>>>> will take care of this for you. Just add a USRP sink and source to your
> >>>>>>>>>>>>> flowgraph and the driver will handle setting up the daughterboard. If
> >>>>>>>>>>>>> you aren't using our drivers, you will have to set the appropriate GPIO
> >>>>>>>>>>>>> pins either by fixing them in the FPGA, or writing your own code to poke
> >>>>>>>>>>>>> the appropriate GPIO register.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Q3: If I 'd like to connect the TX and RX of the db together with a
> >>>>>>>>>>>>>> cable, do I need any attenuator? if so, how much?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> Use at least 30dB. Connecting them together without an attenuator will
> >>>>>>>>>>>>> fry the receiver. The TX/RX switch has enough leakage (-60dB) that you
> >>>>>>>>>>>>> should be able to just terminate the TX and RX ports with 50 ohm
> >>>>>>>>>>>>> terminations and receive TX leakage on the RX path -- no connection
> >>>>>>>>>>>>> required.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Nick
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>> Malihe
> >>>>>>>>>>>>>> Nick Foster wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Malihe,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Due to my schedule it's easiest to continue conversation via email. I am
> >>>>>>>>>>>>>>> also often available on IRC (Freenet) as "bistromath".
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Nick
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Fri, 2010-10-15 at 12:16 -0600, Malihe Ahmadi wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Hi Nick,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I am quite confused with my observation of DAC and ADC data and also the
> >>>>>>>>>>>>>>>> spectrum of the TX. I would very much like to have an intercative
> >>>>>>>>>>>>>>>> conversation with you, anytime you prefer, it could be anytime during
> >>>>>>>>>>>>>>>> the day any day of the week. I can call you or we can skype. Do you
> >>>>>>>>>>>>>>>> think that would work for you at all? otherwise I have to write quite
> >>>>>>>>>>>>>>>> long email and I know I can't learn as much as talking to you!
> >>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>> Malihe
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Nick Foster wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Malihe,
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> That message is normal and doesn't indicate anything wrong with your
> >>>>>>>>>>>>>>>>> setup. It just means that realtime scheduling is not enabled, which
> >>>>>>>>>>>>>>>>> isn't a problem for normal use. Your problem is somewhere else.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Nick
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Thu, 2010-10-07 at 11:36 -0600, Malihe Ahmadi wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Hi Nick,
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> I did what you said, and I eventually got the USRP2 working for me with
> >>>>>>>>>>>>>>>>>> my own TX code in FPGA while I just add my code on top of yours and I
> >>>>>>>>>>>>>>>>>> didn't change a thing in your codes. That way I got find_usrp working
> >>>>>>>>>>>>>>>>>> for me and I also have been able to configure the board as a TX only
> >>>>>>>>>>>>>>>>>> using GRC. but now I want to add my RX FPGA code as well and there is
> >>>>>>>>>>>>>>>>>> barely enough room for it. I wonder if I can remove anything in your
> >>>>>>>>>>>>>>>>>> code without breaking its communication with the firmware (I actually
> >>>>>>>>>>>>>>>>>> removed RAM logic as well as SERDES logic and expansion logic and added
> >>>>>>>>>>>>>>>>>> my RX logic, and I burned that .bin file into the SD card, after that I
> >>>>>>>>>>>>>>>>>> could get find_usrps working for me but as soon as I try to configure
> >>>>>>>>>>>>>>>>>> the board as TX/RX using GRC it breaks and gives me this error : "Fail
> >>>>>>>>>>>>>>>>>> to set real time scheduling", and after that find_usrps doesn't work
> >>>>>>>>>>>>>>>>>> either!, do you know what that error means? which part did I break?)
> >>>>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>>>> Malihe
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Nick Foster wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Malihe,
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> The first thing I'd do is compile a *stock* FPGA image with NO changes,
> >>>>>>>>>>>>>>>>>>> to ensure that your toolchain is producing correct images. After that,
> >>>>>>>>>>>>>>>>>>> get Wireshark or another Ethernet sniffing program on the wire and make
> >>>>>>>>>>>>>>>>>>> sure the firmware is able to send back and forth. If that seems OK,
> >>>>>>>>>>>>>>>>>>> you'll have to get into the host driver code and start tracing it
> >>>>>>>>>>>>>>>>>>> through there to see where it quits.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Another thought is that by removing the DSP and ADC, the firmware is
> >>>>>>>>>>>>>>>>>>> prevented from booting all the way. The firmware initializes these two
> >>>>>>>>>>>>>>>>>>> components, and if they aren't available it may hang while attempting to
> >>>>>>>>>>>>>>>>>>> read or write values to their ports on the Wishbone bus. If this is the
> >>>>>>>>>>>>>>>>>>> case, you will have to modify the firmware as well in order to work for
> >>>>>>>>>>>>>>>>>>> your application.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Nick
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On Wed, 2010-09-22 at 20:00 -0600, Malihe Ahmadi wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Nick,
> >>>>>>>>>>>>>>>>>>>> here is what I did:
> >>>>>>>>>>>>>>>>>>>> I commented out Expansion interface and also SERDES interface (because I
> >>>>>>>>>>>>>>>>>>>> don't need them) and also ADC (b/c I just need the board to be TX) in
> >>>>>>>>>>>>>>>>>>>> u2_rev3.v and then I added chipscope to this top module (to stimulate
> >>>>>>>>>>>>>>>>>>>> some signals). I use u2_core.v (not u2_core_udp) and in that module I
> >>>>>>>>>>>>>>>>>>>> just replaced your DSP module with my own DSP module, and that is all. I
> >>>>>>>>>>>>>>>>>>>> didn't change anything regarding the processor or Ethernet! and now my
> >>>>>>>>>>>>>>>>>>>> chipscope and DSP inside FPGA seems to be working, but yet I get USRP2
> >>>>>>>>>>>>>>>>>>>> not found when I type find_usrps :(
> >>>>>>>>>>>>>>>>>>>> Do you think it is because I used u2_core instead of u2_core_udp? what
> >>>>>>>>>>>>>>>>>>>> else could it be?
> >>>>>>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>>>>>> Malihe
> >>>>>>>>>>>>>>>>>>>> Nick Foster wrote:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Malihe,
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> It is likely that the Ethernet MAC interface in your custom FPGA image
> >>>>>>>>>>>>>>>>>>>>> is not correctly communicating with the firmware running in the
> >>>>>>>>>>>>>>>>>>>>> Microblaze processor core. The firmware must be able to communicate with
> >>>>>>>>>>>>>>>>>>>>> the host via Ethernet in order to function properly.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Nick
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> On Wed, 2010-09-22 at 19:06 -0600, Malihe Ahmadi wrote:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Hi Nick,
> >>>>>>>>>>>>>>>>>>>>>> I burned SD card with the fw and the FPGA image from link you said, and
> >>>>>>>>>>>>>>>>>>>>>> find_usrps worked. Then I burned SD card with my custom FPGA image and
> >>>>>>>>>>>>>>>>>>>>>> the same fw, but find_usrps doesn't work. Any suggestion?
> >>>>>>>>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>>>>>>>> Malihe
> >>>>>>>>>>>>>>>>>>>>>> Nick Foster wrote:
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> I should have read more closely. If you are using find_usrps, you are
> >>>>>>>>>>>>>>>>>>>>>>> using the raw Ethernet FPGA and firmware. That's fine, it should work,
> >>>>>>>>>>>>>>>>>>>>>>> but it changes the stock FPGA image and firmware you should be using.
> >>>>>>>>>>>>>>>>>>>>>>> The stock FPGA image for your USRP2 can be found here:
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> http://code.ettus.com/redmine/ettus/projects/public/wiki/U2binaries
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> It is the "Raw Ethernet" FPGA image, the first link on the page.
> >>>>>>>>>>>>>>>>>>>>>>> Download the corresponding firmware image as well. This would be the
> >>>>>>>>>>>>>>>>>>>>>>> "Raw Ethernet, No WBX or XCVR" image. Load both of these onto the SD
> >>>>>>>>>>>>>>>>>>>>>>> card with the usrp2_card_burner_gui.py program. Verify that find_usrps
> >>>>>>>>>>>>>>>>>>>>>>> works correctly, and then try again with your custom FPGA image.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Nick
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> On Mon, 2010-09-20 at 16:08 -0600, Malihe Ahmadi wrote:
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> Nick, we got our USRP2 boards from Ettus in Aug. How do I know which
> >>>>>>>>>>>>>>>>>>>>>>>> firmware was used before on them? (what is the difference of UHD and
> >>>>>>>>>>>>>>>>>>>>>>>> non-UHD fw?) we have a few SD card with USRP2 boards, can I download the
> >>>>>>>>>>>>>>>>>>>>>>>> fw from one of those and load it on the SD card I am working with now?
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>>>>>>>>>> Malihe
> >>>>>>>>>>>>>>>>>>>>>>>> Nick Foster wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Try loading the stock firmware, downloaded from the website, back onto
> >>>>>>>>>>>>>>>>>>>>>>>>> the memory card and make sure that the upload process works for you.
> >>>>>>>>>>>>>>>>>>>>>>>>> Make sure that if you are using UHD firmware images (from
> >>>>>>>>>>>>>>>>>>>>>>>>> http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/wiki) you
> >>>>>>>>>>>>>>>>>>>>>>>>> are also using corresponding UHD firmware.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Nick
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> On Mon, 2010-09-20 at 14:42 -0600, Malihe Ahmadi wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Hi Nick,
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> I programmed the FPGA (and only FPGA), and basically all I have changed
> >>>>>>>>>>>>>>>>>>>>>>>>>> in it is that I replaced the DSP module with mine where it gets its
> >>>>>>>>>>>>>>>>>>>>>>>>>> inputs from Chipscope module, but after powering up the broad, the
> >>>>>>>>>>>>>>>>>>>>>>>>>> "find_usrps" returns "NO USRP2 FOUND". What could be the reason for
> >>>>>>>>>>>>>>>>>>>>>>>>>> that? Does that mean I can't program the RF center frequency and other
> >>>>>>>>>>>>>>>>>>>>>>>>>> parameters through Ethernet?
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>>>>>>>>>>>> Malihe
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Nick Foster wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Malihe,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> The SD card is not recognized by Linux because it is not formatted with
> >>>>>>>>>>>>>>>>>>>>>>>>>>> a filesystem. The GUI card burner program (usrp2_card_burner_gui.py)
> >>>>>>>>>>>>>>>>>>>>>>>>>>> should see the SD card in its list of devices. Usually it comes up
> >>>>>>>>>>>>>>>>>>>>>>>>>>> as /dev/mmcblk0. You might have to run the program as root to have
> >>>>>>>>>>>>>>>>>>>>>>>>>>> permission to write to the SD card.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Nick
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, 2010-09-17 at 20:24 -0600, Malihe Ahmadi wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi Nick,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> I just inserted the SD card into the USB SDHC memory adapter and
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> connected the adapter to my computer, but linux doesn't seem to know
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> that as a device (since I don't see any folder in My compute for that),
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> how do I get to pick the right path to the device (USB) to burn to SD card?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Malihe
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Nick Foster wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Malihe,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> The file that is written to the SD card is actually the .bin file. ISE
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> should produce both a .bit and a .bin when it compiles.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nick
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, 2010-09-17 at 18:48 -0600, Malihe Ahmadi wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi Nick,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> by FPGA image do you mean the .bit file? Thanks,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Malihe
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nick Foster wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Malihe,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nick
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Malihe
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nick Foster wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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: ahmadina@ualberta.ca
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> To: bistromat@hotmail.com
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> CC: discuss-gnuradio@gnu.org
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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: ahmadina@ualberta.ca
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Discuss-gnuradio mailing list
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Discuss-gnuradio@gnu.org
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
