Re: [Discuss-gnuradio] Discuss-gnuradio Digest, Vol 114, Issue 33

[Derrick Ho]

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, address@hidden wrote:

> Send Discuss-gnuradio mailing list submissions to
>    address@hidden
> 
> 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
>    address@hidden
> 
> You can reach the person managing the list at
>    address@hidden
> 
> 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" <address@hidden>
> To: address@hidden
> Subject: Re: [Discuss-gnuradio] [USRP-users] what is the largest data
>    transfer rate between fpga and overo in e100
> Message-ID: <address@hidden>
> 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 <address@hidden>
> To: Ian Buckley <address@hidden>
> Cc: discuss-gnuradio <address@hidden>,
>    address@hidden
> Subject: Re: [Discuss-gnuradio] [USRP-users] what is the largest data
>    transfer rate between fpga and overo in e100
> Message-ID: <address@hidden>
> 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" <address@hidden> wrote:
>>> Hi Almohanad ,
>>> thanks for this information, can you provide more detail or is there any 
>>> doc?
>>> 
>>> On 5/30/12, Almohanad Fayez <address@hidden> 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" <address@hidden> 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
>>>>> <address@hidden>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 <address@hidden> 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 <address@hidden>
>>>>>>>>> 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 <address@hidden>
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> Thanks, does the ARM memory bus use DMA or it eat cpu?
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On Thu, May 24, 2012 at 5:06 AM, Ben Hilburn
>>>>>>>>>>> <address@hidden>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
>>>>>>>>>>>> <address@hidden>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
>>>>>>>>>>>>> address@hidden
>>>>>>>>>>>>> 
>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> _______________________________________________
>>>>>>>>> USRP-users mailing list
>>>>>>>>> address@hidden
>>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> USRP-users mailing list
>>>>>>> address@hidden
>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> USRP-users mailing list
>>>>> address@hidden
>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>> 
>>>>> 
>>>> 
>>> _______________________________________________
>>> USRP-users mailing list
>>> address@hidden
>>> 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 <address@hidden>
> To: address@hidden
> Subject: [Discuss-gnuradio] File sink file size mismatch problem.
> Message-ID:
>    <address@hidden>
> 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 <address@hidden>
> To: gnuradio mailing list <address@hidden>
> 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:
>    <address@hidden>
> 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" <address@hidden>
> To: <address@hidden>
> Subject: [Discuss-gnuradio] QAM Mod and QAM Demod block in GRC
> Message-ID: <address@hidden>
> 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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> End of Discuss-gnuradio Digest, Vol 114, Issue 33
> *************************************************