[USRP-users] using VHDL modules in an RFNoC block

I have some code from a previous coworker that I would like to take advantage of. Currently it is VHDL and their top block (which I am calling), has things like: USE WORK.TYPES.ALL; USE WORK.HARDWARE.ALL; USE WORK.MATH.ALL; USE WORK.UTIL.ALL; USE WORK.FILTERS.ALL; USE WORK.RESAMPLERS.ALL; I un

[USRP-users] RFNOC OOT module no longer building

I added a new block to my OOT module and now when I run make from the build directory things don't build properly. I source my setup_env.sh and then run make from build and see the following: -- PyBOMBS installed GNU Radio. Setting CMAKE_INSTALL_PREFIX to /home/jmat/rfnoc -- Build type not spe

Re: [USRP-users] RFNOC OOT module no longer building

I think I solved this by blowing away everything within the testbench directory. I am not sure what happened, but this seems like the best fix for now. On 07/07/2017 12:04 PM, Jason Matusiak wrote: I added a new block to my OOT module and now when I run make from the build directory things do

Re: [USRP-users] rfnoc-modtool cores

yet, unfortunately-- Was waiting for confirmation if this approach will be supported in-tree in the future. I could put something together soon though if this would help. I'd also be interested in other good solutions, if anyone has a

[USRP-users] ERROR_CODE_BAD_PACKET

I am splitting one of my RFNoC blocks into two different ones, and one of them is giving me issues. The block is essentially a keep m in n block, so I only spit out data once in a while. This worked fine when combined with my other block, but now when I run it independently, it is throwing th

Re: [USRP-users] ERROR_CODE_BAD_PACKET

7 PM GMT+02:00, Jason Matusiak via USRP-users wrote: I am splitting one of my RFNoC blocks into two different ones, and one of them is giving me issues. The block is essentially a keep m in n block, so I only spit out data once in a while. This worked fine when combined with

[USRP-users] RFNoC timing clarification

I have a timing question that has me going in circles, I don't understand how the USRP timestamps work when using RFNoC. In a normal system, packets have timestamps with them (or at least the first one does) and you can compute the time of any samples based on the timestamp, sample rate, and n

Re: [USRP-users] RFNoC timing clarification

correction, etc. Jonathon On Wed, Jul 12, 2017 at 9:20 AM, Jason Matusiak via USRP-users mailto:usrp-users@lists.ettus.com>> wrote: I have a timing question that has me going in circles, I don't understand how the USRP timestamps work when using RFNoC. In a normal system, pa

[USRP-users] does an RFNoC block HAVE to have an input and an output?

I have a block that I want to essentially be a source block in RFNoC (outputting data from a ROM), but when I go to probe, I get this error: RuntimeError: LookupError: Path not found in tree: /mboards/0/xbar/dataGenerator_0/ports/in Is this because I set it up without sink input? Is there any

Re: [USRP-users] does an RFNoC block HAVE to have an input and an output?

And if the below approach is allowed (a probe seems to run fine now), would that be causing the following errors when I try to run my flowgraph (RFNoC:dataGenerator -> RFNoC:FIFO -> RFNoC:Radio): [INFO] [UHD] linux; GNU C++ version 4.8.4; Boost_105400; UHD_4.0.0.rfnoc-devel-348-g

Re: [USRP-users] does an RFNoC block HAVE to have an input and an output?

15 PM, Jason Matusiak via USRP-users mailto:usrp-users@lists.ettus.com>> wrote: I have a block that I want to essentially be a source block in RFNoC (outputting data from a ROM), but when I go to probe, I get this error: RuntimeError: LookupError: Path not found in tree:

[USRP-users] problem with RFNoC probing

I am not sure what is going on, but while working on my new RFNoC block, I can't probe my X310 anymore. When I do, I get this error: [INFO] [CORES] Performing timer loopback test... [ERROR] [UHD] Exception caught in safe-call. in virtual ctrl_iface_impl::~ctrl_iface_impl() at /home/jmat/rfn

Re: [USRP-users] problem with RFNoC probing

