Help: CIR measurement problems using usrp_sounder.py

GNU Radio
1

Dear all,

I have been trying using the usrp_sounder.py script for measuring the
channel impulse response (CIR), but without success.

Q: - Have anyone succeeded? Does the FPGA-based script work as
advertised?

Here is what I got:
Firstly, making a “loopback” test worked great

usrp_sounder.py -g 50 -f 2.45e9 -d 12 -t -r -l -v -F loopback.log

followed by plotting the recorded CIR-values in Matlab:

loopback = read_complex_binary(‘loopback.log’,inf);
plot(abs(loopback))

This results in a nice looking “impulse-train”, i.e., one strong impulse
followed by near zero correlation values until the next PN-sequence
frame
(4095 values per 12-bit PN-period).
So far, so good!

However, when I try to send from one USRP with RFX2400 and receive with
another (same setup) I do not get a representative output (I believe!).
Distance between USRPs is about 10m, and placed in different rooms (with
wooden walls).
Rx> usrp_sounder.py -g 50 -f 2.45e9 -r -v -F CIRtest.log
Tx> usrp_sounder.py -f 2.45e9 -t -v

In this case I only see when plotting a continuous almost “random”
sequence
with relatively low but uniform max-amplitude, but no distinctive strong
correlation peaks at all ?!?
I do not understand why!? Although the USRP to USRP distance is
relatively
short (~10m) I would then expect a similar CIR-response as in the
loopback
test. That is, my expectation was not just one but a few relatively
strong
impulses, the rest of the long PN-period filled with much weaker
background
correlation noise. But I don’t get any strong correlation-peaks at all !
Not a single one that is well above the uniform bg correlation noise.
Q: - Can anyone explain this result??

It can not depend on a too weak received signal, since I tested to
monitor
it using the “ursp_fft.py” with the same UHDgain (= 50). In this case I
can
clearly see the broadband PN-signal in the frequency domain, well above
the
noise-floor (some 15-20 dB). Furthermore, by turning on and off the
PN-sequence transmitter during CIR-recording, I can also clearly notice
a
corresponding variation in the received signal strength when plotting in
Matlab afterwards - but not a single distinctive peak at all !?!? Again
just
the uniform background correlation noise! Hmmm, why this then?!

Q: - Have anyone had success with the “usrp_sounder.py” script?
Q: - Does it work as advertised, or what can my problem be?

I know it doesn’t contain synchronization, so the CIR’s should “roll”
between PN-periods, but that is not the problem here, since I get no
peaks?!

Help me get nice strong peaks, please!

Glad for any advice!

/ Rickard

Below a summary of how I used the “ursp_sounder.py” script:

Loopback:

usrp_sounder.py -g 50 -f 2.45e9 -d 12 -t -r -l -v -F loopback.log
Using PN code degree of 12 length 4095
Logging impulse records to file: loopback.log
Using smoothing alpha of 1.0
Setting PN code degree to 12
Enabling digital loopback.
Enabling transmitter.
gr_buffer::allocate_buffer: warning: tried to allocate
4 items of size 32760. Due to alignment requirements
512 were allocated. If this isn’t OK, consider padding
your structure to a power-of-two bytes.
On this platform, our allocation granularity is 4096 bytes.
gr_buffer::allocate_buffer: warning: tried to allocate
4 items of size 32760. Due to alignment requirements
512 were allocated. If this isn’t OK, consider padding
your structure to a power-of-two bytes.
On this platform, our allocation granularity is 4096 bytes.
Enter CTRL-C to stop.

Q: – Is it normal behaviour with the buffer-allocation warning above (I
get
it all the time when receiving, depending on the PN code length) ?

Receiver:
Rx > usrp_sounder.py -g 50 -f 2.45e9 -r -v -F CIRtest.log
Using PN code degree of 12 length 4095
Sounding frequency range is 2.434G to 2.466G
Logging impulse records to file: CIRtest.log
Using Flex 2400 Rx MIMO B for sounder receiver.
Setting receiver gain to 50.0
Using smoothing alpha of 1.0
Setting receiver frequency to 2.45G
Setting PN code degree to 12
Disabling digital loopback.
gr_buffer::allocate_buffer: warning: tried to allocate
4 items of size 32760. Due to alignment requirements
512 were allocated. If this isn’t OK, consider padding
your structure to a power-of-two bytes.
On this platform, our allocation granularity is 4096 bytes.
gr_buffer::allocate_buffer: warning: tried to allocate
4 items of size 32760. Due to alignment requirements
512 were allocated. If this isn’t OK, consider padding
your structure to a power-of-two bytes.
On this platform, our allocation granularity is 4096 bytes.
Enter CTRL-C to stop.

Transmitter:
Tx > usrp_sounder.py -f 2.45e9 -t -v
Using PN code degree of 12 length 4095
Sounding frequency range is 2.434G to 2.466G
Using Flex 2400 Tx MIMO B for sounder transmitter.
Setting transmitter frequency to 2.45G
Setting PN code degree to 12
Disabling digital loopback.
Enabling transmitter.
Press return to exit.

followed by plotting the recorded data in Matlab as shown above.

2

