Hello Rob, Thank you for all the info and the assistance.
Just to tie all the loose ends: Graph for recording will be: Radio_rx(0)-->Replay(0)-->rx_streamer, Radio_rx(1)-->Replay(1)-->rx_streamer Code snippet: *graph->connect( radio_ctrl->get_block_id(),radio_chan0 ,replay_ctrl->get_block_id(),replay_chan0)* *graph->connect( radio_ctrl->get_block_id(),radio_chan1 ,replay_ctrl->get_block_id(),replay_chan1) * *uhd::rx_streamer::sptr rx_stream0 = graph->create_rx_streamer(1, stream_args); // Is this correct? Or should I create a single 2-port streamer and connect each port to a replay channel?* * uhd::rx_streamer::sptr rx_stream1 = graph->create_rx_streamer(1, stream_args); * *graph->connect( replay_ctrl->get_block_id(),replay_chan0 ,rx_stream0, 0);* * graph->connect( replay_ctrl->get_block_id(),replay_chan1 ,rx_stream1, 0); * // Stream command *uhd::stream_cmd_t stream_cmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE);stream_cmd.num_samps = total_num_samps;stream_cmd.stream_now = false;* *stream_cmd.time_spec = uhd::time_spec_t(seconds_in_future);radio_ctrl->issue_stream_cmd(stream_cmd);* I am trying to understand what will happen following the issue of the stream command. Since the stream command is for the radio block and not for a specific channel it should trigger sample streaming per graph connectivity so both channels should start sending samples to replay at the same time. Does the record action happen automatically due to graph connectivity? These are exactly the missing pieces of my puzzle. Then at some arbitrary time in the future I would like to do: *replay_ctrl-->play(offset1,size,replay_chan0,uhd::time_spec_t(0.0),false); * * replay_ctrl-->play(offset2,size,replay_chan1,uhd::time_spec_t(0.0),false); * to dump the recorded samples to files. The issue stream command above won't trigger the rx_stream? The write to file operation is an offline operation for me and I don't want it to be a real-time operation that has to keep up with the recording speed. Thanks for all the help. Regards, Ofer Saferman On Tue, Feb 1, 2022 at 10:19 PM Rob Kossler <rkoss...@nd.edu> wrote: > 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 >>> >> -- This message has been scanned for viruses and dangerous content by MailScanner, 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
