[Discuss-gnuradio] USRP and GSM

[Pete Chown]

I have to develop some equipment for receiving GSM 900 and GSM 1800.
(Fortunately, it doesn't have to receive both at the same time!) It would
be good to do this with GNU Radio and the USRP, but I'm not sure what
performance I can expect. I hope you don't mind if I ask a few questions.

The spectrum allocated to GSM is split into a number of carrier
frequencies, which are 200kHz apart. Each of these frequencies can carry
up to eight channels, with a data rate of about 34kbps each. (This
includes framing bits and so on, so much less useful data is actually
transmitted.) As this data rate is quite low, presumably it would be well
within the capacity of GNU Radio to decode it in real time?

According to the wiki, the USRP can push about 6MHz of spectrum over the
USB bus. This is quite a bit lower than the frequency range allocated to
GSM, so I assume it would not be possible to receive all the carrier
frequencies at once. However, no single base station uses all the
frequencies. Neighbouring cells must not interfere with each other, so
they must use different frequencies. So, does my 6MHz have to come from a
single contiguous range of frequencies? Alternatively, can I ask for a
number of 200kHz bands, with some bands in between that I'm not interested
in?

Thanks for your time and for sharing GNU Radio.

Pete

[Berndt Josef Wulf]

Post by Pete Chown
I have to develop some equipment for receiving GSM 900 and GSM 1800.
(Fortunately, it doesn't have to receive both at the same time!) It would
be good to do this with GNU Radio and the USRP, but I'm not sure what
performance I can expect. I hope you don't mind if I ask a few questions.
The spectrum allocated to GSM is split into a number of carrier
frequencies, which are 200kHz apart. Each of these frequencies can carry
up to eight channels, with a data rate of about 34kbps each. (This
includes framing bits and so on, so much less useful data is actually
transmitted.) As this data rate is quite low, presumably it would be well
within the capacity of GNU Radio to decode it in real time?
According to the wiki, the USRP can push about 6MHz of spectrum over the
USB bus. This is quite a bit lower than the frequency range allocated to
GSM, so I assume it would not be possible to receive all the carrier
frequencies at once. However, no single base station uses all the
frequencies. Neighbouring cells must not interfere with each other, so
they must use different frequencies. So, does my 6MHz have to come from a
single contiguous range of frequencies? Alternatively, can I ask for a
number of 200kHz bands, with some bands in between that I'm not interested
in?
Thanks for your time and for sharing GNU Radio.

Hi Pete,

GSM900 defines 124 channels at 200kHz bandwidth for each, the uplink
(890-915MHz) and the downlink (935-960MHz) bands. However, the number of
channels used at any one location depends on factors such as site
distributions, frequency re-use patterns, traffic density and is likely to be
much smaller than the total number of channels available.

One solution may be to obtain network information from the BCCH carrier,
interpreting its data and only processing the active GSM spectrum or cells of
interest, hence managing the data bandwidth within the capabilities of the
USRP.

cheerio Berndt

[Eric Blossom]

Post by Pete Chown
I have to develop some equipment for receiving GSM 900 and GSM 1800.
(Fortunately, it doesn't have to receive both at the same time!) It would
be good to do this with GNU Radio and the USRP, but I'm not sure what
performance I can expect. I hope you don't mind if I ask a few questions.
The spectrum allocated to GSM is split into a number of carrier
frequencies, which are 200kHz apart. Each of these frequencies can carry
up to eight channels, with a data rate of about 34kbps each. (This
includes framing bits and so on, so much less useful data is actually
transmitted.) As this data rate is quite low, presumably it would be well
within the capacity of GNU Radio to decode it in real time?

Definitely possible in real time, though without further testing,
I can't say how many RF channels we can handle concurrently.

Post by Pete Chown
According to the wiki, the USRP can push about 6MHz of spectrum over the
USB bus. This is quite a bit lower than the frequency range allocated to
GSM, so I assume it would not be possible to receive all the carrier
frequencies at once. However, no single base station uses all the
frequencies. Neighbouring cells must not interfere with each other, so
they must use different frequencies. So, does my 6MHz have to come from a
single contiguous range of frequencies? Alternatively, can I ask for a
number of 200kHz bands, with some bands in between that I'm not interested
in?

Assuming that the IF bandwidth of the RF front end is wider than 6
MHz, the bands do not have to be contiguous. You can use the digital
down converters in the FPGA to select 1, 2 or 4 distinct bands. You'd
probably then subdivide those bands into individual channels in software.

Post by Pete Chown
Thanks for your time and for sharing GNU Radio.

You're welcome!

Eric

[cfk]

Gentlemen:

I've spent a while installing swig (1.3.24), fftw (3.0.1) & cppunit (1.10.2)
onto a FedoraCore2 system from their sources.

I allready had pkgconfig (0.15.0), boost (1.31.0), boost-devel (1.31.0),
doxygen (1.3.6) previously installed with the normal "yum upgrade".

./configure succeeds as does make.

Unfortunately, during the "make check" step, after a series of successes,
there is a failure at the testing of gr_vmcircbuf_mmap_shm_open_factory and
it isnt obvious to me why. At this point, make check aborts.

Would someone consider offering a few suggestions so I can get a bit more
prepared for the imminent arrival of my USRP.

With Hope for the Weekend, Charles

[Eric Blossom]

Post by cfk
I've spent a while installing swig (1.3.24), fftw (3.0.1) & cppunit (1.10.2)
onto a FedoraCore2 system from their sources.

FWIW, I'll have a fix for swig 1.3.24 checked in later today.

Post by cfk
I allready had pkgconfig (0.15.0), boost (1.31.0), boost-devel (1.31.0),
doxygen (1.3.6) previously installed with the normal "yum upgrade".
./configure succeeds as does make.

Is this a build from CVS?

Post by cfk
Unfortunately, during the "make check" step, after a series of successes,
there is a failure at the testing of gr_vmcircbuf_mmap_shm_open_factory and
it isnt obvious to me why. At this point, make check aborts.

I assume that if you run gnuradio-core/src/tests/test_vmcircbuf
it fails with a SIGBUS or SIGSEGV, right?

What version of g++?

Eric

[Eric Blossom]

I am concentrating on a FC3 machine today which has g++ 3.4.2 and will report
to you the results of 'make check' from gnuradio-core. I do however, have a
question of education.
I can determine the version of an executable relatively easily by invoking
it. In the case of fftw, boost, boost-devel and other libraries, it is not so
easy. I know that ./configure can do this, but I am not familiar enough with
the nuances of ./configure to figure out how this is done.

For libraries that came as RPM's use

$ rpm -qa | grep fftw

Would you be willing to give a few pointers on two subjects. The first is,
"how to determine the version of a library such as fftw, boost and
boost-devel from the command line without searching for headers buried
*somewhere*?"

Lots of civilized apps and libraries use the pkg-config system. You
can just ask it and it tells you where it's installed, etc.

E.g., $ pkg-config --list-all

It will also tell you stuff about a particular package, such as
CFLAGS, library locations, etc.

E.g., $ pkg-config --cflags gnuradio-core
$ pkg-config --libs gnuradio-core


Eric

[Eric Blossom]

The second is "how to checkout from cvs the gnuradio tree from
the command line?". The first is important now, the second will be important
in another couple of weeks, but I am trying to lay some groundwork.

See http://comsec.com/wiki?CvsAccess

Here's the step-by-step version: We checkout gr-build by hand, then use it to
bootstrap everything else.

$ export CVS_RSH="ssh"
$ cvs -z3 -d:ext:***@savannah.gnu.org:/cvsroot/gnuradio co -P gr-build

You now have a directory called gr-build. chdir into it:

$ cd gr-build

This checkout command will checkout everything except for that related to the
Measurement Computing PCI card.

$ ./checkout -x mc4020

You'll now have a bunch of directories...

If you haven't already, you'll want to set up /etc/sudoers. The
buildit script below does the bulk of the work running as you, then
uses "sudo make install" to install the stuff into /usr/local/...

First, add yourself to group wheel by editing /etc/group.
Find the line that starts with wheel:x:... and add your logname to the
end of it.

Then make these changes to /etc/sudoers:

# Defaults specification

# Only ask for password every 10 minutes.
Defaults timestamp_timeout=10

# Uncomment to allow people in group wheel to run all commands
%wheel ALL=(ALL) ALL


Now, assuming you've got all the dependencies fulfilled, this will
bootstrap, configure, make, make check, and make install
everything in the proper order:

$ sudo -v # give sudo the password now, so you can
# walk away while it builds

# Now build everything that you checked out

$ ./for-all-dirs ../buildit 2>&1 | tee make.log


Assuming the build completed successfully, you're all set.



Later when you want to see if there are updates to CVS head, but don't
want to apply them to your tree use this:

$ ./for-all-dirs cvs -nq up

If you like what you saw from the previous command, this will get the
updates and merge them into your tree:

$ ./for-all-dirs cvs -q up

Then you should rebuild everything:

$ ./for-all-dirs ../buildit