Could this have something to do with tlast? I don't feel like it is the XML files, so I am limited to looking at the verilog, but it is pretty similar to my other blocks, so I am not sure what the problem could be. It is odd to me that the probing is enough to cause issues, I am not sure what

Re: [USRP-users] problem with RFNoC probing

d off your block until after initialization. On Wed, Jul 19, 2017 at 9:44 AM, Jason Matusiak via USRP-users wrote: Could this have something to do with tlast?  I don't feel like it is the XML files, so I am limited to looking at the verilog, but it is pretty similar to my other blocks, so I a

[USRP-users] timout issue on RFNoC output

I am still struggling with my "output only" RFNoC block and can't seem to figure out what silly thing I am doing wrong. I am generating data by reading from a ROM and can see it happening by monitoring the o_tdata (etc) lines coming from my lower module. If I look in my noc_block_dataGenerator

Re: [USRP-users] timout issue on RFNoC output

I need to re-setup my debug messages to check. To be clear, you are talking about the o_tdata (etc) up in my upper level noc_block_dataGenerator, right? On 07/21/2017 02:52 PM, Jonathon Pendlum wrote: Here is what should happen on the axi stream bus to the crossbar. You should first see the

Re: [USRP-users] timout issue on RFNoC output

One last piece of oddball info I've discovered. RFNoC:dataGenerator -> RFNoC:FIFO -> throttle -> QT GUI Time Sink 1 - If I program the X310 and run it, I get timeouts streaming immediately and nothing shows up on the timesink. If I then stop it and run it again, I get some data through, and t

Re: [USRP-users] timout issue on RFNoC output

What I did was instead of creating an enable flag, I used the PKT_SIZE value I write when I execute a flowgraph to be my enable: assign enabled = (PKT_SIZE > 0) ? 1'b1 : 1'b0; assign o_tvalid = enabled; That should work, right? If not, how do I know that initialization is done? I didn't write

Re: [USRP-users] timout issue on RFNoC output

Jonathon, I have been working on this the last two days and can't seem to get it working. My destructor looks like this: dataGenerator_impl::~dataGenerator_impl() { std::cout << "In here3.\n"; uhd::rfnoc::dataGenerator_block_ctrl temp; temp.issue_stream_cmd(::uhd::stream_cmd_t::S

[USRP-users] reducing RFNoC sample rate simpler?

I have an RFNoC block that is probably going to take in a vector of data (200msps off the RFNoC:Radio), sum it with some values and continue. Every X number of vectors (could be as high as 1024 times), it will output a vector of its own. This means that at 200msps, I could have a flow of data

Re: [USRP-users] RFNoC:Delay block?

Nick, I had worked on something similar (a keep m-in-n block actually), and may have oversimplified things. I kept track of how many samples I outputted and set the tlast accordingly, wouldn't that solve the "reconstituting packet boundaries" issue you mentioned? Also, I am not sure I investi

Re: [USRP-users] reducing RFNoC sample rate simpler?

rate. Everything works fine because UHD has no expectations on the line rate of the incoming data stream. On Tue, Aug 8, 2017 at 12:02 PM, Jason Matusiak via USRP-users mailto:usrp-users@lists.ettus.com>> wrote: I have an RFNoC block that is probably going to take in a vector of da

Re: [USRP-users] Building FPGA image

I've done it many times. When you open it and you do a save-as of the project, make sure that you don't check the option box to copy the files over, you want to leave them in their current location. On 08/16/2017 10:15 AM, Torres Figueroa, Luis Angel via USRP-users wrote: Hi folks, Has som

Re: [USRP-users] Building FPGA image

I'm glad you got it working. There are a lot of critical warnings and things of that ilk that scroll by, but as long as you don't get any errors and your project meets timing, I wouldn't worry too much about them. Happy FPGAing. On 08/18/2017 09:26 AM, Torres Figueroa, Luis Angel wrote: Hi

[USRP-users] problem with RFNoC block not outputting

I have a block that I've been working on and it seems like I am missing something vital to get it to work properly. My block takes in a vector of 2048 samples and outputs 2048 samples as well. I simulated it and it passes simulation fine. But, if I look at the output as it goes to a file, no

Re: [USRP-users] problem with RFNoC block not outputting

