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. Sychnronize two USRP X310 with GPS (Simon Hartmann)
2. About USRP1 Receive Frequecy (Thach Nguyen)
3. Re: Sychnronize two USRP X310 with GPS (Ian Buckley)
4. N210: The total sum of rates exceeds the maximum capacity of
the connection. (Anderson, Douglas J.)
5. Re: N210: The total sum of rates exceeds the maximum capacity
of the connection. (Marcus D. Leech)
6. Build problems with UHD_INLINE (David)
7. Re: N210: The total sum of rates exceeds the maximum capacity
of the connection. (Anderson, Douglas J.)
8. Anybody using gr-osmosdr source or gqrx with UHD 3.8.1?
(Louis Brown)
9. Re: Anybody using gr-osmosdr source or gqrx with UHD 3.8.1?
(Marcus D. Leech)
10. Re: Anybody using gr-osmosdr source or gqrx with UHD 3.8.1?
(Louis Brown)
11. Re: Anybody using gr-osmosdr source or gqrx with UHD 3.8.1?
(Marcus D. Leech)
12. Re: About USRP1 Receive Frequecy (Timothy Schaffer)
----------------------------------------------------------------------
Message: 1
Date: Fri, 19 Dec 2014 13:11:19 +0001
From: Simon Hartmann <[email protected]>
To: <[email protected]>
Subject: [USRP-users] Sychnronize two USRP X310 with GPS
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Hi all,
the last weeks we tried to synchronize our two usrps X310 between two
stations with two seperate GPS antenna, but the results weren't as good
as we hoped.
For your information, every usrp is connected to his own pc on which
the same code is running.
Our first intent was to check if the gps antenna is locked
(get_mboard_sensor('gps_locked')) and then start to receive samples
with the same time given
(set_start_time(uhd.time_spec_t(self.start_time))). We only want to
receive samples, therefore we used set_start_time() instead of
set_command_time().
When we checked the sync, there was a difference about 20 - 100 us.
According to the documentation only ~100 ns should be allowed.
We also read out the rx-time stream tags for both measurements and
compared them. However, they were identically.
In the documentation of Ettus it's explained, if the GPS is locked to
the satellites the internal VITA timestamp will be initialized to the
GPS time, and the internal oscillator will be phase-locked to the 10MHz
GPSDO reference.
So if their both locked they should have the same timestamp, or? Or do
we need some further code to initialize the gps time to the usrp?
What else could be the problem?
Thanks,
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141219/be9faee4/attachment-0001.html>
------------------------------
Message: 2
Date: Fri, 19 Dec 2014 16:59:24 +0100
From: Thach Nguyen <[email protected]>
To: [email protected]
Subject: [USRP-users] About USRP1 Receive Frequecy
Message-ID:
<caeyyuglxzopxsneur_k4azfrfzgeqfvx2t+m-ctcgru29mz...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Good morning everyone
I am using couples of USRP1/ FLex900 daughter board. I try to implement
simple couple transmitter/receiver at 910 MHz. I use QT Sink for analysing
received signal
For transmitter and receiver are fine no warning nor error. But it is quite
strange when i plot received signals with different USRPs. (same GRC File)
but the output frequency is totally different. (You can see the GRC
configuration file and the output plot)
Do you know how to calculate UHD:USRP Source receive frequency?.
Thank you and have a nice weekend
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141219/32a798c2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: plot1.png
Type: image/png
Size: 216344 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141219/32a798c2/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: plot2.png
Type: image/png
Size: 206317 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141219/32a798c2/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: transmitter.png
Type: image/png
Size: 187094 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141219/32a798c2/attachment-0005.png>
------------------------------
Message: 3
Date: Fri, 19 Dec 2014 10:26:53 -0800
From: Ian Buckley <[email protected]>
To: Simon Hartmann <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Sychnronize two USRP X310 with GPS
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Simon,
A few questions that will help in diagnosing what you are seeing:
How long have you had the X300's continuously powered (with GPS antennas
connected and a good view of the sky) before you make these measurements?
Can you describe how you determine they are out of sync? It sounds like you
have them at 2 remote locations?
Are you using the latest in UHD and FPGA images?
The fact that you see the same rx-time stream tags is a good sign that you are
using the API correctly to perform the capture. The fact that you are within
20-100uS tells me that UHD has tried to initialize the internal VITA timestamp
to a UTC related time, otherwise this value would be a count of 200MHz clock
ticks since power was applied to each unit.
Thx
-Ian
On Dec 19, 2014, at 5:10 AM, Simon Hartmann via USRP-users
<[email protected]> wrote:
> Hi all,
>
> the last weeks we tried to synchronize our two usrps X310 between two
> stations with two seperate GPS antenna, but the results weren't as good as we
> hoped.
> For your information, every usrp is connected to his own pc on which the same
> code is running.
>
> Our first intent was to check if the gps antenna is locked
> (get_mboard_sensor('gps_locked')) and then start to receive samples with the
> same time given (set_start_time(uhd.time_spec_t(self.start_time))). We only
> want to receive samples, therefore we used set_start_time() instead of
> set_command_time().
>
> When we checked the sync, there was a difference about 20 - 100 us. According
> to the documentation only ~100 ns should be allowed.
> We also read out the rx-time stream tags for both measurements and compared
> them. However, they were identically.
>
> In the documentation of Ettus it's explained, if the GPS is locked to the
> satellites the internal VITA timestamp will be initialized to the GPS time,
> and the internal oscillator will be phase-locked to the 10MHz GPSDO
> reference.
>
> So if their both locked they should have the same timestamp, or? Or do we
> need some further code to initialize the gps time to the usrp?
> What else could be the problem?
>
> Thanks,
>
> Simon
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 4
Date: Fri, 19 Dec 2014 19:35:09 +0000
From: "Anderson, Douglas J." <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] N210: The total sum of rates exceeds the maximum
capacity of the connection.
Message-ID:
<7f5154c3a654cb4c8cbd18629c331b7120c4c...@itsmail01.its.bldrdoc.gov>
Content-Type: text/plain; charset="iso-8859-1"
Hi all,
I'm trying to figure out if I may have missed something in setting up the
connection between my USRP and laptop.
I'm getting the following error when I try and push the USRP's sample rate past
30MSps:
$ uhd_fft -s 50M -f 800M
linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.001-42-g8c87a524
[...]
UHD Warning:
The total sum of rates (50.000000 MSps on 1 channels) exceeds the maximum
capacity of the connection.
This can cause overflows (O).
Then the flowgraph hangs.
I'm using USRP N210 with SBX on Ubuntu laptop with 82577LM Gigabit Network card.
I have tried connected the USRP directly to the laptop and through a D-Link
gigabit switch.
I ran the following commands as recommended on the Latency wiki page:
sudo modprobe -r e1000e
sudo modprobe e1000e InterruptThrottleRate=0 TxAbsIntDelay=0 TxIntDelay=0
RxAbsIntDelay=0 RxIntDelay=0
Here is the other relevant system info:
------------------------------------------------------
$ uname -r
3.17.0-031700-lowlatency
$ sudo lshw
[...]
*-network
description: Ethernet interface
product: 82577LM Gigabit Network Connection
vendor: Intel Corporation
physical id: 19
bus info: pci@0000:00:19.0
logical name: eth0
version: 05
serial: 00:26:b9:d2:92:0a
size: 1Gbit/s
capacity: 1Gbit/s
width: 32 bits
clock: 33MHz
capabilities: pm msi bus_master cap_list ethernet physical tp 10bt
10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=e1000e
driverversion=2.3.2-k duplex=full firmware=0.12-1 ip=192.168.130.28 latency=0
link=yes multicast=yes port=twisted pair speed=1Gbit/s
resources: irq:25 memory:f6900000-f691ffff
memory:f6980000-f6980fff ioport:7040(size=32)
*-usb:0
description: USB controller
product: 5 Series/3400 Series Chipset USB2 Enhanced Host Controller
vendor: Intel Corporation
physical id: 1a
bus info: pci@0000:00:1a.0
version: 05
width: 32 bits
clock: 33MHz
capabilities: pm debug ehci bus_master cap_list
configuration: driver=ehci-pci latency=0
resources: irq:16 memory:f6970000-f69703ff
[...]
$ modinfo e1000e |grep version:
version: 2.3.2-k
$ cat /etc/sysctl.conf |grep max
net.core.rmem_max=50000000
net.core.wmem_max=1048576
------------------------------------------------------
I guess I'm either missing something or not understanding something properly.
Any help would be much appreciated!
-Doug
Douglas Anderson | Intern
DOC/NTIA/ITS-T | 325 Broadway St., Boulder, CO 80305 | P: 303 497 3582
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141219/660f794e/attachment-0001.html>
------------------------------
Message: 5
Date: Fri, 19 Dec 2014 14:40:38 -0500
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] N210: The total sum of rates exceeds the
maximum capacity of the connection.
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 12/19/2014 02:35 PM, Anderson, Douglas J. via USRP-users wrote:
> Hi all,
>
> I'm trying to figure out if I may have missed something in setting up
> the connection between my USRP and laptop.
>
> I'm getting the following error when I try and push the USRP's sample
> rate past 30MSps:
>
If you want to achieve sample-rates between 25Msps and 50Msps, you'll
need to use 8-bit wire-format.
The maximum you can achieve with full-width samples is 25Msps.
Use --wire-format sc8
> $ uhd_fft -s 50M -f 800M
> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.001-42-g8c87a524
> [...]
> UHD Warning:
> The total sum of rates (50.000000 MSps on 1 channels) exceeds the
> maximum capacity of the connection.
> This can cause overflows (O).
>
> Then the flowgraph hangs.
>
> I'm using USRP N210 with SBX on Ubuntu laptop with 82577LM Gigabit
> Network card.
>
> I have tried connected the USRP directly to the laptop and through a
> D-Link gigabit switch.
>
> I ran the following commands as recommended on the Latency wiki page:
>
> sudo modprobe -r e1000e
> sudo modprobe e1000e InterruptThrottleRate=0 TxAbsIntDelay=0
> TxIntDelay=0 RxAbsIntDelay=0 RxIntDelay=0
>
> Here is the other relevant system info:
>
> ------------------------------------------------------
> $ uname -r
> 3.17.0-031700-lowlatency
>
> $ sudo lshw
> [...]
> *-network
> description: Ethernet interface
> product: 82577LM Gigabit Network Connection
> vendor: Intel Corporation
> physical id: 19
> bus info: pci@0000:00:19.0
> logical name: eth0
> version: 05
> serial: 00:26:b9:d2:92:0a
> size: 1Gbit/s
> capacity: 1Gbit/s
> width: 32 bits
> clock: 33MHz
> capabilities: pm msi bus_master cap_list ethernet
> physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
> configuration: autonegotiation=on broadcast=yes
> driver=e1000e driverversion=2.3.2-k duplex=full firmware=0.12-1
> ip=192.168.130.28 latency=0 link=yes multicast=yes port=twisted pair
> speed=1Gbit/s
> resources: irq:25 memory:f6900000-f691ffff
> memory:f6980000-f6980fff ioport:7040(size=32)
> *-usb:0
> description: USB controller
> product: 5 Series/3400 Series Chipset USB2 Enhanced Host
> Controller
> vendor: Intel Corporation
> physical id: 1a
> bus info: pci@0000:00:1a.0
> version: 05
> width: 32 bits
> clock: 33MHz
> capabilities: pm debug ehci bus_master cap_list
> configuration: driver=ehci-pci latency=0
> resources: irq:16 memory:f6970000-f69703ff
> [...]
>
> $ modinfo e1000e |grep version:
> version: 2.3.2-k
>
> $ cat /etc/sysctl.conf |grep max
> net.core.rmem_max=50000000
> net.core.wmem_max=1048576
>
> ------------------------------------------------------
>
> I guess I'm either missing something or not understanding something
> properly. Any help would be much appreciated!
>
>
> -Doug
>
>
> *Douglas Anderson**| Intern*
> DOC/NTIA/ITS-T | 325 Broadway St., Boulder, CO 80305 | P: 303 497 3582
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
--
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/20141219/d4ec9828/attachment-0001.html>
------------------------------
Message: 6
Date: Fri, 19 Dec 2014 20:33:59 +0000
From: David <[email protected]>
To: [email protected]
Subject: [USRP-users] Build problems with UHD_INLINE
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
I'm having trouble building uhd, the below error occurs on both 3.8.0
and 3.8.1 (I never used an earlier version).
The compiler complains with the following message:
In file included from
/var/tmp/portage/net-wireless/uhd-3.8.1/work/uhd-release_003_008_001/host/include/uhd/utils/byteswap.hpp:54:0,
from
/var/tmp/portage/net-wireless/uhd-3.8.1/work/uhd-release_003_008_001/host/lib/usrp/common/async_packet_handler.hpp:24,
from
/var/tmp/portage/net-wireless/uhd-3.8.1/work/uhd-release_003_008_001/host/lib/usrp/common/fifo_ctrl_excelsior.cpp:19:
/var/tmp/portage/net-wireless/uhd-3.8.1/work/uhd-release_003_008_001/host/include/uhd/utils/byteswap.ipp:
In member function 'void fifo_ctrl_excelsior_impl::handle_msg1()':
/var/tmp/portage/net-wireless/uhd-3.8.1/work/uhd-release_003_008_001/host/include/uhd/utils/byteswap.ipp:120:35:
error: inlining failed in call to always_inline 'T uhd::wtohx(T) [with T
= unsigned int]': indirect function call with a yet undetermined callee
template<typename T> UHD_INLINE T uhd::wtohx(T num){
Removing UHD_INLINE from the four related functions in byteswap.ipp
makes it compile and it seems to work fine. I have attached the patch
that makes it compile, included to demonstrate the workaround rather
than as a suggested fix.
I'm using gcc-4.8.3 and glibc-2.19-r1.
David
-------------- next part --------------
--- byteswap.ipp.orig 2014-12-19 20:19:29.918043894 +0000
+++ byteswap.ipp 2014-12-19 20:19:57.708518118 +0000
@@ -101,7 +101,7 @@
**********************************************************************/
#include <boost/detail/endian.hpp>
-template<typename T> UHD_INLINE T uhd::ntohx(T num){
+template<typename T> T uhd::ntohx(T num){
#ifdef BOOST_BIG_ENDIAN
return num;
#else
@@ -109,7 +109,7 @@
#endif
}
-template<typename T> UHD_INLINE T uhd::htonx(T num){
+template<typename T> T uhd::htonx(T num){
#ifdef BOOST_BIG_ENDIAN
return num;
#else
@@ -117,7 +117,7 @@
#endif
}
-template<typename T> UHD_INLINE T uhd::wtohx(T num){
+template<typename T> T uhd::wtohx(T num){
#ifdef BOOST_BIG_ENDIAN
return uhd::byteswap(num);
#else
@@ -125,7 +125,7 @@
#endif
}
-template<typename T> UHD_INLINE T uhd::htowx(T num){
+template<typename T> T uhd::htowx(T num){
#ifdef BOOST_BIG_ENDIAN
return uhd::byteswap(num);
#else
-------------- next part --------------
A non-text attachment was scrubbed...
Name: build-log.zip
Type: application/x-zip-compressed
Size: 9050 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141219/7fe5bb4c/attachment-0001.zip>
------------------------------
Message: 7
Date: Fri, 19 Dec 2014 20:56:29 +0000
From: "Anderson, Douglas J." <[email protected]>
To: "Marcus D. Leech" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] N210: The total sum of rates exceeds the
maximum capacity of the connection.
Message-ID:
<7f5154c3a654cb4c8cbd18629c331b7120c4c...@itsmail01.its.bldrdoc.gov>
Content-Type: text/plain; charset="iso-8859-1"
Marcus,
That worked great. Thank you for the response!
-Doug
Douglas Anderson | Intern
DOC/NTIA/ITS-T | 325 Broadway St., Boulder, CO 80305 | P: 303 497 3582
________________________________
From: USRP-users [[email protected]] on behalf of Marcus D.
Leech via USRP-users [[email protected]]
Sent: Friday, December 19, 2014 12:40 PM
To: [email protected]
Subject: Re: [USRP-users] N210: The total sum of rates exceeds the maximum
capacity of the connection.
On 12/19/2014 02:35 PM, Anderson, Douglas J. via USRP-users wrote:
Hi all,
I'm trying to figure out if I may have missed something in setting up the
connection between my USRP and laptop.
I'm getting the following error when I try and push the USRP's sample rate past
30MSps:
If you want to achieve sample-rates between 25Msps and 50Msps, you'll need to
use 8-bit wire-format.
The maximum you can achieve with full-width samples is 25Msps.
Use --wire-format sc8
$ uhd_fft -s 50M -f 800M
linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.001-42-g8c87a524
[...]
UHD Warning:
The total sum of rates (50.000000 MSps on 1 channels) exceeds the maximum
capacity of the connection.
This can cause overflows (O).
Then the flowgraph hangs.
I'm using USRP N210 with SBX on Ubuntu laptop with 82577LM Gigabit Network card.
I have tried connected the USRP directly to the laptop and through a D-Link
gigabit switch.
I ran the following commands as recommended on the Latency wiki page:
sudo modprobe -r e1000e
sudo modprobe e1000e InterruptThrottleRate=0 TxAbsIntDelay=0 TxIntDelay=0
RxAbsIntDelay=0 RxIntDelay=0
Here is the other relevant system info:
------------------------------------------------------
$ uname -r
3.17.0-031700-lowlatency
$ sudo lshw
[...]
*-network
description: Ethernet interface
product: 82577LM Gigabit Network Connection
vendor: Intel Corporation
physical id: 19
bus info: pci@0000:00:19.0<UrlBlockedError.aspx>
logical name: eth0
version: 05
serial: 00:26:b9:d2:92:0a
size: 1Gbit/s
capacity: 1Gbit/s
width: 32 bits
clock: 33MHz
capabilities: pm msi bus_master cap_list ethernet physical tp 10bt
10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=e1000e
driverversion=2.3.2-k duplex=full firmware=0.12-1 ip=192.168.130.28 latency=0
link=yes multicast=yes port=twisted pair speed=1Gbit/s
resources: irq:25 memory:f6900000-f691ffff
memory:f6980000-f6980fff ioport:7040(size=32)
*-usb:0
description: USB controller
product: 5 Series/3400 Series Chipset USB2 Enhanced Host Controller
vendor: Intel Corporation
physical id: 1a
bus info: pci@0000:00:1a.0<UrlBlockedError.aspx>
version: 05
width: 32 bits
clock: 33MHz
capabilities: pm debug ehci bus_master cap_list
configuration: driver=ehci-pci latency=0
resources: irq:16 memory:f6970000-f69703ff
[...]
$ modinfo e1000e |grep version:
version: 2.3.2-k
$ cat /etc/sysctl.conf |grep max
net.core.rmem_max=50000000
net.core.wmem_max=1048576
------------------------------------------------------
I guess I'm either missing something or not understanding something properly.
Any help would be much appreciated!
-Doug
Douglas Anderson | Intern
DOC/NTIA/ITS-T | 325 Broadway St., Boulder, CO 80305 | P: 303 497 3582
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
--
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/20141219/ea5b0347/attachment-0001.html>
------------------------------
Message: 8
Date: Sat, 20 Dec 2014 02:41:16 +0000 (GMT)
From: Louis Brown <[email protected]>
To: [email protected]
Subject: [USRP-users] Anybody using gr-osmosdr source or gqrx with UHD
3.8.1?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Argh......I'm pulling my hair out trying to get the device string to work with
gr-osmosdr source or gqrx. My B200 works fine with device string of:
uhd
Although if I try (and I know th?is used to work):
type=b200, uhd
It bombs out with:
RuntimeError: Wrong device arguments specified. Missing nchan?
Of course adding nchan=1 does not work.
For the X310 I must specify the address and subdev, which is usually:
'addr=192.168.40.2', subdev=B:A, uhd
I rebuilt uhd, gnuradio, and gr-osmosdr tonight from github and something seems
to have changed, or else I'm doing something stupid; probably the latter. It's
been working fine for the last year, and I never bothered to write down the
device string that made everything work.
Thanks,
Lou
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141220/b0f3be65/attachment-0001.html>
------------------------------
Message: 9
Date: Fri, 19 Dec 2014 21:45:25 -0500
From: "Marcus D. Leech" <[email protected]>
To: Louis Brown <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] Anybody using gr-osmosdr source or gqrx with
UHD 3.8.1?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 12/19/2014 09:41 PM, Louis Brown via USRP-users wrote:
> Argh......I'm pulling my hair out trying to get the device string to
> work with gr-osmosdr source or gqrx. My B200 works fine with device
> string of:
> uhd
>
> Although if I try (and I know this used to work):
> type=b200, uhd
>
> It bombs out with:
> RuntimeError: Wrong device arguments specified. Missing nchan?
>
> Of course adding nchan=1 does not work.
>
> For the X310 I must specify the address and subdev, which is usually:
> 'addr=192.168.40.2', subdev=B:A, uhd
>
> I rebuilt uhd, gnuradio, and gr-osmosdr tonight from github and
> something seems to have changed, or else I'm doing something stupid;
> probably the latter. It's been working fine for the last year, and I
> never bothered to write down the device string that made everything work.
> Thanks,
> Lou
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Use "uhd" as the first token. That tells gr-osmosdr which of several
high-level device types to use:
uhd,type=b200,nchan=1
Should work just fine.
If not, then post to discuss-gnuradio, where Dimitri sometimes hangs out
(he's the author of gr-osmosdr).
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141219/5d4a4fe2/attachment-0001.html>
------------------------------
Message: 10
Date: Sat, 20 Dec 2014 02:54:09 +0000 (GMT)
From: Louis Brown <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Anybody using gr-osmosdr source or gqrx with
UHD 3.8.1?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
That works! I owe you a beer next GRCON.
For the b200:
uhd,type=b200,nchan=1
For the X310:
uhd,'addr=192.168.40.2',subdev=B:A,nchan=1
Thanks,
Lo?u
On Dec 19, 2014, at 08:45 PM, "Marcus D. Leech" <[email protected]> wrote:
> Use "uhd" as the first token. That tells gr-osmosdr which of several
> high-level device types to use:
>
> uhd,type=b200,nchan=1
>
> Should work just fine.
>
> If not, then post to discuss-gnuradio, where Dimitri sometimes hangs out
> (he's the author of gr-osmosdr).
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141220/f2541a98/attachment-0001.html>
------------------------------
Message: 11
Date: Fri, 19 Dec 2014 21:58:40 -0500
From: "Marcus D. Leech" <[email protected]>
To: Louis Brown <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Anybody using gr-osmosdr source or gqrx with
UHD 3.8.1?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 12/19/2014 09:54 PM, Louis Brown wrote:
> That works! I owe you a beer next GRCON.
>
> For the b200:
> uhd,type=b200,nchan=1
>
> For the X310:
> uhd,'addr=192.168.40.2',subdev=B:A,nchan=1
>
> Thanks,
> Lou
>
Glad it helped.
The key thing to remember is that gr-osmosdr uses the *first* token in
the comma-separated list of tokens as the indicator of which overall
device type you're talking about.
>
> On Dec 19, 2014, at 08:45 PM, "Marcus D. Leech" <[email protected]>
> wrote:
>> Use "uhd" as the first token. That tells gr-osmosdr which of several
>> high-level device types to use:
>>
>> uhd,type=b200,nchan=1
>>
>> Should work just fine.
>>
>> If not, then post to discuss-gnuradio, where Dimitri sometimes hangs
>> out (he's the author of gr-osmosdr).
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141219/4df4e244/attachment-0001.html>
------------------------------
Message: 12
Date: Sat, 20 Dec 2014 10:31:29 -0500
From: Timothy Schaffer <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] About USRP1 Receive Frequecy
Message-ID:
<cacx9bdrz-metzp+pd+zh7hguderv+ah1abq+ofhqwrnsinq...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
What are you using to generate the 910MHz reference signal for the two
different USRPs?
Also it might be easier to view your signal in the frequency domain (using
FFT sink) instead of the time domain (scope sink).
-Tim
On Fri, Dec 19, 2014 at 10:59 AM, Thach Nguyen via USRP-users <
[email protected]> wrote:
>
> Good morning everyone
> I am using couples of USRP1/ FLex900 daughter board. I try to implement
> simple couple transmitter/receiver at 910 MHz. I use QT Sink for analysing
> received signal
> For transmitter and receiver are fine no warning nor error. But it is
> quite strange when i plot received signals with different USRPs. (same GRC
> File) but the output frequency is totally different. (You can see the GRC
> configuration file and the output plot)
> Do you know how to calculate UHD:USRP Source receive frequency?.
>
> Thank you and have a nice weekend
>
>
>
>
> _______________________________________________
> 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/20141220/0b8b5bc1/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 52, Issue 22
******************************************
