discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Help: CIR measurement problems using usrp_sounder


From: Rickard Nilsson
Subject: Re: [Discuss-gnuradio] Help: CIR measurement problems using usrp_sounder.py
Date: Wed, 15 Jun 2011 11:37:18 +0200

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



On 15 jun 2011, at 09.22, Martin Braun wrote:

> 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:
>> 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
>> 
>> 
>> 
>> 
>> 
>> 
>> On 31 maj 2011, at 19.44, Rickard Radio wrote:
>> 
>>> 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
>>> 
>>> 
>>> On Sat, May 28, 2011 at 2:09 AM, Rickard Radio <address@hidden> wrote:
>>> 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.
>>> 
>> 
> 
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> -- 
> Karlsruhe Institute of Technology (KIT)
> Communications Engineering Lab (CEL)
> 
> Dipl.-Ing. Martin Braun
> 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
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




reply via email to

[Prev in Thread] Current Thread [Next in Thread]