Dear Rob, 1. Can you explain if the USRP may be configured only in receive/transmit mode or is it also possible to configure in a single mode (a pure transmitter or a pure receiver) using both optical interfaces for the task?
2. In the first remark in your email, you mentioned that the host-to-USRP streaming does not work at 200 MS/s for the transmit case. Does it mean that in the USRP-to-host mode it supports 200MS/s per channel in receiving mode while the host to USRP supports only 100MS/s per channel? 3. About storing the samples on the USRP, does anyone know that if Ettus has any plans to add this capability to the USRPs? Best, Farnaz On Mon, Jul 30, 2018 at 6:27 PM, Jason Matusiak < ja...@gardettoengineering.com> wrote: > I've actually done this with success, unfortunately, I am not allowed to > share it :(. It wasn't too hard, I used a core in the block to hold the > data, and then I just repeated it when I sent it out over and over. > > The catch was that there was a little bit of an issue within rfnoc at the > time (you can see mailing lists conversations from back then in the > archives) that kept it from kicking off at startup (an enable switch worked > fine though). Jonathon P helped with a patch to get me going, but that > obviously has been mainlined by now since they have a siggen working (it > didn't exist yet when I did my block). The issue had something to do with > the block sending data before everything have been initialized and came up > properly. > > So it isn't too bad to create one. Good luck! > > > > --------- Original Message --------- > Subject: Re: [USRP-users] USRP X310 Remote Configuration > From: "Rob Kossler via USRP-users" <usrp-users@lists.ettus.com> > Date: 7/30/18 9:33 am > To: "Farnaz Chamanzadeh" <farnaz.c...@gmail.com> > Cc: "usrp-users" <usrp-users@lists.ettus.com> > > Perhaps look at the RFNoC siggen block. You will need to add some > component such as a block memory or fifo to store the samples on the fpga > and then you will need a way to populate the memory and then play it out > when desired. > > Rob > > On Mon, Jul 30, 2018 at 3:49 AM Farnaz Chamanzadeh <farnaz.c...@gmail.com> > wrote: > >> Dear Rob, >> Thanks for your helpful response. The reason that we need to use a switch >> is due to hour host hardware limits, which only have one 10GBE. >> About the second remark in your email, do you have an example or a >> reference where a similar case was implemented which we can use as a >> guideline for our implementation? >> >> Best regards, >> Farnaz >> >> On Thu, Jul 26, 2018 at 7:52 PM, Rob Kossler <rkoss...@nd.edu> wrote: >> >>> Hi Farnaz, >>> A couple of remarks and questions >>> - Remark 1: in order to get 200 MS/s transmit streaming, you will NEED >>> to have the samples on the USRP. The host-to-USRP streaming does not work >>> at 200 MS/s for the transmit case (unless something has recently changed). >>> The host-to-USRP max for transmit is 100 MS/s per channel >>> - Remark 2: that leads into your question about having the samples >>> stored on the USRP rather than streamed from host. This is not presently a >>> capability, but can be added with some modest FPGA work. I have been >>> desiring such capability for a couple of years - I hope that Ettus adds >>> such capability in the future. >>> - Question 1: why do you plan to use a 10gbe switch with a single >>> connection to the host PC? Why not have multiple 10Gbe links at the PC >>> which connect to each USRP individually. A NIC such as Intel XL-710 >>> provides 4 10gbe links. >>> >>> Rob >>> >>> >>> On Thu, Jul 26, 2018 at 12:13 PM Farnaz Chamanzadeh via USRP-users < >>> usrp-users@lists.ettus.com> wrote: >>> >>>> Dears, >>>> >>>> To be more specific, we want to control multiple USRPs with one >>>> (remote) computer. We would like to stream known and periodic signal from >>>> each USRP. The sequence on each USRP is unique and is different from other >>>> USRPs. >>>> >>>> Since the samples from each USRP are known, it would be more >>>> convenient if we can generate the samples once and preferably store them >>>> locally on each USRP. In this configuration, we want to use the host >>>> computer to send control commands to the USRPs specifying when each of them >>>> must transmit its specific samples. The USRPs are assumed to be >>>> synchronized, so the control commands from the host will generate a TDMA >>>> scheme. Each USRP will start signal transmission upon receiving the control >>>> command from the host computer. I would like to know that: >>>> >>>> 1. Is it possible to store the samples on the USRPs? or should we >>>> stream the samples from the host computer to the USRPs for each >>>> transmission? >>>> 2. Can we use the full bandwidth and 200MS/s in this setup? >>>> 3. After knowing the answer to the previous question, I would like to >>>> know how we can implement it? do you happen to have a demo or an example >>>> that can guide us in this implementation? >>>> >>>> Best, >>>> Farnaz >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Wed, Jun 27, 2018 at 4:50 AM, Michael West <michael.w...@ettus.com> >>>> wrote: >>>> >>>>> Hi Farnaz, >>>>> >>>>> To clarify and expand on Marcus' comments, the answer is maybe. You >>>>> can do burst captures and transmissions at full rate and you can even use >>>>> timed commands to synchronize them, but there are limitations. If you can >>>>> describe in more detail what you want to do, we can more clearly tell you >>>>> if it is possible. How many channels do you plan to do simultaneously? >>>>> How many 10 GbE connections between the host and switch? How many 10 GbE >>>>> connections between each USRP and the switch? >>>>> >>>>> There is buffering of the TX samples on the X310 and it is >>>>> configurable. The current default is 32 MB. The DRAM is a total of 1 GB, >>>>> and it can be divided up however necessary. >>>>> >>>>> Regards, >>>>> Michael >>>>> >>>>> On Mon, Jun 25, 2018 at 12:23 PM, Marcus Müller via USRP-users < >>>>> usrp-users@lists.ettus.com> wrote: >>>>> >>>>>> Dear Fernaz, >>>>>> >>>>>> you can't cheat 10Gig bandwidth! If you time-share any medium, then >>>>>> it's bandwidth must be shared. Since ethernet is de facto a >>>>>> timesharing >>>>>> thing, anyway, no, this won't work: >>>>>> Since you need to push through all the data through a single 10GigE >>>>>> connection, your 10 gigabits per second need to be divided along *all >>>>>> simultaneously operating* USRPs. So, if you have, say 10 USRPs, and >>>>>> all >>>>>> should be working at the same time, you've only got 1 gigabit per >>>>>> second per USRP, which limits you to about 25 MSample/s per USRP. It's >>>>>> really the same principle as a single internet access being shared by >>>>>> all people attached to the same router. >>>>>> >>>>>> Now, if these USRPs *don't* have to transmit all at the same time, >>>>>> then >>>>>> more is possible. >>>>>> >>>>>> > Also, does anyone know if it is possible to store the samples on the >>>>>> transmit USRPs? >>>>>> >>>>>> I'll go with a: no, at least probably not like you hope it is. Can you >>>>>> elaborate on your use case? Maybe we can help you if we better >>>>>> understand what you're trying to implement, from a bit of distance? >>>>>> >>>>>> Best regards, >>>>>> Marcus >>>>>> >>>>>> On Mon, 2018-06-25 at 20:32 +0200, Farnaz Chamanzadeh via USRP-users >>>>>> wrote: >>>>>> > Dear all, >>>>>> > >>>>>> > I want to connect multiple USRP X310 to one host PC and control >>>>>> them >>>>>> > all from that Pc, using one 10Gigabit Ethernet switch. My question >>>>>> > is that if it is possible to stream from each USRP in a different >>>>>> > time slot using the full bandwidth and 200MS/s in a setup similar to >>>>>> > the picture below? >>>>>> > >>>>>> > Also, does anyone know if it is possible to store the samples on the >>>>>> > transmit USRPs? >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > Best, >>>>>> > Farnaz >>>>>> > >>>>>> > _______________________________________________ >>>>>> > USRP-users mailing list >>>>>> > USRP-users@lists.ettus.com >>>>>> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>>> >>>>>> _______________________________________________ >>>>>> USRP-users mailing list >>>>>> USRP-users@lists.ettus.com >>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>> >>>>> _______________________________________________ >>>> USRP-users mailing list >>>> USRP-users@lists.ettus.com >>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>> >>> _______________________________________________ USRP-users mailing list > USRP-users@lists.ettus.com http://lists.ettus.com/ > mailman/listinfo/usrp-users_lists.ettus.com > >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
