size_t num_tx_samps = 0;

//send the entire packet (driver fragments internally)
//num_tx_samps = m_pDev->send(&pVec->front(), pVec->size(),

Hi All, I updated to the new UHD interface (the one that uses multi_usrp and tx_streamer). I am seeing a problem with spurious samples being sent which looks similar to the problem I had here: http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2011-January/000541.html with the old interface. My code worked fine with the old interface after I found a bug in it which caused this problem but was fixed. Here is sample code that sends a burst of 100 samples all with the same value. // Set up tx params. We wish to send a burst. uhd::tx_metadata_t md; md.start_of_burst = true; md.end_of_burst = true; md.has_time_spec = false; size_t num_tx_samps = 0; //send the entire packet (driver fragments internally) //num_tx_samps = m_pDev->send(&pVec->front(), pVec->size(), md,uhd::io_type_t::COMPLEX_FLOAT32,uhd::device::SEND_MODE_FULL_BUFF); // New interface usage uhd::stream_args_t stream_args("fc32", "sc16"); uhd::tx_streamer::sptr tx_stream = m_pDev->get_tx_stream(stream_args); num_tx_samps = tx_stream->send(&pVec->front(), pVec->size(), md); pVec is 100 complex samples long. The output isnt right when I look at it. There's spurious energy floating around. Thanks in advance, Isaac

 size_t num_tx_samps = 0;

 //send the entire packet (driver fragments internally)
 //num_tx_samps = m_pDev->send(&pVec->front(), pVec->size(),

On Tue, May 1, 2012 at 10:28 AM, Isaac Gerg <isaac.gerg@gergltd.com> wrote: > Hi All, > > I updated to the new UHD interface (the one that uses multi_usrp and > tx_streamer). I am seeing a problem with spurious samples being sent which > looks similar to the problem I had here: > http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2011-January/000541.html > with the old interface. My code worked fine with the old interface after I > found a bug in it which caused this problem but was fixed. > > Here is sample code that sends a burst of 100 samples all with the same > value. > // Set up tx params. We wish to send a burst. > uhd::tx_metadata_t md; > md.start_of_burst = true; > md.end_of_burst = true; > md.has_time_spec = false; > > size_t num_tx_samps = 0; > > //send the entire packet (driver fragments internally) > //num_tx_samps = m_pDev->send(&pVec->front(), pVec->size(), > md,uhd::io_type_t::COMPLEX_FLOAT32,uhd::device::SEND_MODE_FULL_BUFF); > > // New interface usage > uhd::stream_args_t stream_args("fc32", "sc16"); > uhd::tx_streamer::sptr tx_stream = m_pDev->get_tx_stream(stream_args); > num_tx_samps = tx_stream->send(&pVec->front(), pVec->size(), md); > > pVec is 100 complex samples long. > > The output isnt right when I look at it. There's spurious energy floating > around. > Isaac, Can you please elaborate a bit? Can you provide your data samples, a plot of what you are observing, and a plot or description of what you believe you should be seeing? Thanks, Nick > > Thanks in advance, > Isaac > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > >

 size_t num_tx_samps = 0;

 //send the entire packet (driver fragments internally)
 //num_tx_samps = m_pDev->send(&pVec->front(), pVec->size(),

