<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN">
<html><body style='font-size: 10pt; font-family: Verdana,Geneva,sans-serif'>
<p>This issue survives multiple computers, and multiple N210s?</p>
<p>Again, make sure that Network Manager isn't "owning" the device and turning it off due to failed DHCP.</p>
<p>On 2014-10-20 10:24, Liwei wrote:</p>
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px"><!-- html ignored --><!-- head ignored --><!-- meta ignored -->
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
4554 xieliwei -51 0 173568 11876 10756 S 0.0 0.1
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...
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.
On 20 October 2014 02:17, Liwei <<a href="mailto:email@example.com">firstname.lastname@example.org</a>> wrote:</pre>
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px">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 <<a href="mailto:email@example.com">firstname.lastname@example.org</a>> wrote:
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px">Whoops, attached the generated python instead of the flow graph. See attached. On 20 October 2014 00:50, Liwei <<a href="mailto:email@example.com">firstname.lastname@example.org</a>> wrote:
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px">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.</blockquote>