Hi all, We're currently developing a demo around 4 USRP X310s, each of which is connected to a host PC through a gigabit ethernet switch. The host PC is using the GNU Radio interface to UHD installed via apt-get. Through a bit of trail and error, we've been able to receive ~9000 contiguous samples @ 100M samples/second from one USRP at a time before an overflow occurs. We're assuming that the overflows are due to limitations in the connection capacity. Despite this, large chunks of dropped samples are a non-issue for our application. We're more concerned about maintaining an extremely high sampling rate and acquiring short bursts of contiguous samples. However, we noticed that overflows cause the radio to re-initialize the RF front-end boards, which results in a rather undesirable transient behavior (see attachment). Is there any way to "ignore" these buffer overflows? If this requires us to modify and recompile any host-side UHD code, we're happy to do it. Thanks in advance! Best, Frank Liu

Frank, it's not quite that simple. When the radio overruns, it actually stops doing anything. What the host does is actually re-start it so you get any more samples at all. You might be better off doing timed receive bursts. If you want to use RFNoC, you can even use the DRAM FIFO to add 32 MB of FIFOs on the FPGA. Cheers, M On 09/22/2016 11:45 PM, Frank Liu via USRP-users wrote: > Hi all, > > We're currently developing a demo around 4 USRP X310s, each of which is > connected to a host PC through a gigabit ethernet switch. The host PC is > using the GNU Radio interface to UHD installed via apt-get. Through a > bit of trail and error, we've been able to receive ~9000 contiguous > samples @ 100M samples/second from one USRP at a time before an overflow > occurs. We're assuming that the overflows are due to limitations in the > connection capacity. > > Despite this, large chunks of dropped samples are a non-issue for our > application. We're more concerned about maintaining an extremely high > sampling rate and acquiring short bursts of contiguous samples. However, > we noticed that overflows cause the radio to re-initialize the RF > front-end boards, which results in a rather undesirable transient > behavior (see attachment). Is there any way to "ignore" these buffer > overflows? > > If this requires us to modify and recompile any host-side UHD code, > we're happy to do it. > > Thanks in advance! > > Best, > Frank Liu > > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >

Thanks for the prompt reply! My initial understanding was that we could do timed bursts by specifying NUM_SAMPS_AND_DONE when issuing stream commands, but this seems to result in a restart every time recv() is called. Is there a way to do these timed receive bursts without incurring transients? Just took a peek at RFNoC as well - looks awesome! I'll dive a bit deeper into the build process later tonight to see if we can utilize any of the modules in our application. Best, Frank On Fri, Sep 23, 2016 at 2:05 PM, Martin Braun via USRP-users < usrp-users@lists.ettus.com> wrote: > Frank, > > it's not quite that simple. When the radio overruns, it actually stops > doing anything. What the host does is actually re-start it so you get > any more samples at all. > > You might be better off doing timed receive bursts. If you want to use > RFNoC, you can even use the DRAM FIFO to add 32 MB of FIFOs on the FPGA. > > Cheers, > M > > On 09/22/2016 11:45 PM, Frank Liu via USRP-users wrote: > > Hi all, > > > > We're currently developing a demo around 4 USRP X310s, each of which is > > connected to a host PC through a gigabit ethernet switch. The host PC is > > using the GNU Radio interface to UHD installed via apt-get. Through a > > bit of trail and error, we've been able to receive ~9000 contiguous > > samples @ 100M samples/second from one USRP at a time before an overflow > > occurs. We're assuming that the overflows are due to limitations in the > > connection capacity. > > > > Despite this, large chunks of dropped samples are a non-issue for our > > application. We're more concerned about maintaining an extremely high > > sampling rate and acquiring short bursts of contiguous samples. However, > > we noticed that overflows cause the radio to re-initialize the RF > > front-end boards, which results in a rather undesirable transient > > behavior (see attachment). Is there any way to "ignore" these buffer > > overflows? > > > > If this requires us to modify and recompile any host-side UHD code, > > we're happy to do it. > > > > Thanks in advance! > > > > Best, > > Frank Liu > > > > > > _______________________________________________ > > 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 >

 Frank,

 it's not quite that simple. When the radio overruns, it actually stops
 doing anything. What the host does is actually re-start it so you get
 any more samples at all.

 You might be better off doing timed receive bursts. If you want to use
 RFNoC, you can even use the DRAM FIFO to add 32 MB of FIFOs on the FPGA.

 Cheers,
 M

 On 09/22/2016 11:45 PM, Frank Liu via USRP-users wrote:

 which is

 PC is

 overflow

 in the

 However,

 <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>

 _______________________________________________
 USRP-users mailing list
 USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
 http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
 <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>

