Re: [USRP-users] UHD Version for New UBX Hardware Rev
Derek, Thank you very much! -David On Tue, Aug 15, 2017 at 11:03 AM, Derek Kozel <derek.ko...@ettus.com> wrote: > Hello Dave, > > This commit added the EEPROM IDs for the updated UBX version. > https://github.com/EttusResearch/uhd/commit/f5a082fd3841571d2a53a9e677b5df > e6d653bd94 > > It was added August 22nd and 3.9.5 has it. I believe there have been a few > improvement changes since then which are on the 3.9 branch, but basic > support would start from 3.9.5. > > Regards, > Derek > > On Tue, Aug 15, 2017 at 3:47 PM, Dave NotTelling via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> I got a UBX-40 that wouldn't work in my N210 and I remembered seeing >> something on the forums about the older UHD versions not working for the >> new UBX-40 rev. What is the oldest version of UHD that is guaranteed to >> work with the new UBX-40 rev? I was running 3.9.4 and when I upgraded to >> 3.9.7 things worked again. The thing that tipped me off was that the >> UBX-40 didn't show up properly in uhd_usrp_probe. >> >> Thanks! >> >> ___ >> 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] N210 DSP Processing Chain
What happens to samples between the ADC and receiving them from UHD? Also, is there any way to get the raw IQ off of the ADC itself? I feel like there isn't only because the ADC (to the best of my knowledge) runs at 100 MSPS which is too high a rate to send over the 1 Gb/s link. Thanks! ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] IQ Calibration - CPU Performance Impact?
Robin, Thanks for your feedback! Marcus, And that overhead is just on the initial tune, or for all tunes? I do mostly timed commands, so should I allow for a little more time before the deadline to send the timed command out? Thanks all! On Thu, Jun 7, 2018 at 1:56 PM Marcus D. Leech via USRP-users < usrp-users@lists.ettus.com> wrote: > On 06/07/2018 01:04 PM, Dave NotTelling via USRP-users wrote: > > Is there a processing requirement impact to using the calibration CSV > > file? Does using the cal data have any impact on tuning time for the > > radio itself? > > > > Thanks! > > > The calibration values are stuffed into some machinery in the FPGA when > tuning happens. So, there's a little extra command-channel overhead. > > > > ___ > 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
Re: [USRP-users] IQ Calibration - CPU Performance Impact?
Derek, I'm very happy to hear that it's the tiniest of additional overhead! Thanks! On Thu, Jun 7, 2018 at 2:32 PM Derek Kozel wrote: > Dave, > > It is most tunes (as often as needed when changing the frequency would > change the IQ correction value). The overhead is, I believe, just a single > write and thus completely inconsequential when compared to the usual length > of synthesizer SPI writes and switch selection that tuning can cause. > > Regards, > Derek > > On Thu, Jun 7, 2018 at 7:08 PM, Dave NotTelling via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> Robin, >> Thanks for your feedback! >> >> Marcus, >> And that overhead is just on the initial tune, or for all tunes? I >> do mostly timed commands, so should I allow for a little more time before >> the deadline to send the timed command out? >> >> Thanks all! >> >> On Thu, Jun 7, 2018 at 1:56 PM Marcus D. Leech via USRP-users < >> usrp-users@lists.ettus.com> wrote: >> >>> On 06/07/2018 01:04 PM, Dave NotTelling via USRP-users wrote: >>> > Is there a processing requirement impact to using the calibration CSV >>> > file? Does using the cal data have any impact on tuning time for the >>> > radio itself? >>> > >>> > Thanks! >>> > >>> The calibration values are stuffed into some machinery in the FPGA when >>> tuning happens. So, there's a little extra command-channel overhead. >>> >>> >>> >>> ___ >>> 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
Re: [USRP-users] IQ Calibration - CPU Performance Impact?
Ian, Thank you very much! That helps me out a lot! -Dave On Thu, Jun 7, 2018 at 2:17 PM Ian Buckley wrote: > Dave, from what I remember the overhead will be incurred each time a > (re)tune takes you to a different line of the IQ imbalance table…you can > see the granularity of that from simply looking in the CSV file. > The overhead is very minor I suspect, we are talking about updating two > integer coefficients (phase and mag correction) in setting regs for each TX > and RX port. > -Ian > > On Jun 7, 2018, at 11:08 AM, Dave NotTelling via USRP-users < > usrp-users@lists.ettus.com> wrote: > > Robin, > Thanks for your feedback! > > Marcus, > And that overhead is just on the initial tune, or for all tunes? I > do mostly timed commands, so should I allow for a little more time before > the deadline to send the timed command out? > > Thanks all! > > On Thu, Jun 7, 2018 at 1:56 PM Marcus D. Leech via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> On 06/07/2018 01:04 PM, Dave NotTelling via USRP-users wrote: >> > Is there a processing requirement impact to using the calibration CSV >> > file? Does using the cal data have any impact on tuning time for the >> > radio itself? >> > >> > Thanks! >> > >> The calibration values are stuffed into some machinery in the FPGA when >> tuning happens. So, there's a little extra command-channel overhead. >> >> >> >> ___ >> 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
Re: [USRP-users] UHD Version >= 3.10 Experimental?
Martin, I tried the following: cd /tmp git clone https://www.github.com/EttusResearch/uhd cd uhd git checkout release_003_010_001_001 cd host mkdir build cd build cmake .. And I get the same experimental warning at the end. I did notice that this message gets printed out fairly early on: -- Working off of feature or development branch. Updating version number. -- Using UHD Images Directory: OFF -- Build type not specified: defaulting to release. I assume that is happening because `git rev-parse --abbrev-ref HEAD` is returning `HEAD` as opposed to something like `UHD-3.9.LTS` for the UHD-3.9.LTS branch. In case it matters, I am running git version 2.17.0. Am I just doing the checkout wrong? Anywho, long story short, it sounds like I can trust that anything with a release_* tag is stable code. Thank you! -Dave On Thu, May 3, 2018 at 4:19 PM, Dave NotTelling <dmp250...@gmail.com> wrote: > Martin, > > Ron is correct, it's a warning at the end. I hadn't considered the > CMake cache. I'll give that another go later. > > Thank you both! > > -Dave > > On Wed, May 2, 2018 at 7:59 PM, Ron Economos via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> It looks like this near the end of cmake. Not an error. >> >> -- ## >> -- # UHD disabled components >> -- ## >> -- * GPSD >> -- * E100 >> -- * E300 >> -- >> -- ** >> -- * You are building a development branch of UHD. >> -- * These branches are designed to provide early access >> -- * to UHD and USRP features, but should be considered >> -- * unstable and/or experimental! >> -- ** >> -- Building version: 003.010.003.HEAD-0-gef157678 >> >> Ron >> >> >> On 05/02/2018 04:51 PM, Martin Braun via USRP-users wrote: >> >>> On 05/02/2018 11:04 AM, Dave NotTelling via USRP-users wrote: >>> >>>> Are versions >= 3.10 still considered experimental? I thought that any >>>> version with a release_XXX_XXX_XXX was considered stable. When I run >>>> cmake ../ on any version 3.10 or higher it warns me that I am on a >>>> development branch. >>>> >>> Our current maint versions are 3.11.*. >>> >>> 3.12.* is currently not released as a tagged version, so consider that >>> 'unstable'. I would not like to call them 'experimental', though. When >>> we put stuff into master branch, we have some confidence it's good. >>> However, we do occasionally slip up on testing there, and also, we have >>> no guarantee with regards to API stability on master. >>> >>> I'm not sure why you're seeing that CMake error, though. Maybe it's a >>> caching artefact? What exactly are you compiling? >>> >>> -- M >>> >>> >> ___ >> 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
Re: [USRP-users] UHD Version >= 3.10 Experimental?
Oh, and here is the relevant code from GitHub: https://github.com/EttusResearch/uhd/blob/release_003_010_001_001/host/cmake/Modules/UHDVersion.cmake#L63 On Thu, May 3, 2018 at 4:46 PM, Dave NotTelling <dmp250...@gmail.com> wrote: > Martin, > > I tried the following: > > cd /tmp > git clone https://www.github.com/EttusResearch/uhd > cd uhd > git checkout release_003_010_001_001 > cd host > mkdir build > cd build > cmake .. > > And I get the same experimental warning at the end. I did notice > that this message gets printed out fairly early on: > > > -- Working off of feature or development branch. Updating > version number. > -- Using UHD Images Directory: OFF > -- Build type not specified: defaulting to release. > > > I assume that is happening because `git rev-parse --abbrev-ref HEAD` > is returning `HEAD` as opposed to something like `UHD-3.9.LTS` for the > UHD-3.9.LTS branch. In case it matters, I am running git version 2.17.0. > Am I just doing the checkout wrong? > > > Anywho, long story short, it sounds like I can trust that anything > with a release_* tag is stable code. > > > Thank you! > > > -Dave > > On Thu, May 3, 2018 at 4:19 PM, Dave NotTelling <dmp250...@gmail.com> > wrote: > >> Martin, >> >> Ron is correct, it's a warning at the end. I hadn't considered the >> CMake cache. I'll give that another go later. >> >> Thank you both! >> >> -Dave >> >> On Wed, May 2, 2018 at 7:59 PM, Ron Economos via USRP-users < >> usrp-users@lists.ettus.com> wrote: >> >>> It looks like this near the end of cmake. Not an error. >>> >>> -- ## >>> -- # UHD disabled components >>> -- ## >>> -- * GPSD >>> -- * E100 >>> -- * E300 >>> -- >>> -- ** >>> -- * You are building a development branch of UHD. >>> -- * These branches are designed to provide early access >>> -- * to UHD and USRP features, but should be considered >>> -- * unstable and/or experimental! >>> -- ** >>> -- Building version: 003.010.003.HEAD-0-gef157678 >>> >>> Ron >>> >>> >>> On 05/02/2018 04:51 PM, Martin Braun via USRP-users wrote: >>> >>>> On 05/02/2018 11:04 AM, Dave NotTelling via USRP-users wrote: >>>> >>>>> Are versions >= 3.10 still considered experimental? I thought that any >>>>> version with a release_XXX_XXX_XXX was considered stable. When I run >>>>> cmake ../ on any version 3.10 or higher it warns me that I am on a >>>>> development branch. >>>>> >>>> Our current maint versions are 3.11.*. >>>> >>>> 3.12.* is currently not released as a tagged version, so consider that >>>> 'unstable'. I would not like to call them 'experimental', though. When >>>> we put stuff into master branch, we have some confidence it's good. >>>> However, we do occasionally slip up on testing there, and also, we have >>>> no guarantee with regards to API stability on master. >>>> >>>> I'm not sure why you're seeing that CMake error, though. Maybe it's a >>>> caching artefact? What exactly are you compiling? >>>> >>>> -- M >>>> >>>> >>> ___ >>> 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
Re: [USRP-users] UHD Version >= 3.10 Experimental?
Martin, Ron is correct, it's a warning at the end. I hadn't considered the CMake cache. I'll give that another go later. Thank you both! -Dave On Wed, May 2, 2018 at 7:59 PM, Ron Economos via USRP-users < usrp-users@lists.ettus.com> wrote: > It looks like this near the end of cmake. Not an error. > > -- ## > -- # UHD disabled components > -- ## > -- * GPSD > -- * E100 > -- * E300 > -- > -- ** > -- * You are building a development branch of UHD. > -- * These branches are designed to provide early access > -- * to UHD and USRP features, but should be considered > -- * unstable and/or experimental! > -- ** > -- Building version: 003.010.003.HEAD-0-gef157678 > > Ron > > > On 05/02/2018 04:51 PM, Martin Braun via USRP-users wrote: > >> On 05/02/2018 11:04 AM, Dave NotTelling via USRP-users wrote: >> >>> Are versions >= 3.10 still considered experimental? I thought that any >>> version with a release_XXX_XXX_XXX was considered stable. When I run >>> cmake ../ on any version 3.10 or higher it warns me that I am on a >>> development branch. >>> >> Our current maint versions are 3.11.*. >> >> 3.12.* is currently not released as a tagged version, so consider that >> 'unstable'. I would not like to call them 'experimental', though. When >> we put stuff into master branch, we have some confidence it's good. >> However, we do occasionally slip up on testing there, and also, we have >> no guarantee with regards to API stability on master. >> >> I'm not sure why you're seeing that CMake error, though. Maybe it's a >> caching artefact? What exactly are you compiling? >> >> -- M >> >> > ___ > 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
Re: [USRP-users] B2x0 Timed Commands
Ooh, I forgot about the FPGA vs analog side. Thanks gents! On Sat, Feb 17, 2018 at 11:10 AM, Marcus Müller via USRP-users < usrp-users@lists.ettus.com> wrote: > To expand on that: timed commands do exist for all things that the FPGA > can control – that is: start/stop of sampling, DSP offset tuning, > antenna switching, GPIOs etc. > They do not work for anything that happens on the AD9361 (analog > tuning, gain control,…), because that thing itself isn't controllable > essentially by FPGA IOs like the tuners etc on let's say a WBX, but via > a (complex) serial protocol. > > Best regards, > Marcus the younger > > On Sat, 2018-02-17 at 10:07 -0500, Marcus D. Leech via USRP-users > wrote: > > On 02/17/2018 09:59 AM, Dave NotTelling via USRP-users wrote: > > > I recall that the B2x0 series do not support timed commands like > > > the > > > N2x0 or the X3x0 series. While looking through the source code I > > > ran > > > across some code that shows the "time/cmd" entry in the tree being > > > set > > > [1]. That key seems to be what multi_usrp uses to set timed > > > commands > > > [2]. I then went to the KB [3] and saw that the B2x0 series is > > > listed > > > as having timed commands on the FPGA just like the N2x0 > > > series. So, > > > does this mean that the B2x0 radios do now support timed commands? > > > > > > Thanks! > > > > > > -Dave > > > > > > > They support timed commands, except that timed tuning doesn't work > > the > > way it does for N3xx or X3xx with boards like WBX and SBX -- there's > > no > >phase-resynch feature. > > > > > > > > > > ___ > > 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
Re: [USRP-users] X3x0 Signal Delay Repeater @ 100 MSPS
Nicolas, Do you think that the timing to go radio->host->delay->radio is going to be deterministic? I feared that it would be really jittery. Thanks!! -Dave On Fri, Dec 22, 2017 at 9:22 AM, Nicolas Cuervo <nicolas.cue...@ettus.com> wrote: > Hi Dave, > > there is a delay fifo > <https://github.com/EttusResearch/fpga/blob/rfnoc-devel/usrp3/lib/rfnoc/delay_fifo.v> > module that you could pack in a custom FPGA image, but I think that you > want to avoid re-synth. However, this rate might be too high to go around > an FPGA modification. If you can uphold 100MSPS in the host, then In UHD > there is no already coded delay, but you could set it up producing a series > of zeros before your signal at the host, just as the GNU Radio delay block > is doing it (or use the GNU Radio delay block > <https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/lib/delay_impl.cc> > ) > > -N > > On Thu, Dec 21, 2017 at 1:50 PM, Dave NotTelling via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> Are there any pre-made modules or baked in ability to UHD/RFNOC that will >> allow me to delay an entire 100 MSPS feed by up to single digit >> milliseconds and then re-transmit? I imagine it could be done with a >> custom FPGA image, but I'm hoping for an easy win. >> >> Thanks! >> >> ___ >> 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] X3x0 Signal Delay Repeater @ 100 MSPS
Are there any pre-made modules or baked in ability to UHD/RFNOC that will allow me to delay an entire 100 MSPS feed by up to single digit milliseconds and then re-transmit? I imagine it could be done with a custom FPGA image, but I'm hoping for an easy win. Thanks! ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] RFNOC Radio Loopback
I seem to recall that you can't actually do a loopback like that in RFNoC. I think you have to send samples to the host at some point. A quick Google search came up with [1]. I'd be really interested if there were a way to do a HW only loopback with RFNoC natively. [1] https://corvid.io/2017/04/22/stupid-rfnoc-tricks-loopback/ On Mon, Jul 9, 2018 at 4:21 PM Weihan Chen via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi, > > I'm new to RFNOC development. I have an X310 with an SBX on slot A, and I > want to do a loopback from antenna port RX2 to TX/RX using RFNOC blocks. I > tried connecting 0/Radio_0 ==> 0/DDC_0 ==> 0/DUC_0 ==> 0/Radio_0 by the > following commands: > > rx_graph->connect(radio_ctrl->get_block_id(), ddc_ctrl->get_block_id()); > rx_graph->connect(ddc_ctrl->get_block_id(), > duc > _ctrl->get_block_id()); > rx_graph->connect(duc_ctrl->get_block_id(), radio_ctrl->get_block_id()); > > and UHD gives me Error: RuntimeError: On node 0/Radio_0, output port 0 is > already connected. > > What am I doing wrong here? Please help. > > Regards, > Alex > ___ > 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
Re: [USRP-users] Bottleneck for high sampling rate?
You can try things like perf, performance counters in gnu radio, and top -H (shows CPU usage of individual threads). For my personal debugging I made a block that simply counts how many samples it has received in the work() call and every X seconds outputs the average number of samples it has seen in that time period (samples per second). I then use this block in offline testing (doesn't really work well with devices in line) of each block (maybe providing the block with a null source of data) and see what the max throughput of each block is (no throttle block!!). In the event that the max throughput is lower than the rate of samples coming into that block for the real world then I know that I need to make that block better or split the functionality into multiple blocks. Here is another post with perf: http://lists.gnu.org/archive/html/discuss-gnuradio/2017-10/msg00239.html On Wed, Jan 17, 2018 at 3:20 PM, Marcus D. Leech via USRP-users < usrp-users@lists.ettus.com> wrote: > On 01/17/2018 01:53 PM, Bakshi, Arjun via USRP-users wrote: > > Not sure where to ask this but, if I had a setup where I had ~10 complex32 > streams (TX+RX) all running at 10Msps, where would the bottlenecks lie? I'd > like to know this for a system upgrade. > > > The network interface for sure. 1Gbps ethernet won't be sufficient, but > whats a good upgrade? 10Gbps? > > > Similarly, how do I compute the requirements for the CPU or RAM? > > > I don't think doing simulations where I have 10 streams throttled at > 10Msps in GRC will give me a good estimate of these things. > > > Thank you, > > > AB > > > > > ___ > USRP-users mailing > listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > It really, REALLY, matters what you're doing with the samples streams. > There are no general guidelines other than the compute load is roughly > approximated as: > > sample-rate * inherent-complexity-per-sample > > > > > ___ > 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
Re: [USRP-users] N310 Questions
Robin, Thank you very much for the explanations! -Dave On Tue, Mar 6, 2018 at 3:26 PM, Robin Coxe <robin.c...@ettus.com> wrote: > Hi Dave. The official product announcement of the USRP N310 was just > posted today. The N310 is now orderable! > > On Mon, Mar 5, 2018 at 2:11 PM, Dave NotTelling via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> Just saw that the N310 is officially on the ettus.com website. Curious >> about the following: >> >>- The product pages says that it's not for fast tuning. Should I >>expect roughly the same tuning times as the B2x0 radios? >> >> Currently, the tuning times are actually a bit slower than the B200/E310 > (~140 ms) because the frequency is adjusted via SW SPI commands to the > AD9371 transceiver. A future performance enhancement will be to implement > frequency tunes via GPIO lines from the FPGA. The AD9371 was not designed > for fast frequency hopping. The AD9371 has an embedded ARM Cortex-M0 > processor that orchestrates an on-chip quadrature error correction (i.e., > I/Q imbalance calibration) that takes an appreciable amount of time to > converge. The fastest that the device will be ever be capable of tuning > without disabling this calibration is ~2 ms. > > >> >>- At the bottom of the page there is a note about only being able to >>tune 2 LOs independently. Does this mean that even though there are 4 RX >>paths, you can only look on 2 large bands at the same time (assuming all >>the bands you want are > 200 MHz apart)? >> >> The N310 has two daughterboards, each of which have an AD9371. The > AD9371 has 2 Tx and 2 Rx channels per chip. The 2 Tx and 2 Rx channels > each share an LO, so you can tune each daughtercard's transmitters and > receivers independently, but not all 4 transmitters and receivers > independently.For additional details, take a look at the AD9371 product > page: http://www.analog.com/en/products/rf-microwave/integ > rated-transceivers-transmitters-receivers/wideband-transceiv > ers-ic/ad9371.html > >> >>- Are timed commands supported the way they are for the N and X >>series? I don't mean the limited timed command support that the B series >>radios have. >> >> Timed commands do exist for the N310, however there is a subtlety here. > Any interactions with AD9371 transceiver are not currently supported via > timed commands. Future support is possible, but with accuracy in the > millisecond range. > >> >>- If so, is there just one command FIFO like in the N and X series? >> >> >> Correct. > > > -Robin > > > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] N310 Questions
Just saw that the N310 is officially on the ettus.com website. Curious about the following: - The product pages says that it's not for fast tuning. Should I expect roughly the same tuning times as the B2x0 radios? - At the bottom of the page there is a note about only being able to tune 2 LOs independently. Does this mean that even though there are 4 RX paths, you can only look on 2 large bands at the same time (assuming all the bands you want are > 200 MHz apart)? - Are timed commands supported the way they are for the N and X series? I don't mean the limited timed command support that the B series radios have. - If so, is there just one command FIFO like in the N and X series? Thanks! -Dave ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] OctoClock Without GPS Signal
Can the GPSDO OctoClock free run without GPS? I've had some PPS generators that claim to have the ability to free run, but require a GPS signal to start that process up. Thanks! -Dave ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] OctoClock Without GPS Signal
Thank you very much! On Thu, Nov 15, 2018, 18:07 Marcus D. Leech via USRP-users < usrp-users@lists.ettus.com wrote: > On 11/15/2018 11:52 AM, Dave NotTelling via USRP-users wrote: > > Can the GPSDO OctoClock free run without GPS? I've had some PPS > > generators that claim to have the ability to free run, but require a > > GPS signal to start that process up. > > > > Thanks! > > > > -Dave > > > > > IF you have an Octoclock without the built-in GPSDO module, then it > *requires* external 1PPS and 10Mhz inputs--it's JUST a distributor. >But if you have the -G, with the built-in GPSDO, I believe that it > will produce 1PPS and 10Mhz outputs in a "free running" mode until it >gets lock. > > > > ___ > 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
Re: [USRP-users] Can't detect usrp in VMWare Player
Check out http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-October/026733.html for some ideas to try. On Wed, Oct 3, 2018 at 5:53 AM dapodun nudopad via USRP-users < usrp-users@lists.ettus.com> wrote: > I run ubuntu on VMWare Workstation Player 15 in a windows 10 host. However > i connected usrp to the port using a gigabit ethernet cable and i can't > ping nor find the uh using uhd_find_device. Does anyone has a solution to > this matter. > thanks. > ___ > 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
Re: [USRP-users] PCI-e bandwidth on X310
Chintan, I have tried both about 1.5 years ago and found that (at least in my use case) the NI drivers for the PCIe card in Linux were effectively single threaded. This is a major issue if you are working on a many core system with a lower clock rate while trying to receive really high rates (> 100 MSPS). I can stream at higher rates using 10 Gb/s copper than I can with the PCIe interface with the same processor. This is on an approx 3.2 GHz Intel Xeon processor. I'd probably be better off with something with fewer cores and a higher clock, but I need the cores. If you don't need the latency of PCIe, then (at least in my opinion) it's better to buy something like the Intel X710 dual port 10 Gb/s NIC. It's usable in more scenarios (it's just a normal NIC after all), and has drivers that are incredibly mature for almost any system. One assumption I have made that could very well be wrong: I feel like the drivers for NICs (especially from a vendor like Intel) are going to be more mature and bullet proof than the NI PCIe driver. They are massively more common and tested in the field and are (AFAIK) more configurable. On Wed, Sep 19, 2018 at 11:56 AM Marcus D. Leech via USRP-users < usrp-users@lists.ettus.com> wrote: > On 09/19/2018 09:45 AM, Chintan Patel via USRP-users wrote: > > Hi, > > > > What is a realistic achievable capacity on the PCI-e(x4) link on the > > X310? The NI PXI brochure claims a 832MBytes/s rate, but not sure what > > has been achieved in practice. Trying to figure out how what sample > > rate will be supported for a 4-channel RX radio configuration. > > > > Thanks > > Chintan > > > > > It depends, as always, on exactly what you're doing with the samples > once you get them, and the capabilities of the CPU. > > The PCI-e doesn't necessarily offer higher bandwidth than the 1GiGe > interface, just lower latency. > > > > > ___ > 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
Re: [USRP-users] X310 Dual 10 Gb/s Link Detection Issue
Ian, I forgot to mention that I did test to see if the cable was at fault. I swapped the cables and still only got a link on port 1. Using either cable to either port on the NIC from port 0 on the radio results in no link for several minutes. The light on the radio port immediately comes on and blinks, but the X710 doesn't seem to think there is a link. Thankfully I have another X310 kicking around and was able to verify that both SFP+ ports work immediately with it. Perhaps something is wrong with the first X310? I've tried flashing it with both the onboard JTAG (USB-B connector up front) and the normal uhd_image_loader utility, so I don't think it's a misconfiguration issue on the radio firmware. Is there a way to flush the EEPROM without bricking the radio? Thanks! -Dave On Mon, Nov 26, 2018 at 11:13 PM Ian Buckley wrote: > Dave, > I can’t speak to anything that might be happening because of recent code > changes, but I would recommend you doing a quick switch of the cables/ports > to see if the problem follows the cable/SFP/Port jut in case it’s a > coincidence that you did the firmware update at that time. I’ve had > problems with those passive Twin-Ax cables being quirky occasionally, and > there were some cheap brands we could never get to work when I originally > qualified various SFP’s and Cables. > > It’s hard to imagine a firmware problem causing a long delay like this at > the physical level, the link negotiation is a largely automatic process > between both ends. > > -Ian > > > On Nov 26, 2018, at 3:17 PM, Dave NotTelling via USRP-users < > usrp-users@lists.ettus.com> wrote: > > I have been messing with the XG image for my X310 and have run into a > strange issue. First, here is the system setup: > >- Intel X710 dual 10 Gb/s SFP+ NIC >- 2x SFP+ direct attach copper cables >- X310 (revision 4) >- 2x UBX-160 (both v1 boards) >- UHD_3.13.1.HEAD-0-ga0a71d10 >- Ubuntu 16.04 > > When I updated the firmware of the radio I noted that port 0 was not > showing up as having a link (per ethtool). I changed UHD versions several > times and flashed the radio after each version change. At some point I > walked away for ~ 15 minutes, and when I came back the link was established > and uhd_find_devices was happy. I rebooted and was able to repeat this > process several times. It seems that it takes ~ 10-20 minutes for the link > to show as active in Linux. The radio shows lights on both port 0 and 1, > but only port 1 comes up right away on the NIC. > > Any ideas as to why this is happening? It's a real bummer because while > testing my current code, it's easy to get the radio into a bad state that > requires restarting it. Then I get to wait for the link to come up. > > Thanks! > > -Dave > ___ > 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
Re: [USRP-users] X310 Dual 10 Gb/s Link Detection Issue
Ian, I take that back. I didn't realize the other X310 was on the HG image. Once I updated it to the XG image port 0 stopped working properly. No matter what combination of cable arrangements I use, port 0 just does not want to come up even on the spare X310. I don't have another system that I can test on at the moment, but I see that as the next step to troubleshooting. Is there a known gold standard version that you've had success using the XG image with? Thanks! -Dave On Tue, Nov 27, 2018 at 8:47 AM Dave NotTelling wrote: > Ian, > > I forgot to mention that I did test to see if the cable was at > fault. I swapped the cables and still only got a link on port 1. Using > either cable to either port on the NIC from port 0 on the radio results in > no link for several minutes. The light on the radio port immediately comes > on and blinks, but the X710 doesn't seem to think there is a link. > > Thankfully I have another X310 kicking around and was able to verify > that both SFP+ ports work immediately with it. Perhaps something is wrong > with the first X310? I've tried flashing it with both the onboard JTAG > (USB-B connector up front) and the normal uhd_image_loader utility, so I > don't think it's a misconfiguration issue on the radio firmware. Is there > a way to flush the EEPROM without bricking the radio? > > Thanks! > > -Dave > > On Mon, Nov 26, 2018 at 11:13 PM Ian Buckley wrote: > >> Dave, >> I can’t speak to anything that might be happening because of recent code >> changes, but I would recommend you doing a quick switch of the cables/ports >> to see if the problem follows the cable/SFP/Port jut in case it’s a >> coincidence that you did the firmware update at that time. I’ve had >> problems with those passive Twin-Ax cables being quirky occasionally, and >> there were some cheap brands we could never get to work when I originally >> qualified various SFP’s and Cables. >> >> It’s hard to imagine a firmware problem causing a long delay like this at >> the physical level, the link negotiation is a largely automatic process >> between both ends. >> >> -Ian >> >> >> On Nov 26, 2018, at 3:17 PM, Dave NotTelling via USRP-users < >> usrp-users@lists.ettus.com> wrote: >> >> I have been messing with the XG image for my X310 and have run into a >> strange issue. First, here is the system setup: >> >>- Intel X710 dual 10 Gb/s SFP+ NIC >>- 2x SFP+ direct attach copper cables >>- X310 (revision 4) >>- 2x UBX-160 (both v1 boards) >>- UHD_3.13.1.HEAD-0-ga0a71d10 >>- Ubuntu 16.04 >> >> When I updated the firmware of the radio I noted that port 0 was not >> showing up as having a link (per ethtool). I changed UHD versions several >> times and flashed the radio after each version change. At some point I >> walked away for ~ 15 minutes, and when I came back the link was established >> and uhd_find_devices was happy. I rebooted and was able to repeat this >> process several times. It seems that it takes ~ 10-20 minutes for the link >> to show as active in Linux. The radio shows lights on both port 0 and 1, >> but only port 1 comes up right away on the NIC. >> >> Any ideas as to why this is happening? It's a real bummer because while >> testing my current code, it's easy to get the radio into a bad state that >> requires restarting it. Then I get to wait for the link to come up. >> >> Thanks! >> >> -Dave >> ___ >> 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] X310 Dual 10 Gb/s Link Detection Issue
I have been messing with the XG image for my X310 and have run into a strange issue. First, here is the system setup: - Intel X710 dual 10 Gb/s SFP+ NIC - 2x SFP+ direct attach copper cables - X310 (revision 4) - 2x UBX-160 (both v1 boards) - UHD_3.13.1.HEAD-0-ga0a71d10 - Ubuntu 16.04 When I updated the firmware of the radio I noted that port 0 was not showing up as having a link (per ethtool). I changed UHD versions several times and flashed the radio after each version change. At some point I walked away for ~ 15 minutes, and when I came back the link was established and uhd_find_devices was happy. I rebooted and was able to repeat this process several times. It seems that it takes ~ 10-20 minutes for the link to show as active in Linux. The radio shows lights on both port 0 and 1, but only port 1 comes up right away on the NIC. Any ideas as to why this is happening? It's a real bummer because while testing my current code, it's easy to get the radio into a bad state that requires restarting it. Then I get to wait for the link to come up. Thanks! -Dave ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] TX Calibration Interpolation
Marcus, Outstanding! Thank you! -Dave On Mon, Apr 1, 2019 at 6:07 PM Marcus D. Leech via USRP-users < usrp-users@lists.ettus.com> wrote: > On 04/01/2019 04:34 PM, Dave NotTelling via USRP-users wrote: > > Assume that I run IQ calibration for frequencies 100 MHz and 102 MHz, > > but then transmit on 101 MHz. Does the radio do any interpolation to > > figure out the most likely calibration information to apply for 101 > > MHz, or do I get no calibration at all? Also, does the same answer > > apply to DC offset calibration? > > > > This is for an N210 with a UBX-40. > > > > Thank you! > > > > -Dave > > > > > There is interpolation in the way UHD manages calibration information. > > > > > ___ > 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
Re: [USRP-users] Daughtercard Serial Number to Hardware Version
I forgot to mention that I had talked with Michael West a while back and been given this idea: $ /usr/local/lib/uhd/utils/usrp_burn_db_eeprom --unit TX --rev --args addr=192.168.10.2 [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_3.13.1.HEAD-0-ga0a71d10 [INFO] [USRP2] Opening a USRP2/N-Series device... [INFO] [USRP2] Current recv frame size: 1472 bytes [INFO] [USRP2] Current send frame size: 1472 bytes [WARNING] [UHD] Unable to set the thread priority. Performance may be negatively affected. Please see the general application notes in the manual for instructions. EnvironmentError: OSError: error in pthread_setschedparam Reading TX EEPROM on A dboard... Current ID: UBX-40 v1 (0x0077) Current serial: "XX" Error: bad lexical cast: source type value could not be interpreted as target But it will error out in most cases with the lexical cast error. On Mon, Apr 1, 2019 at 5:09 PM Dave NotTelling wrote: > Is there a way to get the hardware revision of a daughtercard > (specifically the UBX-40) from the serial number? Perhaps the serial > numbers for HW Rev A ended with serial number kind of thing? The API > to retrieve the hardware revision doesn't tend to work with most N210 w/ > UBX-40 setups that I have used, and it would be very helpful to be able to > get that information without having to take the card out. > > I can run uhd_usrp_probe and see "ID: UBX-40 v1" but the hardware rev is B > according to the sticker on the daughtercard. > > Thanks! > > -Dave > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] TX Calibration Interpolation
Assume that I run IQ calibration for frequencies 100 MHz and 102 MHz, but then transmit on 101 MHz. Does the radio do any interpolation to figure out the most likely calibration information to apply for 101 MHz, or do I get no calibration at all? Also, does the same answer apply to DC offset calibration? This is for an N210 with a UBX-40. Thank you! -Dave ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] Daughtercard Serial Number to Hardware Version
Is there a way to get the hardware revision of a daughtercard (specifically the UBX-40) from the serial number? Perhaps the serial numbers for HW Rev A ended with serial number kind of thing? The API to retrieve the hardware revision doesn't tend to work with most N210 w/ UBX-40 setups that I have used, and it would be very helpful to be able to get that information without having to take the card out. I can run uhd_usrp_probe and see "ID: UBX-40 v1" but the hardware rev is B according to the sticker on the daughtercard. Thanks! -Dave ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
