[USRP-users] N210 Stops Transmitting

Liwei xieliwei+usrp at gmail.com
Sun Oct 19 12:50:18 EDT 2014


Hello Marcus, Marcus,
    Thanks for the reply. I'll get back to what the two of you have
asked me to check in the next email. At the moment, I managed to get
myself a mid-2010 MacBook Pro (running OS 10.10) from a friend. It
runs on a 2.66GHz i7-620M (Arrandale) processor with a BCM5701 gigabit
ethernet controller.

    ... and same thing. Receive works fine but transmit won't last
more than a few seconds.

    GNURadio and UHD were installed via MacPorts, and the USRP is
directly connected to the mac over ethernet (no switch or anything).
Attached is a transcript of me loading firmware, rebooting and trying
the uhd_siggen utility multiple times. In each case, transmission
stops as soon as a "U" appears. The uhd_siggen utility's configured to
generate a FM 440Hz tone at 144.300MHz. Even when I could hear the
tone on the receiver, there're a lot of pops due to discontinuities in
the transmitted signal (even during periods when no "S' were being
reported).

    Also attached is another flow graph that I have tried, along with
the result. As you can see, RX works fine, only TX stops.

    Nothing was running in the background while these tests were being
carried out. Activity monitor reports >95% CPU idle.

    Hopefully, this excludes the laptop/networking hardware from the
problem, since I assume somebody should have reported success running
on this specific MBP before.

    I'll get back to answering your questions. Tomorrow, I'll bring in
the spare N210 (with the exact configuration) and hopefully I can
narrow things further.

Thanks
Liwei


On 19 October 2014 00:23, Marcus D. Leech via USRP-users
<usrp-users at lists.ettus.com> wrote:
> 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<usrp-users at lists.ettus.com>
>>> 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<xieliwei+usrp at gmail.com>  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
>>>>> USRP-users at lists.ettus.com
>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> USRP-users at lists.ettus.com
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users at lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
MacBook-Pro:~ developer$ usrp_n2xx_simple_net_burner --addr 192.168.143.20

Mac OS; Clang version 6.0 (clang-600.0.54); Boost_105600; UHD_003.007.002-0-unknown


Searching for USRP N2XX with IP address 192.168.143.20.

Found n210_r4.


Searching for specified images.


Will burn the following images:

 * Firmware: /opt/local/share/uhd/images/usrp_n210_fw.bin

 * FPGA:     /opt/local/share/uhd/images/usrp_n210_r4_fpga.bin


Querying n210_r4 for flash information.

 * Flash size:  4194304

 * Sector size: 65536


Erasing FPGA image.

 * Successfully erased 1572864 bytes at 1572864.

Writing FPGA image (100%).

 * Successfully wrote 1311560 bytes.

Verifying FPGA image (100%).

 * Successful.


Erasing firmware image.

 * Successfully erased 31744 bytes at 3145728.

Writing firmware image (100%).

 * Successfully wrote 16383 bytes.

Verifying firmware image (100%).

 * Successful.


Image burning successful. Reset USRP (Y/n)? y

Resetting USRP.

MacBook-Pro:~ developer$ ping 192.168.143.20

PING 192.168.143.20 (192.168.143.20): 56 data bytes

Request timeout for icmp_seq 0

Request timeout for icmp_seq 1

Request timeout for icmp_seq 2

Request timeout for icmp_seq 3

Request timeout for icmp_seq 4

ping: sendto: No route to host

Request timeout for icmp_seq 5

ping: sendto: No route to host

Request timeout for icmp_seq 6

ping: sendto: No route to host

Request timeout for icmp_seq 7

ping: sendto: No route to host

Request timeout for icmp_seq 8

Request timeout for icmp_seq 9

64 bytes from 192.168.143.20: icmp_seq=10 ttl=32 time=1.926 ms

64 bytes from 192.168.143.20: icmp_seq=11 ttl=32 time=1.207 ms

64 bytes from 192.168.143.20: icmp_seq=12 ttl=32 time=1.245 ms

64 bytes from 192.168.143.20: icmp_seq=13 ttl=32 time=1.267 ms

64 bytes from 192.168.143.20: icmp_seq=14 ttl=32 time=1.265 ms

^C

--- 192.168.143.20 ping statistics ---

15 packets transmitted, 5 packets received, 66.7% packet loss

round-trip min/avg/max/stddev = 1.207/1.382/1.926/0.273 ms

MacBook-Pro:~ developer$ uhd_siggen -s 200000 -g 20 -f 144300000 -x 62500 -y 440 --sweep

Mac OS; Clang version 6.0 (clang-600.0.54); Boost_105600; UHD_003.007.002-0-unknown


-- Opening a USRP2/N-Series device...

-- Current recv frame size: 1472 bytes

-- Current send frame size: 1472 bytes

-- Detecting internal GPSDO.... No GPSDO found

-- not found

gr::log :WARN: gr uhd usrp sink0 - Sensor 'lo_locked' failed to lock within timeout on channel 0.

UHD Signal Generator

Version: 003.007.002-0-unknown


Using USRP configuration:

Motherboard: N210r4 [F37922]

Daughterboard: WBXv3 TX+GDB [F36389]

Subdev: A:0

Antenna: TX/RX

Using Volk machine: sse4_2_64_orc

Press Enter to quit: SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSU

MacBook-Pro:~ developer$ uhd_siggen -s 200000 -g 20 -f 144300000 -x 62500 -y 440 --sweep

Mac OS; Clang version 6.0 (clang-600.0.54); Boost_105600; UHD_003.007.002-0-unknown


-- Opening a USRP2/N-Series device...

-- Current recv frame size: 1472 bytes

-- Current send frame size: 1472 bytes

gr::log :WARN: gr uhd usrp sink0 - Sensor 'lo_locked' failed to lock within timeout on channel 0.

UHD Signal Generator

Version: 003.007.002-0-unknown


Using USRP configuration:

Motherboard: N210r4 [F37922]

Daughterboard: WBXv3 TX+GDB [F36389]

Subdev: A:0

Antenna: TX/RX

Using Volk machine: sse4_2_64_orc

Press Enter to quit: SSU

MacBook-Pro:~ developer$ uhd_siggen -s 200000 -g 20 -f 144300000 -x 62500 -y 440 --sweep

Mac OS; Clang version 6.0 (clang-600.0.54); Boost_105600; UHD_003.007.002-0-unknown


-- Opening a USRP2/N-Series device...

-- Current recv frame size: 1472 bytes

-- Current send frame size: 1472 bytes

gr::log :WARN: gr uhd usrp sink0 - Sensor 'lo_locked' failed to lock within timeout on channel 0.

UHD Signal Generator

Version: 003.007.002-0-unknown


Using USRP configuration:

Motherboard: N210r4 [F37922]

Daughterboard: WBXv3 TX+GDB [F36389]

Subdev: A:0

Antenna: TX/RX

Using Volk machine: sse4_2_64_orc

Press Enter to quit: SSU

-------------- next part --------------
A non-text attachment was scrubbed...
Name: top_block.py
Type: text/x-python-script
Size: 5579 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141020/c88c15c9/attachment.py>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2014-10-20 at 12.39.12 am.png
Type: image/png
Size: 226460 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141020/c88c15c9/attachment.png>


More information about the USRP-users mailing list