On 09/23/2016 03:32 PM, Frank Liu wrote: > > Thanks for the prompt reply! My initial understanding was that we could > do timed bursts by specifying NUM_SAMPS_AND_DONE when issuing stream > commands, but this seems to result in a restart every time recv() is > called. Is there a way to do these timed receive bursts without > incurring transients? No, but you can start streaming a bit too early and discard samples. > Just took a peek at RFNoC as well - looks awesome! I'll dive a bit > deeper into the build process later tonight to see if we can utilize any > of the modules in our application. Let us know what you think! Cheers, Martin > > Best, > Frank > > On Fri, Sep 23, 2016 at 2:05 PM, Martin Braun via USRP-users > <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote: > > Frank, > > it's not quite that simple. When the radio overruns, it actually stops > doing anything. What the host does is actually re-start it so you get > any more samples at all. > > You might be better off doing timed receive bursts. If you want to use > RFNoC, you can even use the DRAM FIFO to add 32 MB of FIFOs on the FPGA. > > Cheers, > M > > On 09/22/2016 11:45 PM, Frank Liu via USRP-users wrote: > > Hi all, > > > > We're currently developing a demo around 4 USRP X310s, each of > which is > > connected to a host PC through a gigabit ethernet switch. The host > PC is > > using the GNU Radio interface to UHD installed via apt-get. Through a > > bit of trail and error, we've been able to receive ~9000 contiguous > > samples @ 100M samples/second from one USRP at a time before an > overflow > > occurs. We're assuming that the overflows are due to limitations > in the > > connection capacity. > > > > Despite this, large chunks of dropped samples are a non-issue for our > > application. We're more concerned about maintaining an extremely high > > sampling rate and acquiring short bursts of contiguous samples. > However, > > we noticed that overflows cause the radio to re-initialize the RF > > front-end boards, which results in a rather undesirable transient > > behavior (see attachment). Is there any way to "ignore" these buffer > > overflows? > > > > If this requires us to modify and recompile any host-side UHD code, > > we're happy to do it. > > > > Thanks in advance! > > > > Best, > > Frank Liu > > > > > > _______________________________________________ > > USRP-users mailing list > > USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com> > > http://lists.ettus.com/mailman/listinfo/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 <mailto:USRP-users@lists.ettus.com> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com> > >

 Frank,

 it's not quite that simple. When the radio overruns, it actually

 doing anything. What the host does is actually re-start it so you get
 any more samples at all.

 You might be better off doing timed receive bursts. If you want to

 RFNoC, you can even use the DRAM FIFO to add 32 MB of FIFOs on the

 Cheers,
 M

 On 09/22/2016 11:45 PM, Frank Liu via USRP-users wrote:

 which is

 PC is

 overflow

 in the

 However,

 <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>

 _______________________________________________
 USRP-users mailing list
 USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
 http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
 <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>

Unfortunately, we can't seem to acquire enough continuous samples for the transient behavior to die off. I assume adding an RX FIFO to the FPGA should fix the problem we're currently having, correct? On Mon, Sep 26, 2016 at 11:19 AM, Martin Braun via USRP-users < usrp-users@lists.ettus.com> wrote: > On 09/23/2016 03:32 PM, Frank Liu wrote: > > > > Thanks for the prompt reply! My initial understanding was that we could > > do timed bursts by specifying NUM_SAMPS_AND_DONE when issuing stream > > commands, but this seems to result in a restart every time recv() is > > called. Is there a way to do these timed receive bursts without > > incurring transients? > > No, but you can start streaming a bit too early and discard samples. > > > Just took a peek at RFNoC as well - looks awesome! I'll dive a bit > > deeper into the build process later tonight to see if we can utilize any > > of the modules in our application. > > Let us know what you think! > > Cheers, > Martin > > > > Best, > > Frank > > > > On Fri, Sep 23, 2016 at 2:05 PM, Martin Braun via USRP-users > > <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote: > > > > Frank, > > > > it's not quite that simple. When the radio overruns, it actually > stops > > doing anything. What the host does is actually re-start it so you get > > any more samples at all. > > > > You might be better off doing timed receive bursts. If you want to > use > > RFNoC, you can even use the DRAM FIFO to add 32 MB of FIFOs on the > FPGA. > > > > Cheers, > > M > > > > On 09/22/2016 11:45 PM, Frank Liu via USRP-users wrote: > > > Hi all, > > > > > > We're currently developing a demo around 4 USRP X310s, each of > > which is > > > connected to a host PC through a gigabit ethernet switch. The host > > PC is > > > using the GNU Radio interface to UHD installed via apt-get. > Through a > > > bit of trail and error, we've been able to receive ~9000 contiguous > > > samples @ 100M samples/second from one USRP at a time before an > > overflow > > > occurs. We're assuming that the overflows are due to limitations > > in the > > > connection capacity. > > > > > > Despite this, large chunks of dropped samples are a non-issue for > our > > > application. We're more concerned about maintaining an extremely > high > > > sampling rate and acquiring short bursts of contiguous samples. > > However, > > > we noticed that overflows cause the radio to re-initialize the RF > > > front-end boards, which results in a rather undesirable transient > > > behavior (see attachment). Is there any way to "ignore" these > buffer > > > overflows? > > > > > > If this requires us to modify and recompile any host-side UHD code, > > > we're happy to do it. > > > > > > Thanks in advance! > > > > > > Best, > > > Frank Liu > > > > > > > > > _______________________________________________ > > > USRP-users mailing list > > > USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com> > > > http://lists.ettus.com/mailman/listinfo/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 <mailto:USRP-users@lists.ettus.com> > > http://lists.ettus.com/mailman/listinfo/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 >