Hi Wade, The issue can be demonstrated using the stock "replay_samples_from_file" program (N310 UHD3.15). Run with "trace" logging if you want even more detail. So, it's not really an issue related to multiple ports. It's an issue of connecting Replay port 2 (or likely port 3 as well) to an arbitrary downstream port. Rob
******* Here is the command that fails $ replay_samples_from_file --file Documents/waveforms/mtone_100_0p8_0_le.bin --replay_chan 2 --freq 2450e6 --rate 125e6 Creating the USRP device with: . . . [INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501; UHD_3.15.0.0-7-g8d228dbe [INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.20.2,type=n3xx,product=n310,serial=319821D,claimed=False,addr=192.168.20.2 [INFO] [MPM.PeriphManager] init() called with device args `mgmt_addr=192.168.20.2,time_source=internal,product=n310,clock_source=internal'. [INFO] [0/Replay_0] Initializing block control (NOC ID: 0x4E91A00000000004) [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) [INFO] [0/FIFO_0] Initializing block control (NOC ID: 0xF1F0000000000000) [INFO] [0/FIFO_1] Initializing block control (NOC ID: 0xF1F0000000000000) [INFO] [0/FIFO_2] Initializing block control (NOC ID: 0xF1F0000000000000) [INFO] [0/FIFO_3] Initializing block control (NOC ID: 0xF1F0000000000000) Using radio 0, channel 0 Using replay block 0, channel 2 Setting TX Freq: 2450.000000 MHz... Actual TX Freq: 2450.000000 MHz... Setting TX Rate: 125.000000 Msps... Actual TX Rate: 125.000000 Msps... Connecting 0/Replay_0 ==> 0/Radio_0 Error: LookupError: KeyError: [0/Radio_0] sr_write(): No such port: 2 On Fri, May 1, 2020 at 1:19 PM Wade Fife <wade.f...@ettus.com> wrote: > See my responses below. > > On Fri, May 1, 2020 at 11:08 AM Rob Kossler <rkoss...@nd.edu> wrote: > >> Thanks Wade, >> A few follow up questions: >> >> - Regarding play_halt(), it sounds like this should never used if you >> are planning to start playout again (and the replay output feeds the DUC >> input). Is this correct? Or perhaps there is some way to clear the DUC? >> >> My recommendation would be to not call play_halt() if you are planning on > restarting. It will take a little longer to stop because it has to wait to > complete the current memory read and generate the final packet with EOB. > I'd have to look into clearing the DUC, but I think the right thing to do > is to let the replay block stop normally. > >> >> - In the meantime, what is the correct way of using the block in my >> situation where the replay is connected to the DUC and I want to >> repeatedly >> start/stop streaming? Should I just remove the play_halt() call from the >> example and just wait for the buffer to flush following the stop streaming >> command? >> >> Yes, I would just remove the play_halt(). > >> >> - Have you seen my other issue regarding use of the Replay Block on >> the N310 such that you can't connect the 4 Replay block ports to the 4 DUC >> ports to produce 4 Tx outputs using 3.15? There is a graph connection / >> propagation issue that does not like Replay port 2 (3rd port) connected >> to >> DUC_1 port 0. >> >> I'm not aware of any issues with respect to multiple ports. Can you > provide more details on the issue you're seeing? > > Rob >> >> On Fri, May 1, 2020 at 11:37 AM Wade Fife <wade.f...@ettus.com> wrote: >> >>> Hi Rob, >>> >>> I wanted to give you a quick update. I was able to reproduce the issue >>> you found. There were two problems. >>> >>> First, the example you shared calls play_halt() for the replay block >>> each time replay is stopped. This basically stops it as soon as possible, >>> even if that means it can't send a final packet with EOB. The DUC needs the >>> EOB to start/stop cleanly or else the timestamps the DUC generates aren't >>> correct when the next set of data comes through. >>> >>> The second problem I found is part of some known issues that are already >>> fixed in UHD 4.0. I'm going to add these fixes to 3.15 since I know there >>> was a lot of interest in the Replay block in 3.15. So once these fixes >>> appear, you should be able to remove the call the play_halt() and the >>> example will work as expected. >>> >>> Thanks, >>> >>> Wade >>> >>> On Thu, Apr 23, 2020 at 9:34 PM Rob Kossler <rkoss...@nd.edu> wrote: >>> >>>> >>>> Great. I forgot to mention that I was using an n310. >>>> >>>> On Thu, Apr 23, 2020 at 10:18 PM Wade Fife <wade.f...@ettus.com> wrote: >>>> >>>>> Hi Rob, >>>>> >>>>> Thanks for the example! I'd take a look to see if I can reproduce the >>>>> issue and figure out what's going on. I've been working recently on the >>>>> Replay block, so I'm very interested to understand what's going on. >>>>> >>>>> Thanks, >>>>> >>>>> Wade >>>>> >>>>> On Thu, Apr 23, 2020 at 1:36 PM Rob Kossler via USRP-users < >>>>> usrp-users@lists.ettus.com> wrote: >>>>> >>>>>> Hi, >>>>>> I am having an issue with UHD 3.15.LTS using the replay block. When >>>>>> I play out my previously stored samples the first time, everything works >>>>>> fine. But after stopping the first time, if I try to start playing out >>>>>> again, I get a whole bunch of 'Lates' and no RF output. >>>>>> >>>>>> In order to duplicate the problem with an Ettus example, I modified >>>>>> 'replay_samples_from_file' to add a loop and command prompt so that the >>>>>> user could hit <enter> to start playing out while still using <ctrl-c> to >>>>>> stop. Unfortunately for me, this worked fine and did not show the >>>>>> problem. >>>>>> >>>>>> Next, I further modified the example to place a DUC block in between >>>>>> the Replay block and the Radio. Now it duplicates the issue perfectly >>>>>> (modified example attached). >>>>>> >>>>>> So, perhaps I need to clear the DUC in some way when stopping the >>>>>> streaming?? But if so, I'm not really sure how to do so. >>>>>> >>>>>> Thanks. >>>>>> Rob >>>>>> >>>>> _______________________________________________ >>>>>> 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
