The usrp has an fpga with some extra room in it. I would like to use that space.
However I do no know which port is used to program this. Further more, where can I get the source code that was used to program my fpga ? I don't want to risk getting the wrong Source code and breaking the devices functionality. Derrick Ho On May 31, 2012, at 9:00 AM, [email protected] wrote: > Send Discuss-gnuradio mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Discuss-gnuradio digest..." > > > Today's Topics: > > 1. Re: [USRP-users] what is the largest data transfer rate > between fpga and overo in e100 (Marcus D. Leech) > 2. Re: [USRP-users] what is the largest data transfer rate > between fpga and overo in e100 (Philip Balister) > 3. File sink file size mismatch problem. (Josh Stevens) > 4. How to dynamically stop the host PC receiving samples from > USRP and restart it again without touching the top block? (Alex Zhang) > 5. QAM Mod and QAM Demod block in GRC (jiajue ou) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 30 May 2012 13:03:34 -0400 > From: "Marcus D. Leech" <[email protected]> > To: [email protected] > Subject: Re: [Discuss-gnuradio] [USRP-users] what is the largest data > transfer rate between fpga and overo in e100 > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >> There is a mictor connector (J301 on both USRP2 and N2x0) that has 32 >> signal and 2 clock pins all free to be used in the FPGA. Searching for >> "mictor" in the archive of this forum will find other posts about this. >> >> However I do want to drive home the point that you are unlikely to >> find an ARM processor currently that is capable of doing anything >> useful directly with RF data at bandwidths greater than which the E100 >> is capable or indeed one with a flexible physical interface that can >> support 60MB/s....you're clearly in the realm of high-end DSP >> processors at those rates. >> > Well, keep in mind that if the goal is really 60MB/s, rather than > 60Msps, that's only about a factor of 5 beyond what an ARM can resonably > do for lightweight processing. > > > > > -- > Marcus Leech > Principal Investigator > Shirleys Bay Radio Astronomy Consortium > http://www.sbrac.org > > > > > > ------------------------------ > > Message: 2 > Date: Wed, 30 May 2012 13:19:29 -0400 > From: Philip Balister <[email protected]> > To: Ian Buckley <[email protected]> > Cc: discuss-gnuradio <[email protected]>, > [email protected] > Subject: Re: [Discuss-gnuradio] [USRP-users] what is the largest data > transfer rate between fpga and overo in e100 > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > On 05/30/2012 11:46 AM, Ian Buckley wrote: >> There is a mictor connector (J301 on both USRP2 and N2x0) that has 32 signal >> and 2 clock pins all free to be used in the FPGA. Searching for "mictor" in >> the archive of this forum will find other posts about this. >> >> However I do want to drive home the point that you are unlikely to find an >> ARM processor currently that is capable of doing anything useful directly >> with RF data at bandwidths greater than which the E100 is capable or indeed >> one with a flexible physical interface that can support 60MB/s....you're >> clearly in the realm of high-end DSP processors at those rates. > > If you need to do the processing on an ARM, you should research this > company: > > http://www.calxeda.com/products/energycards/quadnode > > Philip > >> >> >> On May 30, 2012, at 8:02 AM, Almohanad Fayez wrote: >> >>> I don't believe there's a document for this it's more of an exercise left >>> for the motivated user. >>> >>> On May 30, 2012 6:27 AM, "Page Jack" <[email protected]> wrote: >>> Hi Almohanad , >>> thanks for this information, can you provide more detail or is there any >>> doc? >>> >>> On 5/30/12, Almohanad Fayez <[email protected]> wrote: >>>> If memory serves correctly the n200 or the usrp 2 has an fpga expansion >>>> interface to some xilinx development platform which you might be able to >>>> use to create a custom solution to serve your needs. >>>> >>>> Al >>>> On May 29, 2012 6:17 PM, "Page Jack" <[email protected]> wrote: >>>> >>>>> I don't want to using a ethernet wire to connect N series to an ARM >>>>> board. >>>>> anyone have tried >>>>> build N series with ARM or DSP in one board which means the ethernet line >>>>> between N and >>>>> the processor is on PCB. >>>>> >>>>> On Wed, May 30, 2012 at 6:24 AM, Philip Balister >>>>> <[email protected]>wrote: >>>>> >>>>>> On 05/25/2012 09:18 PM, Page Jack wrote: >>>>>>> Hi Philip, >>>>>>> How does the conclusion be made that ARM can not swallow the current >>>>>>> max data transfer rate? I need to build a project that need to process >>>>>>> 60MB/s data, so any way to achieve my goal. Use a more powerful CPU or >>>>>>> use dsp on the omap? >>>>>> >>>>>> 60 MB/s is far more data than the OMAP3 can transfer from the FPGA. We >>>>>> have worked hard on configuring the GPMC interface and this figure is >>>>>> basically an order of magnitude more then the hardware will support. >>>>>> >>>>>> You need to look at the N series with Gig-E, or do the high rate >>>>>> processing in the FPGA. >>>>>> >>>>>> Philip >>>>>> >>>>>> >>>>>>> >>>>>>> On 5/25/12, Philip Balister <[email protected]> wrote: >>>>>>>> On 05/24/2012 09:46 PM, Page Jack wrote: >>>>>>>>> Thanks Ben, >>>>>>>>> does e100 use EMIF to transfer sample data between FPGA and ARM? If >>>>>>>>> so >>>>>>>>> the >>>>>>>>> data rate should be able to improved. >>>>>>>>> Anyone have tried to improve the data rate? >>>>>>>> >>>>>>>> EMIF is basically identical to GPMC. The interface uses DMA to move >>>>>> data >>>>>>>> in 2K chunks between the FPGA and memory. This is the largest >>>>>>>> transfer >>>>>>>> possible due to how we connected the address and data lines >>>>>>>> >>>>>>>> My impression of the current limiting factor is interrupt response >>>>>> time. >>>>>>>> There is probably some room for small improvements, but as Ben notes, >>>>>> we >>>>>>>> are already collecting data faster than the ARM can swallow it. >>>>>>>> >>>>>>>> Philip >>>>>>>> >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> >>>>>>>>> On Thu, May 24, 2012 at 9:01 AM, Ben Hilburn <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> The CPU sets up the initial DMA parameters, but from then on, it's >>>>>> pure >>>>>>>>>> DMA. No CPU is required. >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> Ben >>>>>>>>>> ---------------------------- >>>>>>>>>> Ben Hilburn <http://goo.gl/5DdZ3> @ Ettus Research, >>>>>>>>>> LLC<http://www.ettus.com/> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, May 23, 2012 at 5:55 PM, Page Jack <[email protected]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Thanks, does the ARM memory bus use DMA or it eat cpu? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, May 24, 2012 at 5:06 AM, Ben Hilburn >>>>>>>>>>> <[email protected]>wrote: >>>>>>>>>>> >>>>>>>>>>>> Page - >>>>>>>>>>>> >>>>>>>>>>>> The memory bus to the ARM provides 40 MBytes / second. This is >>>>>> used >>>>>>>>>>>> for >>>>>>>>>>>> streaming samples, as controlled via software. Currently, UHD >>>>>> supports >>>>>>>>>>>> 16 >>>>>>>>>>>> bit and 8 bit samples for TX & RX. The GPMC can only going to >>>>>> talk to >>>>>>>>>>>> one >>>>>>>>>>>> slave at a time; the possible slaves are TX, RX, and ethernet. >>>>>>>>>>>> So >>>>>> you >>>>>>>>>>>> can >>>>>>>>>>>> only be sending TX samples, receiving RX samples, or >>>>>>>>>>>> communicating >>>>>> via >>>>>>>>>>>> ethernet. >>>>>>>>>>>> >>>>>>>>>>>> Thus, doing the math with the numbers above, you can stream: >>>>>>>>>>>> 16 bit I, 16 bit Q -- Total: 32-bit samples -- @ 10 MSps >>>>>>>>>>>> 8 bit I, 8 bit Q -- Total: 16-bit samples -- @ 20 MSps >>>>>>>>>>>> >>>>>>>>>>>> What you choose to do with this data is obviously up to you. It >>>>>>>>>>>> is >>>>>>>>>>>> very >>>>>>>>>>>> easy to try to do more processing than the ARM can handle, in >>>>>>>>>>>> which >>>>>>>>>>>> case >>>>>>>>>>>> samples will start getting thrown out by UHD. Thus, you can >>>>>> typically >>>>>>>>>>>> process between 4 and 8 MHz of baseband bandwidth, depending on >>>>>> your >>>>>>>>>>>> application. If you are willing to dig deep into the code to >>>>>>>>>>>> make >>>>>> NEON >>>>>>>>>>>> and >>>>>>>>>>>> C64 optimizations, you can improve the performance dramatically. >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> Ben >>>>>>>>>>>> ---------------------------- >>>>>>>>>>>> Ben Hilburn <http://goo.gl/5DdZ3> @ Ettus Research, >>>>>>>>>>>> LLC<http://www.ettus.com/> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Tue, May 22, 2012 at 7:47 PM, Page Jack >>>>>>>>>>>> <[email protected]>wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> I want to know the overo model used in e100 and the largest data >>>>>>>>>>>>> transfer rate between fpga and overo in e100. >>>>>>>>>>>>> >>>>>>>>>>>>> Regards! >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> USRP-users mailing list >>>>>>>>>>>>> [email protected] >>>>>>>>>>>>> >>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> USRP-users mailing list >>>>>>>>> [email protected] >>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> USRP-users mailing list >>>>>>> [email protected] >>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>>>> >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> USRP-users mailing list >>>>> [email protected] >>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>> >>>>> >>>> >>> _______________________________________________ >>> USRP-users mailing list >>> [email protected] >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> >> > > > > ------------------------------ > > Message: 3 > Date: Wed, 30 May 2012 15:04:48 -0400 > From: Josh Stevens <[email protected]> > To: [email protected] > Subject: [Discuss-gnuradio] File sink file size mismatch problem. > Message-ID: > <CAKTbK68oVM2HKwiuU7-_i=3gLhXiucVRcgnDfW7Zo=axuvw...@mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Hello All, > > A couple of days ago i had installed a GNURadio digital image > processing block that makes an image source and sink block available as > displayed in the image below. > *Resource* : https://github.com/a-w-s/GNURadio-DIP > *Flowgraph* : http://i.imgur.com/1lJzD.png > > The output of the image source and the input to the image sink are "floats" > only and nothing else. I tried to collect pixel information into a file > sink and i am successful at that but the problem comes in when the size of > the input file size is not the same as the size of the file sink output. > > The image is a basic black and white test image called lena.bmp whose file > size is 65.0 KB. The link to which is also provided below , > *Resource to Image :* > https://www.google.com/search?q=lena+256+x+256&hl=en&prmd=imvns&source=lnms&tbm=isch&ei=_G7GT7vkC4rs8wSG99SaBg&sa=X&oi=mode_link&ct=mode&cd=2&sqi=2&ved=0CD8Q_AUoAQ&biw=1280&bih=827 > > The file size of the received file (file sink) is 76.0 KB. > > The reason why I pay more attention to this is because i intend to > calculate BER / Pixel Error Rate which would take into account a reference > stream which in this case would be the file with the extra bits , and Image > sink output ( or the demodulated output) . > > Please feel free to ask me any questions that one might have . > > Thanks and regards, > Josh. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120530/02e0b9e0/attachment.html> > > ------------------------------ > > Message: 4 > Date: Wed, 30 May 2012 20:33:26 -0500 > From: Alex Zhang <[email protected]> > To: gnuradio mailing list <[email protected]> > Subject: [Discuss-gnuradio] How to dynamically stop the host PC > receiving samples from USRP and restart it again without touching the > top block? > Message-ID: > <CA+FEAnddwUr3ijD=NkTEHqN+yhhdFx=uf1ihxd3ldnyb2hl...@mail.gmail.com> > Content-Type: text/plain; charset="windows-1252" > > Hi, > > In my applications, after the flow graph is initialized, I need to > dynamically control the receiving of the USRP samples, i.e, at time T1, I > want the USRP to transfer the received samples to PC, while in T2, I do not > allow the PC to receive these samples. > Stop receiving the unusing packets from USRP can save the traffic over > ethernet and decrease the demands of processing resource on host PC. > > the gr_mute block seems only suppress the incoming packets to further > processing, but these unusing samples can still come into the flow graph. > > Also, the tb.run and tb.wait can be executed more than twice as wish, but > it seems to be not so flexible. It would be good if there some commands > called to control the block of uhd.usrp_source to achieve such purpose? > -- > > Alex, > *Dreams can come true ? just believe.* > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120530/c78fba1c/attachment.html> > > ------------------------------ > > Message: 5 > Date: Thu, 31 May 2012 14:41:36 +0800 > From: "jiajue ou" <[email protected]> > To: <[email protected]> > Subject: [Discuss-gnuradio] QAM Mod and QAM Demod block in GRC > Message-ID: <[email protected]> > Content-Type: text/plain; charset="us-ascii" > > Hi all, > > > > I'm working on an experiment which needs to modify qam modulation block in > gnuradio. But I cannot find the source C++ file the qam blocks use. e.g., > OFDM demod block uses digital_ofdm_frame_sink in > gnuradiobuild/gnuradio/gr-digital/lib. What about qam blocks? > > Thank you for your help! > > > > Best, > > jia > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120531/3cf4a81d/attachment.html> > > ------------------------------ > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > End of Discuss-gnuradio Digest, Vol 114, Issue 33 > ************************************************* _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
