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: problems with ETTUS B200 and maximum clock rate
(Marcus D. Leech)
2. Re: X310 MTU frame size issue (Michael West)
3. Re: X310 MTU frame size issue (Louis Brown)
4. Re: problems with ETTUS B200 and maximum clock rate
(Marcus D. Leech)
5. Re: problem with USRP example on X310 with CBX-120 (Michael West)
6. The receiver ADC goes into saturation (w xd)
7. Re: The receiver ADC goes into saturation (Marcus M?ller)
8. Re: The receiver ADC goes into saturation (Marcus D. Leech)
----------------------------------------------------------------------
Message: 1
Date: Fri, 24 Oct 2014 12:58:32 -0400
From: "Marcus D. Leech" <[email protected]>
To: massimo zampetti <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] problems with ETTUS B200 and maximum clock
rate
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-15"; Format="flowed"
On 10/24/2014 10:29 AM, massimo zampetti via USRP-users wrote:
> Hi,
> I'm using an ETTUS B200 connected to my PC (USB 3.0 port:***Intel
> Z7**7*, motherboard: *ASRock Z77 Extreme 11*,**OS: *Microsoft Windows
> 7 (64 bit)*).
>
> I'm trying to use my SDR with a clock rate of *56 MHz* but it doesn't
> work.
> I did some tests both with GNURadio and with tx_waveforms.exe.
>
> About tx_waveforms contained in UHD directory, I modified its code to
> add 'usrp->set_master_clock_rate()' and set its argument to 56 MHz.
> I set also the argument of 'usrp->set_clock_source()' to 56 MHz. Then
> I run the code.
>
> The result shown on the command prompt is 'UUUU..' (Usrp Underrun).
> I obtained the same result with GNURadio.
>
> At the beginning I thought I could set clock rate up to 61.44 Mhz
> (according to the maximum sample rate of DAC: 61.44 MS/s).
>
> I did some tests and here there are the results:
>
> 1.
>
>
>
> 2.
> set_master_clock_rate : 61.44 MHz
> set_clock_source: 56 MHz
>
>
>
> 2.
> set_master_clock_rate : 70 MHz
> set_clock_source: 56 MHz
>
>
>
> Where is the problem? Any suggestions?
>
> Regards,
>
> Massimo
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
I'll comment that the 'U' is due to underrun--your machine simply can't
keep up with the demand of the USRP for samples at that rate.
Also, set_clock_source() is used to set whether the device derives its
master clock from the on-board oscillator, or GPSDO, or external 10Mhz
input.
It makes no sense to pass it 56Mhz.
If you're just sending a narrowband tone, there's zero reason to send it
at a very-high sample rate.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141024/ba3449bf/attachment-0001.html>
------------------------------
Message: 2
Date: Fri, 24 Oct 2014 11:08:36 -0700
From: Michael West <[email protected]>
To: Louis Brown <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] X310 MTU frame size issue
Message-ID:
<cam4xkrqfvxkdq7dqt_q4+kbmyyocxpyqcfbzct8sev+tyk_...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Louis,
Are you stopping GRC by closing the pop-up window or by the "Kill the
flowgraph" button in the toolbar? I ask because they operate differently.
Closing the pop-up window will exit the application cleanly and you should
be able to run over and over again. Using the "Kill the flowgraph" button
in the toolbar is equivalent to using Ctrl-C and can leave the device in an
undesirable state. As you have observed, the device eventually returns to
a usable state even if you kill the application but it could take a few
seconds.
Regards,
Michael
On Fri, Oct 24, 2014 at 9:16 AM, Louis Brown <[email protected]> wrote:
>
> Regarding my previous post, I have found if I wait until the X310 link light
> goes from red to off, about 10 seconds, I can re-establish communication. If
> I try to run my GRC flow when the link light is red, it finds the incorrect
> MTU. So I guess the rule is, always wait until the link light is off until
> you re-run your flow graph.
>
> Lou
>
> On Oct 23, 2014, at 08:40 PM, Michael West <[email protected]> wrote:
>
> Hi Louis,
>
> I noticed that for the benchmark_rate you are supplying the IP address and
> for GRC you are not. Try supplying the same args ("addr=192.168.40.2") in
> the "Device Addr" field of the UHD USRP Source/Sink block you are using.
>
> Regards,
> Michael E. West
>
> On Thu, Oct 23, 2014 at 6:31 PM, Louis Brown via USRP-users <
> [email protected]> wrote:
>
>> Operating my X310 from a UHD source in GRC via 10GE yields a low MTU at
>> startup:
>>
>> -----------------------------------------------
>> linux; GNU C++ version 4.8.3 20140911 (Red Hat 4.8.3-7); Boost_105400;
>> UHD_003.008.000-6-gbde8e9a3
>> -- X300 initialization sequence...
>> -- Determining maximum frame size... 2188 bytes.
>> UHD Warning:
>>
>> Sent from iCloud
>>
>> For this connection, UHD recommends a send frame size of at least
>> 8000 for best
>> performance, but your system's MTU will only allow 2188.
>> This will negatively impact your maximum achievable sample rate.
>> -----------------------------------------------
>>
>> My MTU for the 10GE interface is 9000 (verified with ifconfig), and when
>> I run benchmark_rate it finds the correct MTU:
>>
>> ------------------------------------------------
>> ./benchmark_rate --rx_rate 200E6 --args "addr=192.168.40.2"
>> linux; GNU C++ version 4.8.3 20140911 (Red Hat 4.8.3-7); Boost_105400;
>> UHD_003.008.000-6-gbde8e9a3
>>
>> Creating the usrp device with: addr=192.168.40.2...
>> -- X300 initialization sequence...
>> -- Determining maximum frame size... 8000 bytes.
>> -----------------------------------------------
>>
>> So is this a GR issue or a UHD issue, or a combination?
>>
>> Thanks,
>> Lou
>> KD4HSO
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141024/04575c16/attachment-0001.html>
------------------------------
Message: 3
Date: Fri, 24 Oct 2014 18:16:16 +0000 (GMT)
From: Louis Brown <[email protected]>
To: Michael West <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] X310 MTU frame size issue
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
I was using stop button. I close the GUI window and the X310 link now stops
cleanly with the link light extinguishing immediately. Wow, I have been doing
it wrong for quite a long time.?
Thanks,
Lou
On Oct 24, 2014, at 12:08 PM, Michael West <[email protected]> wrote:
> Hi Louis,
>
> Are you stopping GRC by closing the pop-up window or by the "Kill the
> flowgraph" button in the toolbar? I ask because they operate differently.
> Closing the pop-up window will exit the application cleanly and you should be
> able to run over and over again. Using the "Kill the flowgraph" button in
> the toolbar is equivalent to using Ctrl-C and can leave the device in an
> undesirable state. As you have observed, the device eventually returns to a
> usable state even if you kill the application but it could take a few seconds.
>
> Regards,
> Michael
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141024/339a295c/attachment-0001.html>
------------------------------
Message: 4
Date: Fri, 24 Oct 2014 14:49:55 -0400
From: "Marcus D. Leech" <[email protected]>
To: Massimo Zampetti <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] problems with ETTUS B200 and maximum clock
rate
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 10/24/2014 02:34 PM, Massimo Zampetti wrote:
>
> I want to set the clock rate to 56 MHz because I want to send an
> impulse with a duration of 17 ns - 20 ns (approximately). For this
> reason I need of a very fast sample rate.
>
SO, you're going to have to figure out how to keep your B200 "fed" at
that very-high sample rate. Maybe a pre-recorded sample set in memory or
something similar. The "U" indicates that your computer isn't
keeping up, and that includes the entire "stack" from application,
through the kernel,
the USB drivers, etc.
> Il 24/ott/2014 18:58 "Marcus D. Leech" <[email protected]> ha scritto:
>
> On 10/24/2014 10:29 AM, massimo zampetti via USRP-users wrote:
>> Hi,
>> I'm using an ETTUS B200 connected to my PC (USB 3.0 port:***Intel
>> Z7**7*, motherboard: *ASRock Z77 Extreme 11*,**OS: *Microsoft
>> Windows 7 (64 bit)*).
>>
>> I'm trying to use my SDR with a clock rate of *56 MHz* but it
>> doesn't work.
>> I did some tests both with GNURadio and with tx_waveforms.exe.
>>
>> About tx_waveforms contained in UHD directory, I modified its
>> code to add 'usrp->set_master_clock_rate()' and set its argument
>> to 56 MHz.
>> I set also the argument of 'usrp->set_clock_source()' to 56 MHz.
>> Then I run the code.
>>
>> The result shown on the command prompt is 'UUUU..' (Usrp Underrun).
>> I obtained the same result with GNURadio.
>>
>> At the beginning I thought I could set clock rate up to 61.44 Mhz
>> (according to the maximum sample rate of DAC: 61.44 MS/s).
>>
>> I did some tests and here there are the results:
>>
>> 1.
>>
>>
>>
>> 2.
>> set_master_clock_rate : 61.44 MHz
>> set_clock_source: 56 MHz
>>
>>
>>
>> 2.
>> set_master_clock_rate : 70 MHz
>> set_clock_source: 56 MHz
>>
>>
>>
>> Where is the problem? Any suggestions?
>>
>> Regards,
>>
>> Massimo
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> I'll comment that the 'U' is due to underrun--your machine simply
> can't keep up with the demand of the USRP for samples at that rate.
>
> Also, set_clock_source() is used to set whether the device derives
> its master clock from the on-board oscillator, or GPSDO, or
> external 10Mhz input.
> It makes no sense to pass it 56Mhz.
>
> If you're just sending a narrowband tone, there's zero reason to
> send it at a very-high sample rate.
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141024/81fa8b88/attachment-0001.html>
------------------------------
Message: 5
Date: Fri, 24 Oct 2014 14:55:52 -0700
From: Michael West <[email protected]>
To: Jim Hunziker <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] problem with USRP example on X310 with
CBX-120
Message-ID:
<cam4xkromsazov77j95nwy_3mbd8lb88x-4zf8enq3yjkihw...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Jim,
An experimental UHD patch was sent to your colleague to address the
calibration issue. Please let me know if you need the patch sent to you
directly and I will get it to you.
Best regards,
Michael
On Thu, Oct 23, 2014 at 10:40 AM, Jim Hunziker via USRP-users <
[email protected]> wrote:
> Marcus Leech responded to me off-list that I was using gain settings that
> were too low. Setting them to 10 greatly improved my signal, though there's
> still a carrier component that's bigger than my signal and not getting
> removed. A colleague tells me he's working with Ettus regarding this
> problem.
>
>
> --
> Jim Hunziker
> BCI Systems and Software Engineering
> (973) 348-9299
> [email protected]
>
> On Wed, Oct 22, 2014 at 4:42 PM, Jim Hunziker <[email protected]>
> wrote:
>
>> It looks like some of my problem was plotting abs(sig_c) rather than
>> real(sig_c), but the signal still doesn't look great.
>>
>>
>> --
>> Jim Hunziker
>> BCI Systems and Software Engineering
>> (973) 348-9299
>> [email protected]
>>
>> On Wed, Oct 22, 2014 at 12:15 PM, Jim Hunziker <[email protected]>
>> wrote:
>>
>>> Hi. I have an X310 with a CBX-120 and a GPSDO, and I'm running the
>>> txrx_loopback_to_file example with UHD version 3.7.3 like this:
>>>
>>> ./txrx_loopback_to_file --tx-args addr=10.10.10.90 --nsamps=250000
>>> --tx-rate 2500000 --rx-rate 2500000 --tx-freq 56000000
>>> 00 --rx-freq 5600000000 --rx-ant CAL --wave-type SINE --ref internal
>>> --wave-freq 1000
>>>
>>> (It makes no difference if I use the RX2 antenna and a loopback cable.)
>>>
>>> With a sampling rate of 2.5 MHz and a sine wave of 1 KHz, I expect to
>>> see a sinusoidal cycle every 2500 samples. I'm plotting them with GNU
>>> Octave and the following commands:
>>>
>>> fid = fopen("~/uhd/host/build/examples/usrp_samples.dat", "rb");
>>> [sig, count] = fread(fid, Inf, "int16");
>>> sig_c = sig(1:2:end) + j * sig(2:2:end);
>>> plot(abs(sig_c));
>>>
>>> The signal seems very noisy, and it's pretty much gone towards the end
>>> of the capture. Am I doing something wrong?
>>>
>>> --
>>> Jim Hunziker
>>> BCI Systems and Software Engineering
>>> [email protected]
>>>
>>
>>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141024/4fd16478/attachment-0001.html>
------------------------------
Message: 6
Date: Sat, 25 Oct 2014 20:28:50 +0800
From: w xd <[email protected]>
To: [email protected]
Subject: [USRP-users] The receiver ADC goes into saturation
Message-ID:
<ca+va9qcuqykeyrf0bcoyljsigk7mgawfxprphax1waovpgc...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi all:
Environment:USRP N210,14bit ADC
According the formula:DR(dynamic range):6.02*14=84.28dB.
And now two USRP N210 close to each other,while one is used for
transmitting and the other is used for receiving.The amplitude of the
signal which to be send is 1.The gain in the transmitter I set
31.5dB.And the gain in the receiver I set also 31.5dB.The
31.5dB*2=63<DR(dynamic range).Why the receiver goes in saturation so
easily?The signal saturates the ADC and gets clipped.Can someone
explain it to me?
Thank you.
Best regards,
xd
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141025/0f281860/attachment-0001.html>
------------------------------
Message: 7
Date: Sat, 25 Oct 2014 15:23:38 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] The receiver ADC goes into saturation
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi XD,
On 25.10.2014 14:28, w xd via USRP-users wrote:
> Hi all:
> Environment:USRP N210,14bit ADC
> According the formula:DR(dynamic range):6.02*14=84.28dB.
That is the theoretical formula for the maximum dynamic range you get
from an ADC.
Most daughterboards have, like yours, adjustable gain. You'd need to add
that gain range to the ADC dynamic range to get the upper boundary of
dynamic range that your receiver system can deal with.
> And now two USRP N210 close to each other,while one is used for
> transmitting and the other is used for receiving.The amplitude of the
> signal which to be send is 1.The gain in the transmitter I set
> 31.5dB.And the gain in the receiver I set also 31.5dB.The
> 31.5dB*2=63<DR(dynamic range).Why the receiver goes in saturation so
> easily?The signal saturates the ADC and gets clipped.Can someone
> explain it to me?
Yes. Dynamic range but defines the ratio between the strongest
detectable and the weakest detectable signal amplitude. Obviously,
you're overdriving you ADC -- why don't you just reduce the RX gain? The
multiplied gains of RX and TX tell you nothing about the strength of the
signal reacing your RX USRP.
Greetings,
Marcus
> Thank you.
> Best regards,
> xd
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141025/4ab9f46a/attachment-0001.html>
------------------------------
Message: 8
Date: Sat, 25 Oct 2014 10:35:24 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] The receiver ADC goes into saturation
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 10/25/2014 08:28 AM, w xd via USRP-users wrote:
> Hi all:
> Environment:USRP N210,14bit ADC
> According the formula:DR(dynamic range):6.02*14=84.28dB.
> And now two USRP N210 close to each other,while one is used for
> transmitting and the other is used for receiving.The amplitude of the signal
> which to be send is 1.The gain in the transmitter I set 31.5dB.And the gain
> in the receiver I set also 31.5dB.The 31.5dB*2=63<DR(dynamic range).Why the
> receiver goes in saturation so easily?The signal saturates the ADC and gets
> clipped.Can someone explain it to me?
> Thank you.
> Best regards,
> xd
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
To use a simple physical world analogy, you're *screaming loudly* into
your friends ear, and wondering why they have gone temporarily deaf...
Reduce your TX power and/or RX gain.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141025/449fcadb/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 25
******************************************
