[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fwd: Re: [Discuss-gnuradio] USRP2, is that possible to skip the Ethe
From: |
Nick Foster |
Subject: |
Re: Fwd: 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, 29 Oct 2010 11:44:12 -0700 |
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
> <address@hidden>
> To:
> Nick Foster <address@hidden>
>
>
> 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: 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
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Discuss-gnuradio mailing list
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> address@hidden
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio