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 ******************************************