Using UHD, trying to tx and rx samples simultaneously

I am using the USRP1 with a Basic RX and Basic TX. I want to send a
message
out the Basic TX and receive it with my Basic Rx. I am using the
Complex
Float32 datatype.

Using Device: Single USRP:
Device: usrp1 device
Mboard: usrp1 mboard - 48cc208a
RX DSP: usrp1 ddc 2X + hb
RX Channel: 0
RX Dboard: usrp1 dboard (rx unit) - A
RX Subdev: Basic RX (0x0001) - AB
TX DSP: usrp1 duc 2X
TX Channel: 0
TX Dboard: usrp1 dboard (tx unit) - A
TX Subdev: Basic TX (0x0000) - AB

Setting RX Rate: 250000.000000 sps…
Actual RX Rate: 250000.000000 sps…

Setting RX Freq: 0.100000 Mhz…
Actual RX Freq: 0.100000 Mhz…

Setting RX Gain: 0.000000 dB…
Actual RX Gain: 0.000000 dB…

Setting TX Rate: 0.250000 Msps…
Actual TX Rate: 0.250000 Msps…

Setting TX Freq: 0.100000 Mhz…
Actual TX Freq: 0.100000 Mhz…

Setting TX Gain: 0.000000 dB…
Actual TX Gain: 0.000000 dB…

I have used the code from
http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/repository/revisions/master/entry/host/examples/to
set up software which has three threads. The first thread spawns two
threads a rx and tx. The rx keeps receiving until it get the message
from
the tx. The tx sends a 94 sample message every 10 seconds.

The rx thread looks at the data and prints out a message when the
data.real()>0.01. (The data is normally (0,0).

When i start the program up… the rx prints out a bunch of samps. Then
it
stops. 10 seconds goes by. the tx thread wakes up and sends its first
message, the rx gets nothing. 10 more seconds goes by, the tx sends
out
another 94 sample message. Now, TONS of samples come out. In fact, the
program print indefinitely.

What is going on here? It seems like the AGC is getting modified after
the
2nd tx. Is this true?

Isaac

When i start the program up… the rx prints out a bunch of samps. Then it
stops. 10 seconds goes by. the tx thread wakes up and sends its first
message, the rx gets nothing. 10 more seconds goes by, the tx sends out
another 94 sample message. Now, TONS of samples come out. In fact, the
program print indefinitely.

Are you setting end of burst when you send the 94 samples? Unlike the
other usrps, USRP1 will not necessarily flush to the transport layer
unless it sees EOB.

Without the EOB, it only sends 512 byte multiples and stores the
remainder. Since 944 is less than 512 bytes, nothing is sent on the
first transmit, and the data is stored. But by the next run, the buffer
has 94
4*2 which is enough to send 512 bytes and store a remainder of
240 bytes.

What is going on here? It seems like the AGC is getting modified after the
2nd tx. Is this true?

No such thing happens

-Josh

I will check on this tomorrow. Thanks for the information!

BTW Where can i find documentation for the stuff you mentioned?

Thanks,
Isaac

On 01/26/2011 06:59 PM, Isaac G. wrote:

I will check on this tomorrow. Thanks for the information!

BTW Where can i find documentation for the stuff you mentioned?

Well, you really should be setting end_of_burst when you “end a burst”.
Though I guess we have not confirmed that that was the issue. If you are
setting EOB, then perhaps there is an bug with the implementation of
said feature.

So the closest thing to docs would be the doxygen for metadata, and
perhaps the transmit examples:
http://www.ettus.com/uhd_docs/doxygen/html/structuhd_1_1tx__metadata__t.html#a00543aaaeb5a5d67b212778d6b5f1b53

I suppose I should add some relevant documentation to the emulated
features:
http://www.ettus.com/uhd_docs/manual/html/usrp1.html#missing-and-emulated-features

_josh

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

Hi, I’ve been working for a while now on adding DSP support for GNU
Radio using OMAP processors, specifically OMAP3530 which has a fixed
point C64x+ DSP. The following is a github for interested people to
download it:

git://github.com/alfayez/gr-dsp.git

I don’t have a USRP E100, I use a Beagleboard, but things should work
out the same. I’ve just recently upgraded to the Angstrom 2010 and the
37 kernel and to the best of my knowledge things are working smoothly.
I’ve done over the air testing with USRP 1’s but haven’t used the UHD
driver with it but that shouldn’t matter. I’d be interested in user
feedback especially E100 users.

almohanad (al) fayez

Josh,
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
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.

Isaac

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 > 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

HI,
I wonder if anyone here is working on TETRA?

I would like to hear about your experience with GR and TETRA
implementation and
if you have had any problems designing it.

Thanks in advance,
Farhad

Hi Michael,
I know this very well, I just wondered if anyone has used it together
with USRP
and GRC,

Thanks,
Farhad


From: Michael O. [email protected]
To: Farhad A. [email protected]
Cc: [email protected]
Sent: Thu, January 27, 2011 4:03:04 PM
Subject: Re: [Discuss-gnuradio] TETRA ?

On Thu, Jan 27, 2011 at 02:34:19AM -0800, Farhad A. wrote:

I wonder if anyone here is working on TETRA?

http://laforge.gnumonks.org/weblog/2011/01/22/

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs