Hi Josh,
Thanks for your responses. I have looked all the example source code in the
repo over the last few days.
You are correct in that when the thread "wakes" up, it sends a burst. I
have configured it to send one cycle of a complex exponential.
Here is my function now. I am setting the both burst flags to true and the
time spec flag to false (I want it to send out the buffer immediatly)
{
Int32 burstSizeSamps = 20;
vector<complex<Float32> > vec(burstSizeSamps);
m_pSdev->set_time_now(uhd::time_spec_t(0.0));
// Set up tx params. We wish to send a burst.
//
http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/repository/revisions/master/entry/host/examples/test_async_messages.cpp
uhd::tx_metadata_t md;
md.start_of_burst = true;
md.end_of_burst = true;
md.has_time_spec = false;
//Float64 seconds_in_future = 1;
//md.time_spec = uhd::time_spec_t(seconds_in_future);
Float32 v = 0;
for (Int32 k=0;k<vec.size();++k)
{
v = 2*M_PI*(Float32(k)/Float32(vec.size()));
vec[k] = complex<Float32>(0.3*cos(v), 0.3*sin(v));
//cout << vec[k] << " ";
}
cout << endl;
// Send the entire contents of the buffer
// This should be the only place where data is sent over the air!
cout << "sending size [cpx samps]: " << vec.size() << endl;
m_pDev->send(&vec.front(), vec.size(),
md,uhd::io_type_t::COMPLEX_FLOAT32, uhd::device::SEND_MODE_FULL_BUFF);
}
However, this still does not work. For burstSizeSamps > 10, I can only see
~10-20 samps that have amplitude on the rx end. I tried doubling the samp
rate of the rx part (for sanity checking) and then I can see twice as much.
I have modified burstSizeSamps and get the following number of samps with
samplitude at the rx:
burstSizeSamps numSamps at rx with abs()>0.01
1 ~1-2
10 ~10
20 ~10-20
100 ~10-20
1000 ~10-20
Any ideas on why this isnt working?
Thanks for your help so far,
Isaac
On Wed, Jan 26, 2011 at 11:35 PM, Josh Blum <j...@ettus.com> wrote:
>
> > If Im always just sending a burst message when I tx, is it safe to say
> that
> > I should always have the EOB flag set? My messages may be as large as a
> few
>
> I believe so, see below
>
> > thousand bytes, but I dont plan to do any continuous streaming.
> Currently,
> > the Tx thread has a queue that it just works off where each item in the
> > queue is a message that could be as large as a few thousand samples. The
> > thread wakes up every so many ms and then says Hey! theres messages to
> send
> > and then one-by-one sends each message as a burst.
> >
>
> To get the terminology strait. It sounds like that each time the thread
> "wakes" up to send, its sending a new burst.
>
> The burst flags convey to the driver and the hardware that the samples
> presented are part of one continuous stream. Suppose you have a
> continuous stream of samples. The first call to send should have start
> of burst set, and the last call should have end of burst set. If you
> send all the samples in a single call to send, then set both start and
> end of burst flags.
>
> This code needlessly fragments a send operation into several smaller
> ones as an example of how to use the flags:
>
> http://code.ettus.com/redmine/ettus/projects/uhd/repository/revisions/master/entry/host/examples/tx_timed_samples.cpp#L94
>
> -josh
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
