[USRP-users] Problems using Airprobe with USRP1

Markus Hofer markus.hofer1 at gmail.com
Thu Apr 11 15:46:09 EDT 2013


For the capturing part, it would be good to set the sample rate (previously
decimation was used, but that value depends on the clock rate, so setting
the sample rate should be preferred).
And as you are using the USRP1 it doesn't hurt to specify the daughterboard
and antenna. An example command would be:
uhd_rx_cfile -f 1987.8M -g 45 --samp-rate=400e3 -a usb --spec=A:0 -A TX/RX
output.cfile

For the decoding part, gsm_receive.py must have the correct key. If you
want to decode CCCH, use "00 00 00 00 00 00 00 00".
Also, since the capturing was now made with a sample rate of 400k, the
decoder needs to be aware of this. So instead of specifying the decimation,
directly set the sample rate with e.g. "self.input_rate = 400e3".

Hope that helps,
Markus


On Thu, Apr 11, 2013 at 6:39 PM, GSM Research
<gsm.research.group at gmail.com>wrote:

> Hello,
>
> We are trying to use Airprobe to capture gsm traffic from an OpenBSC setup
> using an IP.Access nanoBTS PCS 1900 as our cell tower.
>
> For the Airprobe setup, we have a USRP1 with two FLEX900 daughter cards
> (both of which have been modified to work as RFX1800 cards) attached to a
> workstation on which we have installed GnuRadio.  We have also downloaded
> the Airprobe repository and the additional USRP drivers and programs found
> on the Ettus website.
>
> We have tested the USRP1 and using uhd_fft, we can see that we are
> detecting the carrier signals put out by the nanoBTS.
>
> We are trying to use uhd_rx_cfile for the capture.  When running the
> program, it does appear to be capturing data (at least a large file is
> created), but we are unable to decode the datafile that is created.
>
> A typical run of uhd_rx_cfile that we have tried (for ARFCN 800) is:
>     root# uhd_rx_cfile -g 52 -N 2000000 -f 1987800000 output.cfile
>
> When we try to decode the output.cfile using gsm_receive.py, we get the
> following:
>     root# ./gsm_receive.py -I output.cfile
>     input_rate: 406250.0 sample rate: 0.375  filter_cutoff: 145000.0
> filter_t_width: 10000.0
>     >>> gr_fir_ccc: using SSE
>     >>> gr_fir_ccf: using SSE
>     Key: 'ad6a3ec2b442e400'
>     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.
>
> The cfile2.out file that gets created automatically from running
> gsm_receive.py is empty (size 0), and nothing appears in a Wireshark
> capture.
>
> Obviously, we are missing something (a parameter? using the wrong
> program/script?).  We have tried many different combinations of parameters
> and earlier versions of airprobe programs that mailing lists have said are
> now deprecated, but we have not been able to get one successful run.
>
> At this point, we don't know whether we are capturing the data correctly,
> or decoding it improperly (or both).  When we compare (using a hexdump) our
> output file with the sample capture given on the SR Labs Airprobe How-To (
> https://srlabs.de/airprobe-how-to/), we notice differences (odd numbered
> columns in the SR Labs file are for the most part 0000):
> Our output.cfile:
> 0000000 810b bc85 012c bb96 0140 baa0 0108 bc04
> 0000010 01c8 3b64 0100 bc80 01dc bbee 4174 bcba
> 0000020 0176 bc3b 0122 bc91 c174 bcb9 c116 bc8a
> 0000030 c12e bc96 01e2 bc71 0154 bc2a 4110 bc88
> 0000040 41c2 bce1 01d8 bcec 416a 3cb5 01c0 ba60
>
> SR Labs sample file:
> 0000000 0000 3b04 0000 3b20 0000 3b3a 0000 3b26
> 0000010 0000 3b48 0000 3b2a 0000 3ae8 0000 3b76
> 0000020 0000 baf4 0000 3b52 0000 bb24 0000 3b3a
> 0000030 0000 bbab 0000 bbb9 0000 3ac8 0000 3b82
> 0000040 0000 bb98 c000 bca2 0000 3c44 4000 3cde
>
> However, we don't know if this is due to different hardware (SR Labs is
> using a USRP2) or something else (improper capture).
>
> Any suggestions on what we could try on our captures or decodes would be
> greatly appreciated!
>
> Thanks,
> John
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130411/03fb2eb4/attachment-0002.html>


More information about the USRP-users mailing list