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: path for the latest images for usrp N210 (Josh Blum)
2. Synchronizing multiple USRPs (Khalid Jamil)
3. C++ affects on the rbf file (Daniel Artis)
4. Re: C++ affects on the rbf file (Josh Blum)
5. USRP2 frequency offset (Song, Mujun CAPT KR USAF AETC AFIT/ENG)
6. Re: Fwd: Inconsistence in clock modification (Jason Abele)
7. Re: Synchronizing multiple USRPs (Matt Ettus)
8. experience changing USRP2 main oscillator w/UHD?
([email protected])
9. Re: [Discuss-gnuradio] Re: UHD Announcement - February 25rd
2011 (Marc Epard)
----------------------------------------------------------------------
Message: 1
Date: Sun, 27 Feb 2011 22:54:30 -0800
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] path for the latest images for usrp N210
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
> Hi ,
> I want to update my USRP N210 with the latest firmware and fpga images.
> Is the image (usrp_n2xx_fw.bin , usrp_n210_fpga.bin) in the folder
> UHD-images-002.20110122035832.cd5631f-Linux<http://www.ettus.com/downloads/uhd_images/UHD-images-most-recent/UHD-images-002.20110122035832.cd5631f-Linux.zip>
> at http://www.ettus.com/downloads/uhd_images/UHD-images-most-recent/ the
> correct image to use?
>
That is correct.
> Just wanted to confirm ,so that I don't brick my USRP N210 !!
>
Make sure you use the most recent net burner from the uhd repository and
that should not be possible.
-Josh
------------------------------
Message: 2
Date: Mon, 28 Feb 2011 10:48:47 +0300
From: Khalid Jamil <[email protected]>
To: [email protected], [email protected]
Subject: [USRP-users] Synchronizing multiple USRPs
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hello,
I have eight (08) USRP N210s that has been synchronized using 10MHZ and 1PPS
reference. I am receiving data from them using a gigabit ethernet switch to
my computer.
My question is when I will receive packets from all of them through a single
switch, how will I know the time reference for each sample?
Thanks,
Khalid.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20110228/9256f7bf/attachment-0001.html>
------------------------------
Message: 3
Date: Sun, 27 Feb 2011 23:54:20 -0800 (PST)
From: Daniel Artis <[email protected]>
To: USRP <[email protected]>
Subject: [USRP-users] C++ affects on the rbf file
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi All,
I understand that the python statements implement C++ functions and that the
FPGA on the USRP runs verilog. The default file: std_2rxhb_2tx.rbf get changed
by C++ code when a python file is ran correct? How does this rbf file get
changed? Thank you for the help.
Sincerely,
Daniel K. Artis
[email protected]
(310) 686-4134
------------------------------
Message: 4
Date: Mon, 28 Feb 2011 00:23:24 -0800
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] C++ affects on the rbf file
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 02/27/2011 11:54 PM, Daniel Artis wrote:
> Hi All,
>
> I understand that the python statements implement C++ functions and that the
> FPGA on the USRP runs verilog. The default file: std_2rxhb_2tx.rbf get
> changed
> by C++ code when a python file is ran correct? How does this rbf file get
> changed? Thank you for the help.
>
FPGAs do not really "run" verilog. The verilog description is turned
into a digital circuit design that can be loaded into the FPGA. This
design is not changed by any python or C++ code, and I dont think that
is possible to do.
-Josh
> Sincerely,
>
> Daniel K. Artis
> [email protected]
> (310) 686-4134
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 5
Date: Mon, 28 Feb 2011 08:36:02 -0500
From: "Song, Mujun CAPT KR USAF AETC AFIT/ENG"
<[email protected]>
To: <[email protected]>
Subject: [USRP-users] USRP2 frequency offset
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi, all.
I know there's a frequency offset that comes from USRP2 hardware. But I
have one more question on the frequency offset. I found that the
frequency offset varies as the decimation factor changes. So does the
frequency offset varies for every decimation factor or for every
individual USRP2? Or do every USRP2 have the same offset or does the
offset varies every time I run the USRP2?
Hope to get response from you.
Thanks,
Mujun
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20110228/f00cf8e8/attachment-0001.html>
------------------------------
Message: 6
Date: Mon, 28 Feb 2011 07:04:26 -0800
From: Jason Abele <[email protected]>
To: Juli?n David V?squez Guti?rrez <[email protected]>
Cc: ettus <[email protected]>
Subject: Re: [USRP-users] Fwd: Inconsistence in clock modification
Message-ID: <20110228150426.GK1926@manzanita>
Content-Type: text/plain; charset=iso-8859-1
On Sat, Feb 26, 2011 at 05:02:31PM -0500, Juli?n David V?squez Guti?rrez wrote:
> The incosistence is:
>
> GNUradio: Move C925 to C926.
> In Ettus: Move 0.01uF 0603 capacitor C929 to C926
That is a typo in our documentation, the Ettus UHD documentation will be
updated to read: Move 0.01uF 0603 capacitor C925 to C926
Thanks
Jason
------------------------------
Message: 7
Date: Mon, 28 Feb 2011 08:26:26 -0800
From: Matt Ettus <[email protected]>
To: Khalid Jamil <[email protected]>
Cc: [email protected], [email protected]
Subject: Re: [USRP-users] Synchronizing multiple USRPs
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 02/27/2011 11:48 PM, Khalid Jamil wrote:
> Hello,
>
> I have eight (08) USRP N210s that has been synchronized using 10MHZ and
> 1PPS reference. I am receiving data from them using a gigabit ethernet
> switch to my computer.
>
> My question is when I will receive packets from all of them through a
> single switch, how will I know the time reference for each sample?
The packets are all time stamped, and the UHD takes care of
synchronizing everything, so you don't need to do anything special.
In the future, you don't need to post to both gnuradio and usrp-users.
Please choose the one which fits your question better.
Thanks,
Matt
------------------------------
Message: 8
Date: Mon, 28 Feb 2011 16:33:54 +0000
From: [email protected]
To: [email protected]
Subject: [USRP-users] experience changing USRP2 main oscillator w/UHD?
Message-ID: <W989713055176021298910834@webmail38>
Content-Type: text/plain; charset="ansi_x3.110-1983"
USRP2 Users/Modders
I'm interested in hearing from anyone that's changed the main oscillator on a
USRP2 and is running with UHD.
Due to sample rate and performance concerns we decided to look into changing
the main oscillator on the U2. We're actually trying 2 different scenarios:
(1) replace the main oscillator. We purchased replacement VCXO's from Crystek
for this. To get the sample rate we want we went with 122.88MHz oscillators (we
program the ad9510 to divide this by 2 which gets us our sample rate and also
also keeps the frequency under 100MHz to avoid possible overclocking/timing
issues).
(2) rework the board and use the ref clock input to bring in the new main
clock (allowing us to use an external signal generator for the main clock). In
this case the clock is running at 61.44MHz (122.88MHz/2).
We had the latter working with the legacy driver/firmware but getting it going
with UHD is proving to be a bit more challenging as a lot of the firmware
functionality has migrated to the host (and we're slowly picking our way
through the source and identifying changes/updates that need to be made).
The former has proven to be even more challenging as there appears to some
places in the host code that make an assumption that get_master_clock_rate()
returns the oscillator frequency and other places that assume it's the FPGA
clock rate (i.e., input clock == output clock, which is not the case when we're
using the 122MHz osc).
Anyway, if you've attempted to do this, it would be great to compare notes with
you.
Thanks!
--Bob
------------------------------
Message: 9
Date: Mon, 28 Feb 2011 10:54:53 -0600
From: Marc Epard <[email protected]>
To: [email protected]
Cc: Feng Andrew Ge <[email protected]>
Subject: Re: [USRP-users] [Discuss-gnuradio] Re: UHD Announcement -
February 25rd 2011
Message-ID: <[email protected]>
Content-Type: text/plain; CHARSET=US-ASCII
I think I just encountered this bug, too. In our case, it's a C++ tool using
UHD directly. The first transmit+receive works, but from then on it looks
there's nothing's being transmitted until I kill the process and restart it. I
haven't dug very deep, yet, though.
-Marc
On Feb 28, 2011, at 10:21 AM, Feng Andrew Ge wrote:
> Josh,
>
> Thanks for sharing the information and your changes sound quite reasonable.
>
> However, it seems that your changes have introduced some bugs at the
> transmitter side. I updated my system using your new code (following your
> instructions in your Feb. 24's email titled "Re: GRC + N210 + RFX2200 + UHD
> not working"); then I ran python-based benchmark_tx.py. I tested two cases:
> in the first case, I sent packets continuously and it worked well; in the
> second case, I sent packets every second and the transmitter side could send
> only about 10~12 packets, then stopped sending data into USRP2 (based on
> observation from wireshark results). Both cases used 1500B for each packet
> and the send-buff-size was 100kB.
>
> Would you please take a look at this?
>
> Andrew
>
> ----------
>
> Message: 3
> Date: Sat, 26 Feb 2011 16:19:06 -0500
> From: Feng Andrew Ge<[email protected]>
> Subject: [Discuss-gnuradio] Re: UHD Announcement - February 25rd 2011
> To:[email protected]
> Message-ID:<[email protected]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Josh,
>
> When you say "2x" performance increase, do you mean CPU performance or
> send()/recv() latency? Do you mind saying a few words on what changes
> you have made?
>
> Andrew
>
> ---------------
>
> Much of the performance gains involved removing things out of the
> fast-path that only needed to be called once at initialization (forgoing
> code simplicity for performance). Example: a vector of pointers, a bound
> callable object; many of which had calls to malloc and free which incurs
> quite a lot of unnecessary overhead.
>
> Less cpu cycles/less time are spent in the send()/recv() calls. This
> roughly worked out to about half the CPU usage when looking at oprofile.
> Because of this, the overall latency is reduced. We measured about 250us
> RTT from device to host and back to device with the latency measurement
> app in uhd examples.
>
> -josh
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> [email protected]
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
------------------------------
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
End of USRP-users Digest, Vol 6, Issue 44
*****************************************
