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. Help diagnosing SDR software lockups when using B200?
(Robert J. McIntyre via USRP-users)
2. Re: Help diagnosing SDR software lockups when using B200?
(Marcus M?ller via USRP-users)
3. Re: Help diagnosing SDR software lockups when using B200?
(Robert J. McIntyre via USRP-users)
4. Re: Help diagnosing SDR software lockups when using B200?
(Marcus D. Leech via USRP-users)
5. Re: Help diagnosing SDR software lockups when using B200?
(Robert J. McIntyre via USRP-users)
6. Re: Help diagnosing SDR software lockups when using B200?
(Marcus M?ller via USRP-users)
7. Re: Phase Offset between USRP-B210 Channels
(Sivan Toledo via USRP-users)
----------------------------------------------------------------------
Message: 1
Date: Sat, 3 May 2014 13:49:31 -0700
From: "Robert J. McIntyre via USRP-users" <[email protected]>
To: <[email protected]>
Subject: [USRP-users] Help diagnosing SDR software lockups when using
B200?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
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
------------------------------
Message: 2
Date: Sat, 3 May 2014 23:14:09 +0200
From: Marcus M?ller via USRP-users <[email protected]>
To: "Robert J. McIntyre" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Help diagnosing SDR software lockups when
using B200?
Message-ID:
<CAHrJaSUR=way9wLP+HyCcwC9CmvARACqT84yFze=g6zuskc...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140503/5d52b70f/attachment-0001.html>
------------------------------
Message: 3
Date: Sat, 3 May 2014 14:37:06 -0700
From: "Robert J. McIntyre via USRP-users" <[email protected]>
To: 'Marcus M?ller' <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Help diagnosing SDR software lockups when
using B200?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
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. :| 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 ExtIO, it points to something further down the stack. :)
Any tips on getting the VIA controllers to work? I?d like to at least be able
to benchmark one. :)
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] <mailto:[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] <mailto:[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/20140503/a2447122/attachment-0001.html>
------------------------------
Message: 4
Date: Sat, 03 May 2014 17:49:05 -0400
From: "Marcus D. Leech via USRP-users" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Help diagnosing SDR software lockups when
using B200?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
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 ExtIO, 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] <mailto:[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] <mailto:[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
Make sure your Windows drivers for these controllers are up-to-date.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140503/3ce23383/attachment-0001.html>
------------------------------
Message: 5
Date: Sat, 3 May 2014 15:15:57 -0700
From: "Robert J. McIntyre via USRP-users" <[email protected]>
To: <[email protected]>
Subject: Re: [USRP-users] Help diagnosing SDR software lockups when
using B200?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
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. :| 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 ExtIO, it points to something further down the stack. :)
Any tips on getting the VIA controllers to work? I?d like to at least be able
to benchmark one. :)
Thanks!!!!!
Robert
From: Marcus M?ller [mailto:[email protected]]
Sent: Saturday, May 03, 2014 2:14 PM
To: Robert J. McIntyre
Cc: [email protected] <mailto:[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] <mailto:[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] <mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
[email protected] <mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Make sure your Windows drivers for these controllers are up-to-date.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140503/492ecb7f/attachment-0001.html>
------------------------------
Message: 6
Date: Sun, 4 May 2014 11:11:27 +0200
From: Marcus M?ller via USRP-users <[email protected]>
To: "Robert J. McIntyre" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Help diagnosing SDR software lockups when
using B200?
Message-ID:
<cahrjaswefps8flck-8vkaclrvbv5z2sh8xsbh60kc8kyxk+...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Robert,
for the benchmark utility, specifying
<executable> --args type=b200
should 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 ExtIO, 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]<[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 list
>
> [email protected]
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> Make sure your Windows drivers for these controllers are up-to-date.
>
>
>
>
> --
>
> Marcus Leech
>
> Principal Investigator
>
> Shirleys Bay Radio Astronomy Consortium
>
> http://www.sbrac.org
>
>
> _______________________________________________
> 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/20140504/a63e103a/attachment-0001.html>
------------------------------
Message: 7
Date: Sun, 4 May 2014 12:11:42 +0300
From: Sivan Toledo via USRP-users <[email protected]>
To: Stefan Ereth <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Phase Offset between USRP-B210 Channels
Message-ID:
<CAOL_ruHS51QOoL0BBS6S9=wS+w1=+cdhgfc3+adxzl+czkm...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Stefan, make sure that you can the calibration procedure on the USRP. I
have no idea if this is what is affecting your experiment, but you should
do it before you start digging deeper.
Sivan
On Fri, May 2, 2014 at 9:30 AM, Stefan Ereth via USRP-users <
[email protected]> wrote:
> 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;
> }
>
> _______________________________________________
> 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/20140504/b92a5811/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 4
*****************************************
