Update. I solved the bulk of the performance problem. I realized that I wasn't comparing apples to apples when comparing my rfnoc tx graph with my multi_usrp example. In the latter example, I was taking care of sending data in vector sizes that were aligned with tx_stream->get_max_num_samples() which in my case defaults to 1996. After I changed my example to send data (using send() function) with vector length 1996, things started behaving much better. In fact, I am now able to send single channel data at 200 MS/s with just one or two "U" at the beginning.
But, I still have the questions about the "L" which I believe are caused by sub-optimal configuration of the pkt_size parameter in the connect() call (see warnings below). Presently, my code uses the default value of zero. Also, I don't know what's causing the exception at the end (see assertion below). Rob On Tue, Oct 2, 2018 at 3:33 PM Rob Kossler <rkoss...@nd.edu> wrote: > Using similar code, but with the addition of the DmaFIFO to the chain, I > have created the attached source code. Additionally, I have attached a > "log" file which shows the command line parameters as well as the response > for an individual run. I have a few remarks: > > - In general, the code works in that I can repetitively stream the > desired waveform file and it looks as expected on a signal analyzer. > However, it is not well optimized such that when I increase the streaming > rate to 100 MS/s, I get errors (and sometimes see a couple of issues at 50 > MS/s. > - In the log file, you will find some "L" and many "U". This was > actually a "good" run. In additional runs, there were many more "U" that > continued throughout the run > - If instead of this rfnoc tx example, I use a multi_usrp object to > handle the details of connecting the blocks and streaming the data, I have > no problems (no "L" or "U"), even at 100 MS/s > - So, it seems clear to me that I have not connected / configured the > blocks optimally > > Here are my questions: > > - What am I doing wrong that is causing the sub-optimal streaming? > - Why do I get the following warnings? Could this explain the > sub-optimal streaming? What is the correct way to configure SPP for each > block or connection? > - [WARNING] [RFNOC] Assuming max packet size for 0/DmaFIFO_0 > - [WARNING] [RFNOC] Assuming max packet size for 0/DUC_0 > - Why do I get the following error message upon program termination? > - AssertionError: [0/DmaFIFO_0] Attempting to disconnect input port > 0, which is not registered as connected! > > Thanks for any help. > Rob > > > On Thu, Sep 20, 2018 at 7:22 PM Ryan Marlow via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> Hey Leo, >> Glad to hear you were able to work things out. One quick note about the >> code I attached previously. Located a minor typo/bug that you'll want to >> fix if you want to actually transmit useful data. >> >>> 219 radio_ctrl->set_rx_frequency(freq, radio_chan); >>> >> should be: >> >>> 219 radio_ctrl->set_tx_frequency(freq, radio_chan); >>> >> Notice the change from rx->tx. >> Best, >> Ryan Marlow >> >> >> On Thu, Sep 20, 2018 at 10:35 AM, Leandro Echevarría < >> leoechevar...@gmail.com> wrote: >> >>> Hey Ryan, >>> >>> Thanks a lot! I actually ended up doing pretty much the exact same >>> things you described, and came up with a piece of code very similar to >>> yours. Yours is neater though, so I will keep it ;-). >>> >>> Regards, >>> >>> Leo >>> >>> On Wed, Sep 19, 2018 at 7:52 PM Ryan Marlow <r...@lmarlow.com> wrote: >>> >>>> Hey Leo, >>>> I haven't seen anyone respond yet and I recently needed to develop a TX >>>> RFNoC example of my own. I worked off the rfnoc_rx_to_file.cpp example. Far >>>> from perfect, but it gets the job done (transmits data). The main changes >>>> are: >>>> - copied send_from_file function from tx_samples_from_file.cpp example >>>> to handle the streaming of data from the input file >>>> - reversed the order that blocks are connected in the graph->connect() >>>> function. Now connects optional arg block -> radio. Was radio -> optional >>>> arg block. >>>> - uses tx_stream instead of rx_stream. >>>> Just add this cpp file to the CMake file in the host/examples dir to >>>> build it then try it out. >>>> I ran it with: >>>> build/examples$ ./rfnoc_tx_from_file --block-id DUC_0 --block-args >>>> output_rate=200e6,input_rate=5e6 --duration 5 --file usrp_samples.dat >>>> >>>> Hope that helps, >>>> Ryan >>>> -- >>>> Ryan L. Marlow >>>> R L Marlow Consulting LLC >>>> rlmarlow.com >>>> >>> >> >> >> -- >> Ryan L. Marlow >> R L Marlow Consulting LLC >> rlmarlow.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
