Forum: GNU Radio Theory - GSM traffic detection with a USRP board

3853dd5371ac1e094fc45d6c2aa0e459?d=identicon&s=25 Carlo E. Prelz (Guest)
on 2006-08-29 14:13
(Received via mailing list)
Good day everyone. There must be a wide variety of persons reading
this list. I hope there is some good soul there who happens to
concretely understand the wherefores of radio waves, and has the
ability to break the bread of this knowledge with those (like me) who
are more prone to logics than to electronics.

I write code for a living, and life has been so generous as to allow
me to deal with interesting stuff and apply them in the world of arts
(have a look at my simple site if you are interested - www.fluido.as).

I decided to engage in a project whose target is to detect the
existing cell-phone traffic in a specific surrounding and represent it
in some visually or acoustically interesting way. This is a personal
project, so I won't care too much if it gets to no concrete
result. But I invested in an expensive USRP board with appropriate
daughterboards (dbs-rx, range 500 MHz to 2.6GHz), so I would like to
at least give it a concrete try. The boards are connected to
log-periodic antennas provided by Ettus.

Sadly, I did not notice in due time that the Gnuradio code base is
developed in C++/python. Had I seen this I would probably have not
started the project at all. I work in C/Ruby, a combination that is
decidedly at odds with the chosen languages of Gnuradio.

I have had a very hard time extricating the logic for configuring the
USRP and setting the various parameters - frequency, gain, bandwidth,
decimation. But I am now reasonably certain that this part works OK
now in my code.

I am receiving a stream of data samples from the USRP. The
daughterboards return I and Q channels. I feed these to fftw, and
obtain the power spectrum of the required frequency band. So, for
example, with decimation=16 I receive a power spectrum covering 4
MHz. I confirm that this part is ok because I receive the same peaks
in the same areas with my software that I receive with the Gnuradio
tools. E.g: I have a peak at 832MHz (should be UHF 66 - here in
Holland most of TV broadcast is on cable, so there is little activity
on UHF) both with gnuradio-examples/python/usrp/usrp_fft.py and with
my application.

Now it is time to focus on the GSM bands. GSM900 should cover,
according to what I found on the net, 880MHz to 915MHz for the uplink,
in channels spaced 200kHz. What I found on this band was constant and
relatively strong signals spaced 4MHz - some stronger than others, the
strongest of them all at 896MHz and 900MHz. I could confirm that there
were carriers on these frequencies by listening on my hand-scanner.
But I then found out that those carriers would disappear when the USRP
was turned off. It has to be said that, to the scanner, the whole band
appears rather deserted (when the USRP is off). There is a carrier at
912MHz, but not much more. This last signal is indeed seen by the
USRP.

So, this is my question: I expected to find a lot of carriers active
at short bursts in the GSM900 band. This seems not to be the case,
even if there are lots of active cellphones around. Am I looking at
the wrong range? Or does the activity of cellphones manifest itself
somewhat differently, so that no traditional carriers can be detected?
And in this case, could you offer some pointers? I also had a look at
the 1.8GHz range (1710-1785 MHz), with similar results. These, I
believe, are the two bands that are used in this country for mobile
phone traffic.

I apologise in advance for my ignorance... I studied (long time ago)
as an architect.

Carlo

--
  *         Se la Strada e la sua Virtu' non fossero state messe da
parte,
* K * Carlo E. Prelz - fluido@fluido.as             che bisogno ci
sarebbe
  *               di parlare tanto di amore e di rettitudine?
(Chuang-Tzu)
3719f4fea703e38bcbf8de6fe6bcdf55?d=identicon&s=25 Martin Dvh (Guest)
on 2006-08-29 23:28
(Received via mailing list)
Carlo E. Prelz wrote:
> I decided to engage in a project whose target is to detect the
> started the project at all. I work in C/Ruby, a combination that is
> example, with decimation=16 I receive a power spectrum covering 4
> MHz. I confirm that this part is ok because I receive the same peaks
> in the same areas with my software that I receive with the Gnuradio
> tools. E.g: I have a peak at 832MHz (should be UHF 66 - here in
> Holland most of TV broadcast is on cable, so there is little activity
> on UHF) both with gnuradio-examples/python/usrp/usrp_fft.py and with
> my application.
You can look at these sites to find all digital and analog radio and TV
frequenties and transmitters in The Netherlands:

