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. B200 / B210 EMI Shields (Paolo Nenzi via USRP-users)
2. uhd_find_devices cannot find the B210
(Greg Hulands via USRP-users)
3. Re: uhd_find_devices cannot find the B210
(Ian Buckley via USRP-users)
4. Re: uhd_find_devices cannot find the B210
(Greg Hulands via USRP-users)
5. Re: uhd_find_devices cannot find the B210
(Martin Braun via USRP-users)
6. Re: Help diagnosing SDR software lockups when using B200?
(Robert McIntyre via USRP-users)
7. Re: Help diagnosing SDR software lockups when using B200?
(Robert McIntyre via USRP-users)
8. General precautions while using USRP B210
(ali hanif via USRP-users)
9. question about GPSDO module (Francois Quitin via USRP-users)
10. Re: New to USRP :: software development platform
recommendations sought (Ethem Sozer via USRP-users)
11. Re: USRP Documentation - latency (Andre Puschmann via USRP-users)
12. Re: Phase Offset between USRP-B210 Channels
(Stefan Ereth via USRP-users)
13. Re: General precautions while using USRP B210
(Marcus Leech via USRP-users)
14. Re: question about GPSDO module (Marcus M?ller via USRP-users)
----------------------------------------------------------------------
Message: 1
Date: Sat, 3 May 2014 19:28:09 +0200
From: Paolo Nenzi via USRP-users <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] B200 / B210 EMI Shields
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hello,
I recently bought a B210 and I see that designers have provided areas for
soldering EMI shields.
Has anyone applied PCB level shielding ?
Is there any suggested part number ?
Thanks,
Paolo
------------------------------
Message: 2
Date: Mon, 05 May 2014 09:57:00 -0700
From: Greg Hulands via USRP-users <[email protected]>
To: [email protected]
Subject: [USRP-users] uhd_find_devices cannot find the B210
Message-ID: <[email protected]>
Content-Type: text/plain; CHARSET=US-ASCII
Hi,
I received my B210 this morning and when I run uhd_find_devices, it say it
can't find any devices.
$ uhd_find_devices
linux; GNU C++ version 4.8.1; Boost_105300; UHD_003.005.003-0-unknown
No UHD Devices Found
lsusb shows the device, but the product id is different to what is in
/lib/udev/rules.d/40-uhd-host.rules
Bus 003 Device 006: ID 2500:0020
So I added a line to the rules file
SUBSYSTEMS=="usb", ATTRS{idVendor}=="2500", ATTRS{idProduct}=="0020",
GROUP:="usrp", MODE:="0660"
I reloaded udev, unplugged and replugged in the device, but still
uhd_find_devices can't locate it.
What step am i missing?
Thanks,
Greg
------------------------------
Message: 3
Date: Mon, 5 May 2014 11:56:20 -0700
From: Ian Buckley via USRP-users <[email protected]>
To: Greg Hulands <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] uhd_find_devices cannot find the B210
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Greg,
Thats the default USB device of the un-programmed Cypress FX3, it will change
to the Ettus ID after the firmware is loaded.
First step for you; Update your UHD install, the current version is 3.7.1and
you'll need to stay on a modern version when using the newest products.
-Ian
On May 5, 2014, at 9:57 AM, Greg Hulands via USRP-users
<[email protected]> wrote:
> Hi,
> I received my B210 this morning and when I run uhd_find_devices, it say it
> can't find any devices.
>
> $ uhd_find_devices
> linux; GNU C++ version 4.8.1; Boost_105300; UHD_003.005.003-0-unknown
>
> No UHD Devices Found
>
>
> lsusb shows the device, but the product id is different to what is in
> /lib/udev/rules.d/40-uhd-host.rules
>
> Bus 003 Device 006: ID 2500:0020
>
> So I added a line to the rules file
> SUBSYSTEMS=="usb", ATTRS{idVendor}=="2500", ATTRS{idProduct}=="0020",
> GROUP:="usrp", MODE:="0660"
>
> I reloaded udev, unplugged and replugged in the device, but still
> uhd_find_devices can't locate it.
>
> What step am i missing?
>
> Thanks,
> Greg
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 4
Date: Mon, 05 May 2014 11:56:41 -0700
From: Greg Hulands via USRP-users <[email protected]>
To: Greg Hulands <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] uhd_find_devices cannot find the B210
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi I resolved this via the gnu radio discussion list.
Thanks,
Greg
On May 5, 2014, at 9:57 AM, Greg Hulands via USRP-users
<[email protected]> wrote:
> Hi,
> I received my B210 this morning and when I run uhd_find_devices, it say it
> can't find any devices.
>
> $ uhd_find_devices
> linux; GNU C++ version 4.8.1; Boost_105300; UHD_003.005.003-0-unknown
>
> No UHD Devices Found
>
>
> lsusb shows the device, but the product id is different to what is in
> /lib/udev/rules.d/40-uhd-host.rules
>
> Bus 003 Device 006: ID 2500:0020
>
> So I added a line to the rules file
> SUBSYSTEMS=="usb", ATTRS{idVendor}=="2500", ATTRS{idProduct}=="0020",
> GROUP:="usrp", MODE:="0660"
>
> I reloaded udev, unplugged and replugged in the device, but still
> uhd_find_devices can't locate it.
>
> What step am i missing?
>
> Thanks,
> Greg
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140505/3e4ccc3c/attachment-0001.asc>
------------------------------
Message: 5
Date: Mon, 05 May 2014 22:52:31 +0200
From: Martin Braun via USRP-users <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] uhd_find_devices cannot find the B210
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 05.05.2014 20:56, Greg Hulands via USRP-users wrote:
> Hi I resolved this via the gnu radio discussion list.
For the records and the archives: The problem was an old UHD version.
- Martin
>
> Thanks,
> Greg
>
> On May 5, 2014, at 9:57 AM, Greg Hulands via USRP-users
> <[email protected]> wrote:
>
>> Hi,
>> I received my B210 this morning and when I run uhd_find_devices, it say it
>> can't find any devices.
>>
>> $ uhd_find_devices
>> linux; GNU C++ version 4.8.1; Boost_105300; UHD_003.005.003-0-unknown
>>
>> No UHD Devices Found
>>
>>
>> lsusb shows the device, but the product id is different to what is in
>> /lib/udev/rules.d/40-uhd-host.rules
>>
>> Bus 003 Device 006: ID 2500:0020
>>
>> So I added a line to the rules file
>> SUBSYSTEMS=="usb", ATTRS{idVendor}=="2500", ATTRS{idProduct}=="0020",
>> GROUP:="usrp", MODE:="0660"
>>
>> I reloaded udev, unplugged and replugged in the device, but still
>> uhd_find_devices can't locate it.
>>
>> What step am i missing?
>>
>> Thanks,
>> Greg
>>
>>
>>
>>
>> _______________________________________________
>> 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: 6
Date: Mon, 5 May 2014 22:27:22 -0700
From: Robert McIntyre via USRP-users <[email protected]>
To: 'Marcus M?ller' <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Help diagnosing SDR software lockups when
using B200?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
To close the loop on this:
I reformatted my system and installed Win 8.1 Update from scratch, and used the
stock Windows drivers for the VIA board, and it worked right out of the box.
And, it's performance is spectacular. On my system, I can use 32Msps with
very, very low overruns/dropped samples under the benchmark example, and it
works equally well at 32Msps under SDR-Radio v2.2 build 1735.
So, I'm sold on the VIA boards now. :)
Thanks, Marcus, and everyone!
Robert
To: [email protected]; [email protected]
Date: Sun, 4 May 2014 11:23:39 -0700
Subject: Re: [USRP-users] Help diagnosing SDR software lockups when using
B200?
From: [email protected]
Thanks, Marcus. Specified the type=b200, and it?s still not being recognized,
giving the same results as below, but with a ?type: b200? notation. My B200 is
listed in device manager (on Win7) as a ?WestBridge? device, which is how it
seems to be listed until firmware is loaded, at which point it becomes an Ettus
B200. Thanks for your continued help. --Robert From: Marcus M?ller
[mailto:[email protected]]
Sent: Sunday, May 04, 2014 2:11 AM
To: Robert J. McIntyre
Cc: [email protected]
Subject: Re: [USRP-users] Help diagnosing SDR software lockups when using B200?
Hi Robert, for the benchmark utility, specifying <executable> --args
type=b200should explicitely specify you're looking for USB3 devices. If that
doesn't help, make sure your USRP is found by the system at
first.Greetings,Marcus On Sun, May 4, 2014 at 12:15 AM, Robert J. McIntyre via
USRP-users <[email protected]> wrote:I?ve downloaded the latest
drivers off the VIA website (which are newer than the cards? manufacturers?
drivers), as well as the manufacturers? drivers. A variety of USB devices will
work with that card, and the Device Manager shows the B200 as a ?WestBridge?
device attached to the controller, and the power light on the B200 is on. When
trying to run the benchmark utility (or start SDR Sharp via ExtIO), I get:
Creating the usrp device with: ...Error: LookupError: KeyError: No devices
found for ----->Empty Device Address Plugging the B200 into the onboard (Intel)
controller makes
it work as expected. This exact thing happens with both different VIA cards.
I?ve reinstalled the drivers for the cards, as well as UHD. If I put the
Renesas controller back in, it will work fine from it. Thanks!Robert From:
USRP-users [mailto:[email protected]] On Behalf Of Marcus D.
Leech via USRP-users
Sent: Saturday, May 03, 2014 2:49 PM
To: [email protected]
Subject: Re: [USRP-users] Help diagnosing SDR software lockups when using B200?
On 05/03/2014 05:37 PM, Robert J. McIntyre via USRP-users wrote: Thanks,
Marcus. It definitely seems to be related to sample rate: I dropped down to 2
Msps, and then 4 Msps, and was able to use it fine. Jumping to 8, however,
caused almost immediate issues. I switched to the Intel controller, and it
seems to be more stable, even having gone as long as 15-20 minutes at 16Msps
without issue, but strangely I tend to have better benchmark results with the
renesas one. So, one gives better long-term uptime, the other gives less
overruns/dropped samples on the benchmarks. K I?ve tried two different VIA
controllers (built on VL801 and VL805), but neither one would actually load the
firmware to the B200, despite other devices working fine. I do understand the
UHD/ExtIO interaction, but I suppose that there could be an issue with the
ExtIO code calling into UHD, but since the symptoms happen with or without E
xtIO, it points to something further down the stack. J Any tips on getting the
VIA controllers to work? I?d like to at least be able to benchmark one. J
Thanks!!!!!Robert From: Marcus M?ller [mailto:[email protected]]
Sent: Saturday, May 03, 2014 2:14 PM
To: Robert J. McIntyre
Cc: [email protected]
Subject: Re: [USRP-users] Help diagnosing SDR software lockups when using B200?
Hi Robert, this is strange indeed, although there are several reports of things
working out very badly with renesas controllers, so try and stick with the
Intel one; Ettus actively does not recommend using any Renesas control, since
they have problems implementing the USB3.0 standard.
Access is always done using UHD (ExtIO is just an interface for which Balint
wrote an UHD wrapper), just to clear up on that.You could try one of the
binaries from the examples supplied with uhd, for example rx_samples_to_udp,or
_to_file and see if it runs without a GUI on top for the desired amount of time
(warning: 15 minutes of 8Msam/s will be around 29 GB, so make sure you're not
filling up your SSD inadvertently).All the best,
Marcus On Sat, May 3, 2014 at 10:49 PM, Robert J. McIntyre via USRP-users
<[email protected]> wrote:Hoping that someone can help me, and I can
help the group with diagnosing
very frequent "lockups" of SDR software when using the B200.
My system is (roughly):
B200
USB 3 via a Renesas controller (though the same thing happens with an Intel
controller, and another Renesas controller on my laptop)
UHD 003.007.001
Core i7 with 16GB RAM
Regardless of whether I use SDR Sharp, or SDR Console, about every 5-10
minutes of using the SDR as a receiver (clicking around within the
bandwidth, etc.), both software will "lock up", in that they'll continue to
run the waterfall, but there won't be any data displayed. If I stop/restart
the radio (via the SDR software radio selection options) it will almost
always come back to life, for 5-10 minutes, and then die again.
I've set the sample rate to 8Msps, and get zero dropped/lost/overruns using
benchmark_rate.exe.
I'd love to help investigate this, but am looking for some help in where to
start. Based on the fact that it affects multiple programs, which use
different access methods (UHD vs. ExtIO), it seems like it's not the
individual software packages, but rather either my system in general, or
somewhere from UHD down through the firmware/FPGA image.
Thoughts?
Thanks!
Robert
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________USRP-users mailing
[email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.comMake
sure your Windows drivers for these controllers are up-to-date.
-- Marcus LeechPrincipal Investigator Shirleys Bay Radio Astronomy
Consortiumhttp://www.sbrac.org
_______________________________________________
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/20140505/68374f78/attachment-0001.html>
------------------------------
Message: 7
Date: Mon, 5 May 2014 22:29:37 -0700
From: Robert McIntyre via USRP-users <[email protected]>
To: 'Marcus M?ller' <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Help diagnosing SDR software lockups when
using B200?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
To close the loop on this:
I reformatted my system and installed Win 8.1 Update from scratch, and used the
stock Windows drivers for the VIA board, and it worked right out of the box.
And, it's performance is spectacular. On my system, I can use 32Msps with
very, very low overruns/dropped samples under the benchmark example, and it
works equally well at 32Msps under SDR-Radio v2.2 build 1735.
So, I'm sold on the VIA boards now. :)
Thanks, Marcus, and everyone!
Robert
To: [email protected]; [email protected]
Date: Sun, 4 May 2014 11:23:39 -0700
Subject: Re: [USRP-users] Help diagnosing SDR software lockups when using
B200?
From: [email protected]
Thanks, Marcus. Specified the type=b200, and it?s still not being recognized,
giving the same results as below, but with a ?type: b200? notation. My B200 is
listed in device manager (on Win7) as a ?WestBridge? device, which is how it
seems to be listed until firmware is loaded, at which point it becomes an Ettus
B200. Thanks for your continued help. --Robert From: Marcus M?ller
[mailto:[email protected]]
Sent: Sunday, May 04, 2014 2:11 AM
To: Robert J. McIntyre
Cc: [email protected]
Subject: Re: [USRP-users] Help diagnosing SDR software lockups when using B200?
Hi Robert, for the benchmark utility, specifying <executable> --args
type=b200should explicitely specify you're looking for USB3 devices. If that
doesn't help, make sure your USRP is found by the system at
first.Greetings,Marcus On Sun, May 4, 2014 at 12:15 AM, Robert J. McIntyre via
USRP-users <[email protected]> wrote:I?ve downloaded the latest
drivers off the VIA website (which are newer than the cards? manufacturers?
drivers), as well as the manufacturers? drivers. A variety of USB devices will
work with that card, and the Device Manager shows the B200 as a ?WestBridge?
device attached to the controller, and the power light on the B200 is on. When
trying to run the benchmark utility (or start SDR Sharp via ExtIO), I get:
Creating the usrp device with: ...Error: LookupError: KeyError: No devices
found for ----->Empty Device Address Plugging the B200 into the onboard (Intel)
controller makes
it work as expected. This exact thing happens with both different VIA cards.
I?ve reinstalled the drivers for the cards, as well as UHD. If I put the
Renesas controller back in, it will work fine from it. Thanks!Robert From:
USRP-users [mailto:[email protected]] On Behalf Of Marcus D.
Leech via USRP-users
Sent: Saturday, May 03, 2014 2:49 PM
To: [email protected]
Subject: Re: [USRP-users] Help diagnosing SDR software lockups when using B200?
On 05/03/2014 05:37 PM, Robert J. McIntyre via USRP-users wrote: Thanks,
Marcus. It definitely seems to be related to sample rate: I dropped down to 2
Msps, and then 4 Msps, and was able to use it fine. Jumping to 8, however,
caused almost immediate issues. I switched to the Intel controller, and it
seems to be more stable, even having gone as long as 15-20 minutes at 16Msps
without issue, but strangely I tend to have better benchmark results with the
renesas one. So, one gives better long-term uptime, the other gives less
overruns/dropped samples on the benchmarks. K I?ve tried two different VIA
controllers (built on VL801 and VL805), but neither one would actually load the
firmware to the B200, despite other devices working fine. I do understand the
UHD/ExtIO interaction, but I suppose that there could be an issue with the
ExtIO code calling into UHD, but since the symptoms happen with or without E
xtIO, it points to something further down the stack. J Any tips on getting the
VIA controllers to work? I?d like to at least be able to benchmark one. J
Thanks!!!!!Robert From: Marcus M?ller [mailto:[email protected]]
Sent: Saturday, May 03, 2014 2:14 PM
To: Robert J. McIntyre
Cc: [email protected]
Subject: Re: [USRP-users] Help diagnosing SDR software lockups when using B200?
Hi Robert, this is strange indeed, although there are several reports of things
working out very badly with renesas controllers, so try and stick with the
Intel one; Ettus actively does not recommend using any Renesas control, since
they have problems implementing the USB3.0 standard.
Access is always done using UHD (ExtIO is just an interface for which Balint
wrote an UHD wrapper), just to clear up on that.You could try one of the
binaries from the examples supplied with uhd, for example rx_samples_to_udp,or
_to_file and see if it runs without a GUI on top for the desired amount of time
(warning: 15 minutes of 8Msam/s will be around 29 GB, so make sure you're not
filling up your SSD inadvertently).All the best,
Marcus On Sat, May 3, 2014 at 10:49 PM, Robert J. McIntyre via USRP-users
<[email protected]> wrote:Hoping that someone can help me, and I can
help the group with diagnosing
very frequent "lockups" of SDR software when using the B200.
My system is (roughly):
B200
USB 3 via a Renesas controller (though the same thing happens with an Intel
controller, and another Renesas controller on my laptop)
UHD 003.007.001
Core i7 with 16GB RAM
Regardless of whether I use SDR Sharp, or SDR Console, about every 5-10
minutes of using the SDR as a receiver (clicking around within the
bandwidth, etc.), both software will "lock up", in that they'll continue to
run the waterfall, but there won't be any data displayed. If I stop/restart
the radio (via the SDR software radio selection options) it will almost
always come back to life, for 5-10 minutes, and then die again.
I've set the sample rate to 8Msps, and get zero dropped/lost/overruns using
benchmark_rate.exe.
I'd love to help investigate this, but am looking for some help in where to
start. Based on the fact that it affects multiple programs, which use
different access methods (UHD vs. ExtIO), it seems like it's not the
individual software packages, but rather either my system in general, or
somewhere from UHD down through the firmware/FPGA image.
Thoughts?
Thanks!
Robert
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________USRP-users mailing
[email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.comMake
sure your Windows drivers for these controllers are up-to-date.
-- Marcus LeechPrincipal Investigator Shirleys Bay Radio Astronomy
Consortiumhttp://www.sbrac.org
_______________________________________________
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/20140505/785f76ca/attachment-0001.html>
------------------------------
Message: 8
Date: Tue, 6 May 2014 12:27:05 +0500
From: ali hanif via USRP-users <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] General precautions while using USRP B210
Message-ID:
<caejvf3skh8by8ls5j52qykxaxllhp50z-q_5ppaim3jhtat...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
I am new to this field and just bought USRP B210..can anybody tell that
what are the important points/pre-cautions to be kept in mind while using
it to avoid any damage to USRP...
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140506/e50a8380/attachment-0001.html>
------------------------------
Message: 9
Date: Tue, 6 May 2014 15:46:03 +0800
From: Francois Quitin via USRP-users <[email protected]>
To: <[email protected]>
Subject: [USRP-users] question about GPSDO module
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Dear all,
A little question about the GPSDO-module disciplined local oscillator. We
have run an experiment where we connect a GPS antenna to the GPSDO module,
and let the GPSDO acquire enough satellites to achieve a lock (this is to
align the time of different USRPs). We then disconnect the GPS antenna, and
let the local oscillator run by itself.
After disconnecting the GPS antenna, will the local oscillator behave like
any oscillator, or will there be some lingering effect from the GPSDO module
GPS correction?
Thanks a lot,
Francois
--
Francois Quitin, Ph.D.
Research Fellow
INFINITUS - Infocomm Centre of Excellence
School of EEE, Nanyang Technological University
50 Nanyang Ave, S2-B4b-05
Singapore 639798
Phone: +65-8502-3690
Email: [email protected] <mailto:[email protected]>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140506/a063a579/attachment-0001.html>
------------------------------
Message: 10
Date: Tue, 6 May 2014 12:33:38 +0000
From: Ethem Sozer via USRP-users <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] New to USRP :: software development platform
recommendations sought
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Zeng,
You can use MATLAB with USRP directly using the USRP Support Package, which
lets you receive or transmit signals in real-time or in batch mode.
Regards,
Ethem
-----Original Message-----
From: USRP-users [mailto:[email protected]] On Behalf Of zeng,
xuewen via USRP-users
Sent: Thursday, May 01, 2014 11:34 PM
To: [email protected]
Subject: Re: [USRP-users] New to USRP :: software development platform
recommendations sought
We did similar experiments you may want to do: combine matlab baseband signal
processing with usrp real wolrd tranceiving. Matlab is used to generate
baseband IQ data file with added noise, freq-offset & multi-path effects and
up-sampling-pulse shaping filter, then tranceiving thru
gnuradio+usrp and then back to matlab to proc the rxed baseband IQ data
file. We used DIY usrp1 and gnuradio 3.2.2. We modified usrp_standard_tx.cpp to
tx the IQ data file and used usrp_rx_cfile cmdlinee tool to save rxed int16 iq
data to file. We need to locate the start of a frame by preample sync
process.(ref: Frame synchronization in SC-FDE system using PN sequence
modulation in Ieee explore, url:
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=6197855&url=http%3A%
2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D6197855)
This experiment provides a low cost real world trx validation routine.
It also should be noted that RFX 900/2400 will add noticable extra noise and
freq-offset. BasicRX/TX F transceiving maybe used to eval the matlab baseband
proc.
I am wondering if Uhd based usrp-gnuradio or matlab provide ready tools for
baseband IQ file trx experiment. Any info on this would be appreciated.
zeng,xuewen from zxwdsp (at) 126.ocm.
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 11
Date: Tue, 06 May 2014 15:32:03 +0200
From: Andre Puschmann via USRP-users <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP Documentation - latency
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
Hey Balint,
I was trying to access the latency plots today but they are still missing.
Any chance for getting them up again anytime soon?
Thanks
Andre
On 01/31/2014 03:39 AM, Balint Seeber wrote:
> Hi Jurgis,
>
> The page has been moved here:
> http://code.ettus.com/redmine/ettus/projects/uhd/wiki/Latency (we will
> upload the images again very soon)
>
> We are also working to add the latency measurement application into the
> UHD source tree, so you'll be able to run it with your own host/radio
> combination and see what sort of performance you can achieve. Please
> stay tuned for an announcement regarding this.
>
> Kind regards,
> Balint
>
>
> On Wed, Jan 29, 2014 at 6:39 AM, Jurgis Aleksandravicius
> <[email protected]
> <mailto:[email protected]>> wrote:
>
> Hi,
>
> I was hoping to access Ettus documentation on USRP latency
> measurements at:
> http://code.ettus.com/redmine/__ettus/projects/public/wiki/__Latency
> <http://code.ettus.com/redmine/ettus/projects/public/wiki/Latency>
>
> Apparently the site is not there, but is it permanently removed? Was
> it possibly moved somewhere?
> Thanks a lot.
>
> Jurgis Aleksandravicius
>
>
> _________________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/__mailman/listinfo/usrp-users___lists.ettus.com
> <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: 12
Date: Tue, 6 May 2014 15:48:09 +0200
From: Stefan Ereth via USRP-users <[email protected]>
To: Robert Kossler <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Phase Offset between USRP-B210 Channels
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
Hi,
thank you for your notes. Today I had the chance to test them.
Marcus Leech:
> What are you passing in for the subdev argument?
I pass "A:A A:B"
> What does usrp->get_rx_num_channels() Return in this example?
it returns "2"
> Have you confirmed that your splitter is 0deg across all the frequencies you
> care about?
I confirmed my Test Setup with an oscilloscope. The phase shift after splitter
and cabel is only a few degrees and not more than 180 degrees.
Sivan:
> make calibration procedure on the USRP
I'm not sure which calibration you mean. The function "uhd_cal_rx_iq_balance"
returns Error: This board does not have the CAL antenna option, cannot
self-calibrate.
Rob Kossler:
>check for LO locked:
I've implemented your sensor test function. The b210-board has only one sensor.
It's for the external refrence clock. I apply an externel 10 MHz Source and get
a refrence Lock out of the PLL, but with out any improvment.
>Regarding the phase offset, is it just a calibration issue? If you measure a
>phase offset with a ref signal and then later measure a real signal and apply
>the cal offset, does that fix your issue?
I thought about this solution too. But the problem is, the phase offset differs
after retuning. So I need to calibrate after each retune.
Do you have any futher ideas.
Regards,
Stefan Ereth
----- Urspr?ngliche Mail -----
Von: "Robert Kossler" <[email protected]>
An: "Stefan Ereth" <[email protected]>
CC: "[email protected]" <[email protected]>
Gesendet: Freitag, 2. Mai 2014 18:01:31 GMT +01:00
Amsterdam/Berlin/Bern/Rom/Stockholm/Wien
Betreff: RE: [USRP-users] Phase Offset between USRP-B210 Channels
Hi Stefan,
Regarding your code, I noticed that it is streaming the 2 RX channels to file.
I have also modified some Ettus examples to do this same task (see attached).
It is based on rx_samples_to_file and benchmark_rate rather than
rx_multi_samples. One reason I chose to modify the rx_samples_to_file example
was that it included an LO Locked verification. Not sure if that could affect
your results by not doing this check...
Regarding the phase offset, is it just a calibration issue? If you measure a
phase offset with a ref signal and then later measure a real signal and apply
the cal offset, does that fix your issue?
Rob Kossler
-----Original Message-----
From: USRP-users [mailto:[email protected]] On Behalf Of
Stefan Ereth via USRP-users
Sent: Friday, May 02, 2014 2:30 AM
To: [email protected]
Subject: [USRP-users] Phase Offset between USRP-B210 Channels
Hi all,
I'm saving IQ-Samples from both Channels of an USRP B210 for Direction of
Arrival Estimation with Music. My source Code is based on the
rx_multi_samples.cpp example. For tests I connected a sine-generator with a
splitter to both channels. With a pulse sine a verified that the measured data
is time aligned. (picture abs_pulse_sine in appendix) But the problem is, that
there is a phase offset between the two channels of more than 180 degree.
(picture real_sine and phase_diff) This offset varies by retuning.
I don't understand where this phase offset come from, because the LO of both
channels is in the same Chip and should be phase aligned. Is this a known
problem of the B210? Or is there an error in my source code?
Regards,
Stefan Ereth
//
// Copyright 2011 Ettus Research LLC
//
// This program is free software: you can redistribute it and/or modify // it
under the terms of the GNU General Public License as published by // the Free
Software Foundation, either version 3 of the License, or // (at your option)
any later version.
//
// This program is distributed in the hope that it will be useful, // but
WITHOUT ANY WARRANTY; without even the implied warranty of // MERCHANTABILITY
or FITNESS FOR A PARTICULAR PURPOSE. See the // GNU General Public License for
more details.
//
// You should have received a copy of the GNU General Public License // along
with this program. If not, see <http://www.gnu.org/licenses/>.
//
#define use_short
#include <uhd/utils/thread_priority.hpp> #include <uhd/utils/safe_main.hpp>
#include <uhd/usrp/multi_usrp.hpp> #include <boost/program_options.hpp>
#include <boost/format.hpp> #include <boost/thread.hpp> #include
<boost/lexical_cast.hpp> #include <boost/algorithm/string.hpp> #include
<iostream> #include <fstream> #include <complex>
namespace po = boost::program_options;
int UHD_SAFE_MAIN(int argc, char *argv[]){
uhd::set_thread_priority_safe();
//variables to be set by po
std::string args, sync, subdev, channel_list,file,file0,file1;
double seconds_in_future, freq;
size_t total_num_samps;
double rate,gain,tx_gain;
std::ofstream outfile,outfile2;
//setup the program options
po::options_description desc("Allowed options");
desc.add_options()
("help", "help message")
("args", po::value<std::string>(&args)->default_value(""), "single uhd
device address args")
("file", po::value<std::string>(&file)->default_value("measure0-1"),
"name of the file to write binary samples to")
("secs", po::value<double>(&seconds_in_future)->default_value(1.0),
"number of seconds in the future to receive")
("nsamps", po::value<size_t>(&total_num_samps)->default_value(10000),
"total number of samples to receive")
("rate", po::value<double>(&rate)->default_value(8e6), "rate of
incoming samples")
("sync", po::value<std::string>(&sync)->default_value("b210"),
"synchronization method: now, pps, mimo")
("freq", po::value<double>(&freq)->default_value(800e6), "RF center
frequency in Hz")
("gain", po::value<double>(&gain), "gain for the RF chain")
("tx-gain", po::value<double>(&tx_gain), "gain for the TX in
calibration Mode")
("subdev", po::value<std::string>(&subdev), "subdev spec (homogeneous
across motherboards)")
("v", "specify to enable inner-loop verbose")
("calc","specify to enable transmitting and recording of calibration
data")
("channels", po::value<std::string>(&channel_list)->default_value("0"),
"which channel(s) to use (specify \"0\", \"1\", \"0,1\", etc)")
;
po::variables_map vm;
po::store(po::parse_command_line(argc, argv, desc), vm);
po::notify(vm);
//print the help message
if (vm.count("help")){
std::cout << boost::format("UHD RX Multi Samples %s") % desc <<
std::endl;
std::cout <<
" This is a demonstration of how to receive aligned data from
multiple channels.\n"
" This example can receive from multiple DSPs, multiple
motherboards, or both.\n"
" The MIMO cable or PPS can be used to synchronize the
configuration. See --sync\n"
"\n"
" Specify --subdev to select multiple channels per motherboard.\n"
" Ex: --subdev=\"0:A 0:B\" to get 2 channels on a Basic RX.\n"
"\n"
" Specify --args to select multiple motherboards in a
configuration.\n"
" Ex: --args=\"addr0=192.168.10.2, addr1=192.168.10.3\"\n"
<< std::endl;
return ~0;
}
bool verbose = vm.count("v") == 1;
bool calibration = vm.count("calc") == 1;
/**************** RX Init *************************************************/
//create a usrp device
std::cout << std::endl;
std::cout << boost::format("Creating the usrp device with: %s...") % args
<< std::endl;
uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make(args);
usrp->set_master_clock_rate(30e6); //less then 30.72e6 //M?glichkeit 1:
Variable Clock-Rate
//always select the subdevice first, the channel mapping affects the other
settings
if (vm.count("subdev")){
uhd::usrp::subdev_spec_t subdevClass = subdev;
std::cout << subdevClass.to_pp_string() << std::endl;
usrp->set_rx_subdev_spec(subdevClass); //sets across all mboards
}
std::cout << boost::format("Using Device: %s") % usrp->get_pp_string() <<
std::endl;
//set the rx sample rate (sets across all channels)
std::cout << boost::format("Setting RX Rate: %f Msps... ") % (rate/1e6) <<
std::endl;
usrp->set_rx_rate(rate);
std::cout << boost::format("Actual RX Rate: %f Msps...") %
(usrp->get_rx_rate()/1e6) << std::endl << std::endl;
//set center Frequency
std::cout << boost::format("Setting RX Freq: %f MHz...") % (freq/1e6) <<
std::endl;
uhd::tune_request_t tune_request(freq);
for(size_t i=0;i<usrp->get_rx_num_channels();i++)
usrp->set_rx_freq(tune_request,i);
std::cout << boost::format("Actual RX Freq: %f MHz...") %
(usrp->get_rx_freq(1)/1e6) << std::endl << std::endl;
//set the rf gain
if (vm.count("gain")){
for(size_t i=0;i<usrp->get_rx_num_channels();i++){
std::cout << boost::format("Setting RX Gain for Channel %d: %f
dB...") % i % gain << std::endl;
usrp->set_rx_gain(gain,i);
std::cout << boost::format("Actual RX Gain: %f dB...") %
usrp->get_rx_gain() << std::endl << std::endl;
}
}
//open files to write
if(calibration) file+=".calc"; //Kalibrierdaten mit Endung .calc
else file+=".dat"; //Messdaten mit Endung.dat
file0 = file;
file1 = file;
file0 += "0";
file1 += "1";
outfile.open(file0.c_str(), std::ofstream::binary);
if(usrp->get_rx_num_channels()>1){
outfile2.open(file1.c_str(),std::ofstream::binary);
}
/**************** Recieve Start ******************************************/
//create a receive streamer
//linearly map channels (index0 = channel0, index1 = channel1, ...)
uhd::stream_args_t stream_args("sc16"); //complex short
//stream_args.channels = channel_nums;
for (size_t i = 0; i < usrp->get_rx_num_channels(); i++)
stream_args.channels.push_back(i);
uhd::rx_streamer::sptr rx_stream = usrp->get_rx_stream(stream_args);
//setup streaming
std::cout << std::endl;
std::cout << boost::format(
"Begin receiving of %u samples. Start in %f seconds in the future..."
) % total_num_samps % seconds_in_future << std::endl;
uhd::stream_cmd_t
stream_cmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE);
stream_cmd.num_samps = total_num_samps;
stream_cmd.stream_now = false;
stream_cmd.time_spec = uhd::time_spec_t(seconds_in_future) +
usrp->get_time_now();
rx_stream->issue_stream_cmd(stream_cmd); //tells all channels to stream
//meta-data will be filled in by recv()
uhd::rx_metadata_t md;
//allocate buffers to receive with samples (one buffer per channel)
const size_t samps_per_buff = rx_stream->get_max_num_samps();
std::vector<std::vector<std::complex<short> > > buffs(
usrp->get_rx_num_channels(), std::vector<std::complex<short>
>(samps_per_buff)
);
//create a vector of pointers to point to each of the channel buffers
std::vector<std::complex<short> *> buff_ptrs;
for (size_t i = 0; i < buffs.size(); i++)
buff_ptrs.push_back(&buffs[i].front());
//the first call to recv() will block this many seconds before receiving
double timeout = seconds_in_future + 1; //timeout (delay before receive +
padding)
size_t num_acc_samps = 0; //number of accumulated samples
while(num_acc_samps < total_num_samps){
//receive a single packet
size_t num_rx_samps = rx_stream->recv(
buff_ptrs, samps_per_buff, md, timeout
);
//use a small timeout for subsequent packets
timeout = 0.1;
//handle the error code
if (md.error_code == uhd::rx_metadata_t::ERROR_CODE_TIMEOUT) break;
if (md.error_code != uhd::rx_metadata_t::ERROR_CODE_NONE){
throw std::runtime_error(str(boost::format(
"Receiver error %s"
) % md.strerror()));
}
if(verbose) std::cout << boost::format(
"Received packet: %u samples, %u full secs, %f frac secs"
) % num_rx_samps % md.time_spec.get_full_secs() %
md.time_spec.get_frac_secs() << std::endl;
//Schreiben der gelesenen Werte in die Dateien
if(outfile.is_open())
outfile.write((const char
*)&buffs[0].front(),num_rx_samps*sizeof(buffs[0].front()));
if(outfile2.is_open())
outfile2.write((const char
*)&buffs[1].front(),num_rx_samps*sizeof(buffs[1][0]));
num_acc_samps += num_rx_samps;
}
if (num_acc_samps < total_num_samps) std::cerr << "Receive timeout before
all samples received..." << std::endl;
/**************************** Recieve End
*******************************************************/
if(outfile.is_open())
outfile.close();
if(outfile2.is_open())
outfile2.close();
//finished
std::cout << std::endl << "Done! Mine" << std::endl << std::endl;
return EXIT_SUCCESS;
}
------------------------------
Message: 13
Date: Tue, 6 May 2014 14:40:15 +0000 (UTC)
From: Marcus Leech via USRP-users <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] General precautions while using USRP B210
Message-ID: <1089925352.43912.1399387216101.JavaMail.mail@webmail06>
Content-Type: text/plain; charset="us-ascii"
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140506/e891ad06/attachment-0001.html>
------------------------------
Message: 14
Date: Tue, 06 May 2014 17:21:27 +0200
From: Marcus M?ller via USRP-users <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] question about GPSDO module
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi Francois,
I assume you not only use the GPSDO to get a time and a PPS to set that
time, but also to discipline the oscillator of your USRP.
Generally, when losing GPS fix, the GPSDO will continue to provide a clock.
However, in my experience, that (not GPS coordinated) clock is worse
than the USRP-built in oscillator, but not much. Is there a reason why
you would want to remove the GPS antenna during use?
Also, you should be able to use the PPS / time feature of the GPSDO
without disciplining the clock using the GPSDO, and from my perspective
that might be what you want to do.
Greetings,
Marcus
On 06.05.2014 09:46, Francois Quitin via USRP-users wrote:
> Dear all,
>
>
>
> A little question about the GPSDO-module disciplined local oscillator. We
> have run an experiment where we connect a GPS antenna to the GPSDO module,
> and let the GPSDO acquire enough satellites to achieve a lock (this is to
> align the time of different USRPs). We then disconnect the GPS antenna, and
> let the local oscillator run by itself.
>
>
>
> After disconnecting the GPS antenna, will the local oscillator behave like
> any oscillator, or will there be some lingering effect from the GPSDO module
> GPS correction?
>
>
>
> Thanks a lot,
>
> Francois
>
>
>
>
>
> _______________________________________________
> 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/20140506/9b412446/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 45, Issue 6
*****************************************
