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: The time accuracy in usrp e110 (Josh Blum)
2. Re: Multi-USRP: RX signal strength (Steve Peters)
3. GPSDO Kit Documentation Link needs updating (Nowlan, Sean)
4. Re: GPSDO Kit Documentation Link needs updating (Nicholas Corgan)
5. E100 external reference and PPS (Nowlan, Sean)
6. Re: what is the largest data transfer rate between fpga and
overo in e100 (Page Jack)
----------------------------------------------------------------------
Message: 1
Date: Fri, 25 May 2012 10:54:33 -0700
From: Josh Blum <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] The time accuracy in usrp e110
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 05/25/2012 07:49 AM, Josh Blum wrote:
>
>
> On 05/25/2012 05:48 AM, ???? wrote:
>> Hi all: Now I am using e110 and want to synchronize two devices by
>> GPS. Now, I modified the UHD example (rx_timed_samples) to read
>> timestamps for the packets and found the accuracy is microseconds
>> which is not enough for us. Therefore, is it possible to read the
>> time in nanoseconds? Thanks a lot!
>>
>
> Can you tell us more about what you are doing, and what you mean by
> accuracy?
>
> Do you mean to say the GPSDOs are not reporting the same time? Do they
> have good antennas on them? are they reporting locked?
>
> This may help:
> http://files.ettus.com/uhd_docs/manual/html/gpsdo.html#using-the-gpsdo-in-your-application
>
> -josh
To reply to myself post-coffee time. The accuracy for timing sample
events on multiple e100s is probably as good down the clock period, so
at the default rate 64MHz, you have 15.625ns.
The reason that I say "clock period" is that there is a frac-N clock
synthesizer, so even if you are sharing a common ref clock, the clocks
will come up with a different phase.
Now, we will soon have an FPGA image that will sync the clock
synthesizers when the set_time_next_pps() is triggered. That should give
you synchronization/accuracy down to the jitter between the references.
I hope that helps,
-josh
------------------------------
Message: 2
Date: Fri, 25 May 2012 13:00:29 -0500
From: Steve Peters <[email protected]>
To: John Malsbury <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Multi-USRP: RX signal strength
Message-ID:
<CANgtPkiCSsnG1AOi0LwwmY-OTXHXR=P0=w15c+wpbsgixgm...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi John, I just wanted to let you know that my problem was that I wasn't
setting the antenna port. I figured it would default to TX/RX.
Thanks,
Steve
On Fri, May 18, 2012 at 2:16 PM, John Malsbury <[email protected]>wrote:
> **
> Can you port the code/GRC file that would show how you've got the
> multi-USRP device configured?
>
> -John
>
>
>
>
> On 05/18/2012 12:05 PM, Steve Peters wrote:
>
> When I receive with multiple synchronized USRPs, all but one of them will
> have very low sample magnitudes, to the point where the noise floor is
> quantized. This does not occur when running any of the USRPs on their own,
> and it's always addr0 that has the normal-magnitude samples.
>
> I have a 4-radio setup with WBX daughtercards (and simple GDB) operating
> at 450 MHz, but this happens even when running 2 radios at a time. The RX
> gain appears to be getting set correctly on all the boards (or at least
> get_rx_gain() says so). I've run test_pps_input on all the boards and it
> passed each time.
>
> Any suggestions would be much appreciated.
>
> Steve
>
>
> _______________________________________________
> USRP-users mailing
> [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/20120525/d13f1e04/attachment-0001.html>
------------------------------
Message: 3
Date: Fri, 25 May 2012 21:27:14 +0000
From: "Nowlan, Sean" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] GPSDO Kit Documentation Link needs updating
Message-ID: <195933287DC65748BA7AE867BA8E430B621A2832@apatlisdmbx02>
Content-Type: text/plain; charset="us-ascii"
FYI, the link to GPSDO Kit installation on
http://files.ettus.com/uhd_docs/manual/html/gpsdo.html is broken. New location
is http://www.ettus.com/content/files/gpsdo-kit_datasheet.pdf .
Thanks,
Sean
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120525/4a378563/attachment-0001.html>
------------------------------
Message: 4
Date: Fri, 25 May 2012 15:07:40 -0700
From: Nicholas Corgan <[email protected]>
To: "Nowlan, Sean" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] GPSDO Kit Documentation Link needs updating
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Thanks, that will be changed soon.
On 05/25/2012 02:27 PM, Nowlan, Sean wrote:
>
> FYI, the link to GPSDO Kit installation on
> http://files.ettus.com/uhd_docs/manual/html/gpsdo.html is broken. New
> location is http://www.ettus.com/content/files/gpsdo-kit_datasheet.pdf .
>
> Thanks,
>
> Sean
>
>
>
> _______________________________________________
> 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/20120525/36317505/attachment-0001.html>
------------------------------
Message: 5
Date: Fri, 25 May 2012 22:12:02 +0000
From: "Nowlan, Sean" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] E100 external reference and PPS
Message-ID: <195933287DC65748BA7AE867BA8E430B621A28AA@apatlisdmbx02>
Content-Type: text/plain; charset="us-ascii"
Hi all,
I have an E100 (rev 3) and I would like to use an external reference and PPS. I
soldered straight SMA connectors onto J10 and J13 (REF IN and PPS IN,
respectively). I'm supplying a 10MHz and PPS reference to the board, but I'm
not sure how to tell the clock gen circuit to use the external reference.
I tried set_clock_source("external", 0) but the reference won't lock. Do I need
to burn an EEPROM setting as with the N2xx? Is there a jumper I need to change?
FYI I installed UHD 3.4.2 release.
Thanks,
Sean
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120525/b037a9ac/attachment-0001.html>
------------------------------
Message: 6
Date: Sat, 26 May 2012 09:18:37 +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:
<CAMeG1V+JBpi5pBzmEeq4xVXGuYZjXfU9a0dUG8t4O=dka5t...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
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?
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
End of USRP-users Digest, Vol 21, Issue 25
******************************************
