[USRP-users] N210 Stops Transmitting

mleech at ripnet.com mleech at ripnet.com
Mon Oct 20 11:21:56 EDT 2014


 

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--
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141020/8313199c/attachment-0002.html>


More information about the USRP-users mailing list