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 (Liwei)
2. Re: N210 Stops Transmitting (Liwei)
3. Re: N210 Stops Transmitting (Liwei)
4. Mac OS X 10.10 Advice (Michael Dickens)
5. Re: Isolating the grounds of LFTX and LFRX in N200
(khalid.el-darymli)
6. Re: Isolating the grounds of LFTX and LFRX in N200
(Ralph A. Schmid, dk5ras)
7. Re: N210 Stops Transmitting (Liwei)
8. Re: N210 Stops Transmitting ([email protected])
----------------------------------------------------------------------
Message: 1
Date: Mon, 20 Oct 2014 00:50:18 +0800
From: Liwei <[email protected]>
To: "Marcus D. Leech" <[email protected]>, Marcus M?ller
<[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] N210 Stops Transmitting
Message-ID:
<cape0syyquawhf5fxkx2rar44hwv57pcejujypa4zny59vqf...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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
<[email protected]> 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<[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
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> 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:
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSU
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: 5578 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141020/c88c15c9/attachment-0001.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-0001.png>
------------------------------
Message: 2
Date: Mon, 20 Oct 2014 00:55:49 +0800
From: Liwei <[email protected]>
To: "Marcus D. Leech" <[email protected]>, Marcus M?ller
<[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] N210 Stops Transmitting
Message-ID:
<cape0syxea-xwj9qp_cgr_vkoue8zgvopaqrpa8e6ozncze8...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Whoops, attached the generated python instead of the flow graph. See attached.
On 20 October 2014 00:50, Liwei <[email protected]> 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 --------------
A non-text attachment was scrubbed...
Name: looptest.grc
Type: application/octet-stream
Size: 21139 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141020/61b444a5/attachment-0001.grc>
------------------------------
Message: 3
Date: Mon, 20 Oct 2014 02:17:18 +0800
From: Liwei <[email protected]>
To: "Marcus D. Leech" <[email protected]>, Marcus M?ller
<[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] N210 Stops Transmitting
Message-ID:
<CAPE0SYxYrLM=Y=zE2X6cm954m_nsgf2a=szne+se36gfkxp...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
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 <[email protected]> wrote:
> Whoops, attached the generated python instead of the flow graph. See attached.
>
> On 20 October 2014 00:50, Liwei <[email protected]> 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--
------------------------------
Message: 4
Date: Sun, 19 Oct 2014 21:56:28 -0400
From: Michael Dickens <[email protected]>
To: GNU Radio Users Discussion Group <[email protected]>, USRP
Users DIscussion Group <[email protected]>
Subject: [USRP-users] Mac OS X 10.10 Advice
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
GNU Radio and UHD seem to generally work well with the recently released Mac OS
X 10.10. In my testing, everything in UHD works. And, everything in GNU Radio
works -except- for executing flow-graphs from with the GNU Radio Companion
(GRC); GRC can compile scripts (the file is created; or, via ?grcc? on the
command line), and the resulting Python executes correctly. But, executing a
compiled GRC script from within GRC fails. I found CPU usage on Wx and Qt
graphs a little lower on 10.10 than prior OSs; nice!
There is no clear solution to this issue at this time; I?m working on it as
time allows, but it?s looking like something that Apple will have to fix ? not
a GNU Radio or UHD issue directly.
Thus, my recommendation is to stay with Mac OS X 10.9 or earlier if you want to
be able to execute flow graphs from within GRC. I?ll post again once I know
something more. Please feel free to ping me & I?ll discuss the issue in more
depth with anyone interested. - MLD
------------------------------
Message: 5
Date: Mon, 20 Oct 2014 08:55:16 -0230
From: "khalid.el-darymli" <[email protected]>
To: "Ralph A. Schmid, dk5ras" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Isolating the grounds of LFTX and LFRX in
N200
Message-ID:
<CACdmG=wwofij7xbj-uxtbcg5quqlyygcpakyjsi7j0m_n1m...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Ralph,
Yes, I understand that the proximity of both PCBs and the lack of shielding
is a part of the problem, but I think the common ground too plays a role
into this. As mentioned in my earlier email, I personally verified this for
the case of two separate N200 devices.
Please see this,
http://web.mit.edu/~jhawk/tmp/p/EST016_Ground_Loops_handout.pdf
All the best,
Khalid
On Sat, Oct 18, 2014 at 2:31 AM, Ralph A. Schmid, dk5ras <[email protected]>
wrote:
> Not the ground is the problem, but the proximity of both PCBs, and the
> lack of shielding. Guess it will be a bigger task to shield and isolate
> them, using separated devices is better.
>
>
>
> Ralph.
>
>
>
> *From:* USRP-users [mailto:[email protected]] *On Behalf
> Of *khalid.el-darymli via USRP-users
> *Sent:* Friday, October 17, 2014 7:45 PM
> *To:* [email protected]
> *Subject:* [USRP-users] Isolating the grounds of LFTX and LFRX in N200
>
>
>
> Hi,
>
> I have *two N200 *devices. One of which is used as a Tx and Rx
> simultaneously and the other is only used as Rx. The LFRX and LFTX
> daughterboards are used for Rx and Tx, respectively. In my present test, I
> am using FMCW chirp with a BW of 50 KHz.
>
> I noticed that if the grounds of the two N200 units are connected with
> each other (e.g., through using external LNAs with a common ground) I can
> see the FMCW sweeps with a power around 10 dB above the noise floor in the
> Rx only N200 unit; without having nothing connected to its Rx input. I
> managed to absolutely cancel out this effect through simply isolating the
> common grounds between the two N200 units.
>
> The issue I am having now is with the N200 unit that has both the LFTX and
> LFRX daughterboards inside it. In this unit, I am seeing the FMCW sweeps at
> the Rx (without having nothing connected to Rx) with a power of around 20
> dB above the noise floor.
>
> It seems that since the LFTX and LFRX daughterboards are plugged-in to the
> same motherboard, they both share the same ground!
>
> My question is, *how do I isolate the grounds of the LFTX and LFRX
> daughterboards connected to the same N200 unit to minimize the coupling
> between two of them?*
>
> I will appreciate any help on this.
>
> Thanks.
>
> Best regards,
>
> Khalid
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141020/d962d09f/attachment-0001.html>
------------------------------
Message: 6
Date: Mon, 20 Oct 2014 14:38:35 +0200
From: "Ralph A. Schmid, dk5ras" <[email protected]>
To: "'khalid.el-darymli'" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Isolating the grounds of LFTX and LFRX in
N200
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Sure, ground is one path for stray RF, but it is not the main path in such a
setup, inside a box, and anyway you can?t do very much against it in an
existing device. Shielding will be the only way to get some more dB of
isolation. Using the same frequency for both TX and RX in one box is a job for
the few professionals in this field, and usually it is nearly impossible to
modify a finished design to achieve this. Remember that we may talk here about
100dB up to almost 150dB (20 dBm TX out and -125 dBm RX sensitivity are
possible with an USRP!), what is quite a lot :)
Ralph.
From: khalid.el-darymli [mailto:[email protected]]
Sent: Monday, October 20, 2014 1:25 PM
To: Ralph A. Schmid, dk5ras
Cc: [email protected]
Subject: Re: [USRP-users] Isolating the grounds of LFTX and LFRX in N200
Hi Ralph,
Yes, I understand that the proximity of both PCBs and the lack of shielding is
a part of the problem, but I think the common ground too plays a role into
this. As mentioned in my earlier email, I personally verified this for the case
of two separate N200 devices.
Please see this,
http://web.mit.edu/~jhawk/tmp/p/EST016_Ground_Loops_handout.pdf
All the best,
Khalid
On Sat, Oct 18, 2014 at 2:31 AM, Ralph A. Schmid, dk5ras <[email protected]
<mailto:[email protected]> > wrote:
Not the ground is the problem, but the proximity of both PCBs, and the lack of
shielding. Guess it will be a bigger task to shield and isolate them, using
separated devices is better.
Ralph.
From: USRP-users [mailto:[email protected]
<mailto:[email protected]> ] On Behalf Of khalid.el-darymli
via USRP-users
Sent: Friday, October 17, 2014 7:45 PM
To: [email protected] <mailto:[email protected]>
Subject: [USRP-users] Isolating the grounds of LFTX and LFRX in N200
Hi,
I have two N200 devices. One of which is used as a Tx and Rx simultaneously and
the other is only used as Rx. The LFRX and LFTX daughterboards are used for Rx
and Tx, respectively. In my present test, I am using FMCW chirp with a BW of 50
KHz.
I noticed that if the grounds of the two N200 units are connected with each
other (e.g., through using external LNAs with a common ground) I can see the
FMCW sweeps with a power around 10 dB above the noise floor in the Rx only N200
unit; without having nothing connected to its Rx input. I managed to absolutely
cancel out this effect through simply isolating the common grounds between the
two N200 units.
The issue I am having now is with the N200 unit that has both the LFTX and LFRX
daughterboards inside it. In this unit, I am seeing the FMCW sweeps at the Rx
(without having nothing connected to Rx) with a power of around 20 dB above the
noise floor.
It seems that since the LFTX and LFRX daughterboards are plugged-in to the same
motherboard, they both share the same ground!
My question is, how do I isolate the grounds of the LFTX and LFRX
daughterboards connected to the same N200 unit to minimize the coupling between
two of them?
I will appreciate any help on this.
Thanks.
Best regards,
Khalid
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141020/b29d6a9e/attachment-0001.html>
------------------------------
Message: 7
Date: Mon, 20 Oct 2014 22:24:45 +0800
From: Liwei <[email protected]>
To: "Marcus D. Leech" <[email protected]>, Marcus M?ller
<[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] N210 Stops Transmitting
Message-ID:
<cape0syzwhuc6s-6kebzem0odjsgsbf1zyyozatzxmbp60ux...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
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 <[email protected]> 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 <[email protected]> wrote:
>> Whoops, attached the generated python instead of the flow graph. See
>> attached.
>>
>> On 20 October 2014 00:50, Liwei <[email protected]> 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--
------------------------------
Message: 8
Date: Mon, 20 Oct 2014 11:21:56 -0400
From: [email protected]
To: Liwei <[email protected]>
Cc: [email protected], [email protected]
Subject: Re: [USRP-users] N210 Stops Transmitting
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
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 <[email protected]> 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 <[email protected]> wrote: Whoops, attached the generated python
instead of the flow graph. See attached. On 20 October 2014 00:50, Liwei
<[email protected]> 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-0001.html>
------------------------------
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 19
******************************************