Hi Nick, I am using the LF RX/TX boards on a USRP1 with the UHD interface. I am transmitting at baseband (fc=0) with a fs of 250e3. When I send a 250 sample burst with the I/Q parts being float32 and being set to 1.0, I get a burst on the Rx end that is about 1330 samples long, sometimes more sometimes less. I have code that flushes the rx buffer so I know its not any kind of "left over" signal. I had a similar problem January 2011 using the old UHD interface (the one with the single_usrp::make) and it turned out to be a bug Josh found. What I am seeing from my experiments is something very similar to what saw last January. I should add that I _am_ using the new tx_streamer interface. Isaac On Tue, May 1, 2012 at 1:39 PM, Nick Foster <nick@ettus.com> wrote: > On Tue, May 1, 2012 at 10:28 AM, Isaac Gerg <isaac.gerg@gergltd.com>wrote: > >> Hi All, >> >> I updated to the new UHD interface (the one that uses multi_usrp and >> tx_streamer). I am seeing a problem with spurious samples being sent which >> looks similar to the problem I had here: >> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2011-January/000541.html >> with the old interface. My code worked fine with the old interface after I >> found a bug in it which caused this problem but was fixed. >> >> Here is sample code that sends a burst of 100 samples all with the same >> value. >> // Set up tx params. We wish to send a burst. >> uhd::tx_metadata_t md; >> md.start_of_burst = true; >> md.end_of_burst = true; >> md.has_time_spec = false; >> >> size_t num_tx_samps = 0; >> >> //send the entire packet (driver fragments internally) >> //num_tx_samps = m_pDev->send(&pVec->front(), pVec->size(), >> md,uhd::io_type_t::COMPLEX_FLOAT32,uhd::device::SEND_MODE_FULL_BUFF); >> >> // New interface usage >> uhd::stream_args_t stream_args("fc32", "sc16"); >> uhd::tx_streamer::sptr tx_stream = m_pDev->get_tx_stream(stream_args); >> num_tx_samps = tx_stream->send(&pVec->front(), pVec->size(), md); >> >> pVec is 100 complex samples long. >> >> The output isnt right when I look at it. There's spurious energy >> floating around. >> > > Isaac, > > Can you please elaborate a bit? Can you provide your data samples, a plot > of what you are observing, and a plot or description of what you believe > you should be seeing? > > Thanks, > Nick > > >> >> Thanks in advance, >> Isaac >> >> _______________________________________________ >> USRP-users mailing list >> USRP-users@lists.ettus.com >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> >> >

 size_t num_tx_samps = 0;

 //send the entire packet (driver fragments internally)
 //num_tx_samps = m_pDev->send(&pVec->front(), pVec->size(),

Hi again Nick, It's early for me here :) I should be more clear -- the bug I found was in the ettus code. I expect to see a burst of roughly 250 samples but I get one that is many times longer. Isaac On Wed, May 2, 2012 at 8:30 AM, Isaac Gerg <isaac.gerg@gergltd.com> wrote: > Hi Nick, > > I am using the LF RX/TX boards on a USRP1 with the UHD interface. I am > transmitting at baseband (fc=0) with a fs of 250e3. When I send a 250 > sample burst with the I/Q parts being float32 and being set to 1.0, I get a > burst on the Rx end that is about 1330 samples long, sometimes more > sometimes less. I have code that flushes the rx buffer so I know its not > any kind of "left over" signal. > > I had a similar problem January 2011 using the old UHD interface (the one > with the single_usrp::make) and it turned out to be a bug Josh found. What > I am seeing from my experiments is something very similar to what saw last > January. > > I should add that I _am_ using the new tx_streamer interface. > > Isaac > > > On Tue, May 1, 2012 at 1:39 PM, Nick Foster <nick@ettus.com> wrote: > >> On Tue, May 1, 2012 at 10:28 AM, Isaac Gerg <isaac.gerg@gergltd.com>wrote: >> >>> Hi All, >>> >>> I updated to the new UHD interface (the one that uses multi_usrp and >>> tx_streamer). I am seeing a problem with spurious samples being sent which >>> looks similar to the problem I had here: >>> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2011-January/000541.html >>> with the old interface. My code worked fine with the old interface after I >>> found a bug in it which caused this problem but was fixed. >>> >>> Here is sample code that sends a burst of 100 samples all with the same >>> value. >>> // Set up tx params. We wish to send a burst. >>> uhd::tx_metadata_t md; >>> md.start_of_burst = true; >>> md.end_of_burst = true; >>> md.has_time_spec = false; >>> >>> size_t num_tx_samps = 0; >>> >>> //send the entire packet (driver fragments internally) >>> //num_tx_samps = m_pDev->send(&pVec->front(), pVec->size(), >>> md,uhd::io_type_t::COMPLEX_FLOAT32,uhd::device::SEND_MODE_FULL_BUFF); >>> >>> // New interface usage >>> uhd::stream_args_t stream_args("fc32", "sc16"); >>> uhd::tx_streamer::sptr tx_stream = m_pDev->get_tx_stream(stream_args); >>> num_tx_samps = tx_stream->send(&pVec->front(), pVec->size(), md); >>> >>> pVec is 100 complex samples long. >>> >>> The output isnt right when I look at it. There's spurious energy >>> floating around. >>> >> >> Isaac, >> >> Can you please elaborate a bit? Can you provide your data samples, a plot >> of what you are observing, and a plot or description of what you believe >> you should be seeing? >> >> Thanks, >> Nick >> >> >>> >>> Thanks in advance, >>> Isaac >>> >>> _______________________________________________ >>> USRP-users mailing list >>> USRP-users@lists.ettus.com >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>> >>> >> >

 size_t num_tx_samps = 0;

 //send the entire packet (driver fragments internally)
 //num_tx_samps = m_pDev->send(&pVec->front(), pVec->size(),

