Update: The issue is included on the head of the UHD-3.12 branch, but is not included in the v3.12.0.0 release. So, be sure to checkout the v3.12.0.0 tag.
The issue we replicated is the STREAM_CMD_NUM_SAMPS_AND_DONE. The continuous streaming issue is still outstanding, but may be related. Regards, Michael On Thu, Sep 6, 2018 at 10:57 AM, Rob Kossler <rkoss...@nd.edu> wrote: > OK. I will give it a shot. Which issue did you duplicate (the confusion > is my fault for discussing two different issues in the same thread): Issue > #1 (NUM_SAMPS_AND_DONE) or Issue #2 (CONTINUOUS)? > > Rob > > On Thu, Sep 6, 2018 at 1:52 PM Michael West <michael.w...@ettus.com> > wrote: > >> Hi Rob, >> >> Thank you once again. We have reproduced the issue and are working on >> tracing down the root cause and fixing the issue. We have confirmed that >> the issue exists on 3.13, but we have also confirmed it does not exist on >> 3.12.0.0. So, you can use v3.12.0.0 in the meantime. To be sure you are >> using the correct FPGA image for v3.12.0.0, be sure to run >> 'uhd_images_downloader --refetch'. >> >> Regards, >> Michael >> >> On Tue, Sep 4, 2018 at 3:21 PM, Rob Kossler via USRP-users < >> usrp-users@lists.ettus.com> wrote: >> >>> Today, I confirmed that this issue exists on the head of 3.13 and 3.12, >>> but not 3.11. The example program provided with my previous post can be >>> compiled with any of these versions. >>> >>> Rob >>> >>> On Fri, Aug 31, 2018 at 12:33 PM Rob Kossler <rkoss...@nd.edu> wrote: >>> >>>> In this post and one other post, I mentioned two issues I am having >>>> related to N310 streaming: >>>> >>>> 1. With STREAM_MODE_NUM_SAMPS_AND_DONE, sometimes I get a timeout >>>> prior to receiving the requested number of samples (this is the issue >>>> identified in this post). This may be simply dependent upon the number >>>> of >>>> samples requested. >>>> 2. With STREAM_MODE_START_CONTINUOUS, I get errors with repeated >>>> captures such that after several successful captures, I eventually get a >>>> streaming timeout and all subsequent captures fail. >>>> >>>> So, turns out that this issue is bigger for me than I realized. I had >>>> a bunch of trouble yesterday while doing some research experimentation. I >>>> had selected to go with X310 devices rather than N310 devices because of >>>> their relative maturity. Today, I confirmed that my issues yesterday with >>>> the X310 are the same as I previously mentioned for the N310 (#2 above). >>>> So, perhaps it is an issue with UHD-3.13 (I did not check any other >>>> branch). >>>> >>>> I modified the Ettus "txrx_loopback_to_file.cpp" code to include a "for >>>> loop of 50 iterations" and changed the streaming mode to be continuous. >>>> The modified source is included as an attachment (a 'diff' of my code to >>>> the original with show the minor changes I made). I attached a console log >>>> of the output messages when run with my X310 which shows both the command >>>> line parameters I used as well as the resulting errors. Note that >>>> everything is going as expected through Iteration 5, but starting at >>>> Iteration 6, there is no end-of-burst (EOB) and starting at Iteration 8, a >>>> timeout occurs prior to receiving any samples. >>>> >>>> Please let me know if you have any questions. This is a pretty big >>>> issue for me and will prevent me from using 3.13 until addressed. >>>> >>>> Rob >>>> >>>> >>>> On Fri, Aug 24, 2018 at 2:46 PM Rob Kossler <rkoss...@nd.edu> wrote: >>>> >>>>> Hi, >>>>> This post is perhaps a continuation of a previous post "Problems with >>>>> MPM 3.13 on N310", but I wanted to change the subject to reflect this >>>>> current issue. >>>>> >>>>> The issue is an Rx streaming timeout. It can be easily duplicated >>>>> with a stock Ettus example. Below you will find the console log which >>>>> includes the command line parameters. Note the following: >>>>> >>>>> - I requested 31250 samples >>>>> - There is a error "Timeout while streaming" indicated at the end >>>>> - The final file size of 119340 indicates that 29835 samples were >>>>> received >>>>> - I do not have any reason to believe that the specific command >>>>> line arguments below are needed to duplicate the issue. I just didn't >>>>> bother to try other ones. >>>>> >>>>> In the other thread, I mentioned that my Rx timeout issue had gone >>>>> away after switching to streaming mode STREAM_MODE_NUM_SAMPS_AND_DONE. >>>>> However, the issue below occurs when using that mode so it will be a >>>>> problem for me. >>>>> >>>>> Let me know if you have any questions. >>>>> >>>>> Rob >>>>> >>>>> >>>>> irisheyes9@irisheyes9-Z240-SFF:/media/SSD_RAID/multi_pol$ >>>>> txrx_loopback_to_file --tx-args="addr=192.168.61.2" >>>>> --rx-args="addr=192.168.61.2" --nsamps=31250 --tx-rate=31.25e6 >>>>> --rx-rate=31.25e6 --tx-channels=0,1 --rx-channels=2,3 --tx-freq=2500e6 >>>>> --rx-freq=2500e6 >>>>> >>>>> Creating the transmit usrp device with: addr=192.168.61.2... >>>>> [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; >>>>> UHD_3.13.0.2-0-g0ddc19e5 >>>>> [INFO] [MPMD] Initializing 1 device(s) in parallel with args: >>>>> mgmt_addr=192.168.61.2,type=n3xx,product=n310,serial= >>>>> 315A34B,claimed=False,addr=192.168.61.2 >>>>> [INFO] [MPM.PeriphManager] init() called with device args >>>>> `mgmt_addr=192.168.61.2,product=n310'. >>>>> [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: >>>>> 0xF1F0D00000000004) >>>>> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1320 MB/s) >>>>> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1336 MB/s) >>>>> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1331 MB/s) >>>>> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1349 MB/s) >>>>> [INFO] [0/Radio_0] Initializing block control (NOC ID: >>>>> 0x12AD100000011312) >>>>> [INFO] [0/Radio_1] Initializing block control (NOC ID: >>>>> 0x12AD100000011312) >>>>> [INFO] [0/DDC_0] Initializing block control (NOC ID: >>>>> 0xDDC0000000000000) >>>>> [INFO] [0/DDC_1] Initializing block control (NOC ID: >>>>> 0xDDC0000000000000) >>>>> [INFO] [0/DUC_0] Initializing block control (NOC ID: >>>>> 0xD0C0000000000002) >>>>> [INFO] [0/DUC_1] Initializing block control (NOC ID: >>>>> 0xD0C0000000000002) >>>>> >>>>> Creating the receive usrp device with: addr=192.168.61.2... >>>>> Using TX Device: Single USRP: >>>>> Device: N300-Series Device >>>>> Mboard 0: ni-n3xx-315A34B >>>>> RX Channel: 0 >>>>> RX DSP: 0 >>>>> RX Dboard: A >>>>> RX Subdev: Magnesium >>>>> RX Channel: 1 >>>>> RX DSP: 1 >>>>> RX Dboard: A >>>>> RX Subdev: Magnesium >>>>> RX Channel: 2 >>>>> RX DSP: 0 >>>>> RX Dboard: B >>>>> RX Subdev: Magnesium >>>>> RX Channel: 3 >>>>> RX DSP: 1 >>>>> RX Dboard: B >>>>> RX Subdev: Magnesium >>>>> TX Channel: 0 >>>>> TX DSP: 0 >>>>> TX Dboard: A >>>>> TX Subdev: Magnesium >>>>> TX Channel: 1 >>>>> TX DSP: 1 >>>>> TX Dboard: A >>>>> TX Subdev: Magnesium >>>>> TX Channel: 2 >>>>> TX DSP: 0 >>>>> TX Dboard: B >>>>> TX Subdev: Magnesium >>>>> TX Channel: 3 >>>>> TX DSP: 1 >>>>> TX Dboard: B >>>>> TX Subdev: Magnesium >>>>> >>>>> Using RX Device: Single USRP: >>>>> Device: N300-Series Device >>>>> Mboard 0: ni-n3xx-315A34B >>>>> RX Channel: 0 >>>>> RX DSP: 0 >>>>> RX Dboard: A >>>>> RX Subdev: Magnesium >>>>> RX Channel: 1 >>>>> RX DSP: 1 >>>>> RX Dboard: A >>>>> RX Subdev: Magnesium >>>>> RX Channel: 2 >>>>> RX DSP: 0 >>>>> RX Dboard: B >>>>> RX Subdev: Magnesium >>>>> RX Channel: 3 >>>>> RX DSP: 1 >>>>> RX Dboard: B >>>>> RX Subdev: Magnesium >>>>> TX Channel: 0 >>>>> TX DSP: 0 >>>>> TX Dboard: A >>>>> TX Subdev: Magnesium >>>>> TX Channel: 1 >>>>> TX DSP: 1 >>>>> TX Dboard: A >>>>> TX Subdev: Magnesium >>>>> TX Channel: 2 >>>>> TX DSP: 0 >>>>> TX Dboard: B >>>>> TX Subdev: Magnesium >>>>> TX Channel: 3 >>>>> TX DSP: 1 >>>>> TX Dboard: B >>>>> TX Subdev: Magnesium >>>>> >>>>> Setting TX Rate: 31.250000 Msps... >>>>> Actual TX Rate: 31.250000 Msps... >>>>> >>>>> Setting RX Rate: 31.250000 Msps... >>>>> Actual RX Rate: 31.250000 Msps... >>>>> >>>>> Configuring TX Channel 0 >>>>> Setting TX Freq: 2500.000000 MHz... >>>>> Actual TX Freq: 2500.000000 MHz... >>>>> >>>>> Configuring TX Channel 1 >>>>> Setting TX Freq: 2500.000000 MHz... >>>>> Actual TX Freq: 2500.000000 MHz... >>>>> >>>>> Configuring RX Channel 2 >>>>> Setting RX Freq: 2500.000000 MHz... >>>>> Actual RX Freq: 2500.000000 MHz... >>>>> >>>>> Configuring RX Channel 3 >>>>> Setting RX Freq: 2500.000000 MHz... >>>>> Actual RX Freq: 2500.000000 MHz... >>>>> >>>>> Checking TX: all_los: locked ... >>>>> Checking RX: all_los: locked ... >>>>> Setting device timestamp to 0... >>>>> Timeout while streaming >>>>> >>>>> Done! >>>>> >>>>> irisheyes9@irisheyes9-Z240-SFF:/media/SSD_RAID/multi_pol$ ls -l *.dat >>>>> -rw-rw-r-- 1 irisheyes9 irisheyes9 119340 Aug 24 14:33 >>>>> usrp_samples.00.dat >>>>> -rw-rw-r-- 1 irisheyes9 irisheyes9 119340 Aug 24 14:33 >>>>> usrp_samples.01.dat >>>>> irisheyes9@irisheyes9-Z240-SFF:/media/SSD_RAID/multi_pol$ >>>>> >>>>> >>> _______________________________________________ >>> 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