One other piece of information. It seems like I always get hung up on the same output sample, 6905860. I noticed that that is almost exactly 3372 packets of 2048 sample vectors. Is there a set number of samples that can be buffered before the system stops? I set the MTU to be 11 in the axi_

Re: [USRP-users] problem with RFNoC block not outputting

OK, I think that I have solved it. A vector size of 2048 seems to not work in RFNoC, no matter who wrote the block. When I dial back to 256 that seems to work. I changed my block to output a tlast every 256 samples, and data passes through fine now. Is there a way to make 2048 work in RFNoC?

Re: [USRP-users] Quad channel receiver operation of B210

Sumit, There is a T/R switch between the TX/RX and RX2 ports, so you can only use one at a time for each channel. On 09/15/2017 01:17 PM, Sumit Kumar via USRP-users wrote: I asked because the TX/RX port can also be used as RX right. That's why I had the perception that all 4 ports can be used

[USRP-users] the rfnoc fifos

OK, dumb question, but I just can't come up with a good answer.  I understand that the RFNoC FIFOs are a must if you only have one NoC block that you want to use and are using the GNURadio host [1].  So why do pretty much most of the examples ALWAYS have at least one, and why would I want to fi

Re: [USRP-users] the rfnoc fifos

via USRP-users wrote: On Wed, Sep 27, 2017 at 01:42:22PM -0400, Jason Matusiak via USRP-users wrote: OK, dumb question, but I just can't come up with a good answer.  I understand that the RFNoC FIFOs are a must if you only have one NoC block that you want to use and are using the GNURadio

[USRP-users] RFNoC dataGenerator block not outputting to radio

OK, I have a weird problem.  I have a block I wrote a couple of months ago that doesn't seem to be working anymore.  I don't think I've updated anything within uhd-fpga except for some patches that Jonathon sent me so that I could add the logic in that keeps blocks from blasting data before the

[USRP-users] problem with aplay on E3xx

Just want to use a flowgraph that was working fine on an older (load-wise) SG1 E310 system on an up-to-date SG3 E312 system and it throws up if I were to type: aplay -i to start up the app, I get: root@ettus-e3xx-sg3:~# aplay -i ALSA lib /home/balister/docker-work/jethro/jethro-test/build/

[USRP-users] feedback from a USRP message

Is there anyway to get feedback from a sent message command to a USRP source in GR?  I was sending some commands and was /pretty/ sure I was doing it right, but to know for sure I sent a bogus command, and it didn't complain (I expected to see something on the terminal).  Is there anyway to tur

Re: [USRP-users] feedback from a USRP message

ging your GNU Radio logging settings. https://gnuradio.org/doc/doxygen/page_logger.html Regards, Derek On Mon, Oct 30, 2017 at 2:54 PM, Jason Matusiak via USRP-users mailto:usrp-users@lists.ettus.com>> wrote: Is there anyway to get feedback from a sent message command to a USRP s

Re: [USRP-users] Error when burn fpga image file into USRP X310

Did this ever get resolved?  Because I am having the same issues now too. Hi Luis, I will follow up with you on this issue off the list, within the thread that has been sent to support at ettus.com.

[USRP-users] (no subject)

I have been fighting for a day with issues on my N200s and N210s to no avail. These were working units, but are giving me the following: $ uhd_usrp_probe  [INFO] [UHD] linux; GNU C++ version 4.8.5 20150623 (Red Hat 4.8.5-16); Boost_105300; UHD_3.11.0.0-34-g4844f66d [ERROR] [UHD] Exception caught in

[USRP-users] bug in UHD I think

We have a python script that worked before I pulled down the latest UHD. A uhd_usrp_probe works fine, but when we run our command in our script using: usrp.get_usrp_info().vals()[0] We get an error of: LookupError: Path not found in tree: /mboards/0/xbar/Radio_0/eeprom partway through the Et

[USRP-users] rfnoc debug block

Is there anything special to get the rfnoc debug block to work? I copied-and-pasted the section of rfnoc_debug.grc that seems to be relevant into my flowgraph. But when I try to run my flowgraph, I get: Traceback (most recent call last): File "/opt/gnuradio/v3.7.12.0_rfnoc/src/Channelizer/g