I've hooked my USRP1 up to an oscilloscope and can see the following 1. When I try to tx 250 samps and pad the heck out of it with tons of zeros, I *sometimes* get a burst of 1ms. 2. When I don't do the padding and simply try to send 250 samps, I don't see the burst. I get something like looks like a decaying exponential in terms of magnitude. It looks like something with the sending 250 samps by itself does not work correctly. This previously worked with the old UHD interface on my USRP1. Isaac On Wed, May 2, 2012 at 8:33 AM, Isaac Gerg <isaac.gerg@gergltd.com> wrote: > Hi again Nick, > > It's early for me here :) I should be more clear -- the bug I found was > in the ettus code. I expect to see a burst of roughly 250 samples but I > get one that is many times longer. > > Isaac > > > On Wed, May 2, 2012 at 8:30 AM, Isaac Gerg <isaac.gerg@gergltd.com> wrote: > >> Hi Nick, >> >> I am using the LF RX/TX boards on a USRP1 with the UHD interface. I am >> transmitting at baseband (fc=0) with a fs of 250e3. When I send a 250 >> sample burst with the I/Q parts being float32 and being set to 1.0, I get a >> burst on the Rx end that is about 1330 samples long, sometimes more >> sometimes less. I have code that flushes the rx buffer so I know its not >> any kind of "left over" signal. >> >> I had a similar problem January 2011 using the old UHD interface (the one >> with the single_usrp::make) and it turned out to be a bug Josh found. What >> I am seeing from my experiments is something very similar to what saw last >> January. >> >> I should add that I _am_ using the new tx_streamer interface. >> >> Isaac >> >> >> On Tue, May 1, 2012 at 1:39 PM, Nick Foster <nick@ettus.com> wrote: >> >>> On Tue, May 1, 2012 at 10:28 AM, Isaac Gerg <isaac.gerg@gergltd.com>wrote: >>> >>>> Hi All, >>>> >>>> I updated to the new UHD interface (the one that uses multi_usrp and >>>> tx_streamer). I am seeing a problem with spurious samples being sent which >>>> looks similar to the problem I had here: >>>> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2011-January/000541.html >>>> with the old interface. My code worked fine with the old interface after I >>>> found a bug in it which caused this problem but was fixed. >>>> >>>> Here is sample code that sends a burst of 100 samples all with the same >>>> value. >>>> // Set up tx params. We wish to send a burst. >>>> uhd::tx_metadata_t md; >>>> md.start_of_burst = true; >>>> md.end_of_burst = true; >>>> md.has_time_spec = false; >>>> >>>> size_t num_tx_samps = 0; >>>> >>>> //send the entire packet (driver fragments internally) >>>> //num_tx_samps = m_pDev->send(&pVec->front(), pVec->size(), >>>> md,uhd::io_type_t::COMPLEX_FLOAT32,uhd::device::SEND_MODE_FULL_BUFF); >>>> >>>> // New interface usage >>>> uhd::stream_args_t stream_args("fc32", "sc16"); >>>> uhd::tx_streamer::sptr tx_stream = m_pDev->get_tx_stream(stream_args); >>>> num_tx_samps = tx_stream->send(&pVec->front(), pVec->size(), md); >>>> >>>> pVec is 100 complex samples long. >>>> >>>> The output isnt right when I look at it. There's spurious energy >>>> floating around. >>>> >>> >>> Isaac, >>> >>> Can you please elaborate a bit? Can you provide your data samples, a >>> plot of what you are observing, and a plot or description of what you >>> believe you should be seeing? >>> >>> Thanks, >>> Nick >>> >>> >>>> >>>> Thanks in advance, >>>> Isaac >>>> >>>> _______________________________________________ >>>> USRP-users mailing list >>>> USRP-users@lists.ettus.com >>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>> >>>> >>> >> >

 size_t num_tx_samps = 0;

 //send the entire packet (driver fragments internally)
 //num_tx_samps = m_pDev->send(&pVec->front(), pVec->size(),