Nozema:
http://www.nozema.nl/Content.asp?ID=6

Agentschap Telecom:
http://www.at-ez.nl/dav/

FM and TV info site:
http://www.radiowereld.nl/fmtv/
> 912MHz, but not much more. This last signal is indeed seen by the
> phone traffic.
You are looking at the right bands.
Although the downlink is higher then you looked.
GSM900  uplink  880 -  895 Mhz downlink 925 - 960 Mhz
GSM1800 uplink 1770 - 1780 Mhz downlink 1805 - 1880 Mhz

For the GSM channels in use in Holland see:
http://nl.wikipedia.org/wiki/GSM_(communicatie)#Fr...

Probably your handscanner sees the GSM channels only as noise since the
channels are much wider then a scanner can cope with (probably 25 kHz
max)
The other possibility is that all traffic is going on in the high band
(1700/1800 Mhz)
Or something is wrong in your setup.
What antenna are you using?

The handscanner will see something if the usrp is turned on.
The scanner is then picking up the local oscillator of the DBSRX which
is a constant carrier close to the frequency you are receiving.
The scanner is very close to the dbsrx and a constant carrier is very
narrowband, so the scanner will pick this up.


>
> I apologise in advance for my ignorance... I studied (long time ago)
> as an architect.
>
> Carlo

I hope this helped,
Martin
3853dd5371ac1e094fc45d6c2aa0e459?d=identicon&s=25 Carlo E. Prelz (Guest)
on 2006-08-30 10:44
(Received via mailing list)
First of all, many thanks for your kind answer.

	Subject: Re: [Discuss-gnuradio] Theory - GSM traffic detection with a
USRP board
	Date: mar 29 ago 06 11:26:48 +0200

Quoting Martin Dvh (gnuradiomail@olifantasia.com):

> Nozema:
> http://www.nozema.nl/Content.asp?ID=6
>
> Agentschap Telecom:
> http://www.at-ez.nl/dav/
>
> FM and TV info site:
> http://www.radiowereld.nl/fmtv/

...
...

> For the GSM channels in use in Holland see:
> http://nl.wikipedia.org/wiki/GSM_(communicatie)#Fr...

Very useful pointers. Especially the GSM channel allocation
information - so I know where I am to expect traffic when I test with
my KPN cellphone... As far as TV stations are concerned, I live on the
ground floor, well-protected from too many radio waves, it appears.

> Probably your handscanner sees the GSM channels only as noise since
> the channels are much wider then a scanner can cope with (probably 25
> kHz max)
> The other possibility is that all traffic is going on in the high band (1700/1800 Mhz)
> Or something is wrong in your setup.
> What antenna are you using?

All interesting observations. I have an old Yupiteru MVT7100 handheld
scanner - it was already old when I bought it second-hand back in
1999, but it was reputed to be of good quality. It uses its standard
telescopic antenna (not ideal for this, I believe). I have now set it
to wide-fm and it seems to pick up something more.

> I hope this helped,

It surely has. I will dedicate one more coding day to this before
turning my attention myself to paid assignments for some time. But I
surely have received some encouragement from your comments.

I am setting up a utility of this kind: decimation is at 16, so the
read stuff covers 4MHz, corresponding to 20 channels. I set the
frequency, feed the URB, collect it, queue the data for processing and
repeat the loop 4MHz further on in the band. According to your
experience, should I use a higher level of decimation to reliably spot
the signals or is this resolution acceptable? I use packets of 2048*4
bytes (two daughterboards, I and Q data for each). And how should I
treat this 'bw' value? I expect it to be 'bandwidth,' but I found no
explanation apart from the fact that it must be between 1 million and
33 million. Setting it to high values results in somehow smoothing the
curve resulting from the discrete fourier transform, but not in
anything else from what I can see.

And another thing. I experience random hangs in data reception from
the USRP. I have seen this both with my software and with the gnuradio
fftw utility. The programs do not crash - simply, no data seems to
arrive from the USB port anymore. If I restart the application, all is
OK again. I am using firmware compiled from a recent gnuradio SVN
repository. Is this a well-known 'feature', for which there is some
known fix, or is it local to my place?

Again, many thanks

Carlo

--
  *         Se la Strada e la sua Virtu' non fossero state messe da
