[USRP-users] Problems using Airprobe with USRP1

GSM Research gsm.research.group at gmail.com
Mon Apr 15 11:30:39 EDT 2013


Thanks to everyone who responded to my queries so far.  At this point, I
think that the problem must lie in the gsm_receive.py script.  I appear to
be able to capture data, but go.sh (and running gsm_receive.py directly)
does not show any data after the initial output (unlike Thomas' example
below).

To verify that my uhd_rx_cfile is working, did a run using the following
command:
./uhd_rx_cfile.py --samp-rate 571428.571429 -f 19878e6 -a usb  -A TX/RX -N
10000000 capture.dat

Could some kind soul offer to attempt to decode it? I don't want to send it
as an attachment to the list (the file is ~8Mb), but if someone with a
working setup can run it through their go.sh script, it would help me
verify that the problem is in the actual decoding.

The output I get when I run it through gsm_receive.py (I have to run it as
root for some reason - I don't know if that may be part of the issue) is:

$ sudo ./gsm_receive.py -d 112 -I ./capture.dat -c ""  -k "00 00 00 00 00
00 00 00"
input_rate: 571428.571429 sample rate: 0.527472527473  filter_cutoff:
145000.0  filter_t_width: 10000.0

>>> gr_fir_ccc: using SSE
>>> gr_fir_ccf: using SSE
Key: '0000000000000000'
Configuration: ''
  No configuration set.
configure_receiver
gr_buffer::allocate_buffer: warning: tried to allocate
   115 items of size 568. 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.
$

[with no other output.  It is similar to Thomas' example until the data
output]

BTW, for the signal, I am running openbsc with an ip.access PCS1900.  The
config file is set so the ARFCN is 800.

Could it be that the frequency of my USRP1 is off by enough such that it is
actually receiving dead air?  The hexdump of capture.dat is showing actual
values...

Thanks again for any assistance!
John

On Fri, Apr 12, 2013 at 2:48 PM, Thomas Tsou <tom at tsou.cc> wrote:

>
> As previously stated, Airprobe assumes a decimation of 112 on a 64 MHz
> clocked USRP1. The decimation rate itself isn't relevant in
> gsm-receive.py, just sample rate. I ran the following on B100
> similarly clocked at 64 MHz.
>
> $ uhd_rx_cfile.py --samp-rate 571428.571429 -f 1978e6 capture.dat
>
> $ ./go.sh capture.dat
> >>> gr_fir_ccc: using SSE
> >>> gr_fir_ccf: using SSE
> Key: '0000000000000000'
> Configuration: ''
>   No configuration set.
> configure_receiver
> gr_buffer::allocate_buffer: warning: tried to allocate
>    115 items of size 568. 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.
> 2336549 0: 31 06 21 20 08 39 01 62 50 46 91 16 84 2b 2b 2b 2b 2b 2b 2b 2b
> 2b 2b
> 2336553 0: 15 06 21 00 01 f0 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
> 2b 2b
> 2336559 0: 15 06 21 00 01 f0 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
> 2b 2b
> 2336563 0: 49 06 22 a0 0b 5a d9 4d f8 59 15 2d 17 05 f4 c4 5a 36 4d cb 2b
> 2b 2b
> ...
>
>   Thomas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130415/88b5d5c0/attachment-0002.html>


More information about the USRP-users mailing list