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, 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