[USRP-users] RFNoC FPGA clear_tx_seqnum behavior

I know this is an older thread, but I too am struggling to bring a block that someone else designed for us in 2015.4 to work in 2017.4. I dug around but I don't see any of our custom blocks using clear_tx_seqnum in their sub-modules or their config registers. They do use the config registers qu

Re: [USRP-users] RFNoC FPGA clear_tx_seqnum behavior

ssage - Subject: Re: [USRP-users] RFNoC FPGA clear_tx_seqnum behavior From: "Brian Padalino" Date: 6/28/18 3:35 pm Cc: "USRP-users@lists.ettus.com" Hey Jason, On Thu, Jun 28, 2018 at 3:31 PM Jason Matusiak via USRP-users wrote: I know this is an older thread, b

Re: [USRP-users] RFNoC FPGA clear_tx_seqnum behavior

Thanks Brian, that seemed to be the trick, at least for the initial flowgraph I was trying to use (I think I must have missed a block in my second flowgraph). Sadly, I can only run it once and then it doesn't work on the second run, so I need to investigate that next. I feel like I remember so

Re: [USRP-users] RFNoC FPGA clear_tx_seqnum behavior

I found the problem with my one flowgraph that was still not working after I updated my blocks, it was the RFNoC "Split Stream" block. It appears that it was never updated to use these new changes. I sort of modified it based on the addsub block and it seems to work for me, but YMMV. My chan

[USRP-users] Problem with the most recent UHD changes building

I just tried to pull down and build a fresh RFNoC install and it keeps failing. I think this is related to the commit 827adb from a couple of days ago. I say this because that commit showed a change to ad9361_ctrl.hpp, and my error when running "yes |pybombs - prefix init /opt/gnuradio/v3.

Re: [USRP-users] Problem with the most recent UHD changes building

on, The fix was pushed recently and builds fine for me now. Jonathon On Tue, Jul 3, 2018, 2:27 AM Jason Matusiak via USRP-users wrote: I just tried to pull down and build a fresh RFNoC install and it keeps failing.  I think this is related to the commit 827adb from a couple of days ago.  I say th

Re: [USRP-users] Problem with the most recent UHD changes building

recent UHD changes building Hey Jason, The fix was pushed recently and builds fine for me now. Jonathon On Tue, Jul 3, 2018, 2:27 AM Jason Matusiak via USRP-users wrote: I just tried to pull down and build a fresh RFNoC install and it keeps failing. I think this is related to the

[USRP-users] noc_block_null_source_sink module

I was having trouble finding information on this block. I could see its usefulness in an application I am looking into, but I wasn't sure how complete the block was (I don't really see anything using it, nor a GRC xml file for it). Thanks ___ USRP-use

[USRP-users] RFNoC DMA FIFO

I have a silly question. How do I add the axi_dma_fifo to my build? It looks like we can't add it to the uhd_image_builder command line, so I am not sure the way to do it manually. Is this written up somewhere that I missed? ___ USRP-users mailing li

Re: [USRP-users] rfnoc debug block

I was wondering if anyone had thoughts on this? I am now seeing it on a brand new block that I tried to create today. A uhd_usrp_probe looks fine, but when I run the python generated by GRC, I am seeing the same error: Traceback (most recent call last): File "/home/jmat/rfnoc-nocblocks/example

[USRP-users] X310 software reset revisted

I know it has been questioned many times on here, but I wanted to verify something. It has always been said that there is no way to do a software reset on the X310; I am curious if that is "currently" or "ever?" I wasn't sure if there was a way to send a packet either via UHD or RFNoC that c

[USRP-users] RFNoC flowgraph runs right the second time

I have a flowgraph with a custom RFNoC block in the middle. That block has 2 inputs and 2 outputs. Just to get started and work out the MIMO functionality, all I do is cross the the inputs to the outputs (so input 0 comes out output 1). What I am seeing is that if I run the flowgraph after lo

[USRP-users] Any tips to speed up X310 Vivado build time?

I know Vivado build times are dependent on how optimized you want things and how utilized the FPGA is, but is there a way to speed up the build times? I started doing my builds on a server thinking it would be a huge boost from my PC, but I am not really seeing a difference. It has 64 cores an

