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. Isolating the grounds of LFTX and LFRX in N200 (khalid.el-darymli)
2. Re: Isolating the grounds of LFTX and LFRX in N200
(Ralph A. Schmid, dk5ras)
3. Re: N210 Stops Transmitting (Liwei)
4. Re: N210 Stops Transmitting (Marcus M?ller)
5. Re: N210 Stops Transmitting (Liwei)
6. RE: DSP chain flushing for burst transmissions (Nowlan, Sean)
7. Re: N210 Stops Transmitting (Marcus M?ller)
----------------------------------------------------------------------
Message: 1
Date: Fri, 17 Oct 2014 15:15:13 -0230
From: "khalid.el-darymli" <[email protected]>
To: [email protected]
Subject: [USRP-users] Isolating the grounds of LFTX and LFRX in N200
Message-ID:
<CACdmG=zV9pWNA_+artpXtt1Q3VzsmVrmh-5bGuy=regkeo2...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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/20141017/2f0128a6/attachment-0001.html>
------------------------------
Message: 2
Date: Sat, 18 Oct 2014 07:01:08 +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"
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/20141018/94d33820/attachment-0001.html>
------------------------------
Message: 3
Date: Sat, 18 Oct 2014 18:06:45 +0800
From: Liwei <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] N210 Stops Transmitting
Message-ID:
<CAPE0SYwx-cw3OJUcQgHMqStZ4hrPdhyPKH4Y-AV4n=pqy7q...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
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
------------------------------
Message: 4
Date: Sat, 18 Oct 2014 13:49:28 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] N210 Stops Transmitting
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
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
------------------------------
Message: 5
Date: Sat, 18 Oct 2014 20:43:55 +0800
From: Liwei <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] N210 Stops Transmitting
Message-ID:
<CAPE0SYx-aN4SO6Udz3m9zTHK8bfs=yn4+-f9-ltidx5rqum...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
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
------------------------------
Message: 6
Date: Sat, 18 Oct 2014 13:31:29 +0000
From: "Nowlan, Sean" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] RE: DSP chain flushing for burst transmissions
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
> From: USRP-users <[email protected]> on behalf of Nowlan,
> Sean via USRP-users <[email protected]>
> Sent: Monday, September 22, 2014 6:39 PM
> To: [email protected]
> Subject: [USRP-users] DSP chain flushing for burst transmissions ?
>
> Following up from discussions at the GNU Radio conference, it seems that many
> USRP users have a need for flushing
> the DSP chain (interpolation filters, CIC filter, etc.) in the FPGA when
> using the transmit burst interface. Using metadata
> headers for setting transmit time_specs and starts/ends of bursts is useful
> and works very well, but information and
> guidance about how many zero samples are needed to flush the DSP chain is
> sparse and undocumented. (To my
> knowledge, at least). Some things that would be helpful, in increasing level
> of effort:
>
> 1) Documentation about how many zero samples must be transmitted to
> flush the DSP chain: if host sample-rate dependent, a
> formula or lookup table
> 2) A tool/utility to automatically determine this number through a
> loopback test, etc.
>
> Thanks,
> Sean Nowlan
Any information about this would be greatly appreciated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141018/13a087c6/attachment-0001.html>
------------------------------
Message: 7
Date: Sat, 18 Oct 2014 16:25:00 +0200
From: Marcus M?ller <[email protected]>
To: Liwei <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] N210 Stops Transmitting
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
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
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
------------------------------
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 17
******************************************
