In order to do so, you need to build a new FPGA image (using Xilinx Vivado). Ettus provides a "siggen" rfnoc block that can be used to transmit a signal, but the waveform types supported by this block are very simple. However, if this works for you, then you don't have to do any development - you can just build a new image with this existing block.
If you want to be able to have an arbitrary waveform signal generation capability (with fixed length waveforms that are repeated), you need a custom block that includes enough memory to store the largest expected waveforms. Is this the capability you need and if so, how large (how many samples) are your waveforms? Rob On Mon, Sep 14, 2020 at 12:24 PM Ofer Saferman <[email protected]> wrote: > Thank you. > Last question: If the E310 does not support the replay block is it > possible in any way to transmit a signal using the device only without > streaming it from a host computer? If so how? > > Regards, > Ofer Saferman > > On Mon, Sep 14, 2020 at 4:42 PM Rob Kossler <[email protected]> wrote: > >> Hi Ofer, >> Unfortunately, the Replay block is only available for X3x0 and N3x0 >> USRPs. This block does not work for the E310 and I have not heard any >> plans from Ettus to change this. >> >> But, if you were using one of these supported USRPs, you would likely >> just have one Replay block with multiple ports (that is the way Ettus >> builds this block in the N310 default FPGA image). You are correct that you >> will effectively have 2 software commands, but if you provide the same >> "start time" in both commands (where the start time is slightly in the >> future from "now"), the FPGA Radio block will delay streaming until the >> specified time is reached such that both streams start simultaneously. >> >> Rob >> >> On Sun, Sep 13, 2020 at 11:59 PM Ofer Saferman via USRP-users < >> [email protected]> wrote: >> >>> Hello Rob, >>> Thank you for your response. >>> I am using USRP E310. >>> I am using UHD 3.15. >>> >>> So, use one replay block with multiple ports? Or use two replay blocks? >>> Could you point me to the relevant methods to handle more than one port? >>> >>> Is there a detailed block diagram of the various modules (classes) or >>> some class diagram ? It is hard to navigate between the various blocks and >>> know what methods they have only from example code. I looked at the class >>> documentation but couldn't find such block diagram. >>> >>> Regarding synchronization - How does providing the same start time >>> ensure synchronization? How can you actually start replay at the same time? >>> I am asking because everything is controlled by software so if you have to >>> issue two commands in software to start each of the replays they will not >>> be synchronized. Which command in code actually starts replay of signal? >>> >>> Thanks, >>> Ofer. >>> >>> On Mon, Sep 14, 2020 at 5:43 AM Rob Kossler <[email protected]> wrote: >>> >>>> Hi Ofer, >>>> This is possible. The Replay block has multiple ports. You can connect >>>> the ports to the various DUC or Radio ports. Which device? Which version >>>> of UHD? >>>> Yes, you can start them synchronized by providing the same start time >>>> to each channel. >>>> Rob >>>> >>>> On Sat, Sep 12, 2020 at 9:42 AM Ofer Saferman via USRP-users < >>>> [email protected]> wrote: >>>> >>>>> Hello, >>>>> >>>>> I would like to extend the example called >>>>> "rfnoc_replay_sample_from_file" to play 2 files, one for Tx1 and one for >>>>> Tx2. >>>>> I would also like both playbacks to start simultaneously (be >>>>> synchronized). Is the synchronization possible? >>>>> >>>>> What would be the methodology? Creating 2 instances of the replay >>>>> blocks each connected to a Tx channel? Are there even more than one replay >>>>> blocks available? >>>>> >>>>> I am walking blind in the woods here and any direction would be >>>>> helpful. >>>>> >>>>> Regards, >>>>> 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 >>>>> [email protected] >>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_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 >>> [email protected] >>> http://lists.ettus.com/mailman/listinfo/usrp-users_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 [email protected] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
