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…
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?
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 944*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?
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.
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.
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.
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.
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(),
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