Hi Josh,

After more analysis with the scope today I noticed that the waveforms
of my bursts seemed to get queued up and when I send say burst 5, I
see burst 3 go out.

Also, what file has the implementation of the tx_streamer->send()
function?  With this interface, it looks like the parameter to capture
SEND_MODE_FULL_BUFF went away.

Have you had any time to check things out on your end?

Isaac

On Wed, May 2, 2012 at 2:39 PM, Isaac Gerg isaac.gerg@gergltd.com wrote:

On 05/03/2012 12:12 PM, Isaac Gerg wrote:

Its all in usrp1/io_impl.cpp

You should see that tx_stream_on_off is called with enable false when an
end of burst is set, and that flush_send_buff is called.

There wasnt really a distinction. If you just wanted to send 1 packet,
then you just set the length to be 1 packet and no more. So its always
full buffer basically.

I verified that the flush is being called when EOB is set. I havent had
time to look any closer.

Hope that helps,
-Josh

Josh,

The send call from tx_streamer doesnt match the interface in io_impl.

This has 4 arguments,
http://files.ettus.com/uhd_docs/doxygen/html/stream_8hpp_source.html

This has 6,
http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/repository/revisions/6c13ef7855dcfe9c825e819f69f219851387da25/entry/host/lib/usrp/usrp1/io_impl.cpp

I am looking for the implementation of send() call with 4 arguments.

Isaac

On Thu, May 3, 2012 at 5:01 PM, Josh Blum josh@ettus.com wrote:

Hi Josh,

Have you had any more time to look into my problem?  Is there
something I can do to help you?

Thanks,
Isaac

On Fri, May 4, 2012 at 9:27 AM, Isaac Gerg isaac.gerg@gergltd.com wrote:

On 05/08/2012 02:29 PM, Isaac Gerg wrote:

I think you are seeing that the DAC is still modulating the last sample
that it saw.

So, when you EOB, there are zeros flushed out, but it seems that USRP
FPGA transmit state machine is disabled before the zeros are seen in the
FPGA, so the DAC modulates the last known samples, not zero:

Here is a possible fix, dont disable TX state machine:
http://pastebin.com/D9SqYQ6n

Here is another, disable DAC along with TX state machine:
http://pastebin.com/YhVKq6KQ

You could also, from an application standpoint, not set EOB, but rather
send a packet's worth of zeros.

This is all very hairy because USRP1 isnt really capable of bursting.

-josh

Thanks Josh, I will try this later this week.

I don't understand what you mean that the USRP isn't capable of
bursting -- I mean, if it didnt, how would openBTS work?  Perhaps I'm
misunderstanding you.

Isaac

On Tue, May 8, 2012 at 7:04 PM, Josh Blum josh@ettus.com wrote:

On 05/09/2012 01:31 PM, Isaac Gerg wrote:

The problem is that things are asynchronous like shutting off transmit
with respect to the samples. Thats why we do EOB flag inline with the TX
packets in the later USRPs.

The EOB flag for USRP1 shuts off the transmitter, but its asynchronous
with respect to the samples. So its hard to flush out those last zeros.

OpenBTS has a customized FPGA image. If it is using the basically same
TX chain, then it might be left with TX enable, and every end'ing of
burst results in an underflow.

The benefit is that all the samples sent are guaranteed to be
transmitted. Not sure how that affects the ATR switching. But this is a
totally possible and reasonable usage model for USRP1+UHD.

-Josh

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.

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.

Thanks.
Isaac

On Tue, May 8, 2012 at 7:04 PM, Josh Blum josh@ettus.com wrote:

On 05/17/2012 12:33 PM, Isaac Gerg wrote:

Any error in particularthat I could help you 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

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: