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