parte,
* K * Carlo E. Prelz - fluido@fluido.as             che bisogno ci
sarebbe
  *               di parlare tanto di amore e di rettitudine?
(Chuang-Tzu)
3719f4fea703e38bcbf8de6fe6bcdf55?d=identicon&s=25 Martin Dvh (Guest)
on 2006-08-30 14:43
(Received via mailing list)
Carlo E. Prelz wrote:
>>
>
>>Probably your handscanner sees the GSM channels only as noise since
> telescopic antenna (not ideal for this, I believe). I have now set it
> I am setting up a utility of this kind: decimation is at 16, so the
> read stuff covers 4MHz, corresponding to 20 channels. I set the
> frequency, feed the URB, collect it, queue the data for processing and
> repeat the loop 4MHz further on in the band. According to your
> experience, should I use a higher level of decimation to reliably spot
> the signals or is this resolution acceptable?
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.

> I use packets of 2048*4
> bytes (two daughterboards, I and Q data for each). And how should I
> treat this 'bw' value? I expect it to be 'bandwidth,' but I found no
> explanation apart from the fact that it must be between 1 million and
> 33 million. Setting it to high values results in somehow smoothing the
> curve resulting from the discrete fourier transform, but not in
> anything else from what I can see.
This should be the bandwidth in Hertz.

>
> And another thing. I experience random hangs in data reception from
> the USRP. I have seen this both with my software and with the gnuradio
> fftw utility. The programs do not crash - simply, no data seems to
> arrive from the USB port anymore. If I restart the application, all is
> OK again. I am using firmware compiled from a recent gnuradio SVN
> repository. Is this a well-known 'feature', for which there is some
> known fix, or is it local to my place?
I have no idea what this is.
Make sure you don't mix different versions of usrp, gr-usrp and
gnuradio-core.
I can run the usrp for hours at a time without problems.

What operating system are you using?

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)


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)

Also make sure you have an up-to-date libusb.
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.


Greetings,
Martin
79723aa1b24981dcec2dbf7fd59403c1?d=identicon&s=25 Brian Padalino (Guest)
on 2006-08-30 15:11
(Received via mailing list)
I am not sure anyone knows on the list, but I'll throw it out there
anyway.  Since GSM uses GMSK and there is GMSK demodulation already
built in to GNURadio, would it be possible to take a large sample of
the spectrum where a few GSM channels are, filter and demodulate each
channel and use a chip matched filter to look for an unencrypted
preamble being sent for each packet?

It would seem that approach might be better for a burst architecture
like GSM/TDMA versus CDMA where the signal is always present.

I don't have any experience with GSM and don't even know if they
append an unencrypted preamble to their transmissions, but I thought
I'd throw it out there for people to comment on.

Brian
3853dd5371ac1e094fc45d6c2aa0e459?d=identicon&s=25 Carlo E. Prelz (Guest)
on 2006-08-31 10:09
(Received via mailing list)
Subject: Re: [Discuss-gnuradio] Theory - GSM traffic detection with a
USRP board
	Date: mer 30 ago 06 02:41:01 +0200

Quoting Martin Dvh (gnuradiomail@olifantasia.com):

> 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 - fluido@fluido.as             che bisogno ci
sarebbe
  *               di parlare tanto di amore e di rettitudine?
(Chuang-Tzu)
0dfa1a815559738fc7e0f17b0cbf9e54?d=identicon&s=25 Thomas Schmid (Guest)
on 2006-08-31 11:01
(Received via mailing list)
On 8/31/06, Carlo E. Prelz <fluido@fluido.as> wrote:
>         Subject: Re: [Discuss-gnuradio] Theory - GSM traffic detection with a USRP board
>         Date: mer 30 ago 06 02:41:01 +0200

> 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.

Are you sure that you use  CVS? Because GnuRadio now uses a subversion
system. Therefore, it might be that you use an old version.

Here is the link to the new version, just in case:

http://gnuradio.utah.edu/trac

Thomas
3853dd5371ac1e094fc45d6c2aa0e459?d=identicon&s=25 Carlo E. Prelz (Guest)
on 2006-08-31 11:03
(Received via mailing list)
Subject: Re: [Discuss-gnuradio] Theory - GSM traffic detection with a
USRP board
	Date: gio 31 ago 06 10:58:08 +0200