Re: [USRP-users] RFNoC flowgraph runs right the second time

Thanks Martin. I tried that, but it actually seems to be working when I look at the results. I saw you post earlier to someone about changing UHD's logging level. Is this something that can be done via a config file? I looked around, but all I could find was some references to c++ usage. > Ja

Re: [USRP-users] Creating Double Ported Source Block and Running It's Testbench

I will try to take a stab at your first question. The example I like to look at (which I think makes things look clean) is the noc_block_ddc.v. In there, they use a generate block to create multiple axi_wrappers. It is hard to find examples for things that involve more than one port and I w

Re: [USRP-users] USRP X310 Remote Configuration

I've actually done this with success, unfortunately, I am not allowed to share it :(. It wasn't too hard, I used a core in the block to hold the data, and then I just repeated it when I sent it out over and over. The catch was that there was a little bit of an issue within rfnoc at the time (

[USRP-users] Possible to enable via RFNoC block via RFNoC

I am curious if it is possible to enable an RFNoC block from another RFNoC block? An example would be, turning on the siggen when another RFNoC block decides that it should run. I don't believe that I've seen this done anywhere, so I have a suspicion that there isn't a good way to get message

Re: [USRP-users] noc_block_null_source_sink module

List" Hey Jason, The block is functionally complete, in fact I think it was the first block ever made. There is a UHD C++ example, rfnoc_nullsource_ce_rx.cpp, that uses it. A block controller and GRC xml for GNU Radio needs to be created though. Jonathon On Wed, Jul 18, 2018 a

[USRP-users] what would be considered an RFNoC loopback?

I am still having trouble with my OOT block when I add a second radio in the loop. A reminder of what I am doing. Just to test my 2-in, 2-out RFNoC block, I am swapping the inputs to the outputs (so input 0 goes to output 1). When I have: Radio->DDC->MyBlockIn.0 --- MyBlockOut.1->vecToStream

[USRP-users] Problem running RFNoC testbench all of a sudden

I am not sure what I've done, but all of a sudden I don't seem to be able to run my testbench. Things are in the "compiling" stage of the testbench when I get hit with this: Built simulation snapshot ddc_chain_behav ** Webtalk v2017.4 (64-bit) SW Build 2086221 on Fri Dec 15 20:5

Re: [USRP-users] Debugging RFNoC siggen

I experianced the same issues that EJ mentioned last year (maybe earlier). At the time Jon, helped me with a patch to get it to work properly (this was an OOT that sent out a specific chunk of samples on repeat [I think I mentioned this in a thread a few weeks ago]). I am not sure if it is fix

[USRP-users] packet size for RFNOC testbenches

I have been trying to figure out an issue with my block for a while, and it dawned on me that I might be barking up the wrong tree. I would like to send a lot of data for my test (say 5000+ samples). I noticed that things seem to get hosed after 496 samples. It might be an issue with my blo

Re: [USRP-users] packet size for RFNOC testbenches

"Jon Pendlum" Date: 8/20/18 10:58 am To: "Jason Matusiak" Cc: "USRP-users@lists.ettus.com" Hey Jason, You could try testing with noc_block_skeleton. It only does a loopback and has a self checking testbench. Jonathon On Mon, Aug 20, 2018, 11:48 PM Jason M

[USRP-users] RFNoC fifo filling up

This is a long shot, but I have been fighting with my rfnoc block the last few days trying to figure out why it won't work. I am basically combining the threshold block and the siggen block (so it takes in values, and spits out data based on the siggen parameters). My block has been spitting

Re: [USRP-users] RFNoC fifo filling up

5:00) To: Jason Matusiak Cc: "USRP-users@lists.ettus.com" Subject: Re: [USRP-users] RFNoC fifo filling up On Wed, Aug 22, 2018 at 3:53 PM Jason Matusiak via USRP-users wrote: This is a long shot, but I have been fighting with my rfnoc block the last few days trying to figure out

Re: [USRP-users] RFNoC fifo filling up