Have someone experience or other knowledge about the “usrp_sounder.py”
CIR-channel sounder, FPGA-based tool ?
It should be a very valuable and usable Gnu-Radio communications tool if
it
works !?!?

I appreciate any comments or ideas to my issues with it as described
below.

/ Rickard

3

Hi again,

Can someone clarify if the “usrp_sounder.py” FPGA-based script for the
USRP works as intended ?!
And, can someone explain how to produce meaningful CIR-values ?! (That
is, what’s wrong…)

I still have problems as described earlier (see below) and depicted in
the 3 attached figures. I don’t get any meaningful CIR outputs!

First figure: CIR loopback, results as expected - one strong
distinct spike followed by 4095 near zero values
Second figure: Measured CIR with about 10m Tx to Rx distance, with
usrp_sounder.py transmitter ON - no meaningful CIR, just about the
same intensity for all CIR values which can’t be right
Third figure: Measured CIR with about 10m Tx to Rx distance, with
usrp_sounder.py transmitter OFF - looks just like cross-correlation of
b.g. noise/interference (4095 samples periodic).

As I earlier explained; Loopback gives expected results.
But the measured CIR responses with the PN-sequence transmitter ON does
not produce any meaningful CIRs. Remembering that the chip-rate is 32
MHz (which gives about 9.4 m per CIR-sample) and with 4095 long
PN-sequence it results in about 38,4 km long “CIR distance” per
PN-period, simply meaning that most of the CIR should be near zero
during one PN-period as in the loopback.

But I simply do not get ANY distinct “spikes” out of the receiver
correlation, see attached figures, just a somewhat stronger
cross-correlation when the transmitter is ON (i.e. actually transmitting
the PN-sequence). The figure titles show the corresponding commands. See
also explanation below.

How do one get the usrp_sounder.py script to work as intended??? I
really would like to be able to measure CIR:s properly!
Any idea or explanation is welcome.

/ Rickard

4

Yes, I have read thoroughly every discussion there is in this list and
elsewhere.

It is true that there is no synchronization implemented resulting in
that the location of the CIR-peaks will not stay put within the
PN-sequence period but “rolls” (corresponding to the clock mismatch).
However, the script should still be useful and produce quite distinct
peaks, just that averaging becomes trickier and its more difficult e.g.
to evaluate the actual time delay between the Tx and Rx.

But even without any synch implemented distinctive (albeit partial)
autocorrelation peaks should still appear in my opinion (given that the
Tx-Rx distance is not too large, too weak received signal or using a
short PN-sequence with low gain). This is also the impression I get from
going through all previous discussions, even though I have not seen any
actual CIR plots from anyone else (some inactive links to figures
exist).
This fact is also supported by my own observations. When I turn off the
transmitter, the correlation output level is reduced as shown in my
plots. And when the Tx is on, the Rx output looks like PN
autocorrelation, but without the CIR peaks… the effect looks like when
different PN-sequences are used at TX and RX (cross-correlation).

Rickard

5

Hi Rickard,

have you perused the mailing list archives? I remember a discussion
about
this maybe two years ago.
IIRC, the bottom line was that no, gr_sounder is not really useful. In
particular, it has no means of synchronisation and therefore the result
is too noіsy to be useful.

MB

On Wed, Jun 15, 2011 at 12:36:49AM +0200, Rickard Nilsson wrote:

Here is what I got:
However, when I try to send from one USRP with RFX2400 and receive with
another (same setup) I do not get a representative output (I believe!). Distance
between USRPs is about 10m, and placed in different rooms (with wooden walls).
Q: - Does it work as advertised, or what can my problem be?
Below a summary of how I used the “ursp_sounder.py” script:
4 items of size 32760. Due to alignment requirements
Q: – Is it normal behaviour with the buffer-allocation warning above (I get
it all the time when receiving, depending on the PN code length) ?
Setting PN code degree to 12
On this platform, our allocation granularity is 4096 bytes.
Enabling transmitter.
Press return to exit.

followed by plotting the recorded data in Matlab as shown above.

Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page

–
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

6

On Jun 15, 2011, at 4:51 PM, Johnathan C. wrote:

On Wed, Jun 15, 2011 at 00:22, Martin B. [email protected] wrote:

IIRC, the bottom line was that no, gr_sounder is not really useful. In
particular, it has no means of synchronisation and therefore the result
is too noіsy to be useful.

Should I interpret this that gnuradio_sounder.py in fact is unusable in
its current state ?
Or is there is some easy way or fix to actually get some relevant CIR:s
out of it?

Reimplementing this application as a custom FPGA build for the E and N series
USRPs and the UHD, with synchronization, is “on the list.”

Johnathan

That should be very usable and raise the interest of GnuRadio for many I
believe. I hope its “high on the list” :slight_smile:

Rickard

7

On Wed, Jun 15, 2011 at 00:22, Martin B. [email protected]
wrote:

IIRC, the bottom line was that no, gr_sounder is not really useful. In
particular, it has no means of synchronisation and therefore the result
is too noіsy to be useful.

Reimplementing this application as a custom FPGA build for the E and N
series USRPs and the UHD, with synchronization, is “on the list.”

Johnathan