I have tried to zero pad my bursts to see if this flushes something out in the UHD interface. It helps somewhat. However, when I try to send something like 40e3 samps with a single send call (start and end of burst set), sometimes the UHD segfaults. Isaac On Wed, May 2, 2012 at 10:32 AM, Isaac Gerg <isaac.gerg@gergltd.com> wrote: > I've hooked my USRP1 up to an oscilloscope and can see the following > 1. When I try to tx 250 samps and pad the heck out of it with tons of > zeros, I *sometimes* get a burst of 1ms. > 2. When I don't do the padding and simply try to send 250 samps, I don't > see the burst. I get something like looks like a decaying exponential in > terms of magnitude. > > It looks like something with the sending 250 samps by itself does not work > correctly. This previously worked with the old UHD interface on my USRP1. > > Isaac > > On Wed, May 2, 2012 at 8:33 AM, Isaac Gerg <isaac.gerg@gergltd.com> wrote: > >> Hi again Nick, >> >> It's early for me here :) I should be more clear -- the bug I found was >> in the ettus code. I expect to see a burst of roughly 250 samples but I >> get one that is many times longer. >> >> Isaac >> >> >> On Wed, May 2, 2012 at 8:30 AM, Isaac Gerg <isaac.gerg@gergltd.com>wrote: >> >>> Hi Nick, >>> >>> I am using the LF RX/TX boards on a USRP1 with the UHD interface. I am >>> transmitting at baseband (fc=0) with a fs of 250e3. When I send a 250 >>> sample burst with the I/Q parts being float32 and being set to 1.0, I get a >>> burst on the Rx end that is about 1330 samples long, sometimes more >>> sometimes less. I have code that flushes the rx buffer so I know its not >>> any kind of "left over" signal. >>> >>> I had a similar problem January 2011 using the old UHD interface (the >>> one with the single_usrp::make) and it turned out to be a bug Josh found. >>> What I am seeing from my experiments is something very similar to what saw >>> last January. >>> >>> I should add that I _am_ using the new tx_streamer interface. >>> >>> Isaac >>> >>> >>> On Tue, May 1, 2012 at 1:39 PM, Nick Foster <nick@ettus.com> wrote: >>> >>>> On Tue, May 1, 2012 at 10:28 AM, Isaac Gerg <isaac.gerg@gergltd.com>wrote: >>>> >>>>> Hi All, >>>>> >>>>> I updated to the new UHD interface (the one that uses multi_usrp and >>>>> tx_streamer). I am seeing a problem with spurious samples being sent which >>>>> looks similar to the problem I had here: >>>>> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2011-January/000541.html >>>>> with the old interface. My code worked fine with the old interface after I >>>>> found a bug in it which caused this problem but was fixed. >>>>> >>>>> Here is sample code that sends a burst of 100 samples all with the >>>>> same value. >>>>> // Set up tx params. We wish to send a burst. >>>>> uhd::tx_metadata_t md; >>>>> md.start_of_burst = true; >>>>> md.end_of_burst = true; >>>>> md.has_time_spec = false; >>>>> >>>>> size_t num_tx_samps = 0; >>>>> >>>>> //send the entire packet (driver fragments internally) >>>>> //num_tx_samps = m_pDev->send(&pVec->front(), pVec->size(), >>>>> md,uhd::io_type_t::COMPLEX_FLOAT32,uhd::device::SEND_MODE_FULL_BUFF); >>>>> >>>>> // New interface usage >>>>> uhd::stream_args_t stream_args("fc32", "sc16"); >>>>> uhd::tx_streamer::sptr tx_stream = >>>>> m_pDev->get_tx_stream(stream_args); >>>>> num_tx_samps = tx_stream->send(&pVec->front(), pVec->size(), md); >>>>> >>>>> pVec is 100 complex samples long. >>>>> >>>>> The output isnt right when I look at it. There's spurious energy >>>>> floating around. >>>>> >>>> >>>> Isaac, >>>> >>>> Can you please elaborate a bit? Can you provide your data samples, a >>>> plot of what you are observing, and a plot or description of what you >>>> believe you should be seeing? >>>> >>>> Thanks, >>>> Nick >>>> >>>> >>>>> >>>>> Thanks in advance, >>>>> Isaac >>>>> >>>>> _______________________________________________ >>>>> USRP-users mailing list >>>>> USRP-users@lists.ettus.com >>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>> >>>>> >>>> >>> >> >

On 05/02/2012 05:30 AM, Isaac Gerg wrote: > Hi Nick, > > I am using the LF RX/TX boards on a USRP1 with the UHD interface. I am So USRP1 doesnt really support the timed samples or bursty samples interface. Its really only on or off. There is some attempt to emulate the timed behaviour. But its just not exact. http://files.ettus.com/uhd_docs/manual/html/usrp1.html#missing-and-emulated-features I think that explains your observations. You cant really use USRP1 in this way. -Josh

