Re: [Discuss-gnuradio] Theory - GSM traffic detection with a USRP board

[Carlo E. Prelz]

        Subject: Re: [Discuss-gnuradio] Theory - GSM traffic detection with a 
USRP board
        Date: mer 30 ago 06 02:41:01 +0200

Quoting Martin Dvh (address@hidden):

> Depends on how you want to "spot the signals".
> If you use a fft sink then this should be OK.
> If you set the fftbins to 20, you get about one bin per channel.
> If you set the fftbins to 200, you get 10 bins per channel.
> 
> You could also analyse the captured signals by using a decimating
> fir filter with decimation 20 and bandwidth 200e3, setting the
> center frequency to one channel at a time. (remember the center of
> your captured spectrum is now at 0 Hertz) This way you get one
> channel, when you feed this to an oscope sink. you should be able to
> see the time-multiplexed signals.

This is where I encounter problems. I cannot use the existing gnuradio
software, that is incompatible with the languages I use. You must
understand that "a decimating fir filter with decimation 20 and
bandwidth 200e3" means close to nothing to me. I understand that these
parameters can be tuned in the gnuradio modules, but if I go to
gnuradio-core/src/lib/filter/, I find a whopping 117 source files,
between .cc, .h and .py, that contain the string 'fir,' which makes it
an unrewarding task to try and extract from them the logic that a
decimating fir filter should follow. I searched a bit on the net, and
found a simple C source file at the dspguru.com site (FirAlgs.c). This
is a nice, clean source that I would surely have been able to re-code,
if it weren't for the fact that there is no mention in it either of
decimation or bandwidth. On the other side, there is mention of a 'fir
coefficient array' that I have no idea whatsoever how to fill.

The whole afternoon flew away in this entertaining way.

Well, that's it. At least until the end of the coming week I have
to focus on other stuff. Then, I plan to give this stuff another
try. 

> I can run the usrp for hours at a time without problems.

Nice to know. Do you use the dbs-rx daughterboards?

> What operating system are you using?

Linux.

> Also make sure that if you compile the firmware yourself (firmware
> for the FX2), that it corresponds to the installed fpga bitfile
> (*.rbf) build 
> from the same source-version.
> (Look in /usr/local/share/usrp)

I do. /usr/local/share/usrp/rev4 contains the following files:

-rw-r--r-- 1 root staff 180809 2006-08-22 12:35 multi_2rxhb_2tx.rbf
-rw-r--r-- 1 root staff 175896 2006-08-22 12:35 std_2rxhb_2tx.rbf
-rw-r--r-- 1 root staff 171213 2006-08-22 12:35 std_4rx_0tx.rbf
-rw-r--r-- 1 root staff  19170 2006-08-22 12:35 std.ihx

They have been created as a result of the compilation of a CVS
repository source base, updated just before compiling. I am loading to
the USRP the two files, std.ihx and std_2rxhb_2tx.rbf.

> Best way to check is to build and install an unmodified official
> release of all parts (usrp, gr-usrp, gnuradio-core gr-audio-???,
> gr-wxgui)

I may try this...

> Also make sure you have an up-to-date libusb.

No problem there.

> You could also check if the usrp does not overheat.
> 
> If you put it in a hot room with direct sunlight falling onto it or
> build it inside a casing without any airflow with two daughterboards
> active for long periods of time it might get too hot.

*this* may very well be the problem. I put the USRP in a (rather
roomy) box, which is, I am afraid to say, quite closed. Do you
believe it is sufficient if I drill a grid of small holes at the top
of the box, as can be seen in many electronic appliances? I would
prefer to avoid fitting the box with a fan...

All this has to wait, now, anyway... 
Thanks again

Carlo 

-- 
  *         Se la Strada e la sua Virtu' non fossero state messe da parte,
* K * Carlo E. Prelz - address@hidden             che bisogno ci sarebbe
  *               di parlare tanto di amore e di rettitudine? (Chuang-Tzu)