Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
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 USRP-users digest..."
Today's Topics:
1. Re: Sampling frequency offset between 2 USRP2 devices ?
([email protected])
2. Re: what is the largest data transfer rate between fpga and
overo in e100 (Philip Balister)
3. Re: what is the largest data transfer rate between fpga and
overo in e100 (Page Jack)
4. Re: what is the largest data transfer rate between fpga and
overo in e100 (Almohanad Fayez)
5. Re: Oddity in E1xx FPGA (John Buetefuer)
6. Oddity in E1xx FPGA (John Buetefuer)
7. Multifrequency jamming (Dario Lombardo)
8. Re: GPSDO on usrp2 (Josh Blum)
9. Re: GPSDO on usrp2 (Dario Lombardo)
10. Re: what is the largest data transfer rate between fpga and
overo in e100 (Page Jack)
11. problem using LO offset with USRP1 (Stefano Speretta)
12. What is the largest data transfer rate between the PC &
USRP2/USRP N Series through a GB ethernet cable? (Nazmul Islam)
13. Re: what is the largest data transfer rate between fpga and
overo in e100 (Almohanad Fayez)
14. Re: what is the largest data transfer rate between fpga and
overo in e100 (Ian Buckley)
----------------------------------------------------------------------
Message: 1
Date: Tue, 29 May 2012 13:05:29 -0400
From: [email protected]
To: Sanat Gulvadi <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Sampling frequency offset between 2 USRP2
devices ?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Just factor in the +/- 5PPM uncertainty in the clock on the two
devices:
100Mhz/16 = 6.25e6 * +/-5PPM
= +/- 31.25 Hz uncertainty in
sample rate
On 29 May 2012 11:58, Sanat Gulvadi wrote:
> I want to
design the system without any external synchronization. All my
corrections I plan to do within the receiver. I apologize if I seem to
be asking the same question again. But in my case, with no
synchronization with an external reference clock, should I be assuming
that 100e6/16 Hz sampling rate on one USRP2 will not be the same as
100e6/16 Hz sampling rate on the other ? If this is the case, am I also
right in assuming that this is because 100MHz doesn't really mean the
same resulting real-world clock frequency on different devices, because
of these imperfections in the crystals ?
>
> Regards,
> Sanat
>
> On
Tue, May 29, 2012 at 5:00 PM, <[email protected] [2]> wrote:
>
>> The
master oscillator on the USRP2 is a +/- 5PPM TCXO oscillator. Crystal
oscillators are imperfect, and they get closer to perfect the more you
spend on them. Which is why one generally uses an external reference to
move from 5PPM to 50PPB, using a GPSDO or similar.
>>
>> So, you can
take the 5PPM estimate and plug it into your calculations.
>>
>>
-Marcus
>>
>> On 29 May 2012 10:50, Sanat Gulvadi wrote:
>>
>>>
Thanks for the quick response. Could you help me understand this better
please? The different in the physical constraints that affect the clocks
on board the devices that cause the the carrier frequency offset also
causes differences in sampling rates ? So if I am using same
decimation/interpolation factors, setting the sampling frequency on Tx
to 100e6/16 and on the Rx side also to 100e6/16 will still result in
them being sampled at different rates ? What would typically such
numbers ? I have the RFX2400 on both devices and carrier frequency set
to 2.44GHz.
>>>
>>> On Tue, May 29, 2012 at 2:07 PM, Marcus D. Leech
<[email protected] [1]> wrote:
>>>
>>>> On 05/29/2012 07:33 AM, Sanat
Gulvadi wrote:
>>>>
>>>>> Greetings,
>>>>>
>>>>> I apologize in
advance if this question has already been asked or has already been
addressed in the manual. I was unsuccessful in finding the answer.
Should I expect an offset in the sampling frequencies between the 2
devices ? Just to add a little background :
>>>>> I am implementing an
OFDM based communication system using 2 USRP2-REV4s each with an RFX2400
board. My algorithm is supposed to estimate and correct the different
effects that an OFDM symbol might experience. With simulated
transmission within MATLAB alone, the whole algorithm works fine with
the following simulated channel effects
>>>>> * unknown arrival time by
placing a random number of noise samples before and after the sample
stream.
>>>>> * frequency offset simulated by multiplying the time
domain digital samples by an exponential term
>>>>> * additive noise
using function like like awgn()
>>>>> * multipath by summing with say
_cyclicprefixlength_/4 number of multipath components each multiplied
with a small amplitude with the original stream
>>>>> * purposely
placing the FFT window incorrectly and correcting the resulting
constellation for each symbol after demodulation etc.
>>>>> * also found
a linear phase error that was causing the whole constellation to rotate
proportionally with each subsequent OFDM symbol which I corrected
for.
>>>>> I am no OFDM expert but from my reading, I thought I had
accounted for the different effects that can cause the signal to
degrade.
>>>>> So to bring me back to my actual question for the list
is that the only thing that occured to me is whether there is possible
chance for there to be a sampling frequency offset between the 2 devices
when I attempt a real transmission. Is there any to be expected ?
>>>>>
>>>>> Best Regards,
>>>>> Sanat
>>>> Unless your devices are
synchronized to an external reference, there is a near-certainty that
there will be an offset in the sampling
>>>> frequencies between the two
devices -- the master clocks on the two devices won't be synchronized,
which leads both to sample-rate
>>>> differences, and actual
tuned-frequency differences.
>>>>
>>>> --
>>>> Marcus Leech
>>>>
Principal Investigator
>>>> Shirleys Bay Radio Astronomy Consortium
>>>>
http://www.sbrac.org
>>>
>>> --
>
> --
Links:
------
[1]
mailto:[email protected]
[2] mailto:[email protected]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120529/fb36451b/attachment-0001.html>
------------------------------
Message: 2
Date: Tue, 29 May 2012 18:24:01 -0400
From: Philip Balister <[email protected]>
To: Page Jack <[email protected]>
Cc: [email protected], discuss-gnuradio
<[email protected]>
Subject: Re: [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/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
>
------------------------------
Message: 3
Date: Wed, 30 May 2012 09:17:24 +0800
From: Page Jack <[email protected]>
To: Philip Balister <[email protected]>
Cc: [email protected], discuss-gnuradio
<[email protected]>
Subject: Re: [USRP-users] what is the largest data transfer rate
between fpga and overo in e100
Message-ID:
<cameg1vjupu3nxevptdhblqvwo6p+cror2qchk0xdpeipzth...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120530/438f8fb5/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 29 May 2012 20:58:59 -0700
From: Almohanad Fayez <[email protected]>
To: Page Jack <[email protected]>
Cc: Philip Balister <[email protected]>, [email protected],
discuss-gnuradio <[email protected]>
Subject: Re: [USRP-users] what is the largest data transfer rate
between fpga and overo in e100
Message-ID:
<cabv+bnxsvxrqhmeldyct6am3esok9eotk+dknqp7_mf6ddo...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120529/98f45a73/attachment-0001.html>
------------------------------
Message: 5
Date: Wed, 30 May 2012 14:40:43 +0930
From: John Buetefuer <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Oddity in E1xx FPGA
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
It appears I may have spoken too soon. If I remove these signals the
port stops working, which suggests that I have outdated schematics for
the E100.
Are the latest E100/E110 schematics available? (Rev4?)
Cheers
John
On 30/05/2012 1:15 PM, John Buetefuer wrote:
> I've just commenced integrating a 3rd party GPS unit (ie, not a GPSDO)
> with an E100 and have noticed the following odd things with the E100
> FPGA and schematics.
>
> * The FPGA appears to be driving the overo_rxd1 net (and uart Rx input
> pin on the overo) with a signal from the FPGA input pin "fpga_rxd1"
> (ball AB8) - which according to my schematics is not connected on the
> PCB at all (presume this is pulled high by the FPGA I/O pull-ups).
> [fpga/usrp2/top/E1x0/u1e.v]
>
> //
> /////////////////////////////////////////////////////////////////////////
> // UART level conversion
> assign fpga_txd1 = overo_txd1;
> assign overo_rxd1 = fpga_rxd1;
>
> overo_rxd1 is defined as an output pin, which sees it driving against
> the MAX232 driving this line - surely this is not correct or intended.?
>
> It looks to me that this code may have had some historical purpose on
> an earlier rev of the board, but perhaps with the current version of
> the hardware, is not correct?
>
> On a somewhat related note, can someone confirm that on the E1x0
> series units, the FPGA firmware does not communicate with the GPSDO
> unit at all (via RS232), and that the UHD accesses the GPS via the
> Overo serial port (ttyO0)?
>
> Cheers
>
> John
------------------------------
Message: 6
Date: Wed, 30 May 2012 13:15:26 +0930
From: John Buetefuer <[email protected]>
To: [email protected]
Subject: [USRP-users] Oddity in E1xx FPGA
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
I've just commenced integrating a 3rd party GPS unit (ie, not a GPSDO)
with an E100 and have noticed the following odd things with the E100
FPGA and schematics.
* The FPGA appears to be driving the overo_rxd1 net (and uart Rx input
pin on the overo) with a signal from the FPGA input pin "fpga_rxd1"
(ball AB8) - which according to my schematics is not connected on the
PCB at all (presume this is pulled high by the FPGA I/O pull-ups).
[fpga/usrp2/top/E1x0/u1e.v]
//
/////////////////////////////////////////////////////////////////////////
// UART level conversion
assign fpga_txd1 = overo_txd1;
assign overo_rxd1 = fpga_rxd1;
overo_rxd1 is defined as an output pin, which sees it driving against
the MAX232 driving this line - surely this is not correct or intended.?
It looks to me that this code may have had some historical purpose on an
earlier rev of the board, but perhaps with the current version of the
hardware, is not correct?
On a somewhat related note, can someone confirm that on the E1x0 series
units, the FPGA firmware does not communicate with the GPSDO unit at all
(via RS232), and that the UHD accesses the GPS via the Overo serial port
(ttyO0)?
Cheers
John
------------------------------
Message: 7
Date: Wed, 30 May 2012 09:22:53 +0200
From: Dario Lombardo <[email protected]>
To: [email protected]
Subject: [USRP-users] Multifrequency jamming
Message-ID:
<CAOYJJfvDGEuVAHA-6gfbrxRJjc4nxH=t1tn+pisvzsfz4u8...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Greetings
I was wondering if it is possible to use the usrp2 with a sbx card to jam
multiple frequency at a time. Or, if not, if it is possible to change
quickly the transmitting frequency in order to have the same behaviour.
I'm trying to transmit on GSM frequency to make my phone to lose
signal. I've tried to start from uhd_siggen and tried to transmit a couple
of seconds for every jammed frequency. The phone loses signal but when I
switch to the second freq, it comes back to the first.
Did anyone tried it before?
Thanks a lot!
Dario
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120530/af5f58ab/attachment-0001.html>
------------------------------
Message: 8
Date: Wed, 30 May 2012 01:12:20 -0700
From: Josh Blum <[email protected]>
To: Dario Lombardo <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] GPSDO on usrp2
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 05/29/2012 02:15 AM, Dario Lombardo wrote:
> On Tue, May 29, 2012 at 6:02 AM, Josh Blum <[email protected]> wrote:
>
>>
>> The printout from UHD tells me that it is correctly communicating with
>> the gpsdo unit.
>>
>>
> So, your point is that I have a bad gps signal?
>
My best guess short of checking the lock status.
Have been able to lock other GPSDO units to the same antenna?
>
>> You can use the available sensors for the GPSDO to query for locked
>> status among other things:
>>
>> http://files.ettus.com/uhd_docs/manual/html/gpsdo.html#using-the-gpsdo-in-your-application
>
>
> Are there apps ready-to-use to query it? I don't have programmed usrp ever
> :(.
>
Yes but unfortunately the utility hasn't been merged and packaged into
an installer yet.
I wonder if such a check would be useful to have in kalibrate itself.
-josh
------------------------------
Message: 9
Date: Wed, 30 May 2012 12:28:20 +0200
From: Dario Lombardo <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] GPSDO on usrp2
Message-ID:
<CAOYJJfuwoJwomDMa+QYbLi55G4K8qx=fspgziynaq6bndqx...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
On Wed, May 30, 2012 at 10:12 AM, Josh Blum <[email protected]> wrote:
>
>
> On 05/29/2012 02:15 AM, Dario Lombardo wrote:
> > On Tue, May 29, 2012 at 6:02 AM, Josh Blum <[email protected]> wrote:
> >
> >>
> >> The printout from UHD tells me that it is correctly communicating with
> >> the gpsdo unit.
> >>
> >>
> > So, your point is that I have a bad gps signal?
> >
>
> My best guess short of checking the lock status.
>
> Have been able to lock other GPSDO units to the same antenna?
>
No, this is my only gpsdo unit.
>
> >
> >> You can use the available sensors for the GPSDO to query for locked
> >> status among other things:
> >>
> >>
> http://files.ettus.com/uhd_docs/manual/html/gpsdo.html#using-the-gpsdo-in-your-application
> >
> >
> > Are there apps ready-to-use to query it? I don't have programmed usrp
> ever
> > :(.
> >
>
> Yes but unfortunately the utility hasn't been merged and packaged into
> an installer yet.
>
> I wonder if such a check would be useful to have in kalibrate itself.
>
I think so... very useful.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120530/8065ca4e/attachment-0001.html>
------------------------------
Message: 10
Date: Wed, 30 May 2012 21:27:48 +0800
From: Page Jack <[email protected]>
To: Almohanad Fayez <[email protected]>
Cc: Philip Balister <[email protected]>, [email protected],
discuss-gnuradio <[email protected]>
Subject: Re: [USRP-users] what is the largest data transfer rate
between fpga and overo in e100
Message-ID:
<cameg1vkbyt7ph6vdl7qxv+x_-vee+tq1iyfbhezsa-kvp3n...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
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
>>
>>
>
------------------------------
Message: 11
Date: Wed, 30 May 2012 15:55:39 +0200
From: Stefano Speretta <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] problem using LO offset with USRP1
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-15"; Format="flowed"
Hello,
I am seeing a spurious component at DC using a USRP1 and WBX board.
Similar problems were already reported several times in the mailing list
and
the suggestion was to use an offset in tuning to move this DC component
out of band.
I am trying to do this but I keep seeing the same result (so that DC
component in band). I am using a USRP1 and I attached 2 50ohm
terminators to the two antenna
ports to eliminate signals coming from outside but the DC component is
still there, even if I change the RX tuning frequency.
If I do not use the LO offset, in my application I set the RX frequency
like this:
uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make(args);
....
double freq = 200e6;
uhd::tune_result_t tuned = usrp->set_rx_freq(freq);
and if I print tuned.to_string I get this:
Tune Result:
Target RF Freq: 200.000000 (MHz)
Actual RF Freq: 199.999723 (MHz)
Target DSP Freq: -0.000277 (MHz)
Actual DSP Freq: -0.000277 (MHz)
If I do an FFT of the received signal it looks like in the
no_lo_offset.png that is attached (span is 20 kHz centered around 200
MHz and the spike is 15 dB above noise floor).
If I set the offset (5 kHz in this case, I tried with other values too
and the result is the same) in the tune function, like this:
uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make(args);
....
double freq = 200e6;
uhd::tune_result_t tuned = usrp->set_rx_freq(freq, 5000);
printing tuned.to_string gives:
Tune Result:
Target RF Freq: 200.005000 (MHz)
Actual RF Freq: 200.004932 (MHz)
Target DSP Freq: 0.004932 (MHz)
Actual DSP Freq: 0.004932 (MHz)
But the FFT shows again that strong DC peak (check lo_offset.png
attached). If you look carefully you will see that there is a Gaussian
shaped noise around +5 khz
which is exactly the noise around DC, so the offset tuning is working
fine (you see the same noise around DC in the other picture).
The problem is that the peak around DC is always there.
I also tried enabling and disabling the rx_dc_offset (using
set_rx_dc_offset) but with no luck.
The spurious signal that I see is still there if I tune the the receiver
to other frequencies (so I do not think this is an harmonic of the
internal oscillator). The same peak can also be seen
by using rx_ascii_art.
Is it possible that there is some rounding error in the cordic or
decimation stages leading to this DC error? Or in the conversions in the PC?
Does anybody have ideas on what could be the source and how to eliminate
this problem?
Thanks a lot,
Stefano
-------------- next part --------------
A non-text attachment was scrubbed...
Name: no_lo_offset.png
Type: image/png
Size: 42429 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120530/41c711c0/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lo_offset.png
Type: image/png
Size: 41157 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120530/41c711c0/attachment-0003.png>
------------------------------
Message: 12
Date: Wed, 30 May 2012 10:11:21 -0400
From: Nazmul Islam <[email protected]>
To: [email protected]
Subject: [USRP-users] What is the largest data transfer rate between
the PC & USRP2/USRP N Series through a GB ethernet cable?
Message-ID:
<caftrfeyyse-rds_9f12x5awrnbf-astqsugzawd6evfxvex...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hello,
I found a tutorial on GNUradio (
http://www.snowymtn.ca/gnuradio/gnuradiodoc-4.pdf) that mentions that USRP
downconverts the signal to 8 Mega Sample per second before passing it to
the USB cable. They do it due to the 32 Mega byte data transfer rate of USB
cable and 16 bit I & Q samples. I assume that this information applies to
USRP1 with USB cable.
I am planning to use USRP2 & USRP N series along with GB ethernet cables in
my experiments. Do these USRP's downconvert the signal before passing on to
the computer? If my computer is fast enough, can I transmit and receive (in
seperate USRP's) a signal with 20 MHz bandwidth?
Thanks,
Nazmul
--
Muhammad Nazmul Islam
Graduate Student
Electrical & Computer Engineering
Wireless Information & Networking Laboratory
Rutgers, USA.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120530/ec5c1abc/attachment-0001.html>
------------------------------
Message: 13
Date: Wed, 30 May 2012 08:02:28 -0700
From: Almohanad Fayez <[email protected]>
To: Page Jack <[email protected]>
Cc: Philip Balister <[email protected]>, [email protected],
discuss-gnuradio <[email protected]>
Subject: Re: [USRP-users] what is the largest data transfer rate
between fpga and overo in e100
Message-ID:
<cabv+bnvuaywga+10efszjtvfybrh_o7nkgrhe9g867h9soz...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
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
> >>
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120530/da081431/attachment-0001.html>
------------------------------
Message: 14
Date: Wed, 30 May 2012 08:46:48 -0700
From: Ian Buckley <[email protected]>
To: Almohanad Fayez <[email protected]>
Cc: Philip Balister <[email protected]>, [email protected],
discuss-gnuradio <[email protected]>
Subject: Re: [USRP-users] what is the largest data transfer rate
between fpga and overo in e100
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
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.
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120530/7be36513/attachment-0001.html>
------------------------------
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
End of USRP-users Digest, Vol 21, Issue 29
******************************************
