I just ran one of the UHD examples through my USRP1 and see the same problem I am experiencing. Its self evident through an oscope that the bursts are coming out of the USRP1 corrupt. The lengths are significantly different. This was not an issue with the old single_usrp object that was available in early editions of the UHD. Here is what I'm running: \UHD\share\uhd\examples>tx_bursts --rep-delay 3 --repeat --freq 10000 Isaac On Thu, May 24, 2012 at 10:46 AM, Isaac Gerg <isaac.gerg@gergltd.com> wrote: > I'm going to put off rebuilding the UHD for now in lieu of trying to get > any kind of signal out of the radio correctly, then scaling it back for my > application. > > I have lengthened my burst to ~0.2s by padding it with 0.1s of zeros to > the front and back of the signal. At fs = 250e3, I send 50680 samples over > the air . When I call send with that buffer, I get the following UHD error: > > UHD Error: > The vandal caught an unexpected exception AssertionError: > usrp_control_write > _cmd(VRQ_FPGA_SET_TX_ENABLE, on, 0) >= 0 > in void __cdecl fx2_ctrl_impl::usrp_tx_enable(bool) > at > C:\cygdrive\c\remote_fs_root\workspace\u08_win7\s\Win7_x64\stable\uhd_x > 64\host\lib\usrp\common\fx2_ctrl.cpp:353 > > > What am I doing wrong? > > Isaac > > > On Fri, May 18, 2012 at 5:25 PM, Josh Blum <josh@ettus.com> wrote: > >> >> >> On 05/17/2012 12:33 PM, Isaac Gerg wrote: >> > Hi Josh, >> > >> > I tried your suggestion about flushing with zeros and not setting the >> > EOB. It doesn't help. I can't do the other suggestions because I >> > cant get the thing to build correctly in windows. >> > >> >> Any error in particularthat I could help you with? >> >> > I'm send bursts every 2 seconds that start at 1ms in length and >> > increase every time buy 1 ms. So 4 bursts later, my burst is 4ms in >> > length. What I am seeing is that I get nothing until burst 6/7. What >> > comes out is a burst that is 4ms long. It like the samples are >> > getting jammed up in a buffer somewhere. >> > >> > What's an optimal signal length to send out of the USRP1? Id be happy >> > to pad my signal with noise so that it can go out over the air >> > correctly. There's has to be a signal I can send out that the USRP >> > will function correctly with. >> > >> >> It might be most handy to use the streamer->get_max_num_samps(). >> Basically, whenever you call send, all samples up to a multiple of 512 >> bytes are committed over USB. So if you dont have any remainder, then >> there arent any samples to hang around in uncommitted buffers. >> >> The submissions are around max 4000 samples, so that may or may not >> describe what you are seeing, depends on how low your sample rate may >> be, and how many samples per call to send(). >> >> -josh >> > >

  void enable_tx(bool enb){
      _tx_enabled = enb;
      _fx2_ctrl->usrp_tx_enable(enb);

> Here is what I'm running: > \UHD\share\uhd\examples>tx_bursts --rep-delay 3 --repeat --freq 10000 > Looks like the DAC is continuing to modulate. Even though the application stopped feeding it zeros, the modulator in the DAC is still spinning. Apparently flushing out zeros isnt doing the trick. It looks like the best thing ever is to just shutoff the digital part of the ADC when the USRP tx state machine is shutoff. The output of that tx_bursts app then looks quiet in between the bursts: > void enable_tx(bool enb){ > _tx_enabled = enb; > _fx2_ctrl->usrp_tx_enable(enb); > + BOOST_FOREACH(const std::string &key, _dbc.keys()) > + { > + _dbc[key].codec->enable_tx_digital(enb); > + } > } I cant think of a downside to this yet, so this diff should get in there. As far as older UHDs working, I dont even. The tx state machine was actually not disabled, and this somehow led to underflow condition and the output shutting off, possibly due to zeros being flushed out. -josh

  void enable_tx(bool enb){
      _tx_enabled = enb;
      _fx2_ctrl->usrp_tx_enable(enb);

Hi Josh, Is the diff you suggest in one of the releases of the UHD that I can download and use today? Isaac On Tue, May 29, 2012 at 2:17 AM, Josh Blum <josh@ettus.com> wrote: > > > Here is what I'm running: > > \UHD\share\uhd\examples>tx_bursts --rep-delay 3 --repeat --freq 10000 > > > > Looks like the DAC is continuing to modulate. Even though the > application stopped feeding it zeros, the modulator in the DAC is still > spinning. Apparently flushing out zeros isnt doing the trick. > > It looks like the best thing ever is to just shutoff the digital part of > the ADC when the USRP tx state machine is shutoff. The output of that > tx_bursts app then looks quiet in between the bursts: > > > void enable_tx(bool enb){ > > _tx_enabled = enb; > > _fx2_ctrl->usrp_tx_enable(enb); > > + BOOST_FOREACH(const std::string &key, _dbc.keys()) > > + { > > + _dbc[key].codec->enable_tx_digital(enb); > > + } > > } > > I cant think of a downside to this yet, so this diff should get in there. > > As far as older UHDs working, I dont even. The tx state machine was > actually not disabled, and this somehow led to underflow condition and > the output shutting off, possibly due to zeros being flushed out. > > -josh >