Re: Fwd: Re: [Discuss-gnuradio] USRP2, is that possible to skip the Ethe

discuss-gnuradio
[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
[Prev in Thread]
Current Thread
[Next in Thread]
Fwd: Re: [Discuss-gnuradio] USRP2, is that possible to skip the Ethernet and pass data through general purpose (physically accessible) inputs to the FPGA?, Malihe Ahmadi, 2010/10/29
- 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?, Nick Foster <=
Prev by Date: Re: [Discuss-gnuradio] Decreasing Quantization Error
Next by Date: Re: [Discuss-gnuradio] Problem of using UHD blocks as Tx & Rx
Previous by thread: Fwd: Re: [Discuss-gnuradio] USRP2, is that possible to skip the Ethernet and pass data through general purpose (physically accessible) inputs to the FPGA?
Next by thread: [Discuss-gnuradio] Decreasing Quantization Error
Index(es):
- Date
- Thread