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: N210 Stops Transmitting (Marcus D. Leech)
2. Re: N210 Stops Transmitting (Ralph A. Schmid, dk5ras)
3. My b210 uhd crashes... (Ralph A. Schmid, dk5ras)
----------------------------------------------------------------------
Message: 1
Date: Sat, 18 Oct 2014 12:23:17 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] N210 Stops Transmitting
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 10/18/2014 10:25 AM, Marcus M?ller via USRP-users wrote:
> The Realtek controller should work, and I don't know about the USB3
> adapter, so I'd blame your managed switch, but you said that you already
> tried without it...
> Using anything but Gigabit ethernet really won't help. And as the USRP
> *needs* Gigabit ethernet (it's not fast-ethernet compatible itself), you
> won't be able to directly connect your USRP to a fast ethernet
> controller. But since I haven't seen any laptop that has USB3 but only
> fast ethernet
> So, even at your rather low sampling rates, would you mind having a look
> at the output of "top", especially at the %CPU line?
> How much time does, while transmitting, your system spend in idle
> ("id"), how much in userland ("us")?
> The fact that GQRX works rather smoothly (ok, only up to 10MS/s, but
> that's quite an ok number considering we're doing FFTs and render the
> results in real time) but transmitting a few kS/s doesn't really is a
> mystery to me. Are you sure that not, for some reason, Ubuntu decides to
> reconfigure the network interface in the midst of operation? Do you
> really only have a signal source and a USRP sink in your flow graph?
> Does the tx_waveforms example that we ship with UHD work, e.g.:
> /usr/local/lib/uhd/examples/uhd_tx_waveforms --rate 250000 --freq
> <carrier freq>
>
> Greetings,
> Marcus
I would check to make absolutely certain that NetworkManager isn't
reasserting its control over the ethernet device, and shutting it down when
DHCP fails.
Also, check dmesg to see if there are any unusual error messages
involving your ethernet interface.
> On 18.10.2014 14:43, Liwei wrote:
>> Hi Marcus,
>> Thanks for the reply. I guess it is likely that the network
>> interfaces I've tried are buggy. Here's what you've asked for:
>> 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
>> RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 07)
>> I've also tried one of those new USB3 ethernet adapters (seeing
>> that the laptop only has fast ethernet):
>> Bus 004 Device 013: ID 0b95:1790 ASIX Electronics Corp.
>> And out of desperation, Wi-Fi:
>> 02:00.0 Network controller: Qualcomm Atheros AR9485 Wireless
>> Network Adapter (rev 01)
>> I'm going to try a different linux distribution today.
>>
>> Regards,
>> Liwei
>>
>> On 18 October 2014 19:49, Marcus M?ller<[email protected]> wrote:
>>> Hi Liwei,
>>> "SU" is bad, because
>>> "U" stands for underflow, which means the USRP hasn't gotten enough
>>> samples in time and ran out of things to transmit.
>>> The "S" represents a sequence error, which can only happen if for some
>>> reason network packets got lost or reordered.
>>> I haven't seen these errors very often, and in the few cases, it was due
>>> to either a heavily underpowered PC, being so busy with signal
>>> processing that the kernel just had to drop network packets, or due to a
>>> horribly buggy network card, but you seem to achieve reasonable
>>> throughput, so I'm a bit out of ideas here. Nevertheless, could you
>>> share what
>>> "lscpi|grep -i ethernet"
>>> tells you?
>>>
>>> Greetings,
>>> Marcus
>>>
>>>
>>> On 18.10.2014 12:06, Liwei via USRP-users wrote:
>>>> Hello list,
>>>> Anyone with any suggestions? I understand that a "U" in the debug
>>>> output indicates an underflow, but am not sure why that should cause
>>>> gnuradio to stop sending samples.
>>>>
>>>> Thanks
>>>>
>>>> On 9 October 2014 01:10, Liwei<[email protected]> wrote:
>>>>> Hello list,
>>>>> This may have been asked before (I vaguely remember seeing an
>>>>> email with a similar issue some time back), but what causes UHD to
>>>>> stop sending transmission packets to an N210?
>>>>> With a simple flowgraph [signal source] -> [uhd sink] at 200k
>>>>> sample rate over gigabit ethernet, I get up to about 3 seconds of
>>>>> transmission before everything suddenly goes silent.
>>>>> Here's what I see logged:
>>>>>
>>>>> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.007.002-107-g0ca4b4f8
>>>>>
>>>>> -- Opening a USRP2/N-Series device...
>>>>> -- Current recv frame size: 1472 bytes
>>>>> -- Current send frame size: 1472 bytes
>>>>> SU
>>>>>
>>>>> Nothing else after "SU".
>>>>>
>>>>> Interestingly, if I add a receive + fft chain in the same
>>>>> flowgraph, the receive stream works fine even after the transmission
>>>>> has stopped. In fact, if I loop the TX and RX ports on the N210
>>>>> together (with an attenuator in between) I can see, in the received
>>>>> signal fft, the frequency peak for the few seconds the N210 is able to
>>>>> transmit.
>>>>>
>>>>> Gqrx also works well receiving FM radio stations all the way up to
>>>>> about 10MHz sampling rate, after which samples start to get dropped.
>>>>>
>>>>> I'm running on a fresh install of Ubuntu 14.04, with everything
>>>>> installed using pyBOMBS. I've tried switching to yesterday's 3.7.3
>>>>> maint branch but no difference. Firmware and FPGA image were updated
>>>>> after each version switch.
>>>>>
>>>>> Attached is a screenshot in Wireshark showing the sudden
>>>>> transmission stop. Note that only packets originating from the
>>>>> computer is shown.
>>>>>
>>>>> Also attached is the output from uhd_usrp_probe.
>>>>>
>>>>> $ uname -a
>>>>> Linux Ubuntu 3.15.0-031500rc2-generic #201404201435 SMP Sun Apr 20
>>>>> 18:36:18 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
>>>>>
>>>>> It may be due to a buggy ethernet adapter, but I've achieved over
>>>>> 900MBits/s for both TX and RX over iperf. I've also tried another Fast
>>>>> (instead of gigabit) ethernet adapter and even Wi-Fi, but no
>>>>> difference. There is currently a Dell managed switch in-between the
>>>>> computer and N210, but I've tried directly connecting both together
>>>>> with no difference in results either.
>>>>>
>>>>> Also, the current setup works flawlessly with a B210 which I have on
>>>>> hand.
>>>>>
>>>>> At this point, any hint would be great!
>>>>>
>>>>> Thanks
>>>>> Liwei
>>>> _______________________________________________
>>>> 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
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
------------------------------
Message: 2
Date: Sun, 19 Oct 2014 13:37:38 +0200
From: "Ralph A. Schmid, dk5ras" <[email protected]>
To: 'Marcus M?ller' <[email protected]>, "'Liwei'"
<[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] N210 Stops Transmitting
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Just as a side note, more and more tablet PCs and ultra slim notebnook come
without any Ethernet interface, and the Ethernet surrogate often enough is
something like a flimsy USB adapter with 100 or (if lucky) 1000 Mbps, not to
mention the Ethernet jack in the power supply - that is fed via WLAN from the
notebook :( They really sell crap for its weight in gold sometimes.
Bad times for those who want lightweight travel systems.
At least my new MS Surface 3 pro has a docking station with a Gbit interface
that seems to be a real one.
Ralph.
-----Original Message-----
From: USRP-users [mailto:[email protected]] On Behalf Of
Marcus M?ller via USRP-users
Sent: Saturday, October 18, 2014 4:25 PM
To: Liwei
Cc: [email protected]
Subject: Re: [USRP-users] N210 Stops Transmitting
The Realtek controller should work, and I don't know about the USB3 adapter, so
I'd blame your managed switch, but you said that you already tried without it...
Using anything but Gigabit ethernet really won't help. And as the USRP
*needs* Gigabit ethernet (it's not fast-ethernet compatible itself), you won't
be able to directly connect your USRP to a fast ethernet controller. But since
I haven't seen any laptop that has USB3 but only fast ethernet So, even at your
rather low sampling rates, would you mind having a look at the output of "top",
especially at the %CPU line?
How much time does, while transmitting, your system spend in idle ("id"), how
much in userland ("us")?
The fact that GQRX works rather smoothly (ok, only up to 10MS/s, but that's
quite an ok number considering we're doing FFTs and render the results in real
time) but transmitting a few kS/s doesn't really is a mystery to me. Are you
sure that not, for some reason, Ubuntu decides to reconfigure the network
interface in the midst of operation? Do you really only have a signal source
and a USRP sink in your flow graph?
Does the tx_waveforms example that we ship with UHD work, e.g.:
/usr/local/lib/uhd/examples/uhd_tx_waveforms --rate 250000 --freq <carrier freq>
Greetings,
Marcus
On 18.10.2014 14:43, Liwei wrote:
> Hi Marcus,
> Thanks for the reply. I guess it is likely that the network
> interfaces I've tried are buggy. Here's what you've asked for:
> 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 07)
> I've also tried one of those new USB3 ethernet adapters (seeing
> that the laptop only has fast ethernet):
> Bus 004 Device 013: ID 0b95:1790 ASIX Electronics Corp.
> And out of desperation, Wi-Fi:
> 02:00.0 Network controller: Qualcomm Atheros AR9485 Wireless
> Network Adapter (rev 01)
> I'm going to try a different linux distribution today.
>
> Regards,
> Liwei
>
> On 18 October 2014 19:49, Marcus M?ller <[email protected]> wrote:
>> Hi Liwei,
>> "SU" is bad, because
>> "U" stands for underflow, which means the USRP hasn't gotten enough
>> samples in time and ran out of things to transmit.
>> The "S" represents a sequence error, which can only happen if for
>> some reason network packets got lost or reordered.
>> I haven't seen these errors very often, and in the few cases, it was
>> due to either a heavily underpowered PC, being so busy with signal
>> processing that the kernel just had to drop network packets, or due
>> to a horribly buggy network card, but you seem to achieve reasonable
>> throughput, so I'm a bit out of ideas here. Nevertheless, could you
>> share what "lscpi|grep -i ethernet"
>> tells you?
>>
>> Greetings,
>> Marcus
>>
>>
>> On 18.10.2014 12:06, Liwei via USRP-users wrote:
>>> Hello list,
>>> Anyone with any suggestions? I understand that a "U" in the
>>> debug output indicates an underflow, but am not sure why that should
>>> cause gnuradio to stop sending samples.
>>>
>>> Thanks
>>>
>>> On 9 October 2014 01:10, Liwei <[email protected]> wrote:
>>>> Hello list,
>>>> This may have been asked before (I vaguely remember seeing an
>>>> email with a similar issue some time back), but what causes UHD to
>>>> stop sending transmission packets to an N210?
>>>> With a simple flowgraph [signal source] -> [uhd sink] at 200k
>>>> sample rate over gigabit ethernet, I get up to about 3 seconds of
>>>> transmission before everything suddenly goes silent.
>>>> Here's what I see logged:
>>>>
>>>> linux; GNU C++ version 4.8.2; Boost_105400;
>>>> UHD_003.007.002-107-g0ca4b4f8
>>>>
>>>> -- Opening a USRP2/N-Series device...
>>>> -- Current recv frame size: 1472 bytes
>>>> -- Current send frame size: 1472 bytes SU
>>>>
>>>> Nothing else after "SU".
>>>>
>>>> Interestingly, if I add a receive + fft chain in the same
>>>> flowgraph, the receive stream works fine even after the
>>>> transmission has stopped. In fact, if I loop the TX and RX ports on
>>>> the N210 together (with an attenuator in between) I can see, in the
>>>> received signal fft, the frequency peak for the few seconds the
>>>> N210 is able to transmit.
>>>>
>>>> Gqrx also works well receiving FM radio stations all the way up
>>>> to about 10MHz sampling rate, after which samples start to get dropped.
>>>>
>>>> I'm running on a fresh install of Ubuntu 14.04, with everything
>>>> installed using pyBOMBS. I've tried switching to yesterday's 3.7.3
>>>> maint branch but no difference. Firmware and FPGA image were
>>>> updated after each version switch.
>>>>
>>>> Attached is a screenshot in Wireshark showing the sudden
>>>> transmission stop. Note that only packets originating from the
>>>> computer is shown.
>>>>
>>>> Also attached is the output from uhd_usrp_probe.
>>>>
>>>> $ uname -a
>>>> Linux Ubuntu 3.15.0-031500rc2-generic #201404201435 SMP Sun Apr 20
>>>> 18:36:18 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
>>>>
>>>> It may be due to a buggy ethernet adapter, but I've achieved
>>>> over 900MBits/s for both TX and RX over iperf. I've also tried
>>>> another Fast (instead of gigabit) ethernet adapter and even Wi-Fi,
>>>> but no difference. There is currently a Dell managed switch
>>>> in-between the computer and N210, but I've tried directly
>>>> connecting both together with no difference in results either.
>>>>
>>>> Also, the current setup works flawlessly with a B210 which I have on
>>>> hand.
>>>>
>>>> At this point, any hint would be great!
>>>>
>>>> Thanks
>>>> Liwei
>>> _______________________________________________
>>> 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 --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141019/441c6619/attachment-0001.sig>
------------------------------
Message: 3
Date: Sun, 19 Oct 2014 16:09:10 +0200
From: "Ralph A. Schmid, dk5ras" <[email protected]>
To: <[email protected]>
Subject: [USRP-users] My b210 uhd crashes...
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
I played around a bit with UHD, and I found that I can crash it quite fast
when sampling rate is at 16M or more.
Here the output of a uhd_fft session while changing frequencies and
increasing sample rate:
as@ubuntu:~/uhd/host/tests$ uhd_fft
linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.000-6-gbde8e9a3
-- Operating over USB 3.
-- Initialize CODEC control...
-- Initialize Radio control...
-- Performing register loopback test... pass
-- Performing register loopback test... pass
-- Performing CODEC loopback test... pass
-- Performing CODEC loopback test... pass
-- Asking for clock rate 32.000000 MHz
-- Actually got clock rate 32.000000 MHz
-- Performing timer loopback test... pass
-- Performing timer loopback test... pass
Using Volk machine: avx_32_mmx_orc
-- Tune Request: 3025.000000 MHz
-- The RF LO does not support the requested frequency:
-- Requested LO Frequency: 3025.000000 MHz
-- RF LO Result: 3024.999997 MHz
-- Attempted to use the DSP to reach the requested frequency:
-- Desired DSP Frequency: -0.000003 MHz
-- DSP Result: -0.000003 MHz
-- Successfully tuned to 3025.000000 MHz
--
UHD Warning:
Tune Request: 0.000002 MHz
The requested RX frequency is outside of the system range, and has
been clipped:
Target Frequency: 0.000002 MHz
Clipped Target Frequency: 34.000000 MHz
The RF LO does not support the requested frequency:
Requested LO Frequency: 34.000000 MHz
RF LO Result: 50.000000 MHz
Attempted to use the DSP to reach the requested frequency:
Desired DSP Frequency: 16.000000 MHz
DSP Result: 16.000000 MHz
Successfully tuned to 34.000000 MHz
-- Successfully tuned to 1820.000000 MHz
--
OOOOOOOOOO
UHD Error:
The receive packet handler caught an exception.
ValueError: bad vrt header or invalid packet length
UHD source block got error code 0xf
DOOOOOOOOOOOOOOOOOOOO-- Tune Request: 945.000000 MHz
-- The RF LO does not support the requested frequency:
-- Requested LO Frequency: 945.000000 MHz
-- RF LO Result: 944.999999 MHz
-- Attempted to use the DSP to reach the requested frequency:
-- Desired DSP Frequency: -0.000001 MHz
-- DSP Result: -0.000001 MHz
-- Successfully tuned to 945.000000 MHz
--
OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
UHD Error:
The receive packet handler caught an exception.
ValueError: bad vrt header or invalid packet length
UHD source block got error code 0xf
DOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
OOOOOOOOOOOOOOO
UHD Error:
The receive packet handler caught an exception.
ValueError: bad vrt header or invalid packet length
UHD source block got error code 0xf
D
Stuff crashes that badly that even commands like lsusb do not work any more
L
Any ideas?
Ralph.
--
Ralph A. Schmid
Mondstr. 10
90762 F?rth
+49-171-3631223
<mailto:[email protected]> [email protected]
<http://www.bclog.de/> http://www.bclog.de/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141019/f334ab26/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141019/f334ab26/attachment-0001.sig>
------------------------------
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 50, Issue 18
******************************************
