Carlo E. Prelz wrote:
> 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 (address@hidden):
>
>
>>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)#Frequentieverdeling
>
>
> 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?
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
>
> Again, many thanks
>
> Carlo
>
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio