Yes, this is intentional. There is a lot of active development going on for UHD 4.0 and the Replay block will be in there soon.
Thanks for the details with respect to port > 1. I will let you know what I find. Wade On Fri, May 1, 2020 at 1:22 PM Rob Kossler <rkoss...@nd.edu> wrote: > And, one more thing.... Are you aware that the current 'master' (UHD 4.0) > provides images that do not have the replay block on them (e.g., N310) and > that there is no noc_block_replay.v or replay block HPP file anywhere in > the repo? > Rob > > On Fri, May 1, 2020 at 1:28 PM Rob Kossler <rkoss...@nd.edu> wrote: > >> 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