OK, let me elaborate since my first email was not very well written (I was throwing it out there on the way out the door). I spent all day yesterday thinking that I was making progress, the last simulation was copacetic, so I did a build over night, and yet again, no love. I started on this b

Re: [USRP-users] RFNoC fifo filling up

Whoops, I misspoke on the SPP size. At some point I must have changed the SPP to 1024. So with a file size of 57344 bytes, it was 57344/8/1024 = 7 full packets that made it though. When I tried it at SPP=16, 3840 bytes were in the file sink. So 3840/8/16 = 30 packets made it through. This

Re: [USRP-users] RFNOC blocks with multiple inputs?

I may be wrong, but I am pretty sure that RFNoC has issues with more inputs than outputs on a block. I believe the workout is to put a dummy output on the other side and hide it in GRC. Hopefully someone will speak up if I am wrong. - Original Message - Subject: [USRP-users]

Re: [USRP-users] Multiple instances of RFNOC block in single flow graph

Andrew, I have this issue all the time. To get around it, I go into properties of the block (double click on it in the GRC), go to the the RFNoC Config tab, and change the Device Select to 0 for one of them, and 1 for the other. There is some sort of issue (I don't recall why, but it was exp

Re: [USRP-users] RFNoC fifo filling up

Sadly, I still seem to be having this issue. Running threshold's test bench, I seem to be seeing it as well. I've attempted to reset all the files I touched (mostly just debug statements), so I don't know if there is an issue with threshold, but I don't understand why the fifos are filling up

Re: [USRP-users] E310 'make' error while trying to build UHD for RFNoC

I know that this is an old thread from Dec 2017, but I see the same issues. I am running Centos now, and I am thinking that this is related to that (old kernels, etc.). The error I see when I do the make is: [ 39%] Building CXX object lib/CMakeFiles/uhd.dir/usrp/e300/e300_sysfs_hooks.cpp.o [

Re: [USRP-users] Issues installing GNUradio using PYBOMBS (e3xx-custom-uhd or e3xx-rfnoc)

Philip, I know I am digging this up from early in the year, but I didn't see an answer. I am having the exact same issue with the six package. Were you ever able to fix this? - Original Message -On 04/02/2018 06:58 PM, Marcus D. Leech wrote: > On 04/02/2018 06:09 PM, P

Re: [USRP-users] Issues installing GNUradio using PYBOMBS (e3xx-custom-uhd or e3xx-rfnoc)

- Subject: Re: [USRP-users] Issues installing GNUradio using PYBOMBS (e3xx-custom-uhd or e3xx-rfnoc) From: "Philip Balister" Date: 9/5/18 3:35 pm To: "Jason Matusiak" Cc: "USRP-users@lists.ettus.com" On 09/05/2018 03:25 PM, Jason Matusiak via USRP-users wrote: > Ph

Re: [USRP-users] Issues installing GNUradio using PYBOMBS (e3xx-custom-uhd or e3xx-rfnoc)

fnoc -a e300 Or will something need to change there? - Original Message - Subject: Re: [USRP-users] Issues installing GNUradio using PYBOMBS (e3xx-custom-uhd or e3xx-rfnoc) From: "Philip Balister" Date: 9/5/18 3:35 pm To: "Jason Matusiak" Cc: "USRP-users@l

Re: [USRP-users] Issues installing GNUradio using PYBOMBS (e3xx-custom-uhd or e3xx-rfnoc)

he directory with the uncompressed six and run "python setup.py install" 5) Open a new terminal 6) Go back to your prefix directory and source setup_env.sh 7) Run pybombs rebuild gnuradio 8) Run pybombs install gr-ettus On Wed, Sep 5, 2018 at 12:35 PM, Philip Balister via USRP-users

Re: [USRP-users] "No upstream blocks" Warning

The issue is on your output side. It has been explained to me (I think it is somewhere on this mailing list due to an issue I and other have had), that you can't mix ports to be both host and rfnoc streams on the same side of the RFNoC block. So it sounds like the input side has both inputs co

[USRP-users] E310 cross-compile issue

OK, I am having a weird cross-compile issue still. I am using the latest cross-compile files from Philip, but I am getting a weird error that has me stumped. Here are the steps I took, maybe I hosed something up along the way. I am worried about: 1 - How I setup the cmakes 2 - enabling RFNOC

