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: FW: Inquiries on Ettus USRP E110 Hardware Driver
(Philip Balister)
2. UHD error, MTU size inside Ubuntu VM
(Lapointe, Benjamin - 1008 - MITLL)
3. Re: UHD error, MTU size inside Ubuntu VM (Marcus D. Leech)
4. Re: USRP B200 (Keith E Fleming)
5. Re: USRP B200 (Marcus D. Leech)
6. Re: USRP B200 (Marcus D. Leech)
7. Re: USRP B200 (Tom Tsou)
8. Re: USRP B200 (Marcus D. Leech)
9. Re: USRP B200 (Keith E. Fleming)
10. Re: UHD error, MTU size inside Ubuntu VM (Martin Braun)
11. USRP X300 errors on Windows/PCI (Mann, John P. - 1003 - MITLL)
----------------------------------------------------------------------
Message: 1
Date: Tue, 10 Jun 2014 09:48:49 -0700
From: Philip Balister <[email protected]>
To: "Marcus D. Leech" <[email protected]>, [email protected]
Subject: Re: [USRP-users] FW: Inquiries on Ettus USRP E110 Hardware
Driver
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 06/10/2014 08:50 AM, Marcus D. Leech via USRP-users wrote:
> On 06/10/2014 11:48 AM, Chun Mein Soon via USRP-users wrote:
>> Thx for the clarification!
>>
>> I already successful access the device via console through serial com.
>> After that, i follow the steps in this following link
>> http://code.ettus.com/redmine/ettus/projects/usrpe1xx/wiki/FAQ
>>
>> remove the old uhd driver then install the latest uhd driver built and
>> install. However, the example wont run as expected..
>>
>> the error code is
>> RuntimeError: Expected module compatibility number 0x4, but got 0x3..
>> May refer to screenshot as attached in this email..
>>
>> Many thanks
>>
> Do an:
>
> opkg update; opkg upgrade
>
> Then reboot
Also, you would need to update the fpga files.
UHD for the E100 hasn't changed since the version in the package feeds.
Do you need some newer features of UHD?
Philip
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 2
Date: Tue, 10 Jun 2014 20:49:25 +0000
From: "Lapointe, Benjamin - 1008 - MITLL" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] UHD error, MTU size inside Ubuntu VM
Message-ID:
<ba0ac330d0347f4b8d5a1e064a965464021...@lle2k10-mbx02.mitll.ad.local>
Content-Type: text/plain; charset="us-ascii"
Hi all,
I am getting a UHD Error (shown below) when I try to run uhd_usrp_probe with
my X310. I am using the 1GigE connection. I am using a Ubuntu 14.04 VM,
with Windows 7 as the host. Each time I get the error, I have to disable
enable the interface on the windows side in order to re-establish
connection.
I can ping the X310 and run uhd_find_devices without a problem.
On the Ubuntu side MTU size was set to automatic and then to 1500, neither
worked.
On the Windows side MTU size is set at 1500.
Any ideas? Is it a bad idea to run from inside a VM?
Thanks!
-Ben
$ ./uhd_usrp_probe
linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.007.001-0-unknown
-- X300 initialization sequence...
-- Determining maximum frame size...
UHD Error:
RuntimeError: System send MTU size is less than the minimum required by
the IP protocol.
Setup basic communication...
UHD Error:
x300 fw communication failure #1
EnvironmentError: IOError: x300 fw peek32 - reply timed out
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140610/6a190e02/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6662 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140610/6a190e02/attachment-0001.p7s>
------------------------------
Message: 3
Date: Tue, 10 Jun 2014 16:55:58 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] UHD error, MTU size inside Ubuntu VM
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 06/10/2014 04:49 PM, Lapointe, Benjamin - 1008 - MITLL via USRP-users
wrote:
>
> Hi all,
>
> I am getting a UHD Error (shown below) when I try to run
> uhd_usrp_probe with my X310. I am using the 1GigE connection. I am
> using a Ubuntu 14.04 VM, with Windows 7 as the host. Each time I get
> the error, I have to disable enable the interface on the windows side
> in order to re-establish connection.
>
> I can ping the X310 and run uhd_find_devices without a problem.
>
> On the Ubuntu side MTU size was set to automatic and then to 1500,
> neither worked.
>
> On the Windows side MTU size is set at 1500.
>
> Any ideas? Is it a bad idea to run from inside a VM?
>
> Thanks!
>
> -Ben
>
> $ ./uhd_usrp_probe
>
> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.007.001-0-unknown
>
> -- X300 initialization sequence...
>
> -- Determining maximum frame size...
>
> UHD Error:
>
> RuntimeError: System send MTU size is less than the minimum
> required by the IP protocol.
>
> Setup basic communication...
>
> UHD Error:
>
> x300 fw communication failure #1
>
> EnvironmentError: IOError: x300 fw peek32 - reply timed out
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
The X310 socket interface likes big MTUs. It's likely that your VM
doesn't emulate that.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140610/6b7d797a/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 10 Jun 2014 21:15:33 +0000 (UTC)
From: Keith E Fleming <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP B200
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Marcus D. Leech via USRP-users <usrp-users@...> writes:
>
>
> Are you running up-to-date UHD and matching firmware??? What OS??
> What controller?--
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
FWIW, I started having this exact same problem when running scan_mib in the
libLTE project. It looks for LTE cells. I am using a B200,
UHD_003.006.002-64-g92b0b7ab, Fedora 20, AMD quad-core.
I do believe it has something to do with rapid changes in frequency. I can
run OpenBTS for weeks with no problems at all....
------------------------------
Message: 5
Date: Tue, 10 Jun 2014 18:49:08 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP B200
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 06/10/2014 05:15 PM, Keith E Fleming via USRP-users wrote:
> Marcus D. Leech via USRP-users<usrp-users@...> writes:
>
>>
>> Are you running up-to-date UHD and matching firmware? What OS?
>> What controller?--
>> Marcus Leech
>> Principal Investigator
>> Shirleys Bay Radio Astronomy Consortium
>> http://www.sbrac.org
>
> FWIW, I started having this exact same problem when running scan_mib in the
> libLTE project. It looks for LTE cells. I am using a B200,
> UHD_003.006.002-64-g92b0b7ab, Fedora 20, AMD quad-core.
> I do believe it has something to do with rapid changes in frequency. I can
> run OpenBTS for weeks with no problems at all....
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
I recommend the latest UHD, rather than 3.6.2. Also, the B200 doesn't
change frequencies that rapidly--it's not a good platform (at the moment)
due to the way the AD9361 is tuned and re-calibrated on every tuning.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
------------------------------
Message: 6
Date: Tue, 10 Jun 2014 19:15:03 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP B200
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 06/10/2014 06:49 PM, Marcus D. Leech via USRP-users wrote:
> I recommend the latest UHD, rather than 3.6.2. Also, the B200
> doesn't change frequencies that rapidly--it's not a good platform (at
> the moment)
> due to the way the AD9361 is tuned and re-calibrated on every tuning.
>
>
>
Clarification. If you need rapid tuning, with the current UHD software
load, the AD9361 "stuff" tends to produce rather sluggish tuning times.
So if you have rapid-tuning in mind, you may have to wait, or dive
into the code yourself and remove a lot of the redundant calibration
steps that happen in the code.
Otherwise, it's a good platform for all applications that don't require
rapid tuning.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
------------------------------
Message: 7
Date: Tue, 10 Jun 2014 19:58:49 -0400
From: Tom Tsou <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP B200
Message-ID:
<CAATyM+boLTPRs=aQgR6fdFW=ags+5wog5qnw7re33n9esqy...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Tue, Jun 10, 2014 at 7:15 PM, Marcus D. Leech via USRP-users
<[email protected]> wrote:
> Clarification. If you need rapid tuning, with the current UHD software
> load, the AD9361 "stuff" tends to produce rather sluggish tuning times.
> So if you have rapid-tuning in mind, you may have to wait, or dive into
> the code yourself and remove a lot of the redundant calibration
> steps that happen in the code.
The other option, if the application allows for it, is to shift
frequencies at the DDC leaving the AD9361 untouched. Of course, this
will only work for a certain range of frequencies before the front end
needs to be retuned. But, on the B200, that range of frequencies can
be quite wide.
-TT
------------------------------
Message: 8
Date: Tue, 10 Jun 2014 20:06:10 -0400
From: "Marcus D. Leech" <[email protected]>
To: Tom Tsou <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP B200
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 06/10/2014 07:58 PM, Tom Tsou wrote:
> On Tue, Jun 10, 2014 at 7:15 PM, Marcus D. Leech via USRP-users
> <[email protected]> wrote:
>> Clarification. If you need rapid tuning, with the current UHD software
>> load, the AD9361 "stuff" tends to produce rather sluggish tuning times.
>> So if you have rapid-tuning in mind, you may have to wait, or dive into
>> the code yourself and remove a lot of the redundant calibration
>> steps that happen in the code.
> The other option, if the application allows for it, is to shift
> frequencies at the DDC leaving the AD9361 untouched. Of course, this
> will only work for a certain range of frequencies before the front end
> needs to be retuned. But, on the B200, that range of frequencies can
> be quite wide.
>
> -TT
>
Yes, that's always an option. It wouldn't be that hard to do some
just-in-time analog tuning pipelining, either. It's a mere matter, as
they say,
of programming.
But I also understand that at some point, the tuning latency on the B2xx
will get 'looked at'. The problem is the tech notes from ADI apparently
indicate that you have to do a lot of "stuff" every time you tune.
Whether that's "have to have to", or just "have to", isn't entirely clear.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
------------------------------
Message: 9
Date: Tue, 10 Jun 2014 19:05:26 -0700 (PDT)
From: "Keith E. Fleming" <[email protected]>
To: "Marcus D. Leech" <[email protected]>, Tom Tsou <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP B200
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Can the AD9361 chipset signal the host (through a callback function?) that the
tuning/calibration is successful and that it is ready to start sampling? Or
maybe the function call that causes the tuning could block until the hardware
says that it is ready?
On Tuesday, June 10, 2014 8:07 PM, Marcus D. Leech via USRP-users
<[email protected]> wrote:
On 06/10/2014 07:58 PM, Tom Tsou wrote:
> On Tue, Jun 10, 2014 at 7:15 PM, Marcus D. Leech via USRP-users
> <[email protected]>? wrote:
>> Clarification.? If you need rapid tuning, with the current UHD software
>> load, the AD9361 "stuff" tends to produce rather sluggish tuning times.
>>? ? So if you have rapid-tuning in mind, you may have to wait, or dive into
>> the code yourself and remove a lot of the redundant calibration
>>? ? steps that happen in the code.
> The other option, if the application allows for it, is to shift
> frequencies at the DDC leaving the AD9361 untouched. Of course, this
> will only work for a certain range of frequencies before the front end
> needs to be retuned. But, on the B200, that range of frequencies can
> be quite wide.
>
>? ? -TT
>
Yes, that's always an option.? It wouldn't be that hard to do some
just-in-time analog tuning pipelining, either.? It's a mere matter, as
they say,
? of programming.
But I also understand that at some point, the tuning latency on the B2xx
will get 'looked at'.? The problem is the tech notes from ADI apparently
? indicate that you have to do a lot of "stuff" every time you tune.?
Whether that's "have to have to", or just "have to", isn't entirely clear.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140610/5560e795/attachment-0001.html>
------------------------------
Message: 10
Date: Wed, 11 Jun 2014 16:09:05 +0200
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] UHD error, MTU size inside Ubuntu VM
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Benjamin,
this error gets thrown when the MTU drops below the minimum value
specified by the IP standard (something around 500 bytes). If your MTU
is actually 1500, this error will not show up.
Are there any switches between your device and and the VM? We have users
working in VMs, and it usually seems to work.
Martin
On 10.06.2014 22:49, Lapointe, Benjamin - 1008 - MITLL via USRP-users wrote:
> Hi all,
>
> I am getting a UHD Error (shown below) when I try to run uhd_usrp_probe
> with my X310. I am using the 1GigE connection. I am using a Ubuntu
> 14.04 VM, with Windows 7 as the host. Each time I get the error, I have
> to disable enable the interface on the windows side in order to
> re-establish connection.
>
> I can ping the X310 and run uhd_find_devices without a problem.
>
> On the Ubuntu side MTU size was set to automatic and then to 1500,
> neither worked.
>
> On the Windows side MTU size is set at 1500.
>
> Any ideas? Is it a bad idea to run from inside a VM?
>
> Thanks!
>
> -Ben
>
> $ ./uhd_usrp_probe
>
> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.007.001-0-unknown
>
> -- X300 initialization sequence...
>
> -- Determining maximum frame size...
>
> UHD Error:
>
> RuntimeError: System send MTU size is less than the minimum
> required by the IP protocol.
>
> Setup basic communication...
>
> UHD Error:
>
> x300 fw communication failure #1
>
> EnvironmentError: IOError: x300 fw peek32 - reply timed out
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 11
Date: Wed, 11 Jun 2014 15:57:16 +0000
From: "Mann, John P. - 1003 - MITLL" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] USRP X300 errors on Windows/PCI
Message-ID:
<d51b499176a305408baf4a778770d5c0014...@lle2k10-mbx01.mitll.ad.local>
Content-Type: text/plain; charset="us-ascii"
I am trying to get my new X300 to run on Windows 7 using the PCI interface.
It's not going so well, so I have some questions.
The first time I tried to run benchmark_rate, it complained about the
.lvbitx file, but it was looking for it in the wrong directory (Program
Files vs Program Files (x86)), so I copied the entire UHD directory from
"Program Files (x86)" over to the "Program Files" directory. That seemed to
get rid of that error, but then I got a ton of the following errors while it
was running the test:
Receiver error: ERROR_CODE_TIMEOUT
Unexpected error on recv, continuing...
Receiver error: ERROR_CODE_TIMEOUT
Unexpected error on recv, continuing...
Receiver error: ERROR_CODE_TIMEOUT
Unexpected error on recv, continuing...
Receiver error: ERROR_CODE_TIMEOUT
Unexpected error on recv, continuing...
Receiver error: ERROR_CODE_TIMEOUT
Unexpected error on recv, continuing...
Receiver error: ERROR_CODE_TIMEOUT
Unexpected error on recv, continuing...
Receiver error: ERROR_CODE_TIMEOUT
Unexpected error on recv, continuing...
Receiver error: ERROR_CODE_TIMEOUT
Unexpected error on recv, continuing...
Benchmark rate summary:
Num received samples: 3765048
Num dropped samples: 0
Num overflows detected: 0
Num transmitted samples: 0
Num sequence errors: 0
Num underflows detected: 0
Also - the rate I selected was 25 MHz, so I had expected to receive
250,000,000 samples (not 3765048).
On subsequent runs of the same command, it now bombs out earlier with the
following error:
C:\Program Files (x86)\UHD\lib\uhd\examples>benchmark_rate
--rx_rate=25000000
Win32; Microsoft Visual C++ version 10.0; Boost_105400;
UHD_003.007.001-20-unsta
ble
Creating the usrp device with: ...
-- X300 initialization sequence...
-- Connecting to niusrpriorpc at localhost:5444...
-- Using LVBITX bitfile C:\Program
Files\UHD\share\uhd\images\usrp_x300_fpga_HGS
.lvbitx...
-- Setup basic communication...
-- Loading values from EEPROM...
-- Setup RF frontend clocking...
-- Radio 1x clock:200
-- Detecting internal GPSDO.... Found an internal GPSDO
-- Initialize Radio control...
-- Performing register loopback test... Error: EnvironmentError: IOError:
Radio
ctrl (A) no response packet - AssertionError: bool(buff)
in unsigned __int64 __cdecl radio_ctrl_core_3000_impl::wait_for_ack(const
bool
)
at C:\unstable\src\uhd\host\lib\usrp\cores\radio_ctrl_core_3000.cpp:196
Any clues as to what I am doing wrong would be appreciated. Thanks!
John Mann
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140611/5191050f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6638 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140611/5191050f/attachment-0001.p7s>
------------------------------
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 46, Issue 11
******************************************