Quoting Thomas Schmid (thomas.schmid@gmail.com):

> Are you sure that you use  CVS? Because GnuRadio now uses a subversion
> system. Therefore, it might be that you use an old version.
>
> Here is the link to the new version, just in case:
>
> http://gnuradio.utah.edu/trac

Sorry. I should have written svn. I am using the latest version.

Carlo

--
  *         Se la Strada e la sua Virtu' non fossero state messe da
parte,
* K * Carlo E. Prelz - fluido@fluido.as             che bisogno ci
sarebbe
  *               di parlare tanto di amore e di rettitudine?
(Chuang-Tzu)
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2006-08-31 16:38
(Received via mailing list)
On Thu, Aug 31, 2006 at 10:06:51AM +0200, Carlo E. Prelz wrote:
> 	Subject: Re: [Discuss-gnuradio] Theory - GSM traffic detection with a USRP board
> 	Date: mer 30 ago 06 02:41:01 +0200
>
> 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.

That kind of stuff didn't mean anything to me either when I first
started down this path.  I suspect it's not the English that's the
problem ;)

You may want to take a look at some of the books and papers listed
here:  http://comsec.com/wiki?SuggestedReading

"Understanding Digital Signal Processing" by Richard Lyons is a good
place to start.

Eric
3853dd5371ac1e094fc45d6c2aa0e459?d=identicon&s=25 Carlo E. Prelz (Guest)
on 2006-08-31 19:04
(Received via mailing list)
Subject: Re: [Discuss-gnuradio] Theory - GSM traffic detection with a
USRP board
	Date: gio 31 ago 06 02:34:03 +0000

Quoting Eric Blossom (eb@comsec.com):

> That kind of stuff didn't mean anything to me either when I first
> started down this path.  I suspect it's not the English that's the
> problem ;)

Of course not...

> You may want to take a look at some of the books and papers listed
> here:  http://comsec.com/wiki?SuggestedReading
>
> "Understanding Digital Signal Processing" by Richard Lyons is a good
> place to start.

I notice this is a tome that numbers almost 800 pages... What can you
tell me about its content in formulas? I think graphical/spatial, and
a page full of formulas already blocks me. Ideally, I'd need a
formula-free book (pseudo-code or actual code is welcome, of course),
one that is written by a person who knows how to write
(literature-wise)... Can you still advice that book to me?

Thanks for your attention

Carlo

--
  *         Se la Strada e la sua Virtu' non fossero state messe da
parte,
* K * Carlo E. Prelz - fluido@fluido.as             che bisogno ci
sarebbe
  *               di parlare tanto di amore e di rettitudine?
(Chuang-Tzu)
Ece5687b72805e8b87ee702bd003280c?d=identicon&s=25 Daniel Garcia (Guest)
on 2006-08-31 22:25
(Received via mailing list)
> I notice this is a tome that numbers almost 800
> pages...

I think you'll find that software radio really spans
many disciplines: mathematics, software engineering,
signal processing, electronics, program able hardware
(VHDL), digital logic, and communication theory to
name some. There is also is overlap between the
subjects. An 800 page book is really only a small view
in to a really large body of knowledge.

> tell me about its content in formulas? I think
> graphical/spatial, and
> a page full of formulas already blocks me.

The book has plenty of diagrams. There even some nice
diagrams that help you understand the LAPLACE
transform in 3D. It has an excellent balance of Text,
Visualizations, and mathematics.

If you buy a used one, you won't feel so cheated if
you discover it's not for you. Your local library may
have this book.

> I'd need a
> formula-free book (pseudo-code or actual code is
> welcome, of course),

There really isn't any pseudo-code but there are lots
of diagrams with text that explains them very well.
I've yet to find a formula-free book on the subject
(that is of any use). That said, learning how to
connect visual representations (graphs, diagrams, etc)
with mathematical expressions is really important.
That skill will allow you to read more complex
material (that may not have great illustrations).

> one that is written by a person who knows how to
> write (literature-wise)...

The book is well written (as far as technical books
go) but I don't think a technical book has ever been
considered for a "GENERAL NON-FICTION Pulitzer Prize".
:)

Good Luck,
Daniel



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Cec0a4bf0e0575f3a3171892e6097e59?d=identicon&s=25 Johnathan Corgan (Guest)
on 2006-08-31 22:33
(Received via mailing list)
Daniel Garcia wrote:

> The book is well written (as far as technical books
> go) but I don't think a technical book has ever been
> considered for a "GENERAL NON-FICTION Pulitzer Prize".
> :)

I think it would be a tie between Lyon's book and The Art of Electronics
:-)

-Johnathan
Ece5687b72805e8b87ee702bd003280c?d=identicon&s=25 Daniel Garcia (Guest)
on 2006-09-01 05:05
(Received via mailing list)
--- Johnathan Corgan <jcorgan@aeinet.com> wrote:
> I think it would be a tie between Lyon's book and
> The Art of Electronics :-)

Touché.-Daniel


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Dc48f9c00e3e6de9640898a531c26d89?d=identicon&s=25 Charles Swiger (Guest)
on 2006-09-01 21:09
(Received via mailing list)
On Tue, 2006-08-29 at 14:06 +0200, Carlo E. Prelz wrote:
> I decided to engage in a project whose target is to detect the
> existing cell-phone traffic in a specific surrounding and represent it
> in some visually or acoustically interesting way. This is a personal

Carlo got me interested in making an acoustical version of a wide
spectrum, results attached. It takes an fft of up to +/- 3.2Mhz at
rf then an ifft of that at af to get -16 to +16Khz, seems to work.
Decimation of 10, 20, 30, etc work, and it helps to keep the noise
floor below -20 db. Typical usage

usrp_fft_audio2.py -d 30 -g 80 -f 855e6 -R B

for a tvrx in the left side.


Offtopically, is PBS radio going with Ibiquity? Just noticed
my local station (88.5) sporting these digital looking sidebands :

http://webpages.charter.net/cswiger/public_radio_hd.jpg

--Chuck
Dbdc5157899fcad4f0afbd8fd5875688?d=identicon&s=25 Berndt Josef Wulf (Guest)
on 2006-09-22 00:33
(Received via mailing list)
Since your are reading this:

I'm not sure why gnu.org lists are still listed in several RBL
databases. I'm
subscribed to many mailing lists but gnuradio
is the only one giving me grieve.  This situation exists for a long time
now
and I'm surprised that the responsible list maintainers seemingly don't
care
and get this sorted out for once and all! Personally, I couldn't sleep
until
this problem was fixed for once and all if this was my domain being
blacklisted.

cheerio Berndt
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2006-09-22 01:25
(Received via mailing list)
On Fri, Sep 22, 2006 at 07:59:41AM +0930, Berndt Josef Wulf wrote:
> cheerio Berndt
Berndt, it's not our problem.  If your ISP is blacklisting
lists.gnu.org, I suggest you fix it with your ISP, or switch ISPs.

The folks at the blacklist places have their own *very* rigid rules.
One of them is related to what is sometimes called "back scatter".

It works like this: an asshole spammer sends spam to one of the 100's
of lists on lists.gnu.org.  It contains a forged From address, say
foo@bar.com.  foo@bar.com is not subscribed to the list.  Some of the
lists on lists.gnu.org are configured to be helpful.  That is, when
they receive mail from a non-subscriber, instead of just quietly
dropping it on the floor, they reply to foo@bar.com with a message
saying, "You're not subscribed, perhaps you are posting from a
different address than the one you are subscribed to, blah blah blah,
and your posting is being held for moderation" or something similar.
Now, if foo@bar.com happens to be an address (a spam trap address) set
by the ever so helpful black listing people, they consider this
message ("the helpful one"), unsolicited email, and thus mark the
source (lists.gnu.org) as a spammer.

So, it's a bit complicated.  The *-gnuradio lists are configured to be
quiet.  If a non-subscriber posts to discuss-gnuradio it's dropped on
the floor, with no notification sent anywhere.  However,
patch-gnuradio is configured so that it sends *me* a lovely notice
about it.  Thus I waste time every day sorting through the cruft, so
as to ensure that we don't miss anything useful sent to patch-gnuradio.

Eric
4a5c79637bdd957fe74976cc340f8e15?d=identicon&s=25 space c. (space_c)
on 2013-08-15 09:52
hello everyone

I am trying to detect and decode gsm 900 Rach using USRP 2.I tried to
use openbts energy detection implementation but no positive match found.

Does any body know how to?

thank you for your time.
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.