[USRP-users] UHD 4.0 RFNoC migration questions

Just had a few q's regarding RFNoC in UHD 4.0 as I migrate my applications to it. 1. In the style of a tedious conference Q session, this is more of a comment than a question: I noticed NoCScript is dead: great! But it sure would be nice if there were something which filled the role of

Re: [USRP-users] RFNoC: How can I use the GPS time?

Maybe if you provide a more detailed description of what you're trying to accomplish, we can help direct you toward a path to get there. Do you just want to get a timestamp into your UHD application? Do you require a timestamp for the custom logic in your RFNoC block on the FPGA? On Mon, Nov 16,

Re: [USRP-users] X310 RFNoC Basic Transmit Signal Source Flowgraph Not Working

RFNoC Radio runs at a constant 200Msps. Use DUC parameters: input rate 1Msps, output rate 200Msps. Use Radio parameter: Sampling Rate 200Msps. I don't know why you're getting a gain error. What daughterboard are you using? In addition, you probably don't need the DMA FIFO for this FG. Nick On

Re: [USRP-users] Precise Time Synchronization In B200/N210

The change in time of arrival with B200s is due to phase ambiguity. Do you have a 10MHz reference shared between your devices as well? Don't know why N210 has that off-by-one timestamp. I'm guessing that there's an extra flop in the logic for the PPS timing chain somewhere -- as in, the clock

Re: [USRP-users] How to debug timed commands on FPGA side?

I agree that Gnuradio sometimes introduces unpredictable and non-reproducible latencies, which can be especially problematic when dealing with timing-sensitive hardware close to the metal. Setting UHD buffer size is one thing, but Gnuradio can hang onto data in sometimes opaque ways, with

Re: [USRP-users] RFNoC Build Error? Or Something Else?

You're using the wrong version of Vivado. You need to use Vivado 2017.4. On Mon, Mar 16, 2020 at 12:38 PM Jeff S via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi, All. > > I am trying to start down the path of RFNoC development, and I am > following the steps outlined on the following

Re: [USRP-users] Can underflows in any way be bad for hardware in the long term?

Nothing in the USRP will be damaged. It's up to you to ensure that your subsequent RF chain will handle it. There are a few, rare configurations which come to mind where it would be a Bad Thing to suddenly pulse power on a millisecond timescale with extremely high bandwidth. 1. Using your USRP

Re: [USRP-users] Device Recovery N210: JTAG programmer

Sumit, Any JTAG programmer which is compatible with Xilinx iMPACT should work fine. I can recommend the solutions from Digilent (HS2, HS3) or Xilinx (Platform USB II). Nick On Fri, Feb 28, 2020 at 2:19 AM Sumit Kumar via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi, > I have 3 bricked

[USRP-users] Block parameters in NOC block testbenches