Re: [USRP-users] E310 cross-compile issue

of gnuradio and trying to use those instead of the fresh ones generated by make. I might uninstall any repository installs of gnuradio or temporarily muck with some environment variables so make only finds your local, up-to-date header files. On Mon, Sep 10, 2018 at 4:51 AM, Jason Matusiak

Re: [USRP-users] installing rfnoc using pybombs

Rob, Honestly, it seems like stuff has gotten sideways all over the place. Things I used to be able to do are no longer working (granted, I am working on an E310, so that increases the complexities). Try this instruction though: https://github.com/gnuradio/gnuradio/issues/1706#issuecomment-

[USRP-users] can't build an E310 bitfile

It has been a while since I've built a bitfile for the E310, but I used a setup that works fine for my X310. I source: /opt/gnuradio/v3.7.12.0_rfnoc/src/uhd-fpga/usrp3/top/e300/setupenv.sh it finds vivado 2017.4 fine and it said it was successful. then I run: /uhd_image_builder.py keep_1_in_

[USRP-users] Error in uhd_usrp_probe revisit

There was a thread back in 2017 (and revisited at least once) on the mailing list that is biting me and stopping me from running an RFNoC cross-compiled UHD on an E312. Here is Jonathon's answer on the original thread: http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-March/02395

Re: [USRP-users] Error in uhd_usrp_probe revisit

OK, I made a little more progress, but it is still having issues. If I run the simple GRC example supplied headless ( got rid of QT, just straight python dump samples to a file), it is throwing a weird UHD error: root@ettus-e3xx-sg3:~# ./uhd_wbfm_receive.py [INFO] [UHD] linux; GNU C++ version 7.3.

[USRP-users] custom E310 bitfile weird new error

I had a system that worked pretty well for creating a new bitfile for my E310. I ran through all the steps again so I could make sure that my notes were OK, but now I get an error when I run a probe on my E310 using that bitfile. I copied over the bitfile and replaced /home/root/localinstall/

[USRP-users] UHD not getting full bandwidth on E310

I have a cross-compile setup for my E312 that is working fine. If I run a benchmark_rate using my compiled UHD and bitfile, it works as intended. I see about 10MHz throughput from the FPGA to the ARM before I start dropping samples, that is about right based on my readings. Now, if I use all

Re: [USRP-users] UHD not getting full bandwidth on E310