Hi Josh, I am not using the timed interface. I would just like to send a burst of samples. The functionality is possible with a USRP1. I was doing it last year with a USRP1 before the old UHD interfaces went away. If you recall, I had this same problem and you found a bug in the driver code where a flush was not being done correctly. You patched it and then my application worked fine. Since moving to the new UHD interface, I am getting the same behavior I had last year before your patch. Thanks, Isaac On Wed, May 2, 2012 at 1:33 PM, Josh Blum <josh@ettus.com> wrote: > > > On 05/02/2012 05:30 AM, Isaac Gerg wrote: > > Hi Nick, > > > > I am using the LF RX/TX boards on a USRP1 with the UHD interface. I am > > So USRP1 doesnt really support the timed samples or bursty samples > interface. Its really only on or off. There is some attempt to emulate > the timed behaviour. But its just not exact. > > > http://files.ettus.com/uhd_docs/manual/html/usrp1.html#missing-and-emulated-features > > I think that explains your observations. You cant really use USRP1 in > this way. > > -Josh > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >

On 05/02/2012 10:37 AM, Isaac Gerg wrote: > Hi Josh, > > I am not using the timed interface. I would just like to send a burst of > samples. > > The functionality is possible with a USRP1. I was doing it last year with > a USRP1 before the old UHD interfaces went away. If you recall, I had this > same problem and you found a bug in the driver code where a flush was not > being done correctly. You patched it and then my application worked fine. > Since moving to the new UHD interface, I am getting the same behavior I > had last year before your patch. > Alright, flashbacks confirmed. The flushing code looks to be in there and in-tact. Have to give it a closer look. -josh > Thanks, > Isaac > > On Wed, May 2, 2012 at 1:33 PM, Josh Blum <josh@ettus.com> wrote: > >> >> >> On 05/02/2012 05:30 AM, Isaac Gerg wrote: >>> Hi Nick, >>> >>> I am using the LF RX/TX boards on a USRP1 with the UHD interface. I am >> >> So USRP1 doesnt really support the timed samples or bursty samples >> interface. Its really only on or off. There is some attempt to emulate >> the timed behaviour. But its just not exact. >> >> >> http://files.ettus.com/uhd_docs/manual/html/usrp1.html#missing-and-emulated-features >> >> I think that explains your observations. You cant really use USRP1 in >> this way. >> >> -Josh >> >> _______________________________________________ >> USRP-users mailing list >> USRP-users@lists.ettus.com >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> >

Josh, Hooked up the USRP1 to an o-scope. I see that sometimes, my 250 sample burst goes through just fine. Other times, its jumbled in a way that looks like the bursts are concatenated. Sometimes I see the decaying exponential. It looks similar to this (ignore the units, just the shape matches): http://www.innovatia.com/Design_Center/DC_images/image761.gif Thanks! Isaac On Wed, May 2, 2012 at 2:03 PM, Josh Blum <josh@ettus.com> wrote: > > > On 05/02/2012 10:37 AM, Isaac Gerg wrote: > > Hi Josh, > > > > I am not using the timed interface. I would just like to send a burst of > > samples. > > > > The functionality is possible with a USRP1. I was doing it last year > with > > a USRP1 before the old UHD interfaces went away. If you recall, I had > this > > same problem and you found a bug in the driver code where a flush was not > > being done correctly. You patched it and then my application worked > fine. > > Since moving to the new UHD interface, I am getting the same behavior I > > had last year before your patch. > > > > Alright, flashbacks confirmed. The flushing code looks to be in there > and in-tact. Have to give it a closer look. -josh > > > Thanks, > > Isaac > > > > On Wed, May 2, 2012 at 1:33 PM, Josh Blum <josh@ettus.com> wrote: > > > >> > >> > >> On 05/02/2012 05:30 AM, Isaac Gerg wrote: > >>> Hi Nick, > >>> > >>> I am using the LF RX/TX boards on a USRP1 with the UHD interface. I am > >> > >> So USRP1 doesnt really support the timed samples or bursty samples > >> interface. Its really only on or off. There is some attempt to emulate > >> the timed behaviour. But its just not exact. > >> > >> > >> > http://files.ettus.com/uhd_docs/manual/html/usrp1.html#missing-and-emulated-features > >> > >> I think that explains your observations. You cant really use USRP1 in > >> this way. > >> > >> -Josh > >> > >> _______________________________________________ > >> USRP-users mailing list > >> USRP-users@lists.ettus.com > >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > >> > > >