Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: Latency Through RF NoC on X310 (Martin Braun)
2. Cannot find usrp e310 with uhd_find_devices (Ivan)
3. x310 Master clock rate (Taariqa Maharaj)
4. Errors 0x8 and 0xf when capturing with b210. (Tyler Weaver)
5. Re: Cannot find usrp e310 with uhd_find_devices (Marcus M?ller)
6. Re: x310 Master clock rate (Marcus M?ller)
7. Re: Errors 0x8 and 0xf when capturing with b210.
([email protected])
8. Re: Cannot find usrp e310 with uhd_find_devices (Neel Pandeya)
9. Re: Errors 0x8 and 0xf when capturing with b210. (Weaver, Tyler)
10. B200 over USB 3 Ubuntu 10.14 Vmworkstation 11 (Paul B)
11. Re: B200 over USB 3 Ubuntu 10.14 Vmworkstation 11
([email protected])
12. Re: B200 over USB 3 Ubuntu 10.14 Vmworkstation 11 (Neel Pandeya)
13. Re: B200 over USB 3 Ubuntu 10.14 Vmworkstation 11 (Neel Pandeya)
14. Re: B200 over USB 3 Ubuntu 10.14 Vmworkstation 11 (Paul B)
15. Re: B200 over USB 3 Ubuntu 10.14 Vmworkstation 11
(Marcus D. Leech)
16. Re: time sync 2 ettus x310 (Michael West)
17. Re: time sync 2 ettus x310 (Sanjoy Basak)
18. Re: x310 Master clock rate (Marcus M?ller)
19. How to (Luong Tan Phong)
20. Solution to get data from 2 RX channels from X310 with the
difference sample rate? (Luong Tan Phong)
21. Measurement of throughput and delay during USRP transmission (???)
22. Re: Solution to get data from 2 RX channels from X310 with
the difference sample rate? (Marcus M?ller)
23. Re: Measurement of throughput and delay during USRP
transmission (Marcus M?ller)
24. Re: x310 Master clock rate (Marcus M?ller)
25. Re: x310 Master clock rate (Marcus M?ller)
26. Re: x310 Master clock rate (Marcus M?ller)
27. Re: Errors 0x8 and 0xf when capturing with b210. (Marcus D. Leech)
28. Re: time sync 2 ettus x310 (Michael West)
----------------------------------------------------------------------
Message: 1
Date: Tue, 21 Apr 2015 09:28:30 -0700
From: Martin Braun <[email protected]>
To: Johnathan Rodgers <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Latency Through RF NoC on X310
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
On 21.04.2015 06:35, Johnathan Rodgers wrote:
> Hi,
> Is there an alternative solution to measure the minimum loopback latency
> in the fpga ?
> I tried to do as follow (radio0 --> radio1) with RFnoc in grc without
> any success : radio0 stays connected.
This is currently a known deficiency, we're on it.
Cheers,
Martin
> Thanks in advance.
> Johnathan
>
> Le 19 mars 2015 23:28, "Martin Braun" <[email protected]
> <mailto:[email protected]>> a ?crit :
>
> FG == flow graph (what GRC produces).
>
> What I mean is a flow graph such as this: http://imgur.com/LuBHfxp
>
> However, we just yesterday realized that if you do this, the Rx
> radio won't be kicked off. We'll have a fix for that soon.
>
> Cheers,
> M
>
> On 19.03.2015 14:53, Johnathan Rodgers wrote:
>
> Hi,
> Martin, what do you mean by :
> "To measure loopback latency, you'd need a simple GRC FG that
> connects
> the rx radio to the tx directly on the FPGA".
> Is it a simple radio0 --> radio1 connection in Gnuradio with a
> src/sink ?
> What does FG mean ?
> Thanks in advance.
> Johnathan
>
> Nevermind again.
>
> On Wed, Mar 18, 2015 at 4:14 PM, John Malsbury
> <[email protected]
> <mailto:[email protected]>
> <mailto:[email protected]
> <mailto:[email protected]>>> wrote:
>
> "Traceback (most recent call last):
> File "/home/jmalsbury/src/gr-ettus/build/top_block.py",
> line 122,
> in <module>
> tb = top_block()
> File "/home/jmalsbury/src/gr-ettus/build/top_block.py",
> line 63,
> in __init__
> self.device3,
> File
>
> "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py",
> line 93, in __getattr__
> return getattr(self._impl, name)
> AttributeError: 'top_block_sptr' object has no attribute
> 'device3'"
>
> Am I missing some device args?
>
> On Wed, Mar 18, 2015 at 4:07 PM, John Malsbury
> <[email protected]
> <mailto:[email protected]>
> <mailto:[email protected]
> <mailto:[email protected]>>>
> wrote:
>
> I'm blind. disregard
>
> On Wed, Mar 18, 2015 at 4:00 PM, John Malsbury
> <[email protected]
> <mailto:[email protected]>
> <mailto:[email protected]
> <mailto:[email protected]>>> wrote:
>
> So... is there an RF NoC 101? I've used the UHD
> src/sink in
> the UHD->RF NoC category. is there anything I need to
> specify to route from Rx/Radio0 to RxRadio1?
>
> -John
>
>
>
> On Fri, Mar 13, 2015 at 2:21 PM, Martin Braun via
> USRP-users
> <[email protected]
> <mailto:[email protected]>
> <mailto:[email protected]
> <mailto:[email protected]>>> wrote:
>
> Yes, you can reduce the 'spp' value. It defaults
> to 364,
> because that's what fits into a standard MTU.
>
> To measure loopback latency, you'd need a simple
> GRC FG
> that connects the rx radio to the tx directly on the
> FPGA, and a scope or something to see the delay.
> In GNU
> Radio, give the rx radio a stream arg value
> 'spp=20' or
> whatever. There may be limits to the size, and
> non-multiples of 64-bits won't do you any good
> (2 sc16
> samples per line).
>
> M
>
>
> On 13.03.2015 11:32, John Malsbury via
> USRP-users wrote:
>
> Are there any UHD tricks I might use to
> stream the
> output of a radio
> block through RF NoC, directly to the other
> radio
> block for re
> transmission, without any FPGA mods? I
> would like
> to test/measure the
> lowest delay possible across the rx
> frontend, ADCs,
> RF NoC, DACs and tx
> frontend...
>
> Are there knobs to tweak to reduce latency
> across RF
> NoC (samples/frame
> or equivalent)?
>
> -John
>
>
>
> _________________________________________________
> USRP-users mailing list
> [email protected]
> <mailto:[email protected]>
> <mailto:[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]
> <mailto:[email protected]>
> <mailto:[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] <mailto:[email protected]>
> <mailto:[email protected]
> <mailto:[email protected]>>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
------------------------------
Message: 2
Date: Tue, 21 Apr 2015 05:44:47 +0000 (UTC)
From: Ivan <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Cannot find usrp e310 with uhd_find_devices
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi,
I've recently started using an E310 USRP. I want to use some GNU radio examples
to generate and receive waveforms but the device is not being detected. I can
log on using both the console and ethernet port. I've configured the usrp to
use a static IP address and set it to 192.168.10.3. I can access this address
through ssh and pinging it also sends replies back. However, running
uhd_find_devices does not work. I get "no uhd devices found". Even when I
specify the address with uhd_find_devices --args="addr=192.168.10.3", I still
don't get anything.?
I use Ubuntu 14.04. I've installed gnuradio and uhd using the gnuradio build
script. When I run uhd_find_devices or uhd_fft, the uhd version that comes out
is UHD_003.008.003-137-g2f760ac0. I've also tried disabling the firewall with
sudo ufw disable, but that makes no difference. What else should I do?
Regards,Ivan
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150421/d9bd4959/attachment-0001.html>
------------------------------
Message: 3
Date: Tue, 21 Apr 2015 09:37:18 +0200
From: Taariqa Maharaj <[email protected]>
To: [email protected]
Subject: [USRP-users] x310 Master clock rate
Message-ID:
<cag71rt1ypsfe+nut_f6kmu2wxfkgjzzn2y3hq+c5on0asvl...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi
Is it possible to set the master clock rate to 160Mhz?
When I try to set the master clock rate to 160Mhz and the sampling rate to
40Msps it brings up an interpolation error.
Its displays the interpolation as odd but uses the master clock rate of
200Mhz to do the calculation which does not make sense as I am setting the
clock rate to 160Mhz.
Regards,
Taariqa
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150421/e76c4079/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 21 Apr 2015 10:42:41 -0600
From: Tyler Weaver <[email protected]>
To: <[email protected]>
Subject: [USRP-users] Errors 0x8 and 0xf when capturing with b210.
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hello,
When trying to capture form the b210 I'm getting the errors 0x8
(overflow) and 0xf (bad packet). I'm running UHD 3.8.2 and have tried
my code (C++ interface) on a dell laptop with the Intel 8 Series C210
USB xHCI (rev 04) Controller. I have tried setting stream_mode to both
STREAM_MODE_START_CONTINUOUS and STREAM_MODE_START_CONTINUOUS. My
otw_format is "sc8". I am also setting the peak value to these values
at different times (0.125, 0.0625, and 1.0). What could I be doing to
cause these errors. This code does not generate errors on the n210 I
have. I've also tried this on a macbook pro (unknown usb controller)
with the same results.
Thank you,
tyler
------------------------------
Message: 5
Date: Tue, 21 Apr 2015 18:44:59 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Cannot find usrp e310 with uhd_find_devices
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Dear Ivan,
the E310 is not designed to work as a peripheral to a PC, but is its own
embedded computer, integrating a USRP. You'd normally run your signal
processing applications, for example GNU Radio, on the E310 itself
rather than on a separate PC.
Thus, E310 can't be detected by uhd_find_devices.
You can try the network_mode [1] on the E310, but it's really just a
diagnostic tool, and delivers only very small sampling rates.
Best regards,
Marcus M?ller
[1] http://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_network_mode
On 04/21/2015 07:44 AM, Ivan via USRP-users wrote:
> Hi,
>
> I've recently started using an E310 USRP. I want to use some GNU radio
> examples to generate and receive waveforms but the device is not being
> detected. I can log on using both the console and ethernet port. I've
> configured the usrp to use a static IP address and set it to
> 192.168.10.3. I can access this address through ssh and pinging it
> also sends replies back. However, running uhd_find_devices does not
> work. I get "no uhd devices found". Even when I specify the address
> with uhd_find_devices --args="addr=192.168.10.3", I still don't get
> anything.
>
> I use Ubuntu 14.04. I've installed gnuradio and uhd using the gnuradio
> build script. When I run uhd_find_devices or uhd_fft, the uhd version
> that comes out is UHD_003.008.003-137-g2f760ac0. I've also tried
> disabling the firewall with sudo ufw disable, but that makes no
> difference. What else should I do?
>
> Regards,
> Ivan
>
>
>
> _______________________________________________
> 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/20150421/09a3d013/attachment-0001.html>
------------------------------
Message: 6
Date: Tue, 21 Apr 2015 18:46:40 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] x310 Master clock rate
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hello Taariqa,
> Is it possible to set the master clock rate to 160Mhz?
no.
> sampling rate to 40Msps
you can do that with the standard 200MS/s master clock rate, so I'm
curious why you want to set it to 160MHz; if you explain a bit about
your application, maybe we can help you find an optimal solution for the
problems you might be encountering.
Best regards,
Marcus M?ller
On 04/21/2015 09:37 AM, Taariqa Maharaj via USRP-users wrote:
> Hi
>
> Is it possible to set the master clock rate to 160Mhz?
> When I try to set the master clock rate to 160Mhz and the sampling
> rate to 40Msps it brings up an interpolation error.
> Its displays the interpolation as odd but uses the master clock rate
> of 200Mhz to do the calculation which does not make sense as I am
> setting the clock rate to 160Mhz.
>
> Regards,
> Taariqa
>
>
> _______________________________________________
> 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/20150421/a28a2ae0/attachment-0001.html>
------------------------------
Message: 7
Date: Tue, 21 Apr 2015 12:50:18 -0400
From: [email protected]
To: Tyler Weaver <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Errors 0x8 and 0xf when capturing with b210.
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
What sample rate?
What are the specs on your Dell laptop, other than the 8-series USB
controller.
What master clock rate are you using?
On 2015-04-21 12:42, Tyler Weaver via USRP-users wrote:
> Hello,
>
> When trying to capture form the b210 I'm getting the errors 0x8
> (overflow) and 0xf (bad packet). I'm running UHD 3.8.2 and have tried
> my code (C++ interface) on a dell laptop with the Intel 8 Series C210
> USB xHCI (rev 04) Controller. I have tried setting stream_mode to both
> STREAM_MODE_START_CONTINUOUS and STREAM_MODE_START_CONTINUOUS. My
> otw_format is "sc8". I am also setting the peak value to these values
> at different times (0.125, 0.0625, and 1.0). What could I be doing to
> cause these errors. This code does not generate errors on the n210 I
> have. I've also tried this on a macbook pro (unknown usb controller)
> with the same results.
>
> Thank you,
> tyler
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [1]
Links:
------
[1] 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/20150421/2166ad55/attachment-0001.html>
------------------------------
Message: 8
Date: Tue, 21 Apr 2015 09:58:25 -0700
From: Neel Pandeya <[email protected]>
To: Ivan <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Cannot find usrp e310 with uhd_find_devices
Message-ID:
<CACaXmv_1o-pCGRHJjqVZcJFWs3pwe0M=g-kjcvg6qyb_7an...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Ivan:
I assume you're trying to run "uhd_find_devices" on the external host,
running Ubuntu 14.04. You need to have Network Mode enabled on your E310,
and you also need to build UHD on the external host with E310 support. By
default, E310 is not enabled when you build UHD. To enable E310 support,
add "-DENABLE_E300=ON" as an option when you invoke cmake. Please see the
links below.
http://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_network_mode
http://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_sdk_usage_uhd
--Neel
On 20 April 2015 at 22:44, Ivan via USRP-users <[email protected]>
wrote:
> Hi,
>
> I've recently started using an E310 USRP. I want to use some GNU radio
> examples to generate and receive waveforms but the device is not being
> detected. I can log on using both the console and ethernet port. I've
> configured the usrp to use a static IP address and set it to 192.168.10.3.
> I can access this address through ssh and pinging it also sends replies
> back. However, running uhd_find_devices does not work. I get "no uhd
> devices found". Even when I specify the address with uhd_find_devices
> --args="addr=192.168.10.3", I still don't get anything.
>
> I use Ubuntu 14.04. I've installed gnuradio and uhd using the gnuradio
> build script. When I run uhd_find_devices or uhd_fft, the uhd version that
> comes out is UHD_003.008.003-137-g2f760ac0. I've also tried disabling the
> firewall with sudo ufw disable, but that makes no difference. What else
> should I do?
>
> Regards,
> Ivan
>
>
> _______________________________________________
> 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/20150421/d10116e6/attachment-0001.html>
------------------------------
Message: 9
Date: Tue, 21 Apr 2015 17:41:17 +0000
From: "Weaver, Tyler" <[email protected]>
To: "[email protected]" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Errors 0x8 and 0xf when capturing with b210.
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Sample rates:
I have tried various sample rates and the errors occur at > 8 MHz. For my
application I need something > 20 MHz. Preferably I want to sample at 30.72
MHz.
Hardware:
dell: i7-4800MQ, 16gb ram, radion 8790M, SSD hd.
mac: i704980HQ, 16gb ram, nvidia gt 750M, SSD hd.
Clock rate:
I?ve tried 30.72 and 61.44 MHz. Neither have gotten rid of the errors.
On Apr 21, 2015, at 10:50 AM, [email protected] wrote:
What sample rate?
What are the specs on your Dell laptop, other than the 8-series USB controller.
What master clock rate are you using?
On 2015-04-21 12:42, Tyler Weaver via USRP-users wrote:
Hello,
When trying to capture form the b210 I'm getting the errors 0x8
(overflow) and 0xf (bad packet). I'm running UHD 3.8.2 and have tried
my code (C++ interface) on a dell laptop with the Intel 8 Series C210
USB xHCI (rev 04) Controller. I have tried setting stream_mode to both
STREAM_MODE_START_CONTINUOUS and STREAM_MODE_START_CONTINUOUS. My
otw_format is "sc8". I am also setting the peak value to these values
at different times (0.125, 0.0625, and 1.0). What could I be doing to
cause these errors. This code does not generate errors on the n210 I
have. I've also tried this on a macbook pro (unknown usb controller)
with the same results.
Thank you,
tyler
_______________________________________________
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>
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQEcBAEBCgAGBQJVNou9AAoJED34NDp4cyE8kaoH/0gdrEHF/q5w7k7CIQGag17K
2atVLHtKBSrjpbKw/g1eXgIqTDnuNf6ih436Rg1XoSsnXprGgBcOuKdYlWw9OwHz
ObEii1PvQvOoBr+pbhJA99TgdaE0099A3ejKiEJqS3hz7hkX3e2hRCFm8mFfVzR/
6IAVzEKL7SrNY3i8m5faRXmFIBNA3Ao9BKEUewPDAvClGZoSr6qtuqt3uY1mPuqU
UTAEapZfLnAKmRdGW1mAPoJf2nmUYfF9UWVrlrb/OHha5YZ+u3I9ztnEk2EHMgaJ
meBlY5rDb/x04N8yZCwDt6d9hEZv1PaE2daGyQCztf5crkztKgMPzkQJMKJj0+g=
=q1fq
-----END PGP SIGNATURE-----
------------------------------
Message: 10
Date: Tue, 21 Apr 2015 17:53:42 +0000
From: Paul B <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] B200 over USB 3 Ubuntu 10.14 Vmworkstation 11
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi guys,
I've managed to get my B200 working in Ubuntu 10.14 running on VMWorkstation
11, but i can only seem to get it working using a USB 2.0 port.
First off, my computer specs running the B200 are:4.0 GHz Intel Core i7Gigabyte
Z97X-UD5H-BK Motherboard16GB RAM
When running the B200 on my USB 2.0 port, i get the following output when using
uhd_usrp_probe:
paul@ubuntu:/usr/lib/uhd/utils$ uhd_usrp_probelinux; GNU C++ version 4.8.3;
Boost_105500; UHD_003.007.001-0-unknown
-- Loading firmware image: /usr/share/uhd/images/usrp_b200_fw.hex... done
UHD Error: USB open failed: insufficient permissions. See the application
notes for your device.-- Loading FPGA image:
/usr/share/uhd/images/usrp_b200_fpga.bin... done-- Operating over USB 2.--
Detecting internal GPSDO.... No GPSDO found-- not found-- Initialize CODEC
control...-- Initialize Radio control...-- Performing register loopback test...
pass-- Performing CODEC loopback test... pass-- Asking for clock rate 32 MHz--
Actually got clock rate 32 MHz-- Performing timer loopback test... pass
_____________________________________________________ /| Device: B-Series
Device| _____________________________________________________| /| |
Mboard: B200| | revision: 4| | product: 1| | serial: 3070E4B|
| FW Version: 4.0| | FPGA Version: 3.0| | | | Time sources: none,
external, gpsdo| | Clock sources: internal, external, gpsdo| | Sensors:
ref_locked| | _____________________________________________________| |
/| | |
RX DSP: 0| | | Freq range: -16.000 to 16.000 Mhz| |
_____________________________________________________| | /| | |
RX Dboard: A| | |
_____________________________________________________| | | /| | |
| RX Frontend: A| | | | Name: FE-RX2| | | | Antennas:
TX/RX, RX2| | | | Sensors: | | | | Freq range: 50.000 to
6000.000 Mhz| | | | Gain range PGA: 0.0 to 73.0 step 1.0 dB| | |
| Connection Type: IQ| | | | Uses LO offset: No| | |
_____________________________________________________| | | /| | |
| RX Codec: A| | | | Name: B200 RX dual ADC| | | | Gain
Elements: None| | _____________________________________________________|
| /| | | TX DSP: 0| | | Freq range: -16.000 to 16.000 Mhz|
| _____________________________________________________| | /| | |
TX Dboard: A| | | ______________
_______________________________________| | | /| | | | TX
Frontend: A| | | | Name: FE-TX2| | | | Antennas: TX/RX| | |
| Sensors: | | | | Freq range: 50.000 to 6000.000 Mhz| | | |
Gain range PGA: 0.0 to 89.8 step 0.2 dB| | | | Connection Type: IQ|
| | | Uses LO offset: No| | |
_____________________________________________________| | | /| | |
| TX Codec: A| | | | Name: B200 TX dual DAC| | | | Gain
Elements: None
I imagine the insufficient permissions message is due to not running
uhd_usrp_probe as sudo? It normally doesn't come up though, and the card
functions as normal. I can run gr-air-modes as normal and without issues
(currently trying to figure out how to send data from gr-air-modes from the
guest Linux OS to the Host Windows OS so i can plot the aircraft).
I know i'm using uhd 003.007.001, but it's currently working, and i'm not too
sure how i go about upgrading to the new version, as i'm currently quite new to
Linux and the whole GNURadio scene and I've read you have to completely remove
the old UHD version before installing the new version, and i'm not too sure how
that'll affect everything.
However, when i try to connect to the B200 via a USB 3.0 port, i get the
following output:
paul@ubuntu:/usr/lib/uhd/utils$ uhd_usrp_probelinux; GNU C++ version 4.8.3;
Boost_105500; UHD_003.007.001-0-unknown
-- Loading firmware image: /usr/share/uhd/images/usrp_b200_fw.hex... doneError:
LookupError: KeyError: No devices found for ----->Empty Device Address
After running that, the B200 will disconnect and no longer show up as a
connectable device in Ubuntu until i disconnect and reconnect the board.
Doing a lsusb gives the following output:
paul@ubuntu:/usr/lib/uhd/utils$ lsusbBus 004 Device 001: ID 1d6b:0003 Linux
Foundation 3.0 root hubBus 003 Device 004: ID 0e0f:0002 VMware, Inc. Virtual
USB HubBus 003 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB HubBus 003
Device 010: ID 2500:0020 Bus 003 Device 002: ID 0e0f:0003 VMware, Inc. Virtual
MouseBus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hubBus 001
Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hubBus 002 Device 002: ID
0e0f:0002 VMware, Inc. Virtual USB HubBus 002 Device 001: ID 1d6b:0001 Linux
Foundation 1.1 root hub
I'm guessing Linux can see the USB 3.0 Host Controller (which shows up in
Windows as Intel USB 3.0 eXtensible Host Controller - 0100 (Microsoft)). I
thought the problem might be with the USB 3 ports themselves, but i tried my
USB Thumb Drive in a USB 3 port, and Linux detects that no problem and it works
fine.
I'm really not sure what the problem is here, but any help will be greatly
appreciated.
Thanks, Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150421/b5a5e365/attachment-0001.html>
------------------------------
Message: 11
Date: Tue, 21 Apr 2015 14:05:42 -0400
From: [email protected]
To: Paul B <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] B200 over USB 3 Ubuntu 10.14 Vmworkstation
11
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
I would emphatically and strongly recommend updgrading to the latest
Ubuntu from Ubuntu 10. There's no way the USB-3.0 drivers
in such an old release of Ubuntu will be stable enough.
Once you've done that:
http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/wiki/UHD_Linux
On 2015-04-21 13:53, Paul B via USRP-users wrote:
> Hi guys,
>
> I've managed to get my B200 working in Ubuntu 10.14 running on VMWorkstation
> 11, but i can only seem to get it working using a USB 2.0 port.
>
> First off, my computer specs running the B200 are:
> 4.0 GHz Intel Core i7
> Gigabyte Z97X-UD5H-BK Motherboard
> 16GB RAM
>
> When running the B200 on my USB 2.0 port, i get the following output when
> using uhd_usrp_probe:
>
> paul@ubuntu:/usr/lib/uhd/utils$ uhd_usrp_probe
> linux; GNU C++ version 4.8.3; Boost_105500; UHD_003.007.001-0-unknown
>
> -- Loading firmware image: /usr/share/uhd/images/usrp_b200_fw.hex... done
>
> UHD Error:
> USB open failed: insufficient permissions.
> See the application notes for your device.
> -- Loading FPGA image: /usr/share/uhd/images/usrp_b200_fpga.bin... done
> -- Operating over USB 2.
> -- Detecting internal GPSDO.... No GPSDO found
> -- not found
> -- Initialize CODEC control...
> -- Initialize Radio control...
> -- Performing register loopback test... pass
> -- Performing CODEC loopback test... pass
> -- Asking for clock rate 32 MHz
> -- Actually got clock rate 32 MHz
> -- Performing timer loopback test... pass
> _____________________________________________________
> /
> | Device: B-Series Device
> | _____________________________________________________
> | /
> | | Mboard: B200
> | | revision: 4
> | | product: 1
> | | serial: 3070E4B
> | | FW Version: 4.0
> | | FPGA Version: 3.0
> | |
> | | Time sources: none, external, gpsdo
> | | Clock sources: internal, external, gpsdo
> | | Sensors: ref_locked
> | | _____________________________________________________
> | | /
> | | | RX DSP: 0
> | | | Freq range: -16.000 to 16.000 Mhz
> | | _____________________________________________________
> | | /
> | | | RX Dboard: A
> | | | _____________________________________________________
> | | | /
> | | | | RX Frontend: A
> | | | | Name: FE-RX2
> | | | | Antennas: TX/RX, RX2
> | | | | Sensors:
> | | | | Freq range: 50.000 to 6000.000 Mhz
> | | | | Gain range PGA: 0.0 to 73.0 step 1.0 dB
> | | | | Connection Type: IQ
> | | | | Uses LO offset: No
> | | | _____________________________________________________
> | | | /
> | | | | RX Codec: A
> | | | | Name: B200 RX dual ADC
> | | | | Gain Elements: None
> | | _____________________________________________________
> | | /
> | | | TX DSP: 0
> | | | Freq range: -16.000 to 16.000 Mhz
> | | _____________________________________________________
> | | /
> | | | TX Dboard: A
> | | | _____________________________________________________
> | | | /
> | | | | TX Frontend: A
> | | | | Name: FE-TX2
> | | | | Antennas: TX/RX
> | | | | Sensors:
> | | | | Freq range: 50.000 to 6000.000 Mhz
> | | | | Gain range PGA: 0.0 to 89.8 step 0.2 dB
> | | | | Connection Type: IQ
> | | | | Uses LO offset: No
> | | | _____________________________________________________
> | | | /
> | | | | TX Codec: A
> | | | | Name: B200 TX dual DAC
> | | | | Gain Elements: None
>
> I imagine the insufficient permissions message is due to not running
> uhd_usrp_probe as sudo? It normally doesn't come up though, and the card
> functions as normal. I can run gr-air-modes as normal and without issues
> (currently trying to figure out how to send data from gr-air-modes from the
> guest Linux OS to the Host Windows OS so i can plot the aircraft).
>
> I know i'm using uhd 003.007.001, but it's currently working, and i'm not too
> sure how i go about upgrading to the new version, as i'm currently quite new
> to Linux and the whole GNURadio scene and I've read you have to completely
> remove the old UHD version before installing the new version, and i'm not too
> sure how that'll affect everything.
>
> However, when i try to connect to the B200 via a USB 3.0 port, i get the
> following output:
>
> paul@ubuntu:/usr/lib/uhd/utils$ uhd_usrp_probe
> linux; GNU C++ version 4.8.3; Boost_105500; UHD_003.007.001-0-unknown
>
> -- Loading firmware image: /usr/share/uhd/images/usrp_b200_fw.hex... done
> Error: LookupError: KeyError: No devices found for ----->
> Empty Device Address
>
> After running that, the B200 will disconnect and no longer show up as a
> connectable device in Ubuntu until i disconnect and reconnect the board.
>
> Doing a lsusb gives the following output:
>
> paul@ubuntu:/usr/lib/uhd/utils$ lsusb
> Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> Bus 003 Device 004: ID 0e0f:0002 VMware, Inc. Virtual USB Hub
> Bus 003 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub
> Bus 003 Device 010: ID 2500:0020
> Bus 003 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse
> Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 002 Device 002: ID 0e0f:0002 VMware, Inc. Virtual USB Hub
> Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
>
> I'm guessing Linux can see the USB 3.0 Host Controller (which shows up in
> Windows as Intel USB 3.0 eXtensible Host Controller - 0100 (Microsoft)). I
> thought the problem might be with the USB 3 ports themselves, but i tried my
> USB Thumb Drive in a USB 3 port, and Linux detects that no problem and it
> works fine.
>
> I'm really not sure what the problem is here, but any help will be greatly
> appreciated.
>
> Thanks,
> Paul
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [1]
Links:
------
[1] 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/20150421/76a7e541/attachment-0001.html>
------------------------------
Message: 12
Date: Tue, 21 Apr 2015 11:12:57 -0700
From: Neel Pandeya <[email protected]>
To: Paul B <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] B200 over USB 3 Ubuntu 10.14 Vmworkstation
11
Message-ID:
<CACaXmv9Gzk2-fiGXGJX=G-F8Okowcp=xo1WMHVMS3=dwjq4...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Paul:
You should not need to run with "sudo". Be make sure to setup udev rules
for USB. Please see the link below.
http://files.ettus.com/manual/page_transport.html#transport_usb_udev
I would still suggest that you upgrade to UHD 3.8.2. Please let me know if
you have any questions about how to do that.
--Neel
On 21 April 2015 at 10:53, Paul B via USRP-users <[email protected]
> wrote:
> Hi guys,
>
> I've managed to get my B200 working in Ubuntu 10.14 running on
> VMWorkstation 11, but i can only seem to get it working using a USB 2.0
> port.
>
> First off, my computer specs running the B200 are:
> 4.0 GHz Intel Core i7
> Gigabyte Z97X-UD5H-BK Motherboard
> 16GB RAM
>
> When running the B200 on my USB 2.0 port, i get the following output when
> using uhd_usrp_probe:
>
> paul@ubuntu:/usr/lib/uhd/utils$ uhd_usrp_probe
> linux; GNU C++ version 4.8.3; Boost_105500; UHD_003.007.001-0-unknown
>
> -- Loading firmware image: /usr/share/uhd/images/usrp_b200_fw.hex... done
>
> UHD Error:
> USB open failed: insufficient permissions.
> See the application notes for your device.
> -- Loading FPGA image: /usr/share/uhd/images/usrp_b200_fpga.bin... done
> -- Operating over USB 2.
> -- Detecting internal GPSDO.... No GPSDO found
> -- not found
> -- Initialize CODEC control...
> -- Initialize Radio control...
> -- Performing register loopback test... pass
> -- Performing CODEC loopback test... pass
> -- Asking for clock rate 32 MHz
> -- Actually got clock rate 32 MHz
> -- Performing timer loopback test... pass
> _____________________________________________________
> /
> | Device: B-Series Device
> | _____________________________________________________
> | /
> | | Mboard: B200
> | | revision: 4
> | | product: 1
> | | serial: 3070E4B
> | | FW Version: 4.0
> | | FPGA Version: 3.0
> | |
> | | Time sources: none, external, gpsdo
> | | Clock sources: internal, external, gpsdo
> | | Sensors: ref_locked
> | | _____________________________________________________
> | | /
> | | | RX DSP: 0
> | | | Freq range: -16.000 to 16.000 Mhz
> | | _____________________________________________________
> | | /
> | | | RX Dboard: A
> | | | _____________________________________________________
> | | | /
> | | | | RX Frontend: A
> | | | | Name: FE-RX2
> | | | | Antennas: TX/RX, RX2
> | | | | Sensors:
> | | | | Freq range: 50.000 to 6000.000 Mhz
> | | | | Gain range PGA: 0.0 to 73.0 step 1.0 dB
> | | | | Connection Type: IQ
> | | | | Uses LO offset: No
> | | | _____________________________________________________
> | | | /
> | | | | RX Codec: A
> | | | | Name: B200 RX dual ADC
> | | | | Gain Elements: None
> | | _____________________________________________________
> | | /
> | | | TX DSP: 0
> | | | Freq range: -16.000 to 16.000 Mhz
> | | _____________________________________________________
> | | /
> | | | TX Dboard: A
> | | | _____________________________________________________
> | | | /
> | | | | TX Frontend: A
> | | | | Name: FE-TX2
> | | | | Antennas: TX/RX
> | | | | Sensors:
> | | | | Freq range: 50.000 to 6000.000 Mhz
> | | | | Gain range PGA: 0.0 to 89.8 step 0.2 dB
> | | | | Connection Type: IQ
> | | | | Uses LO offset: No
> | | | _____________________________________________________
> | | | /
> | | | | TX Codec: A
> | | | | Name: B200 TX dual DAC
> | | | | Gain Elements: None
>
> I imagine the insufficient permissions message is due to not running
> uhd_usrp_probe as sudo? It normally doesn't come up though, and the card
> functions as normal. I can run gr-air-modes as normal and without issues
> (currently trying to figure out how to send data from gr-air-modes from the
> guest Linux OS to the Host Windows OS so i can plot the aircraft).
>
> I know i'm using uhd 003.007.001, but it's currently working, and i'm not
> too sure how i go about upgrading to the new version, as i'm currently
> quite new to Linux and the whole GNURadio scene and I've read you have to
> completely remove the old UHD version before installing the new version,
> and i'm not too sure how that'll affect everything.
>
> However, when i try to connect to the B200 via a USB 3.0 port, i get the
> following output:
>
> paul@ubuntu:/usr/lib/uhd/utils$ uhd_usrp_probe
> linux; GNU C++ version 4.8.3; Boost_105500; UHD_003.007.001-0-unknown
>
> -- Loading firmware image: /usr/share/uhd/images/usrp_b200_fw.hex... done
> Error: LookupError: KeyError: No devices found for ----->
> Empty Device Address
>
> After running that, the B200 will disconnect and no longer show up as a
> connectable device in Ubuntu until i disconnect and reconnect the board.
>
> Doing a lsusb gives the following output:
>
> paul@ubuntu:/usr/lib/uhd/utils$ lsusb
> Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> Bus 003 Device 004: ID 0e0f:0002 VMware, Inc. Virtual USB Hub
> Bus 003 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub
> Bus 003 Device 010: ID 2500:0020
> Bus 003 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse
> Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 002 Device 002: ID 0e0f:0002 VMware, Inc. Virtual USB Hub
> Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
>
>
> I'm guessing Linux can see the USB 3.0 Host Controller (which shows up in
> Windows as Intel USB 3.0 eXtensible Host Controller - 0100 (Microsoft)). I
> thought the problem might be with the USB 3 ports themselves, but i tried
> my USB Thumb Drive in a USB 3 port, and Linux detects that no problem and
> it works fine.
>
> I'm really not sure what the problem is here, but any help will be greatly
> appreciated.
>
> Thanks,
> Paul
>
> _______________________________________________
> 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/20150421/112e35d7/attachment-0001.html>
------------------------------
Message: 13
Date: Tue, 21 Apr 2015 11:15:05 -0700
From: Neel Pandeya <[email protected]>
To: Paul B <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] B200 over USB 3 Ubuntu 10.14 Vmworkstation
11
Message-ID:
<CACaXmv_p2E3p9Xo+VixeAFd=5kusjdjdrbzpvhejsakjfca...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Paul, are you running Ubuntu 10.04, 10.10, or 14.10?? You wrote "10.14" in
your email - was that a typo??
I agree with Marcus, you should definitely be running Ubuntu 14.04 or 14.10.
On 21 April 2015 at 11:05, Marcus D. Leech via USRP-users <
[email protected]> wrote:
> I would emphatically and strongly recommend updgrading to the latest
> Ubuntu from Ubuntu 10. There's no way the USB-3.0 drivers
> in such an old release of Ubuntu will be stable enough.
>
>
>
> Once you've done that:
>
>
>
> http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/wiki/UHD_Linux
>
>
>
>
>
>
> On 2015-04-21 13:53, Paul B via USRP-users wrote:
>
> Hi guys,
>
> I've managed to get my B200 working in Ubuntu 10.14 running on
> VMWorkstation 11, but i can only seem to get it working using a USB 2.0
> port.
>
> First off, my computer specs running the B200 are:
> 4.0 GHz Intel Core i7
> Gigabyte Z97X-UD5H-BK Motherboard
> 16GB RAM
>
> When running the B200 on my USB 2.0 port, i get the following output when
> using uhd_usrp_probe:
>
> paul@ubuntu:/usr/lib/uhd/utils$ uhd_usrp_probe
> linux; GNU C++ version 4.8.3; Boost_105500; UHD_003.007.001-0-unknown
>
> -- Loading firmware image: /usr/share/uhd/images/usrp_b200_fw.hex... done
>
> UHD Error:
> USB open failed: insufficient permissions.
> See the application notes for your device.
> -- Loading FPGA image: /usr/share/uhd/images/usrp_b200_fpga.bin... done
> -- Operating over USB 2.
> -- Detecting internal GPSDO.... No GPSDO found
> -- not found
> -- Initialize CODEC control...
> -- Initialize Radio control...
> -- Performing register loopback test... pass
> -- Performing CODEC loopback test... pass
> -- Asking for clock rate 32 MHz
> -- Actually got clock rate 32 MHz
> -- Performing timer loopback test... pass
> _____________________________________________________
> /
> | Device: B-Series Device
> | _____________________________________________________
> | /
> | | Mboard: B200
> | | revision: 4
> | | product: 1
> | | serial: 3070E4B
> | | FW Version: 4.0
> | | FPGA Version: 3.0
> | |
> | | Time sources: none, external, gpsdo
> | | Clock sources: internal, external, gpsdo
> | | Sensors: ref_locked
> | | _____________________________________________________
> | | /
> | | | RX DSP: 0
> | | | Freq range: -16.000 to 16.000 Mhz
> | | _____________________________________________________
> | | /
> | | | RX Dboard: A
> | | | _____________________________________________________
> | | | /
> | | | | RX Frontend: A
> | | | | Name: FE-RX2
> | | | | Antennas: TX/RX, RX2
> | | | | Sensors:
> | | | | Freq range: 50.000 to 6000.000 Mhz
> | | | | Gain range PGA: 0.0 to 73.0 step 1.0 dB
> | | | | Connection Type: IQ
> | | | | Uses LO offset: No
> | | | _____________________________________________________
> | | | /
> | | | | RX Codec: A
> | | | | Name: B200 RX dual ADC
> | | | | Gain Elements: None
> | | _____________________________________________________
> | | /
> | | | TX DSP: 0
> | | | Freq range: -16.000 to 16.000 Mhz
> | | _____________________________________________________
> | | /
> | | | TX Dboard: A
> | | | _____________________________________________________
> | | | /
> | | | | TX Frontend: A
> | | | | Name: FE-TX2
> | | | | Antennas: TX/RX
> | | | | Sensors:
> | | | | Freq range: 50.000 to 6000.000 Mhz
> | | | | Gain range PGA: 0.0 to 89.8 step 0.2 dB
> | | | | Connection Type: IQ
> | | | | Uses LO offset: No
> | | | _____________________________________________________
> | | | /
> | | | | TX Codec: A
> | | | | Name: B200 TX dual DAC
> | | | | Gain Elements: None
>
> I imagine the insufficient permissions message is due to not running
> uhd_usrp_probe as sudo? It normally doesn't come up though, and the card
> functions as normal. I can run gr-air-modes as normal and without issues
> (currently trying to figure out how to send data from gr-air-modes from the
> guest Linux OS to the Host Windows OS so i can plot the aircraft).
>
> I know i'm using uhd 003.007.001, but it's currently working, and i'm not
> too sure how i go about upgrading to the new version, as i'm currently
> quite new to Linux and the whole GNURadio scene and I've read you have to
> completely remove the old UHD version before installing the new version,
> and i'm not too sure how that'll affect everything.
>
> However, when i try to connect to the B200 via a USB 3.0 port, i get the
> following output:
>
> paul@ubuntu:/usr/lib/uhd/utils$ uhd_usrp_probe
> linux; GNU C++ version 4.8.3; Boost_105500; UHD_003.007.001-0-unknown
>
> -- Loading firmware image: /usr/share/uhd/images/usrp_b200_fw.hex... done
> Error: LookupError: KeyError: No devices found for ----->
> Empty Device Address
>
> After running that, the B200 will disconnect and no longer show up as a
> connectable device in Ubuntu until i disconnect and reconnect the board.
>
> Doing a lsusb gives the following output:
>
> paul@ubuntu:/usr/lib/uhd/utils$ lsusb
> Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> Bus 003 Device 004: ID 0e0f:0002 VMware, Inc. Virtual USB Hub
> Bus 003 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub
> Bus 003 Device 010: ID 2500:0020
> Bus 003 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse
> Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 002 Device 002: ID 0e0f:0002 VMware, Inc. Virtual USB Hub
> Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
>
>
> I'm guessing Linux can see the USB 3.0 Host Controller (which shows up in
> Windows as Intel USB 3.0 eXtensible Host Controller - 0100 (Microsoft)). I
> thought the problem might be with the USB 3 ports themselves, but i tried
> my USB Thumb Drive in a USB 3 port, and Linux detects that no problem and
> it works fine.
>
> I'm really not sure what the problem is here, but any help will be greatly
> appreciated.
>
> Thanks,
> Paul
>
> _______________________________________________
> USRP-users mailing
> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150421/a256e849/attachment-0001.html>
------------------------------
Message: 14
Date: Tue, 21 Apr 2015 19:32:04 +0100
From: Paul B <[email protected]>
To: <[email protected]>, "Neel Pandeya" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] B200 over USB 3 Ubuntu 10.14 Vmworkstation
11
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Neel, Marcus,
I?m so so sorry, i meant to say i?m runing 14.10, with the 3.16 Kernel.
I just put them the wrong way round when typing the e-mail. Sorry for confusing
you both.
I?m just in the process of re-installing my Windows 8.1 (Virtual Machine is
backed up and safe) then i?ll get back on and see if i can sort it out.
I?m not sure how i go about upgrading to the latest UHD drivers from what i
have how, so any help regarding that would be great. (What to remove, what to
keep, commands etc ? as i say, i?m pretty much new to Linux after being a
Windows user for a long time)
Sorry again guys!
From: [email protected]
Sent: Tuesday, April 21, 2015 7:05 PM
To: Paul B
Cc: [email protected]
Subject: Re: [USRP-users] B200 over USB 3 Ubuntu 10.14 Vmworkstation 11
I would emphatically and strongly recommend updgrading to the latest Ubuntu
from Ubuntu 10. There's no way the USB-3.0 drivers
in such an old release of Ubuntu will be stable enough.
Once you've done that:
http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/wiki/UHD_Linux
On 2015-04-21 13:53, Paul B via USRP-users wrote:
Hi guys,
I've managed to get my B200 working in Ubuntu 10.14 running on VMWorkstation
11, but i can only seem to get it working using a USB 2.0 port.
First off, my computer specs running the B200 are:
4.0 GHz Intel Core i7
Gigabyte Z97X-UD5H-BK Motherboard
16GB RAM
When running the B200 on my USB 2.0 port, i get the following output when
using uhd_usrp_probe:
paul@ubuntu:/usr/lib/uhd/utils$ uhd_usrp_probe
linux; GNU C++ version 4.8.3; Boost_105500; UHD_003.007.001-0-unknown
-- Loading firmware image: /usr/share/uhd/images/usrp_b200_fw.hex... done
UHD Error:
USB open failed: insufficient permissions.
See the application notes for your device.
-- Loading FPGA image: /usr/share/uhd/images/usrp_b200_fpga.bin... done
-- Operating over USB 2.
-- Detecting internal GPSDO.... No GPSDO found
-- not found
-- Initialize CODEC control...
-- Initialize Radio control...
-- Performing register loopback test... pass
-- Performing CODEC loopback test... pass
-- Asking for clock rate 32 MHz
-- Actually got clock rate 32 MHz
-- Performing timer loopback test... pass
_____________________________________________________
/
| Device: B-Series Device
| _____________________________________________________
| /
| | Mboard: B200
| | revision: 4
| | product: 1
| | serial: 3070E4B
| | FW Version: 4.0
| | FPGA Version: 3.0
| |
| | Time sources: none, external, gpsdo
| | Clock sources: internal, external, gpsdo
| | Sensors: ref_locked
| | _____________________________________________________
| | /
| | | RX DSP: 0
| | | Freq range: -16.000 to 16.000 Mhz
| | _____________________________________________________
| | /
| | | RX Dboard: A
| | | _____________________________________________________
| | | /
| | | | RX Frontend: A
| | | | Name: FE-RX2
| | | | Antennas: TX/RX, RX2
| | | | Sensors:
| | | | Freq range: 50.000 to 6000.000 Mhz
| | | | Gain range PGA: 0.0 to 73.0 step 1.0 dB
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Codec: A
| | | | Name: B200 RX dual ADC
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | TX DSP: 0
| | | Freq range: -16.000 to 16.000 Mhz
| | _____________________________________________________
| | /
| | | TX Dboard: A
| | | _____________________________________________________
| | | /
| | | | TX Frontend: A
| | | | Name: FE-TX2
| | | | Antennas: TX/RX
| | | | Sensors:
| | | | Freq range: 50.000 to 6000.000 Mhz
| | | | Gain range PGA: 0.0 to 89.8 step 0.2 dB
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Codec: A
| | | | Name: B200 TX dual DAC
| | | | Gain Elements: None
I imagine the insufficient permissions message is due to not running
uhd_usrp_probe as sudo? It normally doesn't come up though, and the card
functions as normal. I can run gr-air-modes as normal and without issues
(currently trying to figure out how to send data from gr-air-modes from the
guest Linux OS to the Host Windows OS so i can plot the aircraft).
I know i'm using uhd 003.007.001, but it's currently working, and i'm not too
sure how i go about upgrading to the new version, as i'm currently quite new to
Linux and the whole GNURadio scene and I've read you have to completely remove
the old UHD version before installing the new version, and i'm not too sure how
that'll affect everything.
However, when i try to connect to the B200 via a USB 3.0 port, i get the
following output:
paul@ubuntu:/usr/lib/uhd/utils$ uhd_usrp_probe
linux; GNU C++ version 4.8.3; Boost_105500; UHD_003.007.001-0-unknown
-- Loading firmware image: /usr/share/uhd/images/usrp_b200_fw.hex... done
Error: LookupError: KeyError: No devices found for ----->
Empty Device Address
After running that, the B200 will disconnect and no longer show up as a
connectable device in Ubuntu until i disconnect and reconnect the board.
Doing a lsusb gives the following output:
paul@ubuntu:/usr/lib/uhd/utils$ lsusb
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 004: ID 0e0f:0002 VMware, Inc. Virtual USB Hub
Bus 003 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub
Bus 003 Device 010: ID 2500:0020
Bus 003 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 0e0f:0002 VMware, Inc. Virtual USB Hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
I'm guessing Linux can see the USB 3.0 Host Controller (which shows up in
Windows as Intel USB 3.0 eXtensible Host Controller - 0100 (Microsoft)). I
thought the problem might be with the USB 3 ports themselves, but i tried my
USB Thumb Drive in a USB 3 port, and Linux detects that no problem and it works
fine.
I'm really not sure what the problem is here, but any help will be greatly
appreciated.
Thanks,
Paul
_______________________________________________
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/20150421/aca86b2f/attachment-0001.html>
------------------------------
Message: 15
Date: Tue, 21 Apr 2015 17:12:44 -0400
From: "Marcus D. Leech" <[email protected]>
To: Paul B <[email protected]>, Neel Pandeya
<[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] B200 over USB 3 Ubuntu 10.14 Vmworkstation
11
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 04/21/2015 02:32 PM, Paul B wrote:
> Neel, Marcus,
> I?m so so sorry, i meant to say i?m runing 14.10, with the 3.16 Kernel.
> I just put them the wrong way round when typing the e-mail. Sorry for
> confusing you both.
> I?m just in the process of re-installing my Windows 8.1 (Virtual
> Machine is backed up and safe) then i?ll get back on and see if i can
> sort it out.
> I?m not sure how i go about upgrading to the latest UHD drivers from
> what i have how, so any help regarding that would be great. (What to
> remove, what to keep, commands etc ? as i say, i?m pretty much new to
> Linux after being a Windows user for a long time)
> Sorry again guys!
>
Use your package management tools to remove any vestiges of UHD, then:
http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/wiki/UHD_Linux
Also, getting decent performance over USB-3.0 within a VM is just asking
for trouble. USB support in VMs varies from kinda-OK to downright
horrific.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150421/a284c24d/attachment-0001.html>
------------------------------
Message: 16
Date: Tue, 21 Apr 2015 17:29:34 -0700
From: Michael West <[email protected]>
To: Sanjoy Basak <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] time sync 2 ettus x310
Message-ID:
<CAM4xKrrta5Ry3_msOr=PdYMR7TtVjdQGFZmkBnfs-Dy=fat...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Sanjoy,
The distortion may be due to the fact that some frontend components are
disabled or powered down while not transmitting or receiving and take a
little time to settle when enabled or powered up. For the X310, there are
3 ways around this:
1) Start TX and RX earlier and throw away RX data (as you have done)
2) Modify ATR settings dynamically so the frontend components stay powered
on and enabled. This can be done by using the multi_usrp::set_gpio_attr()
method. The banks are RX0, RX1, TX0, and TX1. You can accomplish this by
adding the following lines to your code:
usrp->set_gpio_attr("RX0", "ATR_0X", usrp->get_gpio_attr("RX0",
"ATR_XX", 0), ~0, 0);
usrp->set_gpio_attr("RX1", "ATR_0X", usrp->get_gpio_attr("RX1",
"ATR_XX", 0), ~0, 0);
usrp->set_gpio_attr("TX0", "ATR_0X", usrp->get_gpio_attr("TX0",
"ATR_XX", 0), ~0, 0);
usrp->set_gpio_attr("TX1", "ATR_0X", usrp->get_gpio_attr("TX1",
"ATR_XX", 0), ~0, 0);
usrp->set_gpio_attr("RX0", "ATR_0X", usrp->get_gpio_attr("RX0",
"ATR_XX", 1), ~0, 1);
usrp->set_gpio_attr("RX1", "ATR_0X", usrp->get_gpio_attr("RX1",
"ATR_XX", 1), ~0, 1);
usrp->set_gpio_attr("TX0", "ATR_0X", usrp->get_gpio_attr("TX0",
"ATR_XX", 1), ~0, 1);
usrp->set_gpio_attr("TX1", "ATR_0X", usrp->get_gpio_attr("TX1",
"ATR_XX", 1), ~0, 1);
*Note that changing the antenna or gain settings may overwrite these values.
3) Modify ATR settings in UHD code. This is done by editing the UHD code
for the specific daughter board to change the ATR settings.
Option #3 is the one that has worked the best for most users. If you let
me know what daughter card and UHD version you are using, I may be able to
provide you with a UHD patch.
Regards,
Michael
On Tue, Apr 21, 2015 at 1:34 AM, Sanjoy Basak via USRP-users <
[email protected]> wrote:
> Dear Mr. Martin,
> Thanks for the reply. Yes, right now I am not using octoclock, so the
> problem while using 2 USRPsis understandable.
>
> However, regarding distortion, yes I am having distortion at the beginning
> when I am using one usrp for SISO case for x310. I found this problem even
> in b210 as well. I wonder why no one discussed or how did they actually
> solved for radar uses. But I hope I would get my solution here.
>
>
> [image: Inline image 1]
> This is a figure of xcorr of rx and tx signal. The red marked distortion I
> am having almost always. I don't know the reason. If I drop few bins in my
> binary file and then start receiving my signal then I am getting an
> undistorted signal looks like the following.( I am transmitting and
> receiving using binary file).
> However, dropping bins is undesirable for radar application.
> [image: Inline image 3]
> If I use the distorted frame, as obvious I get distorted result. However,
> after dropping bins the fresh frame gives me the exact result after signal
> processing in matlab.
> Can you please tell me how to avoid this distortion at the beginning?
>
> best regards
> Sanjoy
>
>
>
>
>
>
>
>
> On Tue, Apr 21, 2015 at 12:10 AM, Martin Braun via USRP-users <
> [email protected]> wrote:
>
>> Sanjoy,
>>
>> if you want to do radar, you need to make sure both devices are
>> connected to the same external reference. For radar, you can't run off
>> of separate clocks.
>>
>> We've confirmed timing accuracy across devices on the nanosecond scale
>> in the past (using OctoClocks for clock distribution).
>>
>> Cheers,
>> M
>>
>> On 17.04.2015 06:00, Sanjoy Basak via USRP-users wrote:
>> > Hi all,
>> > I am trying to sync 2 ettus x310 in time. However, I am always having a
>> > distortion at the beginning after receiving, and there is always a
>> > delay of few microseconds between the tx and rx. I put tx in one x310
>> > and rx in another x310 and its in a wired connection. GPS antenna is
>> > connected to one usrp(with Tx) and another one is on external ref(Rx).
>> >
>> > So now if I check the last pps on both usrp; it shows tx:0; rx:2s;
>> > then I am compensating it making it set_start_time both at for 4s. So
>> > ideally I should get time synced tx and rx signal.
>> >
>> > But I am getting distortion in Rx signal for 2seconds at the beginning;
>> > this is constant for every sampling freq; so if in that region I have my
>> > rx signal I can't retrieve that as the distortion is already introduced
>> > there.
>> > As I am trying to implement radar with x310, this is a serious problem
>> > for me. As within first 2 seconds and few microseconds I can't receive
>> > anything.
>> >
>> > I would really appreciate any kind of suggestion that come through. If
>> > anyone have question regarding setup or python code please ask.
>> > Thanks for reading.
>> >
>> > Best regards
>> > Sanjoy
>> >
>> >
>> >
>> > _______________________________________________
>> > USRP-users mailing list
>> > [email protected]
>> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> >
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150421/1f3077ee/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: untitled.jpg
Type: image/jpeg
Size: 122891 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150421/1f3077ee/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: untitled2.jpg
Type: image/jpeg
Size: 18723 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150421/1f3077ee/attachment-0003.jpg>
------------------------------
Message: 17
Date: Wed, 22 Apr 2015 11:36:29 +0200
From: Sanjoy Basak <[email protected]>
To: Michael West <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] time sync 2 ettus x310
Message-ID:
<cajpq1a2z1ffewwkbabhxv8f_zdwfpmctypsky1d6p9xrewu...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear Mr. Michael,
Thank you very much for the reply. I am putting all the information here
regarding usrp.
daughter board: SBX-120
UHD version: UHD_003.008.002-80-ge28d7844
I am attaching here a pdf which includes all other information of the usrp.
Please send me the patch and other instruction and suggestion.
Have a nice day.
best regards
Sanjoy
On Wed, Apr 22, 2015 at 2:29 AM, Michael West <[email protected]>
wrote:
> Hi Sanjoy,
>
> The distortion may be due to the fact that some frontend components are
> disabled or powered down while not transmitting or receiving and take a
> little time to settle when enabled or powered up. For the X310, there are
> 3 ways around this:
>
> 1) Start TX and RX earlier and throw away RX data (as you have done)
> 2) Modify ATR settings dynamically so the frontend components stay
> powered on and enabled. This can be done by using the
> multi_usrp::set_gpio_attr() method. The banks are RX0, RX1, TX0, and TX1.
> You can accomplish this by adding the following lines to your code:
> usrp->set_gpio_attr("RX0", "ATR_0X", usrp->get_gpio_attr("RX0",
> "ATR_XX", 0), ~0, 0);
> usrp->set_gpio_attr("RX1", "ATR_0X", usrp->get_gpio_attr("RX1",
> "ATR_XX", 0), ~0, 0);
> usrp->set_gpio_attr("TX0", "ATR_0X", usrp->get_gpio_attr("TX0",
> "ATR_XX", 0), ~0, 0);
> usrp->set_gpio_attr("TX1", "ATR_0X", usrp->get_gpio_attr("TX1",
> "ATR_XX", 0), ~0, 0);
> usrp->set_gpio_attr("RX0", "ATR_0X", usrp->get_gpio_attr("RX0",
> "ATR_XX", 1), ~0, 1);
> usrp->set_gpio_attr("RX1", "ATR_0X", usrp->get_gpio_attr("RX1",
> "ATR_XX", 1), ~0, 1);
> usrp->set_gpio_attr("TX0", "ATR_0X", usrp->get_gpio_attr("TX0",
> "ATR_XX", 1), ~0, 1);
> usrp->set_gpio_attr("TX1", "ATR_0X", usrp->get_gpio_attr("TX1",
> "ATR_XX", 1), ~0, 1);
> *Note that changing the antenna or gain settings may overwrite these
> values.
> 3) Modify ATR settings in UHD code. This is done by editing the UHD code
> for the specific daughter board to change the ATR settings.
>
> Option #3 is the one that has worked the best for most users. If you let
> me know what daughter card and UHD version you are using, I may be able to
> provide you with a UHD patch.
>
> Regards,
> Michael
>
>
>
> On Tue, Apr 21, 2015 at 1:34 AM, Sanjoy Basak via USRP-users <
> [email protected]> wrote:
>
>> Dear Mr. Martin,
>> Thanks for the reply. Yes, right now I am not using octoclock, so the
>> problem while using 2 USRPsis understandable.
>>
>> However, regarding distortion, yes I am having distortion at the
>> beginning when I am using one usrp for SISO case for x310. I found this
>> problem even in b210 as well. I wonder why no one discussed or how did they
>> actually solved for radar uses. But I hope I would get my solution here.
>>
>>
>> [image: Inline image 1]
>> This is a figure of xcorr of rx and tx signal. The red marked distortion
>> I am having almost always. I don't know the reason. If I drop few bins in
>> my binary file and then start receiving my signal then I am getting an
>> undistorted signal looks like the following.( I am transmitting and
>> receiving using binary file).
>> However, dropping bins is undesirable for radar application.
>> [image: Inline image 3]
>> If I use the distorted frame, as obvious I get distorted result. However,
>> after dropping bins the fresh frame gives me the exact result after signal
>> processing in matlab.
>> Can you please tell me how to avoid this distortion at the beginning?
>>
>> best regards
>> Sanjoy
>>
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Apr 21, 2015 at 12:10 AM, Martin Braun via USRP-users <
>> [email protected]> wrote:
>>
>>> Sanjoy,
>>>
>>> if you want to do radar, you need to make sure both devices are
>>> connected to the same external reference. For radar, you can't run off
>>> of separate clocks.
>>>
>>> We've confirmed timing accuracy across devices on the nanosecond scale
>>> in the past (using OctoClocks for clock distribution).
>>>
>>> Cheers,
>>> M
>>>
>>> On 17.04.2015 06:00, Sanjoy Basak via USRP-users wrote:
>>> > Hi all,
>>> > I am trying to sync 2 ettus x310 in time. However, I am always having a
>>> > distortion at the beginning after receiving, and there is always a
>>> > delay of few microseconds between the tx and rx. I put tx in one x310
>>> > and rx in another x310 and its in a wired connection. GPS antenna is
>>> > connected to one usrp(with Tx) and another one is on external ref(Rx).
>>> >
>>> > So now if I check the last pps on both usrp; it shows tx:0; rx:2s;
>>> > then I am compensating it making it set_start_time both at for 4s. So
>>> > ideally I should get time synced tx and rx signal.
>>> >
>>> > But I am getting distortion in Rx signal for 2seconds at the beginning;
>>> > this is constant for every sampling freq; so if in that region I have
>>> my
>>> > rx signal I can't retrieve that as the distortion is already introduced
>>> > there.
>>> > As I am trying to implement radar with x310, this is a serious problem
>>> > for me. As within first 2 seconds and few microseconds I can't receive
>>> > anything.
>>> >
>>> > I would really appreciate any kind of suggestion that come through. If
>>> > anyone have question regarding setup or python code please ask.
>>> > Thanks for reading.
>>> >
>>> > Best regards
>>> > Sanjoy
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > USRP-users mailing list
>>> > [email protected]
>>> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>> >
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150422/b293b45e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: untitled2.jpg
Type: image/jpeg
Size: 18723 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150422/b293b45e/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: untitled.jpg
Type: image/jpeg
Size: 122891 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150422/b293b45e/attachment-0003.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: usrp info.pdf
Type: application/pdf
Size: 7926 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150422/b293b45e/attachment-0001.pdf>
------------------------------
Message: 18
Date: Wed, 22 Apr 2015 11:44:54 +0200
From: Marcus M?ller <[email protected]>
To: Taariqa Maharaj <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] x310 Master clock rate
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi!
Thanks for following up on this.
> With the master clock set at 200Mhz and a sampling rate of 40Msps the
> following warning appears:
>
> UHD Warning:
>
> The requested interpolation is odd; the user should expect CIC rolloff.
>
> Select an even interpolation to ensure that a halfband filter is enabled.
>
> interpolation = dsp_rate/samp_rate -> 5 = (200.000000 MHz)/(40.000000 MHz)
>
>
To explain the warning:
The FPGA decimates the RX samples down, coming in at the master clock
rate from the ADC, to the sampling rate you select.
To do that without introducing aliasing, it has to low-pass filter them.
The FPGA filter chain has multiple stages; if I remember correctly, the
filters are in this order:
1. 1x CIC filter for odd factors in decimation
2. 3x 31-tap half band filters that each implement a good decimation for
factors of 2 each.
Now, if you use an odd decimation (200MHz/40MHz==5), there's no factor
of 2 in your decimation, and hence you only use the "not-as-good" CIC
filter, and are likely to see effects of filter roll-of at the edges of
your band.
In TX direction, it's quite the same problem:
1. 1x 17-tap half band interpolators
2. 1x 5-tap half band interpolators
3. 1x CIC
Therefore: if your measurements show that your signal is OK for your
application, just ignore the warning (it's just a warning, not an
error); if you think this is bad for the signal you want to work with,
I'd recommend using a 50MS/s sampling rate -- that would have a
decimation of 4 and should work beautifully. Of course, this means that
your host computer would have to implement the interpolation.
How wide is the signal you're planning to transmit spectrally? Is it
significantly less than 40MHz wide?
> When we increase the sampling rate to anything above 40Msps, the
> following discrepancy is seen in the data.
> If you look at the above image there seems to be some missing data.
I can only guess here, but is it possible UHD printed an "O" when you
tried to transmit this?
That would imply that your computer was too slow to supply the samples
in real time, and since the USRP did not have anything to transmit,
there is a "pause".
Best regards,
Marcus M?ller
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150422/a8fa7b93/attachment-0001.html>
------------------------------
Message: 19
Date: Wed, 22 Apr 2015 19:18:30 +0900
From: Luong Tan Phong <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] How to
Message-ID:
<CAA8YXsr=C_e6SSVQg=ky_ggkNpYKy8=ygykfamfd6udsucp...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi list,
I desire to use X310 as a base platform for my application so I must add
my HDL routine signal processing module after DDC module in two radio
modules. So that, the data rate output from two radios are not the same,
and I can't receive them on PC (because the data not align error).
Could you please point out a solution ( about fpga, host, firmware) for me?
I look forward to hearing from you.
With best regards,
LTP
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150422/0a075ebe/attachment-0001.html>
------------------------------
Message: 20
Date: Wed, 22 Apr 2015 19:20:23 +0900
From: Luong Tan Phong <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Solution to get data from 2 RX channels from
X310 with the difference sample rate?
Message-ID:
<caa8yxsowir6jeec+epmz+xlxn9nzfbubotyw2bksu5rc3qh...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi list,
I desire to use X310 as a base platform for my application so I must add
my HDL routine signal processing module after DDC module in two radio
modules. So that, the data rate output from two radios are not the same,
and I can't receive them on PC (because the data not align error).
Could you please point out a solution ( about fpga, host, firmware) for me?
I look forward to hearing from you.
With best regards,
LTP
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150422/3b7a691e/attachment-0001.html>
------------------------------
Message: 21
Date: Wed, 22 Apr 2015 19:27:05 +0900 (KST)
From: ??? <[email protected]>
To: [email protected]
Subject: [USRP-users] Measurement of throughput and delay during USRP
transmission
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Dear list
Hi, I need to measure the throughput and transmission delay between Tx and Rx
USRP.
How can I measure that values?
I want to other GRC references codes concerning throughput and delay.
Thanks
Jaehoon
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150422/bbe0e694/attachment-0001.html>
------------------------------
Message: 22
Date: Wed, 22 Apr 2015 12:28:23 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Solution to get data from 2 RX channels from
X310 with the difference sample rate?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi LTP,
have a look at what RF NoC can do; it's still beta, but maybe it enables
you to solve your problems!
Generally, you must use the same master clock rate on both
Daughterboards, but I don't think you must use the same sampling rate on
both channels on X300 -- but I'm not totally sure. Maybe someone else
could confirm, but since on the FPGA side, both radio units are rather
independent, you should be able to request one streamer with rate X for
your first channel, and one streamer with rate Y for your second channel.
I did not really understand the error you mentioned; is it something
that UHD says? Where? Would you please paste the whole error?
Best regards,
Marcus
On 04/22/2015 12:20 PM, Luong Tan Phong via USRP-users wrote:
> Hi list,
>
> I desire to use X310 as a base platform for my application so I must
> add my HDL routine signal processing module after DDC module in two
> radio modules. So that, the data rate output from two radios are not
> the same, and I can't receive them on PC (because the data not align
> error).
>
>
> Could you please point out a solution ( about fpga, host, firmware)
> for me?
>
> I look forward to hearing from you.
>
> With best regards,
>
> LTP
>
>
> _______________________________________________
> 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/20150422/98d7e148/attachment-0001.html>
------------------------------
Message: 23
Date: Wed, 22 Apr 2015 12:37:30 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Measurement of throughput and delay during
USRP transmission
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Dear Jaehoon,
the troughput doesn't need measuring -- it's simply the sampling rate
you set!
If your system can't keep up with that sampling rate, you will see "O"
and/or "U" errors.
Delay is a bit of a more complicated thing to measure, but what about this:
You make a loopback from TX to RX (include attenuator!);
you use a flow graph that simply looks like this
file_source(precomputed noise file, a few seconds long; repeat=false)
--> usrp_sink
usrp_source --> file_sink(measurement)
then you open the generated Python file and add (assuming your sink has
the name usrp_sink0, and your source usrp_source0; this might be
different for you!):
usrp_source0.set_time_now(uhd.time_spec(0))
timestamp = uhd.time_spec(2.0)
usrp_source0.set_start_time(timestamp)
usrp_sink0.set_start_time(timestamp)
before the line that contains tb.start().
Afterwards, you just correlate your measurement with your precomputed
noise file; the maximum correlation will mark your delay.
Notice that this value will depend on various factors -- sampling rate,
frequency, bandwidth... and you will need to measure this for all
configurations you want to have calibrated.
Best regards,
Marcus
On 04/22/2015 12:27 PM, ??? via USRP-users wrote:
>
> Dear list
>
>
>
>
>
> Hi, I need to measure the throughput and transmission delay between Tx
> and Rx USRP.
>
>
>
> How can I measure that values?
>
>
>
> I want to other GRC references codes concerning throughput and delay.
>
>
>
> Thanks
>
>
>
> Jaehoon
>
>
>
>
>
> _______________________________________________
> 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/20150422/356dbd04/attachment-0001.html>
------------------------------
Message: 24
Date: Wed, 22 Apr 2015 15:49:31 +0200
From: Marcus M?ller <[email protected]>
To: Taariqa Maharaj <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] x310 Master clock rate
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Taariqa,
oh, yes, sorry, "O" is for Overflow, i.e. when your computer doesn't
take samples fast enough from the receiving streamer of the USRP;
"U" is Underflow, which is the equivalent thing on TX, so yes, that's
probably why you are seeing "holes" in your transmission.
If you'd like to transmit a 50 MHz pulse, then you need to use at least
a 50MS/s sampling rate, which does solve the "odd decimation" warning,
but introduces a heavier computational load on your PC, so it makes the
"U" problem worse.
How do you connect your X310 to your computer, and how do you generate
your transmit signal?
Best regards,
Marcus
On 04/22/2015 03:45 PM, Taariqa Maharaj wrote:
> Hi Marcus
>
> We would Ideally like to transmit a 50Mhz (bandwidth) pulse.
>
> The UHD did not print out an "O". It did however print out "L" and
> "U", would this cause the same effect?
>
> Regards,
> Taariqa
>
> On Wed, Apr 22, 2015 at 11:44 AM, Marcus M?ller
> <[email protected] <mailto:[email protected]>> wrote:
>
> Hi!
>
> Thanks for following up on this.
>> With the master clock set at 200Mhz and a sampling rate of 40Msps
>> the following warning appears:
>>
>> UHD Warning:
>>
>> The requested interpolation is odd; the user should expect CIC
>> rolloff.
>>
>> Select an even interpolation to ensure that a halfband filter is
>> enabled.
>>
>> interpolation = dsp_rate/samp_rate -> 5 = (200.000000
>> MHz)/(40.000000 MHz)
>>
>>
>
> To explain the warning:
> The FPGA decimates the RX samples down, coming in at the master
> clock rate from the ADC, to the sampling rate you select.
> To do that without introducing aliasing, it has to low-pass filter
> them.
> The FPGA filter chain has multiple stages; if I remember
> correctly, the filters are in this order:
> 1. 1x CIC filter for odd factors in decimation
> 2. 3x 31-tap half band filters that each implement a good
> decimation for factors of 2 each.
>
> Now, if you use an odd decimation (200MHz/40MHz==5), there's no
> factor of 2 in your decimation, and hence you only use the
> "not-as-good" CIC filter, and are likely to see effects of filter
> roll-of at the edges of your band.
>
> In TX direction, it's quite the same problem:
> 1. 1x 17-tap half band interpolators
> 2. 1x 5-tap half band interpolators
> 3. 1x CIC
>
> Therefore: if your measurements show that your signal is OK for
> your application, just ignore the warning (it's just a warning,
> not an error); if you think this is bad for the signal you want to
> work with, I'd recommend using a 50MS/s sampling rate -- that
> would have a decimation of 4 and should work beautifully. Of
> course, this means that your host computer would have to implement
> the interpolation.
>
> How wide is the signal you're planning to transmit spectrally? Is
> it significantly less than 40MHz wide?
>
>> When we increase the sampling rate to anything above 40Msps, the
>> following discrepancy is seen in the data.
>> If you look at the above image there seems to be some missing data.
> I can only guess here, but is it possible UHD printed an "O" when
> you tried to transmit this?
> That would imply that your computer was too slow to supply the
> samples in real time, and since the USRP did not have anything to
> transmit, there is a "pause".
>
> Best regards,
> Marcus M?ller
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150422/68fe7cf2/attachment-0001.html>
------------------------------
Message: 25
Date: Wed, 22 Apr 2015 16:20:22 +0200
From: Marcus M?ller <[email protected]>
To: Taariqa Maharaj <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] x310 Master clock rate
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Taariqa,
"L" is for Late packet, i.e. you did something that had a command time,
but the command time was already in the past -- without knowing what
your transmission application does, I can't really say what effects that
has on transmission continuity. It does, however, either point to a lack
of performance in your PC, or a bug in your application, so it's not an
"OK" thing.
JSON sounds like a bad choice to transport 50 Million complex samples
per second, really.
Try writing the samples as short (int16) values to a raw file (e.g.
using matlab's fwrite() ) and try transmitting that with the UHD example
tx_samples_from_file
which should be installed.
You say you are connecting using Ethernet; are you referring to 10
Gigabit Ethernet?
Best regards,
Marcus M?ller
On 04/22/2015 04:15 PM, Taariqa Maharaj wrote:
> Hi Marcus
>
> Just to confirm the "L" would not cause the "holes" in the transmission?
>
> We are connecting the x310 via Ethernet to the PC. The baseband signal
> is generated in matlab and written to a json file. We read this file
> and feed it into the buffer and transmit.
>
> Regards,
> Taariqa
>
> On Wed, Apr 22, 2015 at 3:49 PM, Marcus M?ller
> <[email protected] <mailto:[email protected]>> wrote:
>
> Hi Taariqa,
>
> oh, yes, sorry, "O" is for Overflow, i.e. when your computer
> doesn't take samples fast enough from the receiving streamer of
> the USRP;
> "U" is Underflow, which is the equivalent thing on TX, so yes,
> that's probably why you are seeing "holes" in your transmission.
>
> If you'd like to transmit a 50 MHz pulse, then you need to use at
> least a 50MS/s sampling rate, which does solve the "odd
> decimation" warning, but introduces a heavier computational load
> on your PC, so it makes the "U" problem worse.
> How do you connect your X310 to your computer, and how do you
> generate your transmit signal?
>
> Best regards,
> Marcus
>
>
> On 04/22/2015 03:45 PM, Taariqa Maharaj wrote:
>> Hi Marcus
>>
>> We would Ideally like to transmit a 50Mhz (bandwidth) pulse.
>>
>> The UHD did not print out an "O". It did however print out "L"
>> and "U", would this cause the same effect?
>>
>> Regards,
>> Taariqa
>>
>> On Wed, Apr 22, 2015 at 11:44 AM, Marcus M?ller
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>> Hi!
>>
>> Thanks for following up on this.
>>> With the master clock set at 200Mhz and a sampling rate of
>>> 40Msps the following warning appears:
>>>
>>> UHD Warning:
>>>
>>> The requested interpolation is odd; the user should expect
>>> CIC rolloff.
>>>
>>> Select an even interpolation to ensure that a halfband
>>> filter is enabled.
>>>
>>> interpolation = dsp_rate/samp_rate -> 5 = (200.000000
>>> MHz)/(40.000000 MHz)
>>>
>>>
>>
>> To explain the warning:
>> The FPGA decimates the RX samples down, coming in at the
>> master clock rate from the ADC, to the sampling rate you select.
>> To do that without introducing aliasing, it has to low-pass
>> filter them.
>> The FPGA filter chain has multiple stages; if I remember
>> correctly, the filters are in this order:
>> 1. 1x CIC filter for odd factors in decimation
>> 2. 3x 31-tap half band filters that each implement a good
>> decimation for factors of 2 each.
>>
>> Now, if you use an odd decimation (200MHz/40MHz==5), there's
>> no factor of 2 in your decimation, and hence you only use the
>> "not-as-good" CIC filter, and are likely to see effects of
>> filter roll-of at the edges of your band.
>>
>> In TX direction, it's quite the same problem:
>> 1. 1x 17-tap half band interpolators
>> 2. 1x 5-tap half band interpolators
>> 3. 1x CIC
>>
>> Therefore: if your measurements show that your signal is OK
>> for your application, just ignore the warning (it's just a
>> warning, not an error); if you think this is bad for the
>> signal you want to work with, I'd recommend using a 50MS/s
>> sampling rate -- that would have a decimation of 4 and should
>> work beautifully. Of course, this means that your host
>> computer would have to implement the interpolation.
>>
>> How wide is the signal you're planning to transmit
>> spectrally? Is it significantly less than 40MHz wide?
>>
>>> When we increase the sampling rate to anything above 40Msps,
>>> the following discrepancy is seen in the data.
>>> If you look at the above image there seems to be some
>>> missing data.
>> I can only guess here, but is it possible UHD printed an "O"
>> when you tried to transmit this?
>> That would imply that your computer was too slow to supply
>> the samples in real time, and since the USRP did not have
>> anything to transmit, there is a "pause".
>>
>> Best regards,
>> Marcus M?ller
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150422/35f531db/attachment-0001.html>
------------------------------
Message: 26
Date: Wed, 22 Apr 2015 16:38:27 +0200
From: Marcus M?ller <[email protected]>
To: Taariqa Maharaj <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] x310 Master clock rate
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Excellent! You'll need that, because 50MS/s with 16 bit samples on both
I and Q mean that you end up with a bit rate of 1.6Gbit/s -- which
nicely illustrates why JSON might be a performance killer here:
When you save your samples in raw int16 on your permanent storage, it
"only" needs to provide you with 1.6Gbit/s; JSON stores numbers in
textual format.
Now, assuming the case where you save values as unsigned integers, each
integer in the 16 bit range will have 5 digits (on average 4.83,
actually if the values have a constant PDF, 5.16 if you're using signed
integers), plus one value-separating comma, so that's 6 digits; now,
assuming the standard case with 1B/character, this means a complex value
consisting of two integers needs 12B, or 96bit, which is three times
what your raw int16 storage would need; now, since you're actually
seeing small amounts of "U", I'd recommend doing optimizations like these.
The other aspect is that you need to parse JSON to get transmitable
samples, whereas raw storage just gives you the numbers you would hand
over to UHD directly as "bytes in memory", without any conversion,
parsing overhead.
Best regards,
Marcus
On 04/22/2015 04:24 PM, Taariqa Maharaj wrote:
>
> Hi
>
> Yes I am referring to the 10 Gigabit Ethernet.
>
> Regards,
> Taariqa
>
> On 22 Apr 2015 4:20 PM, "Marcus M?ller" <[email protected]
> <mailto:[email protected]>> wrote:
>
> Hi Taariqa,
>
> "L" is for Late packet, i.e. you did something that had a command
> time, but the command time was already in the past -- without
> knowing what your transmission application does, I can't really
> say what effects that has on transmission continuity. It does,
> however, either point to a lack of performance in your PC, or a
> bug in your application, so it's not an "OK" thing.
>
> JSON sounds like a bad choice to transport 50 Million complex
> samples per second, really.
> Try writing the samples as short (int16) values to a raw file
> (e.g. using matlab's fwrite() ) and try transmitting that with the
> UHD example
>
> tx_samples_from_file
>
> which should be installed.
>
> You say you are connecting using Ethernet; are you referring to 10
> Gigabit Ethernet?
>
> Best regards,
> Marcus M?ller
>
> On 04/22/2015 04:15 PM, Taariqa Maharaj wrote:
>> Hi Marcus
>>
>> Just to confirm the "L" would not cause the "holes" in the
>> transmission?
>>
>> We are connecting the x310 via Ethernet to the PC. The baseband
>> signal is generated in matlab and written to a json file. We read
>> this file and feed it into the buffer and transmit.
>>
>> Regards,
>> Taariqa
>>
>> On Wed, Apr 22, 2015 at 3:49 PM, Marcus M?ller
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>> Hi Taariqa,
>>
>> oh, yes, sorry, "O" is for Overflow, i.e. when your computer
>> doesn't take samples fast enough from the receiving streamer
>> of the USRP;
>> "U" is Underflow, which is the equivalent thing on TX, so
>> yes, that's probably why you are seeing "holes" in your
>> transmission.
>>
>> If you'd like to transmit a 50 MHz pulse, then you need to
>> use at least a 50MS/s sampling rate, which does solve the
>> "odd decimation" warning, but introduces a heavier
>> computational load on your PC, so it makes the "U" problem worse.
>> How do you connect your X310 to your computer, and how do you
>> generate your transmit signal?
>>
>> Best regards,
>> Marcus
>>
>>
>> On 04/22/2015 03:45 PM, Taariqa Maharaj wrote:
>>> Hi Marcus
>>>
>>> We would Ideally like to transmit a 50Mhz (bandwidth) pulse.
>>>
>>> The UHD did not print out an "O". It did however print out
>>> "L" and "U", would this cause the same effect?
>>>
>>> Regards,
>>> Taariqa
>>>
>>> On Wed, Apr 22, 2015 at 11:44 AM, Marcus M?ller
>>> <[email protected] <mailto:[email protected]>>
>>> wrote:
>>>
>>> Hi!
>>>
>>> Thanks for following up on this.
>>>> With the master clock set at 200Mhz and a sampling rate
>>>> of 40Msps the following warning appears:
>>>>
>>>> UHD Warning:
>>>>
>>>> The requested interpolation is odd; the user should
>>>> expect CIC rolloff.
>>>>
>>>> Select an even interpolation to ensure that a halfband
>>>> filter is enabled.
>>>>
>>>> interpolation = dsp_rate/samp_rate -> 5 = (200.000000
>>>> MHz)/(40.000000 MHz)
>>>>
>>>>
>>>
>>> To explain the warning:
>>> The FPGA decimates the RX samples down, coming in at the
>>> master clock rate from the ADC, to the sampling rate you
>>> select.
>>> To do that without introducing aliasing, it has to
>>> low-pass filter them.
>>> The FPGA filter chain has multiple stages; if I remember
>>> correctly, the filters are in this order:
>>> 1. 1x CIC filter for odd factors in decimation
>>> 2. 3x 31-tap half band filters that each implement a
>>> good decimation for factors of 2 each.
>>>
>>> Now, if you use an odd decimation (200MHz/40MHz==5),
>>> there's no factor of 2 in your decimation, and hence you
>>> only use the "not-as-good" CIC filter, and are likely to
>>> see effects of filter roll-of at the edges of your band.
>>>
>>> In TX direction, it's quite the same problem:
>>> 1. 1x 17-tap half band interpolators
>>> 2. 1x 5-tap half band interpolators
>>> 3. 1x CIC
>>>
>>> Therefore: if your measurements show that your signal is
>>> OK for your application, just ignore the warning (it's
>>> just a warning, not an error); if you think this is bad
>>> for the signal you want to work with, I'd recommend
>>> using a 50MS/s sampling rate -- that would have a
>>> decimation of 4 and should work beautifully. Of course,
>>> this means that your host computer would have to
>>> implement the interpolation.
>>>
>>> How wide is the signal you're planning to transmit
>>> spectrally? Is it significantly less than 40MHz wide?
>>>
>>>> When we increase the sampling rate to anything above
>>>> 40Msps, the following discrepancy is seen in the data.
>>>> If you look at the above image there seems to be some
>>>> missing data.
>>> I can only guess here, but is it possible UHD printed an
>>> "O" when you tried to transmit this?
>>> That would imply that your computer was too slow to
>>> supply the samples in real time, and since the USRP did
>>> not have anything to transmit, there is a "pause".
>>>
>>> Best regards,
>>> Marcus M?ller
>>>
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150422/5edb7a88/attachment-0001.html>
------------------------------
Message: 27
Date: Wed, 22 Apr 2015 10:39:49 -0400
From: "Marcus D. Leech" <[email protected]>
To: "Weaver, Tyler" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Errors 0x8 and 0xf when capturing with b210.
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 04/21/2015 01:41 PM, Weaver, Tyler wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Sample rates:
> I have tried various sample rates and the errors occur at > 8 MHz. For my
> application I need something > 20 MHz. Preferably I want to sample at 30.72
> MHz.
>
> Hardware:
> dell: i7-4800MQ, 16gb ram, radion 8790M, SSD hd.
> mac: i704980HQ, 16gb ram, nvidia gt 750M, SSD hd.
>
>
> Clock rate:
>
> I?ve tried 30.72 and 61.44 MHz. Neither have gotten rid of the errors.
>
>
What happens if you do something super-simple, like using
rx_samples_to_file, and specifying /dev/null for the output file, and
then try your
various sample rates. Leaving the master clock at the default
32MHz, I'd try 4, 8, and 16 msps.
If this is through a VM, then you can expect potentially-horrible USB
performance...
------------------------------
Message: 28
Date: Wed, 22 Apr 2015 08:48:08 -0700
From: Michael West <[email protected]>
To: Sanjoy Basak <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] time sync 2 ettus x310
Message-ID:
<CAM4xKro8BFiRKuk_SZSvoVJg4gCN6RPAO-UsggY-=mpzeyf...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Sanjoy,
I have attached the UHD patch that changes the ATR settings at the idle
state to always enable frontend components for SBX and CBX daughter
boards. Give it a try and let us know if it works for you.
Regards,
Michael
On Wed, Apr 22, 2015 at 2:36 AM, Sanjoy Basak <[email protected]>
wrote:
> Dear Mr. Michael,
> Thank you very much for the reply. I am putting all the information here
> regarding usrp.
>
> daughter board: SBX-120
> UHD version: UHD_003.008.002-80-ge28d7844
>
> I am attaching here a pdf which includes all other information of the
> usrp. Please send me the patch and other instruction and suggestion.
> Have a nice day.
>
> best regards
> Sanjoy
>
>
> On Wed, Apr 22, 2015 at 2:29 AM, Michael West <[email protected]>
> wrote:
>
>> Hi Sanjoy,
>>
>> The distortion may be due to the fact that some frontend components are
>> disabled or powered down while not transmitting or receiving and take a
>> little time to settle when enabled or powered up. For the X310, there are
>> 3 ways around this:
>>
>> 1) Start TX and RX earlier and throw away RX data (as you have done)
>> 2) Modify ATR settings dynamically so the frontend components stay
>> powered on and enabled. This can be done by using the
>> multi_usrp::set_gpio_attr() method. The banks are RX0, RX1, TX0, and TX1.
>> You can accomplish this by adding the following lines to your code:
>> usrp->set_gpio_attr("RX0", "ATR_0X", usrp->get_gpio_attr("RX0",
>> "ATR_XX", 0), ~0, 0);
>> usrp->set_gpio_attr("RX1", "ATR_0X", usrp->get_gpio_attr("RX1",
>> "ATR_XX", 0), ~0, 0);
>> usrp->set_gpio_attr("TX0", "ATR_0X", usrp->get_gpio_attr("TX0",
>> "ATR_XX", 0), ~0, 0);
>> usrp->set_gpio_attr("TX1", "ATR_0X", usrp->get_gpio_attr("TX1",
>> "ATR_XX", 0), ~0, 0);
>> usrp->set_gpio_attr("RX0", "ATR_0X", usrp->get_gpio_attr("RX0",
>> "ATR_XX", 1), ~0, 1);
>> usrp->set_gpio_attr("RX1", "ATR_0X", usrp->get_gpio_attr("RX1",
>> "ATR_XX", 1), ~0, 1);
>> usrp->set_gpio_attr("TX0", "ATR_0X", usrp->get_gpio_attr("TX0",
>> "ATR_XX", 1), ~0, 1);
>> usrp->set_gpio_attr("TX1", "ATR_0X", usrp->get_gpio_attr("TX1",
>> "ATR_XX", 1), ~0, 1);
>> *Note that changing the antenna or gain settings may overwrite these
>> values.
>> 3) Modify ATR settings in UHD code. This is done by editing the UHD
>> code for the specific daughter board to change the ATR settings.
>>
>> Option #3 is the one that has worked the best for most users. If you let
>> me know what daughter card and UHD version you are using, I may be able to
>> provide you with a UHD patch.
>>
>> Regards,
>> Michael
>>
>>
>>
>> On Tue, Apr 21, 2015 at 1:34 AM, Sanjoy Basak via USRP-users <
>> [email protected]> wrote:
>>
>>> Dear Mr. Martin,
>>> Thanks for the reply. Yes, right now I am not using octoclock, so the
>>> problem while using 2 USRPsis understandable.
>>>
>>> However, regarding distortion, yes I am having distortion at the
>>> beginning when I am using one usrp for SISO case for x310. I found this
>>> problem even in b210 as well. I wonder why no one discussed or how did they
>>> actually solved for radar uses. But I hope I would get my solution here.
>>>
>>>
>>> [image: Inline image 1]
>>> This is a figure of xcorr of rx and tx signal. The red marked distortion
>>> I am having almost always. I don't know the reason. If I drop few bins in
>>> my binary file and then start receiving my signal then I am getting an
>>> undistorted signal looks like the following.( I am transmitting and
>>> receiving using binary file).
>>> However, dropping bins is undesirable for radar application.
>>> [image: Inline image 3]
>>> If I use the distorted frame, as obvious I get distorted result.
>>> However, after dropping bins the fresh frame gives me the exact result
>>> after signal processing in matlab.
>>> Can you please tell me how to avoid this distortion at the beginning?
>>>
>>> best regards
>>> Sanjoy
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Apr 21, 2015 at 12:10 AM, Martin Braun via USRP-users <
>>> [email protected]> wrote:
>>>
>>>> Sanjoy,
>>>>
>>>> if you want to do radar, you need to make sure both devices are
>>>> connected to the same external reference. For radar, you can't run off
>>>> of separate clocks.
>>>>
>>>> We've confirmed timing accuracy across devices on the nanosecond scale
>>>> in the past (using OctoClocks for clock distribution).
>>>>
>>>> Cheers,
>>>> M
>>>>
>>>> On 17.04.2015 06:00, Sanjoy Basak via USRP-users wrote:
>>>> > Hi all,
>>>> > I am trying to sync 2 ettus x310 in time. However, I am always having
>>>> a
>>>> > distortion at the beginning after receiving, and there is always a
>>>> > delay of few microseconds between the tx and rx. I put tx in one x310
>>>> > and rx in another x310 and its in a wired connection. GPS antenna is
>>>> > connected to one usrp(with Tx) and another one is on external ref(Rx).
>>>> >
>>>> > So now if I check the last pps on both usrp; it shows tx:0; rx:2s;
>>>> > then I am compensating it making it set_start_time both at for 4s. So
>>>> > ideally I should get time synced tx and rx signal.
>>>> >
>>>> > But I am getting distortion in Rx signal for 2seconds at the
>>>> beginning;
>>>> > this is constant for every sampling freq; so if in that region I have
>>>> my
>>>> > rx signal I can't retrieve that as the distortion is already
>>>> introduced
>>>> > there.
>>>> > As I am trying to implement radar with x310, this is a serious problem
>>>> > for me. As within first 2 seconds and few microseconds I can't receive
>>>> > anything.
>>>> >
>>>> > I would really appreciate any kind of suggestion that come through. If
>>>> > anyone have question regarding setup or python code please ask.
>>>> > Thanks for reading.
>>>> >
>>>> > Best regards
>>>> > Sanjoy
>>>> >
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > USRP-users mailing list
>>>> > [email protected]
>>>> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>> >
>>>>
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected]
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150422/41326707/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: untitled.jpg
Type: image/jpeg
Size: 122891 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150422/41326707/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: untitled2.jpg
Type: image/jpeg
Size: 18723 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150422/41326707/attachment-0003.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sbx_cbx_atr.patch
Type: text/x-patch
Size: 1249 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150422/41326707/attachment-0001.patch>
------------------------------
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 56, Issue 22
******************************************
