[USRP-users] N210 Stops Transmitting

Marcus D. Leech mleech at ripnet.com
Tue Oct 21 08:52:45 EDT 2014


On 10/21/2014 07:29 AM, Liwei wrote:
> Hi Marcus,
>      Not multiple N210s. I've just tried out the spare N210, and it is
> working fine for both TX and RX. I think this possibly narrows it down
> to a hardware issue with the N210. Any way to figure out what is
> wrong?
>
> Thanks
> Liwei
You've tried different ethernet cables?

Otherwise, send a note to support at ettus.com

>
> On 20 October 2014 23:21,  <mleech at ripnet.com> wrote:
>> This issue survives multiple computers, and multiple N210s?
>>
>>
>>
>> Again, make sure that Network Manager isn't "owning" the device and turning
>> it off due to failed DHCP.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On 2014-10-20 10:24, Liwei wrote:
>>
>> Hi all,
>>      Sigh, should have known I'm not lucky enough to have this go away.
>> Couldn't get transmit to work without stopping when I checked in
>> today. Did the same things I did yesterday to try to replicate the
>> result, but no go.
>>      So here's the information requested.
>>      Unfortunately, I can't get tx_waveforms running long enough to see
>> it do anything on top, even with delay set to 0.5s. id hovers above
>> 95% and us hovers below 4% or so:
>>          %Cpu(s):  1.0 us,  0.5 sy,  0.0 ni, 98.5 id,  0.0 wa,  0.0 hi,
>>   0.0 si,  0.0 st
>>      tx_waveforms seems to be doing nothing once transmission stops:
>>          PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM
>> TIME+ COMMAND
>>          4554 xieliwei -51   0  173568  11876  10756 S   0.0  0.1
>> 0:00.09 tx_waveforms
>>      Here's how running tx_waveforms look like, the "S" appears
>> instantly and nothing gets transmitted:
>> $ /usr/lib/uhd/examples/tx_waveforms --rate 200000 --freq 144300000
>> --gain 20 --wave-type CONST
>> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.000-6-gbde8e9a3
>>
>>
>> Creating the usrp device with: ...
>> -- Opening a USRP2/N-Series device...
>> -- Current recv frame size: 1472 bytes
>> -- Current send frame size: 1472 bytes
>> Using Device: Single USRP:
>>    Device: USRP2 / N-Series Device
>>    Mboard 0: N210r4
>>    RX Channel: 0
>>      RX DSP: 0
>>      RX Dboard: A
>>      RX Subdev: WBXv3 RX+GDB
>>    TX Channel: 0
>>      TX DSP: 0
>>      TX Dboard: A
>>      TX Subdev: WBXv3 TX+GDB
>>
>> Setting TX Rate: 0.200000 Msps...
>> Actual TX Rate: 0.200000 Msps...
>>
>> Setting TX Freq: 144.300000 MHz...
>> -- Tune Request: 144.300000 MHz
>> --   The RF LO does not support the requested frequency:
>> --     Requested LO Frequency: 144.300000 MHz
>> --     RF LO Result: 144.299451 MHz
>> --   Attempted to use the DSP to reach the requested frequency:
>> --     Desired DSP Frequency: 0.000549 MHz
>> --     DSP Result: 0.000549 MHz
>> --   Successfully tuned to 144.300000 MHz
>> --
>> Actual TX Freq: 144.300000 MHz...
>>
>> Setting TX Gain: 20.000000 dB...
>> Actual TX Gain: 20.000000 dB...
>>
>> Setting device timestamp to 0...
>> Checking TX: LO: locked ...
>> Press Ctrl + C to stop streaming...
>> S
>>
>>
>>      As for NetworkManager being the cause, I have it set to manual
>> configuration, no go. It won't explain how receive works fine while
>> transmit stops too, and the problem is the same on OS X on an entirely
>> different laptop. Nothing in the system logs too.
>>
>>      I'm starting to suspect that the N210 I have is faulty.
>>
>> Thanks
>> Liwei
>>
>>
>> On 20 October 2014 02:17, Liwei <xieliwei+usrp at gmail.com> wrote:
>>
>> Hi all, My mind is officially blown now. Everything suddenly works. After
>> returning the MacBook to my friend, I started collecting the data Marcus
>> asked for. The first thing I did was to load new firmware with
>> usrp_n2xx_simple_net_burner (since the UHD version on my laptop is newer
>> than the one from macports on the MBP). Next I tried to run the tx_waveforms
>> test as suggested. I was expecting the same result since tx_waveforms should
>> behave similar to uhd_siggen. To my surprise, it actually worked without
>> issue. So I went back to uhd_siggen thinking maybe the problem lies with
>> gnuradio. Again, I was surprised when it actually worked fine. Then I tried
>> the test flow graph, then the flow graph I was working on, on fast ethernet,
>> on the USB3 gigabit ethernet adapter, and even Wi-Fi. Now I have uhd_siggen
>> running at 2.5Msps over Wi-Fi for the past 15 minutes without issue. 3 weeks
>> recompiling different UHD/GNURadio versions, power cycling, firmware
>> updating, swapping network devices around, network capturing, and things
>> suddenly start working without clear explanation. So there are a few things
>> that could have solved the problem: 1. Switching to the older
>> firmware/UHD/gnuradio version from the MBP 2. Switching back to the new
>> firmware/UHD/gnuradio version from my laptop 3. Running tx_waveforms (does
>> it do anything especially different from uhd_siggen?) 4. Sentience, I did
>> hint in my previous email of replacing this USRP unit with the spare ;) To
>> be sure, I just power cycled the N210 and rebooted my laptop. Still works.
>> Hopefully this holds up and what I've provided so far is of use in figuring
>> out what exactly was happening. Thanks Liwei On 20 October 2014 00:55, Liwei
>> <xieliwei+usrp at gmail.com> wrote:
>>
>> Whoops, attached the generated python instead of the flow graph. See
>> attached. On 20 October 2014 00:50, Liwei <xieliwei+usrp at gmail.com> wrote:
>>
>> 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.
>>
>> --Snip--





More information about the USRP-users mailing list