I sent this email out a little prematurely. The stock software works fine with the non-RFNoC flowgraph I have. Some difference are: Stock gnuradio-config-info -v = 3.7.13.4 uhd_usrp_probe = [INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106400; UHD_3.11.0.1-0-unknown My cross-compile gnu

[USRP-users] general RFNoC timing question

I have a flowgraph I am running on an E310 using all stock RFNoC blocks. It looks a lot like this: RFNoC:Radio ---> RFNoC: Split Stream ---> RFNoC: FFT ---> RFNoC: Keep 1 in N ---> RFNoC: Log Power > GR: complex to float ---> GR:Raster Sink

[USRP-users] max usable SPP on the E310

Is the max usable SPP size on the E310 capped at 512? In my flowgraph, I have an RFNoC FFT block. I know that the SPP needs to be set to the size of the FFT to make things happy and using 512 seems to work fine. As soon as I step up to 1024 I see a lot of errors: RFNoC Streamer block receiv

Re: [USRP-users] Can't find a block controller for key FFT, using default block controller!

I wouldn't mind seeing your solution to #2 as well. The messages certainly make things look more ominous than they actually are. - Original Message - Subject: Re: [USRP-users] Can't find a block controller for key FFT, using default block controller! From: "EJ Kreinar via USR

Re: [USRP-users] general RFNoC timing question

OK, now I am really confused. Part of my math issue seems to be that I set the "sample rate" in the RFNoC radio to be my sample_rate because I knew I could ignore due to the lack of DDC (it would then be set to the master clock rate). When I run my flowgraph, I see that the master clock rate

Re: [USRP-users] max usable SPP on the E310

s between multiple packets and issue an EOB on the last packet. I have tried that in the past and had some success. Jonathon On Tue, Sep 25, 2018 at 8:54 PM Jason Matusiak via USRP-users wrote: Is the max usable SPP size on the E310 capped at 512? In my flowgraph, I have an RFNoC FFT blo

[USRP-users] Messaging the DDC

I have a block that outputs a message with a frequency.  I would love to be able to set the frequency adjustment in the RFNoC DDC, but I don't see a way to do it it automagically. I am guessing that there is no way to do it even though it can be set from a variable slider easily. Is there an opt

Re: [USRP-users] Messaging the DDC

tags in uhd_rfnoc_ddc.xml. I'm attaching what I hope will fix your problem as a patch (use with `git apply` from within gr-ettus). We'll most likely upstream a more general changeset. Best regards, Marcus On Wed, 2018-09-26 at 19:45 -0400, Jason Matusiak via USRP-users wrote: &

Re: [USRP-users] Messaging the DDC

x27;m attaching what I hope will fix your problem as a patch (use with `git apply` from within gr-ettus). We'll most likely upstream a more general changeset. Best regards, Marcus On Wed, 2018-09-26 at 19:45 -0400, Jason Matusiak via USRP-users wrote: > I have a block that outputs a

Re: [USRP-users] Messaging the DDC

h (use with `git apply` from within gr-ettus). We'll most likely upstream a more general changeset. Best regards, Marcus On Wed, 2018-09-26 at 19:45 -0400, Jason Matusiak via USRP-users wrote: > I have a block that outputs a message with a frequency. I would love > to be able to

[USRP-users] source and run rfnoc on boot on E310

I have a problem that I thought I solved a year or two back, but I can't seem to find it in my notes anywhere. I have a GR app that I want to run on boot on an E310, I know how to do that for straight GR. The problem is that it is an RFNoC GR app, so I need to source the cross-compiled tools

[USRP-users] getting GPS time from RFNoC bitfile on E310

I was trying to get GPS from a python OOT module block, but it doesn't look like it is possible when running RFNoC mode. I have top_block passed in, and I tried the command: print self.top_block.uhd_rfnoc_streamer_radio_0.get_mboard_sensor('gps_position') But I get the error

Re: [USRP-users] getting GPS time from RFNoC bitfile on E310

Hope this helps! I agree it's one of those things that might be nice > to have in the main tree. > > EJ > > On Mon, Oct 22, 2018, 11:08 AM Jason Matusiak via USRP-users < > usrp-users@lists.ettus.com> wrote: > > I was trying to get GPS from a python

Re: [USRP-users] Messaging the DDC

essages in the PMT dict format. You can extract the shape of information you need to send in from the tags in uhd_rfnoc_ddc.xml. I'm attaching what I hope will fix your problem as a patch (use with `git apply` from within gr-ettus). We'll most likely upstream a more general cha

Re: [USRP-users] RFNoC Replay block for E310?

I might be speaking out of turn here since I don't really know what the replay block does. But in the past, I successfully created a block that used a .coe file as a generated signal I transmitted over and over again. It was a pretty easy OOT module that just used a Xilinx core if I remember r

Re: [USRP-users] upgrading gcc on the E310

(sorry for the hijack, but I felt it was somewhat on topic) Just curious, I am sure there is a good reason, but why can't we build in our own custom drivers (I am not a low-level linux guy, so I am sure it is probably obvious)? So far we have been OK, but we have been a little nervous with som

[USRP-users] building host and remote in same location

Stupid question. I do a lot of work on both the E310 and X310. Currently I setup my X310 via pybombs and then my E310 by hand (pybombs install doesn't seem to work for us). The problem is that I am now maintaining two different trees if I want to have the same OOT module in both. Is there ar

[USRP-users] rfnoc build works for E310, doesn't meet timing with X310

OK, this has befuddled me for 3 days and I can't seem to get past it. I have a prefix that seems to work fine. Here are my working steps for building a bitfile on an E310: cd /opt/gnuradio/e300/src/uhd/fpga-src/usrp3/tools/scripts source ../../top/e300/setupenv.sh ./uhd_image_builder.py kee

  1   2   3   >