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 >> >
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
