I just reviewed the Replay block "issue_stream_cmd" and I think I was wrong in the previous post. This appears to operate with the playback buffer rather than the record buffer. So, I think you will need to use plan B and call "issue_stream_cmd" directly on the radio controller.
On Tue, Feb 1, 2022 at 3:11 PM Rob Kossler <rkoss...@nd.edu> wrote: > Hi Ofer, > The Replay block has an "issue_stream_cmd" that should work identically to > the same command in the rx_streamer. You should be able to use a timed > command with it. Even if this doesn't work for some reason, you could > instead use the "issue_stream_cmd" directly on the Radio (using a timed > command). Note that the reason for issuing it at the rx_streamer or at the > replay block is so that ALL blocks in the graph will get notified of the > impending stream (in case any given block needs to prepare in some way for > the impending stream). Thus, in a typical graph, when you call > issue_stream_cmd on the rx_streamer, this command then propagates to the > DDC and ultimately to the Radio which guarantees the start sample. > Rob > > On Tue, Feb 1, 2022 at 2:34 PM Ofer Saferman <o...@navigicom.com> wrote: > >> Hello Rob, >> >> Thank you for your assistance. >> I will take your advice and keep it simple and use a separate port for >> each operation/channel. >> I want to do it not only to keep things simple but also because my Tx >> playback should never stop while my recording is timed and rare. >> >> Can you or Wade comment on item (4) in my latest query? - How to issue >> recording simultaneously on two replay ports? As I mentioned, I know how to >> do timed commands on streams but not on the replay block. >> >> Regards, >> Ofer Saferman >> >> On Tue, Feb 1, 2022 at 7:02 PM Rob Kossler <rkoss...@nd.edu> wrote: >> >>> Oops. In step 3, I meant graph Replay->rx_streamer. Also, in step 2, >>> since this is a circular graph, you need to disconnect property propagation >>> on one leg of the graph (or something like that). >>> >>> On Tue, Feb 1, 2022 at 11:58 AM Rob Kossler <rkoss...@nd.edu> wrote: >>> >>>> Hi Ofer, >>>> Considering just a single port replay block, it seems that you want to >>>> do the following: >>>> Step 1: Populate Tx samples: Configure tx_streamer->Replay graph and >>>> populate Mem block A with Tx waveform >>>> Step 2: Transmit/Receive samples: Change graph to Radio->Replay->Radio >>>> and "play" from Mem block A while recording to Mem block B >>>> Step 3: Download Rx samples: Change graph to Radio->rx_streamer and >>>> play samples from Mem block B >>>> >>>> This seems doable to me, but you may want to start with a simpler >>>> approach (such as separate ports that don't require reconfiguring graphs). >>>> Also, regarding your question about a fixed number of samples, I think that >>>> the limit is 2^28 samples in the NUM_SAMPS_AND_DONE option. If you need >>>> more than that, I think you are out of luck (I don't think there is a timed >>>> radio command to tell it to stop streaming on a given sample). >>>> Rob >>>> >>>> On Tue, Feb 1, 2022 at 12:18 AM Ofer Saferman <o...@navigicom.com> >>>> wrote: >>>> >>>>> Hello Wade, >>>>> >>>>> Thank you for your prompt response. >>>>> A few more questions please: >>>>> 1. I am not sure that when we say bi-directional we mean the same >>>>> thing. The record and playback functions derive their function to some >>>>> extent from the graph connectivity. I would like, for the *same port* >>>>> of Replay, to make 2 graphs: tx_stream --> Replay --> Radio, Radio --> >>>>> Replay --> rx_stream. When I do record or playback, which of the graphs is >>>>> active? Both of them? In both directions? Can I control it to activate >>>>> only >>>>> one direction? For Tx I want to use the record function only once to get >>>>> the samples into the buffer and playback them periodically (same as in the >>>>> rfnoc_replay_samples_from_file example) but for the other direction of Rx >>>>> I >>>>> want to use the record function all the time. When I issue the record >>>>> command, which graph is active? The Tx graph? The Rx graph? Will it allow >>>>> me to make the 2 graphs at all using the same port? It is my understanding >>>>> that for the 2 graphs I mentioned I need two ports of replay, one for each >>>>> graph. Please correct me if I am wrong. >>>>> 4. I would like to use two ports of Replay to record 2 Rx channels. >>>>> One replay port for each Rx channel. How do I issue a record command that >>>>> will cause both channels (ports) to record at the same time instant? I >>>>> know >>>>> we can do timed commands for streams but how to do it for replay ? My use >>>>> of the rx streams is done later in an offline fashion and can be done in >>>>> series for each of the Rx channels but the recording of samples itself to >>>>> DRAM has to be simultaneous. >>>>> >>>>> Thanks, >>>>> Ofer Saferman >>>>> >>>>> ---------- Forwarded message ---------- >>>>>> From: Wade Fife <wade.f...@ettus.com> >>>>>> To: Ofer Saferman <o...@navigicom.com> >>>>>> Cc: usrp-users <usrp-users@lists.ettus.com> >>>>>> Bcc: >>>>>> Date: Mon, 31 Jan 2022 16:52:41 -0600 >>>>>> Subject: [USRP-users] Re: Questions about replay block >>>>>> Hi Ofer, >>>>>> >>>>>> 1. It is bidirectional. You can think of the "record" and the "play" >>>>>> components as independent, but connected to the same memory. So be >>>>>> careful >>>>>> not to read/write to the same memory space and be aware that reading and >>>>>> writing simultaneously slows down the DRAM making under/overflow more >>>>>> likely. But I think the E320 DRAM should be fast enough for your use >>>>>> case. >>>>>> >>>>>> 2. The number of ports on the Replay block doesn't have any >>>>>> restrictions that I know of. Any positive integer should be fine. You >>>>>> could >>>>>> also leave ports unused/unconnected if it was somehow a problem. >>>>>> >>>>>> 3. To record at a predetermined time for a fixed amount of data, you >>>>>> should be able to issue a stream command with the time and the number of >>>>>> samples you want. >>>>>> a. Yes. >>>>>> b. Yes. The first time you want to record data, you call record(). To >>>>>> record to the same buffer again, call record_restart(). Make sure >>>>>> num_samps >>>>>> for your stream command does not exceed the size of your record buffer, >>>>>> or >>>>>> else the radio will overflow. >>>>>> c. Yes, you need to play back the buffer. Since the output is >>>>>> connected to the rx streamer, it'll stream to the host. So you can call >>>>>> recv() on your rx streamer to capture the data. Something like this (in >>>>>> Python): >>>>>> replay.play(0, num_bytes, port, uhd.libpyuhd.types.time_spec(0.0), >>>>>> False) >>>>>> rx_md = uhd.types.RXMetadata() >>>>>> num_rx = rx_streamer.recv(output_data, rx_md, timeout) >>>>>> >>>>>> Happy coding! >>>>>> >>>>>> Wade >>>>>> >>>>>> >>>>>> On Mon, Jan 31, 2022 at 9:45 AM Ofer Saferman <o...@navigicom.com> >>>>>> wrote: >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I am working on a E320 USRP unit and using UHD-4.1.0.5. >>>>>>> I prepared my own FPGA image that has 1 radio block and 1 replay >>>>>>> block with 2 ports (channels) >>>>>>> I would like to be able to simultaneously perform playback of 1 Tx >>>>>>> channel and recording of 2 Rx channels (to/from different memory >>>>>>> locations) >>>>>>> The example rfnoc_replay_samples_from_file.cpp is only helpful to >>>>>>> some extent because it shows only the playback path and I am having some >>>>>>> difficulty setting up the recording path. >>>>>>> >>>>>>> I have a few questions about the replay block functionality and >>>>>>> connectivity that I hope you may be able to resolve. >>>>>>> >>>>>>> 1. Is the replay block bi-directional? If I have a replay block with >>>>>>> 1 channel, can it be used for both playback of samples and recording of >>>>>>> samples (from/to different memory locations) simultaneously ? or does >>>>>>> each >>>>>>> operation require one channel? >>>>>>> 2. If the answer to question (1) is no then I guess I need at least >>>>>>> 3 replay channels. Is it possible to define in the FPGA image (in the >>>>>>> yml >>>>>>> file) a replay block with 3 channels (ports) or does it have to be a >>>>>>> power >>>>>>> of 2? a multiple of 2? I didn't want to try and see what happens >>>>>>> because it >>>>>>> takes a while to compile the FPGA image and I would rather get it right >>>>>>> on >>>>>>> the 1st try. >>>>>>> 3. I would like to issue samples recording at a predetermined time >>>>>>> for a fixed size data chunk and then at my own leisure dump the memory >>>>>>> buffer that was recorded to a file. Since I don't have a working >>>>>>> example I >>>>>>> am having some difficulty getting it right. >>>>>>> a. The graph should be Radio --> Replay --> rx_stream. Is this >>>>>>> correct? >>>>>>> b. I should start my recording with replay_ctrl->record_restart and >>>>>>> check for fullness, right? >>>>>>> c. Then how do I get the rx_stream to dump it to file? Do I need to >>>>>>> do playback for this to happen, mirroring what is going on in the >>>>>>> rfnoc_replay_samples_from_file example? >>>>>>> If someone has a working code snippet I would appreciate it if they >>>>>>> can share it. >>>>>>> >>>>>>> Thanks, >>>>>>> Ofer Saferman >>>>>>> >>>>>>> -- >>>>>>> This message has been scanned for viruses and >>>>>>> dangerous content by *MailScanner* <http://www.mailscanner.info/>, >>>>>>> and is >>>>>>> believed to be clean. _______________________________________________ >>>>>>> USRP-users mailing list -- usrp-users@lists.ettus.com >>>>>>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com >>>>>>> >>>>>> _______________________________________________ >>>>>> USRP-users mailing list -- usrp-users@lists.ettus.com >>>>>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com >>>>>> >>>>> >>>>> -- >>>>> This message has been scanned for viruses and >>>>> dangerous content by *MailScanner* <http://www.mailscanner.info/>, >>>>> and is >>>>> believed to be clean. _______________________________________________ >>>>> USRP-users mailing list -- usrp-users@lists.ettus.com >>>>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com >>>>> >>>> >> -- >> This message has been scanned for viruses and >> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and >> is >> believed to be clean. _______________________________________________ >> USRP-users mailing list -- usrp-users@lists.ettus.com >> To unsubscribe send an email to usrp-users-le...@lists.ettus.com >> >
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
