[USRP-users] Problems using Airprobe with USRP1
ianb at ionconcepts.com
Thu Apr 11 14:51:48 EDT 2013
I know practically nothing about using Airprobe but here's a few starter pointers:
hexdumping a file full of binary complex floats is going to make far more sense with some command line options:
hexdump -e '1/4 "%f" " "1/4 "%f" "\n"' output.cfile
Explicitly setting the sample rate used to capture the off-air data is probably a tremendously good idea, I believe for USRP1 "-d 112" is what is typically used for Airprobe but you should check that.
Starting with the RX gain low and working up would be a good methodology, starting with it turned way up is a guarantee that the RFX900 is operating in a non-linear range.
On Apr 11, 2013, at 9:39 AM, GSM Research <gsm.research.group at gmail.com> wrote:
> 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.
> 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!
> USRP-users mailing list
> USRP-users at lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the USRP-users