Hi all, I'm wondering if there's any good way to instantiate blocks in testbenches with testbench-defined block parameters. The macro `RFNOC_ADD_BLOCK takes care of defining all the NOC bus interfaces, but there's no place to define block parameters. Say I have a NOC block which takes a

Re: [USRP-users] Vivado IP locked issue

/home/kossler/nd_overhaul/uhd_nd/rfnoc/testbenches/noc_block_txarb_tb/build-ip/ Wipe that whole directory and try it again. If you want to be selective and save some time you can wipe only the axi_mem_64k directory. On Thu, Feb 20, 2020 at 6:13 PM Rob Kossler via USRP-users <

Re: [USRP-users] noc_block_addsub_tb.sv - number of samples/packets.

The NOC bus is 64 bits wide. This means each item in the testbench data array is 2 samples {16i, 16q, 16i, 16q}. The testbench is failing because you're reading past the end of the input data array. On Sat, Feb 8, 2020 at 5:04 AM Andrew Payne via USRP-users < usrp-users@lists.ettus.com> wrote: >

Re: [USRP-users] USRP filter delay

You will also have latency introduced by the ADCs themselves, as well as baseband analog filters if applicable. If you need very accurate calibration of arrival time, it is best to generate an accurately timed calibration signal using a GPS reference. You could continue to use your TX/RX loopback

Re: [USRP-users] Receiving IO Block Error when Using RFNoC Split Stream

I also haven't tested to see if this is a gr-ettus limitation or a UHD limitation. On Thu, Nov 14, 2019 at 3:04 PM Nick Foster wrote: > You can't have heterogenous output destinations on RFNoC blocks -- i.e., > you can't send one output to the host and one output to another RFNoC block. > > I'm

Re: [USRP-users] Receiving IO Block Error when Using RFNoC Split Stream

You can't have heterogenous output destinations on RFNoC blocks -- i.e., you can't send one output to the host and one output to another RFNoC block. I'm not sure why this limitation exists as there is no architectural reason I can see. Nick On Thu, Nov 14, 2019 at 12:35 PM Jonathan Lockhart

Re: [USRP-users] Receiving IO Block Error when Using RFNoC Split Stream

Can you be more specific about what your flowgraph looks like? On Thu, Nov 7, 2019 at 2:22 PM Jonathan Lockhart via USRP-users < usrp-users@lists.ettus.com> wrote: > Greetings, > > I was wondering if anyone had encountered the following error and had a > way to fix it? > > [INFO] [UHD] linux;

Re: [USRP-users] Controlling an X310 from embedded devices

You should have no trouble running UHD on an ARM architecture. The Ettus E300 series radios are ARM devices. UHD does a huge amount of initialization and configuration for the X310, and in any case the X310 doesn't use VRT in any real capacity. You won't realistically be able to divorce the X310

Re: [USRP-users] Addsub HLS Block Error

Yes, I've used it, no custom block controller required. Attached are XML and GRC descriptors. On Sat, Sep 7, 2019 at 11:22 AM d.des wrote: > I wonder if you have successfully used this block with grc or if you > were just using it with uhd. When I try to use the 2-input, 1-output > block in grc

Re: [USRP-users] Addsub HLS Block Error

Here's a modified add-only block. You'll have to make a matching .xml descriptor and GRC block (if you're using gr-ettus). Probably it would be a super useful thing to have an add/sub block, instead of an addsub block. A register-controlled mux to select which operation you want. I'll think about

Re: [USRP-users] Addsub HLS Block Error

That shouldn't be. Even if you connect both outputs to the host? I admit I got fed up with it in my own application (don't want both streams going into the host) and just modified the addsub block to be an add-only block. On Tue, Sep 3, 2019 at 8:43 PM Quadri,Adnan wrote: > I tried connecting

Re: [USRP-users] Addsub HLS Block Error

Oh, I see. You have separate sources connected to the same addsub block. It's telling you that you need to use timed stream commands to start the stream, or else you will see undefined behavior. Personally I think that error should be demoted to a warning -- anyone from Ettus want to chime in? On

Re: [USRP-users] Addsub HLS Block Error

I ran into this the other day and it's independent of the HLS component of the addsub block (since the interface is identical). You need to connect both outputs of the addsub block to something, even a null sink. I'm pretty sure this wasn't the intended behavior and also pretty sure that it wasn't

Re: [USRP-users] RFNoC Polyphase Channelizer updates

Last ditch, does your application permit aliasing? I.e., do you need to be able to receive all four channels simultaneously? It would be computationally cheap to sample at 5Msps and alias to 1Msps, then filter in the CPU. You'd have to rotate two of the carriers down to baseband but the sample

Re: [USRP-users] RFNoC Polyphase Channelizer updates

Nevermind, I just saw you're doing it in an E310. Reading is fundamental. You might consider splitting the problem into a pair of DDCs instead. Nick On Thu, Aug 8, 2019 at 11:35 AM Nick Foster wrote: > Royce, > > Is there a reason you absolutely need it to be done in RFNoC? This is only >

Re: [USRP-users] RFNoC Polyphase Channelizer updates

Royce, Is there a reason you absolutely need it to be done in RFNoC? This is only 5MHz of bandwidth, and any commodity PC should be able to handle channelizing it in software. Nick On Thu, Aug 8, 2019 at 11:19 AM Royce Connerley via USRP-users < usrp-users@lists.ettus.com> wrote: > EJ: > > I’m

Re: [USRP-users] Delayed samples receiving, X310

This is exactly what the "timed commands" feature is used for. See the documentation here: https://files.ettus.com/manual/structuhd_1_1stream__cmd__t.html On Wed, Aug 7, 2019 at 7:15 AM Cherif Diouf via USRP-users < usrp-users@lists.ettus.com> wrote: > Hello guys, > > I have developed a custom

Re: [USRP-users] 214 MHz ce_clk vs 200 MHz radio_clk, USRP X310

All synthesized clocks are synchronized to whatever reference is selected. On Mon, Aug 5, 2019 at 1:03 PM Cherif Diouf wrote: > Thanks Nick, > > > That's fine as explanation. I however need a HW clock synchronized to the > 10 MHz external reference. I am using some local counters to run timely

Re: [USRP-users] 214 MHz ce_clk vs 200 MHz radio_clk, USRP X310

The radio TX frontend backpressures upstream blocks. You don't have to worry about providing samples at the frontend rate. There is no reason to use a 200MHz clock in your block. Remember: if the frontend is operating at 200Msps, then the samples your block is producing must assume a 200Msps

Re: [USRP-users] RFNoC Polyphase Channelizer updates

I'll test! Forgot about this one and now have a very good use case for it. I'll let you know how it goes. On Wed, Jul 24, 2019 at 4:35 PM EJ Kreinar via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi Royce, > > Phil and I have been working on the channelizer in the theseus-cores repo >

[USRP-users] Receiving response packets via UHD

Hi all, I've created an RFNoC block which sends back a response to indicate whether a transmission successfully occurred or not, via the cmdout interface of noc_shell. The Verilog is all fine and the testbench works using pull_resp_pkt() to retrieve the data. I'm wondering how to receive that

Re: [USRP-users] Registering Block Controllers to UHD

This thread might be helpful: https://www.mail-archive.com/usrp-users@lists.ettus.com/msg07959.html Nick On Wed, Jun 19, 2019 at 6:35 AM Christian Valledor via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi All, > > I'm developing a few custom RFNoC Blocks for a UHD application I'm

Re: [USRP-users] Waveform Shape Not Accurate

Can you post the flowgraph you're using again? If you changed transmit gain and amplitude, the result should have changed in amplitude, while the image you just sent has the fame magnitude the last one did. On Wed, Jun 19, 2019, 5:03 AM Simona Sibio wrote: > Thank you very much. > I tried to

Re: [USRP-users] Waveform Shape Not Accurate

Turn up the transmit gain on the USRP sink. Start with ~40dB and transmit amplitude 0.3. Nick On Tue, Jun 18, 2019 at 9:40 AM Simona Sibio wrote: > Thank you for the assistance. > I tried to change the amplitude but the amplitude and frequency are not > accurate in the oscilloscope yet. > If I

Re: [USRP-users] Waveform Shape Not Accurate

Waveform source amplitude is too high. Turn it down to <0.4. On Tue, Jun 18, 2019 at 9:31 AM Simona Sibio via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi Michael, > > thank you for your interest. > > I have two N200 and each one have two daughterboard UBX-40; the > transmitters are

Re: [USRP-users] Getting interval between samples

Varban, The sample rate (interval between samples) is whatever you ask UHD to provide. If you ask for 10Msps, you will get a stream of samples with a sample interval of 100ns. The B205mini will configure the master clock rate (i.e., the clock rate used natively with the AD9364) to an appropriate

Re: [USRP-users] X310 master clock rate incorrect?

, 2019 at 11:03 AM Ian Buckley wrote: > Go tune WWV, your friendly Federal signal generator? > (Also isn’t LFRX DC coupled?) > > > On Jun 14, 2019, at 11:43 PM, Nick Foster via USRP-users < > usrp-users@lists.ettus.com> wrote: > > > > Got a weird one here. I'

Re: [USRP-users] B210: 1/f noise and LO offset

Did you make sure to select the external reference when creating the UHD device? On Tue, Jun 4, 2019, 7:11 AM Erik Heinz via USRP-users < usrp-users@lists.ettus.com> wrote: > Thank you for the explanation. > > I tried using an external reference clock (HP 58503A). Unexpectedly, this > made no

Re: [USRP-users] Need a little help with running legacy prebuilt UHD versions

Great news! Also great that we have this on record for others with older hardware they'd like to put to use again. Nick On Fri, May 10, 2019 at 4:54 PM Joe Martin via USRP-users < usrp-users@lists.ettus.com> wrote: > Holy smoke! SUCCESS!! Nick pointed out that there are two switches on > the

Re: [USRP-users] Need a little help with running legacy prebuilt UHD versions

I'm saying that you might try to continue the effort to JTAG load a more modern FPGA image. It's possible you have to hold down the safe mode button while loading the image. On Thu, May 9, 2019, 2:22 PM Joe Martin wrote: > Thanks for digging into that for us, Nick. Interesting. As the

Re: [USRP-users] Need a little help with running legacy prebuilt UHD versions

So I really dug into the old archives here and literally pulled an old hard drive out of a closet, and found a copy of the old hardware repository from back in the days when N210 was called "USRP2+". Best that I can tell, we only ever released two versions to the public. We might have sold R3

Re: [USRP-users] Need a little help with running legacy prebuilt UHD versions

Well, it's not a rev 4. It's either 2 or 3 in terms of hardware revision. On Thu, May 9, 2019 at 12:58 PM Joe Martin wrote: > …able to ping 192.168.10.2 successfully. > > On May 9, 2019, at 1:54 PM, Joe Martin wrote: > > Ian, > > Yes, I have tried many times to boot in safe mode, same result >

Re: [USRP-users] Need a little help with running legacy prebuilt UHD versions

Moreover, the best "tell" is to look at the N210 motherboard. If the SRAM chip is on the top side, it's a rev 2/3. If the SRAM is on the bottom side, it's a rev 4. If you send a picture along of the top of the N210, I can tell you if it's early or late rev. On Thu, May 9, 2019 at 11:36 AM Ian

Re: [USRP-users] Bringing an elderly N210 to life by loading current firmware/fpga images

Yes, code loaded over JTAG is gone at next boot. I can't think of an easy way to figure out what image is loaded other than asking UHD to query it for FPGA compat number. On Wed, May 8, 2019 at 1:04 PM Joe Martin wrote: > I guess the proper way to ask is “Is there a way to determine what fpga >

Re: [USRP-users] Bringing an elderly N210 to life by loading current firmware/fpga images

I see you got there already! If you're still having trouble, I'll see what I can dig up over here. On Wed, May 8, 2019 at 12:31 PM Nick Foster wrote: > You might be best off reverting to a UHD old enough to support the bitfile > currently loaded on your N210. You could then bootstrap your N210

Re: [USRP-users] Bringing an elderly N210 to life by loading current firmware/fpga images

You might be best off reverting to a UHD old enough to support the bitfile currently loaded on your N210. You could then bootstrap your N210 by using the old UHD to load a newer FPGA image. Otherwise, it's fairly simple to convert the binfiles (which still exist -- usrp_n210_r2_fpga.bin) to

Re: [USRP-users] X310 RFNoC transmission issues

Have you simulated your RFNoC CEs with Verilog testbenches? On Wed, May 8, 2019 at 8:12 AM zluudg via USRP-users < usrp-users@lists.ettus.com> wrote: > Hello! > > I'm having some issues while trying to transmit a signal using the > RFNoC: Radio block in Gnuradio. My block diagram is: > > >

Re: [USRP-users] RFNOC GPIO Remapping

Have you defined that GPIO as an output in the mask register? On Fri, Apr 26, 2019 at 9:01 AM Chatterjee, Pratik via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi Jonathan, > > I have a question regarding fpga and rfnoc. I am trying to set a 1'bit > value on one of the registers in my

Re: [USRP-users] How to insert an EOB for rfnoc transmission?

I don't know what your block does, so I don't know which to recommend. The rfnoc-modtool testbench example is fine, as are most of the existing testbenches in usrp3/lib/rfnoc. Ignore the error you're having now, spend some time setting up a testbench. I promise it will save you time in the end.

Re: [USRP-users] How to insert an EOB for rfnoc transmission?

Also, just to be clear, I usually see "no response packet" when I've messed up something in the CHDR. Looking more closely, you're using vita time set to "future_vita_time", but I don't see where that's assigned, either. Similarly for has_time and payload_length. Have you simulated this? It is

Re: [USRP-users] How to insert an EOB for rfnoc transmission?

Are you assigning a value for eob? You declare it, but I don't see where you assign it. On Wed, Apr 24, 2019 at 7:15 AM Xingjian Chen via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi Guys, > Good morning. I am wondering how to insert an EOB in Verilog code to the > radio. What I have

Re: [USRP-users] how to properly use static libuhd?

I suspect the same solution I gave a couple weeks ago will work here: set(MY_LIB_OPT -Wl,--whole-archive libuhd -Wl,--no-whole-archive) target_link_libraries(myapp ${MY_LIB_OPT} <...the rest of your libs...>) On Wed, Apr 17, 2019 at 3:02 AM Paolo Palana via USRP-users <

Re: [USRP-users] (no subject)

Just wanted to follow up on this, because I thought of something in the shower this morning. If you compile your block controller as a shared library and you want your block to be initialized/used with the default UHD apps, you can use LD_PRELOAD to ensure the block registration happens at

Re: [USRP-users] RFNoC RX -> TX loopback

Should still work just fine. I'm using the same approach with a UHD version from within the last few months. On Thu, Apr 11, 2019 at 8:00 AM Ryan Marlow via USRP-users < usrp-users@lists.ettus.com> wrote: > Hey Jason, > That post seemed to be exactly what I was looking for. > Thanks! > Ryan > >

Re: [USRP-users] (no subject)

OK, I looked further into it. UHD registers out-of-tree block controllers using the UHD_RFNOC_BLOCK_REGISTER macro, which under the hood creates a static function and a fixture which calls it before main(). Problem is, when linking your out-of-tree executable, the linker sees that the static

Re: [USRP-users] (no subject)

Make very sure that your program is actually linking in the library correctly. Linkers are weird and their interaction with build systems is often unpredictable and sometimes perverse. Find the symbols in the compiled library with nm and see that they aren't undefined. Use make VERBOSE=1 to see

Re: [USRP-users] (no subject)

Your program needs to be linked against the library which your custom block controller is compiled into, if in fact your block is using a custom block controller. uhd_usrp_probe and the other UHD utilities aren't linked against the custom library. This isn't generally a problem since the

Re: [USRP-users] A few questions about RFNoC streaming

I can tell you the answer to #3 off the top of my head: the two streams will be sample-aligned, and if you use timed start commands, they will be time-aligned. The other two are probably best answered by trying it out. Maybe someone from Ettus can chime in. Nick On Fri, Mar 22, 2019 at 7:09 AM

Re: [USRP-users] RFNoC questions - standalone system, docs

I wrote a blog post a while back describing a RX->TX RFNoC loopback application. It should still apply to the latest UHD: https://corvid.io/2017/04/22/stupid-rfnoc-tricks-loopback/ Nick On Sun, Mar 24, 2019 at 5:33 PM Julius Baxter via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi all,

Re: [USRP-users] UBX coherence between TX and RX

Well, according to your description, you could transmit a carrier from TX to RX (through an attenuator) with both sides set to the same frequency. Your received signal should look like a sine wave at the frequency of the offset. On Mon, Mar 25, 2019 at 9:16 AM Michael R. Freedman via USRP-users <

Re: [USRP-users] A few questions about RFNoC streaming

First things first. The flow graph you're describing don't work because the two radio blocks will saturate the bus going into the addsub block. You will need to decimate the streams going into the addsub block. I don't have a ready answer to your question about the streamers, but I'd suggest

Re: [USRP-users] Sending very short bursts with RFNoC on X310

erruns, but when there are, the radio never sees it. In the meantime, I can work around the problem by just padding my bursts with zeroes to force the packet size up. It's not ideal but I think it'll get me going. Nick > > Jonathon > > On Sat, Mar 9, 2019 at 8:36 AM Nick Foster

[USRP-users] Sending very short bursts with RFNoC on X310

Hi all, I'm trying to write an RFNoC application which generates very short bursts -- 20 samples or less -- which are then upsampled. I'm running into problems with the radio underflowing which I believe has to do with the DUC. I can reduce the problem to the following -- create an RFNoC graph

Re: [USRP-users] [UHD] Announcing 3.14.0.0 Release Candidate 1

Any plans to update to the latest API? Won't compile with anything after 17.05. On Wed, Feb 13, 2019, 11:33 AM Michael West wrote: > Hi Nick, > > Information on using DPDK can be found here: > http://files.ettus.com/manual/page_dpdk.html > > DPDK can be used with any example. Think of it as an

Re: [USRP-users] [UHD] Announcing 3.14.0.0 Release Candidate 1

Great news! DPDK support is an interesting development. Is there any documentation or examples which show this capability? Nick On Thu, Feb 7, 2019 at 10:05 AM Michael West via USRP-users < usrp-users@lists.ettus.com> wrote: > The release candidate of UHD version 3.14.0.0 has been tagged and

Re: [USRP-users] Protecting USRP's from humidity and salt

A HEPA filter won't do anything to reduce salt or moisture in the air inside the enclosure. There are a few things you could do to try to ensure the electronics live a while. Just ensure that there is adequate climate control inside the shack. This means air conditioning in the summer to bring

Re: [USRP-users] X310 xpr Files

You can do "make GUI=1 X310_HG" to open the Vivado GUI and build the project. Nick On Tue, Dec 18, 2018 at 1:33 PM Alexander Olihovik via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi all, > > Will running "make X310_HG" generate a .xpr file that I can open with > Vivado? I have a .xpr

Re: [USRP-users] RFNoC data format

The values are converted within UHD before sending to or after receiving from the device. The mapping is signed int16 <-> float [-1, 1]. If you need to work with the original int16 data you can just select complex int16 in the "[input, output] type" dropdown in the sink/source blocks. Nick On

Re: [USRP-users] GPIO pin used for ground on the X300

Any of those choices are fine. On Tue, Oct 16, 2018 at 11:22 AM Mega Samples via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi USRP-users, > > I have an X300. I am trying to connect an external circuit to GPIO pin 2 > ("data[0]" on the pinout). What is a good pin to use for ground --

Re: [USRP-users] Synch'ing two USRP-X310

It is definitely regenerated, and I can believe that there's no compensation for delay. I haven't measured the output on a phase noise analyzer, but as it's coming from the same clock generator which provides the sample clock for the device I would expect it to be similarly clean. Nick On Tue,

Re: [USRP-users] Synch'ing two USRP-X310

Wait, what? I've been using REF OUT for years now. What am I missing? What does "aren't actually fully supported" mean? On Tue, Oct 16, 2018 at 8:57 AM Marcus D. Leech via USRP-users < usrp-users@lists.ettus.com> wrote: > On 10/16/2018 07:44 AM, Francois Quitin via USRP-users wrote: > > Dear

Re: [USRP-users] Rfnoc latency

In a packet-switched system, because a whole packet must be buffered before being passed through the crossbar, your delay is going to be governed by your packet size and your sample rate. If you are decimating down to a lower sample rate, you will incur larger delays. To a first approximation,

Re: [USRP-users] RFNoC loopback

Haven't had time to look at it, but certainly you should be able to connect blocks directly in UHD; this should be independent of loopback operation. I'll give it a shot in the next few days. Nick On Fri, Sep 28, 2018 at 2:39 AM Daniel Rauschen via USRP-users < usrp-users@lists.ettus.com> wrote:

Re: [USRP-users] axi_round_and_clip busted?

I've successfully used axi_round_and_clip in a number of designs and it seems to simulate fine for me. Xsim or vsim? How is it being instantiated? What weird internal simulation issues are you seeing? Nick On Fri, Aug 31, 2018 at 2:58 PM Andrew Danowitz via USRP-users <

Re: [USRP-users] About CHDR packet size

That's the MTU of your network interface limiting the CHDR packet size. Can't break up CHDR packets over multiple network packets. Nick On Wed, Aug 1, 2018 at 11:25 AM Leandro Echevarría via USRP-users < usrp-users@lists.ettus.com> wrote: > Hey everybody, > > I'll somehow repeat a question I

Re: [USRP-users] X310 software reset revisted

; > > Regards, > Nate Temple > > On Mon, Jul 23, 2018 at 9:45 AM, Nick Foster via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> I've solved this with the USB JTAG interface and an external machine. An >> RPi will happily run Vivado Lab. >> >&

Re: [USRP-users] X310 software reset revisted

I've solved this with the USB JTAG interface and an external machine. An RPi will happily run Vivado Lab. AFAIK there are no plans to integrate a software reset into the X310. Nick On Mon, Jul 23, 2018 at 6:11 AM Jason Matusiak via USRP-users < usrp-users@lists.ettus.com> wrote: > I know it

Re: [USRP-users] X310 calibration with WBX

OK, just one more bump -- can anyone from Ettus confirm that they're able to get calibration working on X310, and that it actually reduces DC offset and IQ imbalance images? I think it's broken in master as well. Nick On Fri, Jun 29, 2018 at 1:34 PM Nick Foster wrote: > Following up on this, I

Re: [USRP-users] RFNoc Relay

Carl Friedrich Gauss, 7 > 08860 Castelldefels, Barcelona (Spain) > Tel: +34 93 645 29 00 Ext: 2177 <+34%20936%2045%2029%2000> > www.cttc.cat > > El 25/6/2018 a les 17:28, Nick Foster via USRP-users ha escrit: > > What is the behavior of the lights on the front pa

Re: [USRP-users] X310 calibration with WBX

Following up on this, I have an additional question: is there any plan to expose the DC offset and IQ balance API through device3? Currently it appears as though the legacy interface can make use of these functions to manually set IQ balance and DC offset, while device3-based programs (i.e.,

[USRP-users] X310 calibration with WBX

Hi all, I haven't looked at daughterboard calibration in a long time, and picking it up, it sure looks broken to me. I'm using X310 + WBX on rfnoc-devel as of March. Let's assume for the moment I'm running a stock FPGA image -- I'm not, but for testing I replicated the same results on the stock

Re: [USRP-users] RFNoc Relay

What is the behavior of the lights on the front panel? On Mon, Jun 25, 2018, 12:31 AM Pol Henarejos via USRP-users < usrp-users@lists.ettus.com> wrote: > Dear Derek, > > I tried the link that you gave but no luck. > 1) I disabled the use of timestamp and, dissecting the packets with > wireshark,

Re: [USRP-users] RFNoC Overrun Using Split Stream

It's not necessarily a limitation in RFNoC, or at least it seems to be a reasonable one; if the bus is to support 2 full-rate streams on a single block, why not 3, or even 4? To allow multiple streams at full rate you'd have to either increase the speed of bus_clk relative to ce_clk, or you'd have

Re: [USRP-users] X310 Register's Memory Capability

It's going to depend on how much block RAM the image is already using, and how much more you can use while still getting the image to route. The easiest way to find out will be to try it. On Thu, Jun 7, 2018, 9:14 AM shachar J. brown wrote: > Thanks Nick, that's an excellent example. > Do you

Re: [USRP-users] X310 Register's Memory Capability

Look at the RFNoC FIR filter block for a good example of pushing configuration data into a block via the settings bus. On Thu, Jun 7, 2018, 8:25 AM shachar J. brown via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi all, > > I'm working on an X310. > > I have large data (tables of 1-3 K of

Re: [USRP-users] RFNoC Overrun Using Split Stream

The same solution that works for E310 won't work for X310. The easiest fix will be to use a DDC block to reduce the sample rate ahead of the Split Stream block. The RFNoC bus cannot handle two full-rate streams on a single NoC port. Nick On Thu, Jun 7, 2018, 2:44 AM Juan Francisco via USRP-users

Re: [USRP-users] Question regarding the term "wrt A/D full scale" on OpenBTS

Oscar, that document covers a *lot* of testing using quite a lot of expensive calibrated instrumentation. Maybe you could elaborate a bit on what exactly you want to test, and why? On Sun, Jun 3, 2018 at 9:49 AM oscar llerena via USRP-users < usrp-users@lists.ettus.com> wrote: > Thanks Nick and

Re: [USRP-users] Multiple Output RFNoC Block

I'm positive I've done exactly this, but it was 18 months ago -- and that design has since moved to using 1 input and 2 outputs instead. I don't recall having any trouble getting that part to work, but there's been a lot of changes to RFNoC since then. On Tue, May 29, 2018, 5:12 PM EJ Kreinar via

Re: [USRP-users] Question regarding the term "wrt A/D full scale" on OpenBTS

Neither. It will depend on the gain setting and individual variation in the device. It is not calibrated to any specific dBm value and if you require dBm you must calibrate your readings against a known source. The listed maximum power figure is a maximum to avoid damage to the device. Nick On

Re: [USRP-users] Getting started with FPGA and RFNoC developement

On Thu, Apr 19, 2018 at 2:48 AM TIMMEN Koen < koen.tim...@thalesaleniaspace.com> wrote: > Nick, > > > > Since you replied to my previous questions regarding working with RFNoC, I > would like to address some follow up questions to you if you don’t mind. I > am still working on the same subject

Re: [USRP-users] AD9361 in USRP B210

They are both necessary and serve completely separate and complementary functions. At this point you are best served by reading the documentation. Nick On Wed, Apr 11, 2018, 10:33 PM Yeo Jin Kuang Alvin (IA) wrote: > Hi, > > > > Thank you! Btw will the FPGA image be

Re: [USRP-users] AD9361 in USRP B210

The best option is probably to use existing UHD commands to set the gain, frequency, master clock rate, etc., while modifying the image to generate the transmit signal in the FPGA rather than in the host. Nick On Wed, Apr 11, 2018 at 6:41 PM Yeo Jin Kuang Alvin (IA) < yjink...@dso.org.sg> wrote:

Re: [USRP-users] AD9361 in USRP B210

What exactly do you want to do? On Wed, Apr 11, 2018 at 6:33 PM Yeo Jin Kuang Alvin (IA) via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi all, > > > > How do we set up the Ad9361_driver and ad9361 controls in the > uhd/host/lib/usrp/common file for Ubuntu? What are the steps and >

Re: [USRP-users] RFNoC spp rate limitation

Just chiming in to say you aren't crazy -- I've seen similar results in my RFNoC loopback testing. There's a critical spp that you can't go below at full rate without experiencing over/underflows. I didn't take the time to dig down to the bottom of it, so I can't be of too much help here except to

Re: [USRP-users] Getting started with FPGA and RFNoC developement

Replies inline. On Thu, Mar 22, 2018 at 9:48 AM TIMMEN Koen via USRP-users < usrp-users@lists.ettus.com> wrote: > Hello, > > > > First of all I would like to mention that I am not sure if this is the > right location to ask these type of questions. However, I tried to find > answers to my

Re: [USRP-users] How to change B210 10Mz from Output to Input?

Without an external reference, the onboard 40MHz VCTCXO will handle creating a decent reference without the benefit of the PLL locking it to a 10MHz reference. Wouldn't be much use otherwise. On Fri, Mar 9, 2018, 9:46 PM Sailor Jerry wrote: > Guys, thank you so

Re: [USRP-users] How to change B210 10Mz from Output to Input?

I uh what? I don't see why that would be the case. The whole reason U103 exists is to switch between a GPSDO (if present) and an external reference. You might wait for the official Ettus response for this if you don't want to take responsibility for blowing it up, but I drew the schematic and I

Re: [USRP-users] How to change B210 10Mz from Output to Input?

It's a slick mod though. See the zero-ohm resistor bridging U103 pins 1 and 3? Remove it, and you'll return the B210 to factory standard. Assuming no other modifications have also been made. =) Nick On Fri, Mar 9, 2018 at 4:31 PM Marcus D. Leech via USRP-users < usrp-users@lists.ettus.com>

Re: [USRP-users] GRC + RFNoC + Radio Loopback

If the lights are on, the device is streaming, guaranteed. At this point, make sure your frequencies, gains, and antenna selections are correct. Nick On Fri, Mar 9, 2018 at 11:19 AM Kei Nguyen wrote: > Sorry I mean the lights were on when I closed the program. >

Re: [USRP-users] GRC + RFNoC + Radio Loopback

Are you using a custom FPGA image? What happens if you just omit the DMA FIFO? Also, set a reasonable spp in your RX Radio block arguments -- 300 to 600 is a good start. Nick On Fri, Mar 9, 2018 at 10:24 AM Kei Nguyen wrote: > Thanks for the reply and sorry for not

Re: [USRP-users] E312 Loopback Path Delay Changes when FPGA image is reloaded

nyone has any ideas as to what could be causing this please help! The > phase stability of the E312 is amazing within the same fpga image cycle but > these relatively large jumps after reload/ power cycle are a deal breaker > for some applications! > > Thanks > > Sam > > On

Re: [USRP-users] GRC + RFNoC + Radio Loopback

You're going to have to ask a better question than that. Please provide the following: * What you are trying to accomplish * What hardware you are using * What UHD and Gnuradio version you are using * The approach you followed * The result you expected * The result you actually got * A flowgraph

  1   2   >