Send USRP-users mailing list submissions to
usrp-users@lists.ettus.com
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
usrp-users-requ...@lists.ettus.com
You can reach the person managing the list at
usrp-users-ow...@lists.ettus.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: Enclosure for B205mini-i (Michael West)
2. Re: UBX-160 Performance < 500 MHz (Michael West)
3. Non-integer number of dropped samples during overflow
(Jacob Gilbert)
4. Re: Complex taps for RFNoC FIR (Jonathon Pendlum)
5. Re: E310 FPGA build Failure (Long, Jeffrey P.)
6. Re: X310 GPIO 3.3V supply pin: what is the recommended
maximum current it can supply? (Nicolas Cuervo)
7. Gain control with timed commands (Vladica Sark)
8. Weird behaviour with set_master_clock_rate in X300 (Pol Henarejos)
9. LFRX sensitivity (Matis Alun)
10. Re: Weird behaviour with set_master_clock_rate in X300
(Claudio Cicconetti)
11. Re: Weird behaviour with set_master_clock_rate in X300
(Pol Henarejos)
12. Re: Gain control with timed commands (Marcus M?ller)
13. Re: Gain control with timed commands (Vladica Sark)
14. Re: LFRX sensitivity (Marcus M?ller)
15. Re: RFNOC on E312 (Long, Jeffrey P.)
16. Re: X310 GPIO 3.3V supply pin: what is the recommended
maximum current it can supply? (Andy Walls)
----------------------------------------------------------------------
Message: 1
Date: Thu, 13 Oct 2016 09:08:05 -0700
From: Michael West <michael.w...@ettus.com>
To: Vladica Sark <vladicas...@gmail.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Enclosure for B205mini-i
Message-ID:
<CAM4xKrr09PH73tO3fCwizcAP=sew-xcu4qoelyzuhva1vns...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Vladica,
Yes, the dimensions of the boards are the same. The differences in the
cases are the temperature ranges and the labelling.
Regards,
Michael
On Thu, Oct 13, 2016 at 1:09 AM, Vladica Sark via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi there,
>
> I want to buy an enclosure for my b205mini-i, but there are 3 different
> enclosures which look that would fit. What is the difference between the 3
> enclosures offered for the B200mini series? The dimensions of the boards
> should be the same, so physically all board would fit to all of the
> enclosures offered.
>
> BR,
> Vladica
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> 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/20161013/d4dd185a/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 13 Oct 2016 10:10:04 -0700
From: Michael West <michael.w...@ettus.com>
To: "Marcus D. Leech" <mle...@ripnet.com>
Cc: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] UBX-160 Performance < 500 MHz
Message-ID:
<CAM4xKrrVoeoBONx5tQtMyjUqcMN15DVD52Z=vnc8ghqtvi2...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
That is correct. The dboard clock rate is not configurable on the N2xx.
But I don't believe the real issue is the dboard clock rate. The reduced
dboard clock rate is to achieve phase synchronization on UBX.
I think the real issue is the gain setting. Running at the maximum gain
setting can result in clipping. The gain value needs to be calibrated to
avoid clipping and provide highest dynamic range.
Regards,
Michael
On Thu, Oct 13, 2016 at 8:17 AM, Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:
> On 10/13/2016 11:07 AM, Perelman, Nathan via USRP-users wrote:
>
> Looking at this in more detail, does this affect the N2xx series USRPs? I
> don?t see any code in UHD to set the daughterboard clock rate for
> usrp2/N2xx USRPs, but I am seeing a fairly high noise floor with the UBX-40
> in an N210 at low frequencies.
>
>
>
> My recollection is that DB clock-rate simply isn't settable on the
> N2xx--it's fixed by the hardware.
>
>
>
> *From:* USRP-users [mailto:usrp-users-boun...@lists.ettus.com
> <usrp-users-boun...@lists.ettus.com>] *On Behalf Of *Perelman, Nathan via
> USRP-users
> *Sent:* Monday, September 26, 2016 11:21 AM
> *To:* Michael West
> *Cc:* Ben Hilburn via USRP-users
> *Subject:* Re: [USRP-users] UBX-160 Performance < 500 MHz
>
>
>
> Does the dboard_clock_rate argument only affect the UBX or will it mess up
> the SBX or WBX daughterboards if set? I?m trying to figure out if I can
> code my application so it doesn?t care about which daughterboard is in use
> or if I have to code specially for the UBX. What version of UHD was support
> for the argument added in?
>
>
>
> *From:* Michael West [mailto:michael.w...@ettus.com
> <michael.w...@ettus.com>]
> *Sent:* Friday, September 23, 2016 2:43 PM
> *To:* Perelman, Nathan
> *Cc:* Ben Hilburn via USRP-users
> *Subject:* Re: [USRP-users] UBX-160 Performance < 500 MHz
>
>
>
> Hi Nathan,
>
> If you plan on using frequencies both above and below 1 GHz, use the 20
> MHz dboard_clock_rate. A lower clock rate will mean a little more phase
> noise, but it should be fine for most applications.
>
> Regards,
>
> Michael
>
>
>
> On Fri, Sep 23, 2016 at 10:27 AM, Perelman, Nathan <
> nperel...@lgsinnovations.com> wrote:
>
> Is there a way to switch the daughterboard clock rate after creating a
> usrp object or can it only be set once on creation? What are the
> implications of using a clock rate of 20 MHz instead of 50 MHz when tuning
> above 1 GHz?
>
>
>
> *From:* Michael West [mailto:michael.w...@ettus.com]
> *Sent:* Thursday, September 22, 2016 12:40 PM
> *To:* Perelman, Nathan
> *Cc:* Ben Hilburn via USRP-users
>
>
> *Subject:* Re: [USRP-users] UBX-160 Performance < 500 MHz
>
>
>
> Hi Nathan,
>
> Yes. Both UBX-40 and UBX-160 are affected.
>
> Regards,
>
> Michael
>
>
>
> On Thu, Sep 22, 2016 at 7:09 AM, Perelman, Nathan via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Does this affect the UBX-40 as well?
>
>
>
> *From:* USRP-users [mailto:usrp-users-boun...@lists.ettus.com] *On Behalf
> Of *Michael West via USRP-users
> *Sent:* Tuesday, September 20, 2016 1:05 PM
> *To:* Michael Wentz
> *Cc:* USRP-users@lists.ettus.com
> *Subject:* Re: [USRP-users] UBX-160 Performance < 500 MHz
>
>
>
> Hi Michael,
>
> I'm glad to hear that made a substantial improvement.
>
>
>
> We need to update the documentation with the dboard_clock_rate parameter
> information and we will do that. The MAX2871 synthesizer used on the UBX
> has proven to be a bit touchy and has required a lot of special settings to
> perform properly. The default dboard_clock_rate on the X310 is 50 MHz,
> which is the ideal PFD frequency for the UBX. For frequencies under 1 GHz,
> we have found it necessary to reduce the dboard_clock_rate to 20 MHz due to
> several limitations in the MAX2871.
>
>
>
> We looked into setting the dboard_clock_rate automatically in UHD, but it
> is a non-trivial exercise because it is dependent on the user's intended
> use. Changing the dboard_clock_rate dynamically whenever the user
> application changes the frequency presents a host of other potential
> problems, not to mention what to do if there are 2 different types of
> daughterboards in the USRP.
>
>
>
> Regards,
>
> Michael
>
>
>
>
>
>
>
> On Tue, Sep 20, 2016 at 4:55 AM, Michael Wentz <mchlw...@gmail.com> wrote:
>
> Hi Michael,
>
>
>
> Adding "dboard_clock_rate=20e6" made a significant difference - the spurs
> and odd shape in the noise floor are both gone, image attached. I did the
> same type of measurement and it was around 75 dB SFDR, almost a 20 dB
> improvement.
>
>
>
> I had never heard of the dboard_clock_rate argument before. Are there any
> implications of setting that to 20 MHz and using the default master clock
> rate of 200 MHz? Also, is there a reason that UHD wouldn't know to use that
> number by default (based on the fact that I'm using a UBX < 1 GHz)?
>
>
>
> Thanks,
>
> Michael
>
>
>
> On Mon, Sep 19, 2016 at 9:34 PM, Michael West <michael.w...@ettus.com>
> wrote:
>
> Hi Michael,
>
> We do recommend a lower dboard clock rate for frequencies below 1 GHz on
> the UBX (for better LO performance). Can you try adding
> 'dboard_clock_rate=20e6' to your device arguments and see if there is any
> change?
>
> It is odd that introducing a signal causes the noise floor to rise. I
> will run this by the hardware engineer for the UBX and see if he has any
> ideas.
>
>
>
> Regards,
>
> Michael West
>
>
>
> On Mon, Sep 19, 2016 at 5:19 PM, Michael Wentz via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> I'm using the latest commit on rfnoc-devel, built today. I can also try
> without RFNoC but figured it would be identical since the master branch was
> merged in 10 days ago.
>
>
>
> On Mon, Sep 19, 2016 at 8:15 PM, Marcus D. Leech <mle...@ripnet.com>
> wrote:
>
> On 09/19/2016 06:30 PM, Michael Wentz wrote:
>
> Hi Marcus,
>
>
>
> Thanks for the feedback. Yes, I've tried gain ranges 0 to 31.5 - I'm
> intending to use an external LNA so was searching for settings where these
> issues were minimized, but they were fairly consistent across the gain
> range. I've also tried a variety of input signal strengths, usually around
> 30-40 dB below IIP3.
>
>
>
> I'm aware of the two RF chains and there is a noticeable performance
> difference < 500 MHz in the data on files.ettus.com, but nothing that
> informed me about the spurious content and odd behavior of the noise floor
> when there's a signal applied.
>
>
>
> Is the UBX design more optimized for higher frequencies? Wondering if I
> should have gone with the WBX-120 here.
>
>
>
> -Michael
>
> The UBX design is optimized for its entire frequency range.
>
> What version of UHD are you using?
>
>
>
> On Mon, Sep 19, 2016 at 6:03 PM, Marcus D. Leech via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> On 09/19/2016 02:58 PM, Michael Wentz via USRP-users wrote:
>
> Hi,
>
> I am working with an X310 and UBX-160 with the latest version of UHD. I've
> started to characterize the performance a bit at frequencies I'm interested
> in (< 500 MHz), and while trying to determine full range I noticed strange
> behavior compared to the WBX and SBX. Attached are some screen shots from
> measurements I made at 400 MHz with full gain (31.5) on the WBX-40,
> SBX-120, and UBX-160. I'm just eye balling the SDFR and picking the most
> noticeable spur away from the carrier, nothing really precise.
>
> WBX-40 : input power -15 dBm, SFDR around 76 dB
> SBX-120: input power -34 dBm, SFDR around 82 dB
> UBX-120: input power -32 dBm, SFDR around 56 dB
>
> I also noticed on the UBX that there is a significant increase in the
> noise floor when an input signal is applied, even if that input is 20-30 dB
> below where the input would clip. I've verified with test equipment that
> the noise floor is not from my signal source. Additionally, I did some
> measurements at 600 MHz and 1 GHz and saw much better performance, in line
> with the WBX/SBX.
>
> Is any of this expected? Is there anything I can do to improve the
> performance?
>
> Thanks,
> Michael
>
> Two quick comments.
>
> The first is that the analog RF chain on UBX is *very* different from
> SBX/WBX (which are almost identical, BTW, except for mixers).
>
> The second is a question. Have you tried dropping the gain on the UBX?
> Have you tried lowering the signal level? The UBX has two
> different RF chains, with 500Mhz being the dividing line between the
> two. So I would expect there to be not-subtle differences in things
> like OIP3, p1dB, etc.
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
>
>
> _______________________________________________
> USRP-users mailing
> listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> 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/20161013/e9fadb25/attachment-0001.html>
------------------------------
Message: 3
Date: Thu, 13 Oct 2016 11:14:15 -0600
From: Jacob Gilbert <mrjacobagilb...@gmail.com>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] Non-integer number of dropped samples during
overflow
Message-ID:
<cac52akabo66gg270mg33w-3jdxfdzbh6vh6do9odr+jvc6b...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I am experiencing a behavior with overflows and dropped samples I did not
expect and am looking for some confirmation/information regarding it:
I have an application that is very sensitive to unknown dropped samples,
but if the number of dropped samples is known there is not an issue. I have
developed a simple block for tracking the number of dropped samples based
on the timestamps the gr-uhd source block tags after an overflow.
In tracking this, I have observed non-integer numbers of dropped samples
_unless_ the master clock rate and sample rate are the same, in which case
I only see integer numbers of dropped samples. In every case of dropped
samples, there time difference corresponds to an integer number of
digitized samples. This leads me to believe that these samples are being
dropped prior to decimation in the FPGA, and in an arbitrary number
Is there a reason for this as opposed to dropping samples after decimation?
This appears to be causing me issues with keeping the data from multiple
synchronized devices (X310s) aligned as non-integer numbers of
over-the-wire samples cannot be easily aligned. Is there a way to force
dropping of integer number of over-the-wire samples?
Thanks,
Jacob
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161013/847533f9/attachment-0001.html>
------------------------------
Message: 4
Date: Thu, 13 Oct 2016 14:43:03 -0500
From: Jonathon Pendlum <jonathon.pend...@ettus.com>
To: ???? <r...@eng.gov.il>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Complex taps for RFNoC FIR
Message-ID:
<cagdo0utzqwd+phn-w8gm_9kpazxowkypv7jeugbu3o_q2wr...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Roy,
The FIR filter block is not designed for complex taps, but you could use
the block as a starting point to create one.
Jonathon
On Thu, Oct 13, 2016 at 12:45 AM, ???? via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Dear all,
>
>
> I'm trying to use the RFNoC FIR block as a matched filter on E310 (release
> 4 sg1 image).
>
> I've noticed that in the fir_block_ctrl (fir_block_ctrl.hpp), the method
> set_taps() gets a vector of integers as taps.
>
> Is there a way to filter with complex taps using RFNoC blocks?
>
>
> Thanks,
>
> Roy
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> 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/20161013/c95f0954/attachment-0001.html>
------------------------------
Message: 5
Date: Thu, 13 Oct 2016 21:26:34 +0000
From: "Long, Jeffrey P." <jpl...@mitre.org>
To: Jonathon Pendlum <jonathon.pend...@ettus.com>
Cc: "USRP-users@lists.ettus.com" <USRP-users@lists.ettus.com>
Subject: Re: [USRP-users] E310 FPGA build Failure
Message-ID:
<dm5pr09mb1372b60808a87b5ea34307dcd9...@dm5pr09mb1372.namprd09.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
Jonathon-
Ok thanks that is kind of what I thought. Yes I can avoid using the DUC and
DDC. Given the DDC and DUC probably have not changed all that much relative to
the non-rfnoc design it would appear that rfnoc infrastructure is taking up
more space.
I will have to be more creative in fitting my design in.
Thanks
Jeff
From: Jonathon Pendlum [mailto:jonathon.pend...@ettus.com]
Sent: Wednesday, October 12, 2016 5:29 PM
To: Long, Jeffrey P.
Cc: USRP-users@lists.ettus.com
Subject: Re: [USRP-users] E310 FPGA build Failure
Hi Jeff,
We are working on reducing utilization on the DDC / DUC. One option is to
reduce the NUM_CHAINs option on the DDC to 1 to save some space. Also unless
you specifically need timed CORDIC tunes, you do not need a DDC or DUC on the
E310. Instead you can set the master clock rate to the sampling rate you want.
Jonathon
On Wed, Oct 12, 2016 at 2:29 PM, Long, Jeffrey P. via USRP-users
<usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>> wrote:
I am trying to build a FPGA image for an E312 using the rfnoc-devel branch.
I issued this command:
./make.py ddc duc -d e310 -t E310_RFNOC_sg3
And it appears that the design ran over on resources. I thought I was building
a pretty basic image but perhaps I have something wrong here.
Can you give some guidance on the usage of make.py? I also attached the
build.log incase that sheds some light.
Thanks
Jeff
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com<mailto:USRP-users@lists.ettus.com>
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/20161013/0dbb9c5e/attachment-0001.html>
------------------------------
Message: 6
Date: Thu, 13 Oct 2016 19:27:42 -0700
From: Nicolas Cuervo <nicolas.cue...@ettus.com>
To: Andy Walls <a...@silverblocksystems.net>
Cc: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] X310 GPIO 3.3V supply pin: what is the
recommended maximum current it can supply?
Message-ID:
<CAOuPCviO5=g3eT3msSEoSCi0E4UR9gy=mo0c86pd3o9tb6f...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Andy,
We are very sorry for the late response. It appears that this email went
through the cracks. Have you come to an answer?
Regarding the +3.3v pin, it is not really a supply, but a clamp. This pin
is primarily used for ESD protection, and it is not intended to supply high
currents. You can see the configuration for this pin in the schematics at
[1], page 14.
Using this pin as a power source is, generally, not recommended. If it
suits the needs of your application, it would be, lets say, at your own
risk, as this is not the what the pin is intended to do. I would recommend
you to have a look at the circuit that I point you out at the schematic,
and analyze if the load that you intend to connect is power demanding.
Apart from that, making a quick simulation of this configuration, the 3.3v
pin should be able to source 5-10mA, having a droop of the output voltage
as the current increases (~2.6V would be about right in this case). You
could say that, as for the documentation, the "5mA" notation applies to
this pin.
As for the other pins, they are connected to the FPGA GPIOs. The reasoning
would be basically the same, but as this are indeed in and outs, you could
say that the "12mA" notation of the documentation apply to them. However,
note that we do not recommend the driving of big loads through the GPIO
prior a slightly more exhausting analysis of your load configuration.
Cheers,
- Nicolas
[1] http://files.ettus.com/schematics/x300/x3xx.pdf
On Tue, Sep 6, 2016 at 11:39 AM, Andy Walls via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi:
>
> Regarding, the X310 GPIO 3.3V supply pin: what is the recommended
> maximum current it can supply?
>
> The wiki pages mention the GPIO signal pins can source up to either 12
> mA, or 5 mA. Neither page below talks about a 3.3V supply pin current
> limit:
> https://kb.ettus.com/X300/X310_Getting_Started_Guides#
> GPIO_Specifications_.283.3V_Bank.2C_LVCMOS.29
> https://kb.ettus.com/X300/X310#Front_Panel_GPIO
>
> Thanks.
>
> Regards,
> Andy
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> 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/20161013/27aabc1d/attachment-0001.html>
------------------------------
Message: 7
Date: Fri, 14 Oct 2016 09:01:26 +0200
From: Vladica Sark <vladicas...@gmail.com>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] Gain control with timed commands
Message-ID: <7ec9949c-e7f2-b513-0e1b-c1b1e28eb...@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi,
I am using N210 with timed commands for rx/tx. I send and receive
samples in time slots. Is there a way to change the transmit and receive
gain for each timed command, i.e. each time slot, since it is reserved
for different user? BTW, I issue multiple timed commands at once, and
than wait for the received data.
BR,
Vladica
------------------------------
Message: 8
Date: Fri, 14 Oct 2016 09:25:09 +0200
From: Pol Henarejos <pol.henare...@cttc.es>
To: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] Weird behaviour with set_master_clock_rate in
X300
Message-ID: <425ec889-8b02-7a37-a1f9-0f124d0ca...@cttc.es>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Dear all,
I am experimenting some weird issues when I try to change the master
clock. I wish to set the TX rate of my X300 to 15.36 Msps. So,
previously I set the master clock to 184.32 MHz in order to obtain an
integer decimation (184.32/15.36 = 12) but it seems that is not set
properly. What I get from USRP X300 is the following warning:
UHD Warning:
The requested interpolation is odd; the user should expect passband
CIC rolloff.
Select an even interpolation to ensure that a halfband filter is
enabled.
interpolation = dsp_rate/samp_rate -> 13 = (200.000000
MHz)/(15.360000 MHz)
UHD Warning:
The hardware does not support the requested TX sample rate:
Target sample rate: 15.360000 MSps
Actual sample rate: 15.384615 MSps
I guess that the master clock is set to the default 200 MHz and not
changed to 184.32e6.
Any clue?
The code is:
usrp->set_master_clock(184.32e6);
usrp->set_tx_rate(15.36e6); //Warnings are displayed here
I am using the UHD version Win32; Microsoft Visual C++ version 14.0;
Boost_106000; UHD_003.010.000.000-92-ON
Thanks.
--
Pol Henarejos
Researcher, MSc
pol.henare...@cttc.es
Centre Tecnol?gic de Telecomunicacions de Catalunya (CTTC)
Av. Carl Friedrich Gauss, 7
08860 Castelldefels, Barcelona (Spain)
Tel: +34 93 645 29 00 Ext: 2177
Fax. +34 93 645 29 01
www.cttc.es
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3741 bytes
Desc: Signatura criptogr??fica S/MIME
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161014/576437ee/attachment-0001.p7s>
------------------------------
Message: 9
Date: Fri, 14 Oct 2016 09:41:15 +0200
From: Matis Alun <matis.a...@gmail.com>
To: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] LFRX sensitivity
Message-ID: <b71c8f06-5211-3b1b-8870-c9b0617ef...@gmail.com>
Content-Type: text/plain; charset=utf-8
Hell usrp users,
I didn't find some datasheet describing the RF specifications of the LFRX
daughterboard.
Can you tell me what is the sensitivity of the LFRX board ? We can define the
sensitivity
in the following way:
This is the power of a 3kHz bandwidth signal injected in the input which gives
a 10 dB
signal to noise ratio
(noise is the noise level of the sampler).
Thanks,
matis
------------------------------
Message: 10
Date: Fri, 14 Oct 2016 10:09:53 +0200
From: Claudio Cicconetti <cciccone...@mbigroup.it>
To: pol.henare...@cttc.es, usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Weird behaviour with set_master_clock_rate
in X300
Message-ID: <580092d1.5080...@mbigroup.it>
Content-Type: text/plain; charset=windows-1252
Dear Pol,
I experienced the same issue with X300, while the same code with
set_master_clock() works fine with B210.
I worked around the issue by adding "master_clock_rate=184.32e6" to the
argument of multi_usrp::make(), which works with both X300 and B210.
Best regards,
Claudio
On 10/14/2016 09:25 AM, Pol Henarejos via USRP-users wrote:
> Dear all,
>
> I am experimenting some weird issues when I try to change the master
> clock. I wish to set the TX rate of my X300 to 15.36 Msps. So,
> previously I set the master clock to 184.32 MHz in order to obtain an
> integer decimation (184.32/15.36 = 12) but it seems that is not set
> properly. What I get from USRP X300 is the following warning:
>
> UHD Warning:
> The requested interpolation is odd; the user should expect passband
> CIC rolloff.
> Select an even interpolation to ensure that a halfband filter is
> enabled.
> interpolation = dsp_rate/samp_rate -> 13 = (200.000000
> MHz)/(15.360000 MHz)
>
> UHD Warning:
> The hardware does not support the requested TX sample rate:
> Target sample rate: 15.360000 MSps
> Actual sample rate: 15.384615 MSps
>
> I guess that the master clock is set to the default 200 MHz and not
> changed to 184.32e6.
>
> Any clue?
>
> The code is:
>
> usrp->set_master_clock(184.32e6);
> usrp->set_tx_rate(15.36e6); //Warnings are displayed here
>
> I am using the UHD version Win32; Microsoft Visual C++ version 14.0;
> Boost_106000; UHD_003.010.000.000-92-ON
>
> Thanks.
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 11
Date: Fri, 14 Oct 2016 11:13:15 +0200
From: Pol Henarejos <pol.henare...@cttc.es>
To: Claudio Cicconetti <cciccone...@mbigroup.it>,
usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Weird behaviour with set_master_clock_rate
in X300
Message-ID: <c2482dc4-ec33-7f2c-b656-5e1327709...@cttc.es>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
Dear Claudio,
Thank you! Your snippet works like a charm. This is a temporary
workaround but I guess the behvaiour should not be the described one.
Thank you again.
Pol Henarejos
Researcher, MSc
pol.henare...@cttc.es
Centre Tecnol?gic de Telecomunicacions de Catalunya (CTTC)
Av. Carl Friedrich Gauss, 7
08860 Castelldefels, Barcelona (Spain)
Tel: +34 93 645 29 00 Ext: 2177
Fax. +34 93 645 29 01
www.cttc.es
El 14/10/2016 a les 10:09, Claudio Cicconetti ha escrit:
> Dear Pol,
> I experienced the same issue with X300, while the same code with
> set_master_clock() works fine with B210.
>
> I worked around the issue by adding "master_clock_rate=184.32e6" to the
> argument of multi_usrp::make(), which works with both X300 and B210.
>
> Best regards,
> Claudio
>
> On 10/14/2016 09:25 AM, Pol Henarejos via USRP-users wrote:
>> Dear all,
>>
>> I am experimenting some weird issues when I try to change the master
>> clock. I wish to set the TX rate of my X300 to 15.36 Msps. So,
>> previously I set the master clock to 184.32 MHz in order to obtain an
>> integer decimation (184.32/15.36 = 12) but it seems that is not set
>> properly. What I get from USRP X300 is the following warning:
>>
>> UHD Warning:
>> The requested interpolation is odd; the user should expect passband
>> CIC rolloff.
>> Select an even interpolation to ensure that a halfband filter is
>> enabled.
>> interpolation = dsp_rate/samp_rate -> 13 = (200.000000
>> MHz)/(15.360000 MHz)
>>
>> UHD Warning:
>> The hardware does not support the requested TX sample rate:
>> Target sample rate: 15.360000 MSps
>> Actual sample rate: 15.384615 MSps
>>
>> I guess that the master clock is set to the default 200 MHz and not
>> changed to 184.32e6.
>>
>> Any clue?
>>
>> The code is:
>>
>> usrp->set_master_clock(184.32e6);
>> usrp->set_tx_rate(15.36e6); //Warnings are displayed here
>>
>> I am using the UHD version Win32; Microsoft Visual C++ version 14.0;
>> Boost_106000; UHD_003.010.000.000-92-ON
>>
>> Thanks.
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3741 bytes
Desc: Signatura criptogr??fica S/MIME
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161014/36037df7/attachment-0001.p7s>
------------------------------
Message: 12
Date: Fri, 14 Oct 2016 13:46:09 +0200
From: Marcus M?ller <marcus.muel...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Gain control with timed commands
Message-ID: <f68fe3f1-3bc2-ff2b-f7fc-a27232c3b...@ettus.com>
Content-Type: text/plain; charset=windows-1252
Hi Vladica,
setting gain can be done _as_ a timed command itself!
Note that timed commands are queued in order, i.e. it's a must that you
issue the timed commands ordered by their timespec.
Best regards,
Marcus
On 14.10.2016 09:01, Vladica Sark via USRP-users wrote:
> Hi,
>
> I am using N210 with timed commands for rx/tx. I send and receive
> samples in time slots. Is there a way to change the transmit and
> receive gain for each timed command, i.e. each time slot, since it is
> reserved for different user? BTW, I issue multiple timed commands at
> once, and than wait for the received data.
>
> BR,
> Vladica
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 13
Date: Fri, 14 Oct 2016 13:50:05 +0200
From: Vladica Sark <vladicas...@gmail.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Gain control with timed commands
Message-ID: <65babb9f-f5de-747b-e317-a5213e110...@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Thanks Marcus,
Would try this.
Best regards,
Vladica
On 14.10.2016 13:46, Marcus M?ller via USRP-users wrote:
> Hi Vladica,
>
> setting gain can be done _as_ a timed command itself!
>
> Note that timed commands are queued in order, i.e. it's a must that you
> issue the timed commands ordered by their timespec.
>
>
> Best regards,
> Marcus
>
> On 14.10.2016 09:01, Vladica Sark via USRP-users wrote:
>> Hi,
>>
>> I am using N210 with timed commands for rx/tx. I send and receive
>> samples in time slots. Is there a way to change the transmit and
>> receive gain for each timed command, i.e. each time slot, since it is
>> reserved for different user? BTW, I issue multiple timed commands at
>> once, and than wait for the received data.
>>
>> BR,
>> Vladica
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 14
Date: Fri, 14 Oct 2016 14:40:28 +0200
From: Marcus M?ller <marcus.muel...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] LFRX sensitivity
Message-ID: <51e22b9f-6bf0-63fa-7793-a1acfa10a...@ettus.com>
Content-Type: text/plain; charset="windows-1252"
Hi Matis,
the LFRX is really just a dual-opamp in a band-limited voltage-follower
configuration [1]. The Opamp's datasheet can be found at [2].
Which frequencies are we referring to? The gain of this active filter
depends on the center frequency, and so does the noise of the ADC and of
the opamp, though to a lesser extent.
Now, the SNR after sampling depends on the motherboard you're using the
LFRX with (USRP1,2,B100,N200/210,E100/110 or X300/310); it's also worth
noting that all the USRPs sample at a sampling rate much higher than
your signal's bandwidth, and do decimate according to your needs inside
the FPGA ? so that you get the oversampling "processing SNR gain" for free.
So, let's do a rough estimate:
The AD8132 datasheet says on p.6 Input Voltage Noise is
$8\,\frac{\si{\nano\volt}}{\sqrt{\si{\hertz}}}$ , so let's square that,
$\SI{64e-18}{\square\volt\per\hertz}$, which over the nominal
$\SI{50}{\ohm}$ is (according to P=UI and Ohm's law) means a noise power
of $N=\SI{3.2e-15}{\watt\per\hertz}\approx\SI{-115}{\dBm\per\hertz}$; so
in $\SI{3}{\kilo\hertz}\approx\SI{34.7}{\dB\hertz}$, your signal would
need to have $(-115+34.7+10)\si{\dBm} = \SI{-70.5}{\dBm}$ power.
Note that this really isn't the end of the story ? for example, assuming
you're using a N210, the ADC runs with a constant 100 MS/s, oversampling
your 3kHz signal more than thirtythousandfold. So there's a lot of
processing gain to be had. However, the ADC is a 14bit ADC with an
effective number of bits of ca. 12 ? at full sampling rate. So,
technically, the minimum differential voltage reliably detectable is
$U_\text{full scale}\cdot 2^{-12}$. On the N210, the full-scale voltage
is 1Vpp, leading to a minimum detectable voltage of 244 ?V, or a power
of $\SI{1.19}{\nano\watt}\approx\SI{-59.2}{\dBm}$ over $\SI{50}{\ohm}$,
which seems to be worse than what's technically possible. Now, dithering
to the rescue; by adding uncorrelated noise to the signal and using the
oversampling you have, anyway, a signal smaller than the minimum
quantization step can be visible; but the possibility of that depends on
your signal's correlation properties and how much noise you willingly or
inherently add, as well as that noise's amplitude PDF and autocorrelation.
Hope that gives you a start on things,
best regards,
Marcus
[1] https://files.ettus.com/schematics/lfrx/lfrx.pdf
[2]
http://www.analog.com/media/en/technical-documentation/data-sheets/AD8132.pdf
On 14.10.2016 09:41, Matis Alun via USRP-users wrote:
> Hell usrp users,
>
> I didn't find some datasheet describing the RF specifications of the LFRX
> daughterboard.
>
> Can you tell me what is the sensitivity of the LFRX board ? We can define the
> sensitivity
> in the following way:
> This is the power of a 3kHz bandwidth signal injected in the input which
> gives a 10 dB
> signal to noise ratio
> (noise is the noise level of the sampler).
>
> Thanks,
>
> matis
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> 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/20161014/45f0ca7b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 978 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161014/45f0ca7b/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 1342 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161014/45f0ca7b/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 814 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161014/45f0ca7b/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 2201 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161014/45f0ca7b/attachment-0011.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 1365 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161014/45f0ca7b/attachment-0012.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 1856 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161014/45f0ca7b/attachment-0013.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 1207 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161014/45f0ca7b/attachment-0014.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 1539 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161014/45f0ca7b/attachment-0015.png>
------------------------------
Message: 15
Date: Fri, 14 Oct 2016 13:10:52 +0000
From: "Long, Jeffrey P." <jpl...@mitre.org>
To: Nicolas Cuervo <nicolas.cue...@ettus.com>
Cc: "USRP-users@lists.ettus.com" <USRP-users@lists.ettus.com>
Subject: Re: [USRP-users] RFNOC on E312
Message-ID:
<dm5pr09mb1372a89abe92e7fc4606f00ad9...@dm5pr09mb1372.namprd09.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
Nicolas-
Thanks this is great. Just as some feedback I was not too successful with
pybombs so I just did the build from source using the toolchain and cmake. Your
idea of keeping it all contained in one directory is good and thank you for
explaining the remote mount thing. I have done things like that on other
embedded systems but its always a cryptic process. Thanks for making it easy.
A little googling seemed to say that my pybombs problem is maybe a version
issue. I am doing this work from a Ubuntu 12 machine which is starting to get
more and more out of date for many things. : )
Jeff
From: Nicolas Cuervo [mailto:nicolas.cue...@ettus.com]
Sent: Tuesday, October 11, 2016 3:17 PM
To: Long, Jeffrey P.
Cc: USRP-users@lists.ettus.com
Subject: Re: [USRP-users] RFNOC on E312
Hello Jeffrey,
We have a page in our knowledge base that approaches the procedure to set up
your development environment. You can find it here:
https://kb.ettus.com/Software_Development_on_the_E310_and_E312. You can use the
PyBOMBS recipe "e3xx-rfnoc" to set it up for RFNoC development. (This step is
included in the tutorial provided within the given link).
After you have all that set up, you can continue with RFNoC development in your
machine following this guide:
https://kb.ettus.com/Getting_Started_with_RFNoC_Development. After you have
your FPGA design ready, you just have to locate the image in the usual location
so that the device picks it up at initialization.
Let us know if this is the info that you need, or if you have more questions.
Cheers,
-Nicolas
On Tue, Oct 11, 2016 at 11:58 AM, Long, Jeffrey P. via USRP-users
<usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>> wrote:
What is the best approach to use the latest RFNOC on a E312/E310? Are there any
pre-built SD images to get you started or do you need to build everything from
scratch(FPGA image, filesystem, uhd etc..)?
>From what I can see the only RFNOC image is a fido based one that is now
>considered obsolete. If I am yocto challenged maybe start with a release 4
>image and update uhd(switch to rfnoc-devel) and get updated fpga images or
>build them?
Thanks
Jeff
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com<mailto:USRP-users@lists.ettus.com>
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/20161014/9b0186c4/attachment-0001.html>
------------------------------
Message: 16
Date: Fri, 14 Oct 2016 10:17:30 -0400
From: Andy Walls <a...@silverblocksystems.net>
To: Nicolas Cuervo <nicolas.cue...@ettus.com>
Cc: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] X310 GPIO 3.3V supply pin: what is the
recommended maximum current it can supply?
Message-ID: <1476454650.4690.2.camel@localhost>
Content-Type: text/plain; charset="UTF-8"
Hi Nicolas:
Thanks for the information.
Understood on the ESD protection intent and use at my own risk.
I was looking at it to power one side of an isolator/level-convertor
chip to isolate about ~4 of the GPIOs.
We'll check our current draws.
Regards,
Andy
On Thu, 2016-10-13 at 19:27 -0700, Nicolas Cuervo wrote:
> Hello Andy,
>
>
> We are very sorry for the late response. It appears that this email
> went through the cracks. Have you come to an answer?
>
>
> Regarding the +3.3v pin, it is not really a supply, but a clamp. This
> pin is primarily used for ESD protection, and it is not intended to
> supply high currents. You can see the configuration for this pin in
> the schematics at [1], page 14.
>
>
> Using this pin as a power source is, generally, not recommended. If it
> suits the needs of your application, it would be, lets say, at your
> own risk, as this is not the what the pin is intended to do. I would
> recommend you to have a look at the circuit that I point you out at
> the schematic, and analyze if the load that you intend to connect is
> power demanding.
>
>
> Apart from that, making a quick simulation of this configuration, the
> 3.3v pin should be able to source 5-10mA, having a droop of the output
> voltage as the current increases (~2.6V would be about right in this
> case). You could say that, as for the documentation, the "5mA"
> notation applies to this pin.
>
>
> As for the other pins, they are connected to the FPGA GPIOs. The
> reasoning would be basically the same, but as this are indeed in and
> outs, you could say that the "12mA" notation of the documentation
> apply to them. However, note that we do not recommend the driving of
> big loads through the GPIO prior a slightly more exhausting analysis
> of your load configuration.
>
>
> Cheers,
>
>
> - Nicolas
>
>
>
> [1] http://files.ettus.com/schematics/x300/x3xx.pdf
>
>
> On Tue, Sep 6, 2016 at 11:39 AM, Andy Walls via USRP-users
> <usrp-users@lists.ettus.com> wrote:
> Hi:
>
> Regarding, the X310 GPIO 3.3V supply pin: what is the
> recommended
> maximum current it can supply?
>
> The wiki pages mention the GPIO signal pins can source up to
> either 12
> mA, or 5 mA. Neither page below talks about a 3.3V supply pin
> current
> limit:
>
> https://kb.ettus.com/X300/X310_Getting_Started_Guides#GPIO_Specifications_.283.3V_Bank.2C_LVCMOS.29
> https://kb.ettus.com/X300/X310#Front_Panel_GPIO
>
> Thanks.
>
> Regards,
> Andy
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 74, Issue 14
******************************************
