Hi Marc,
if in doubt, keep the list in. If it's too specific, someone will
complain (or not. Simply sorting away mails you don't care about
is what you need to do when using a mailing list).
I don't get what you say yet. What do you mean with "tell
the hackrf to re-tune"? The only way that I see to do this is
by software (using gnuradio).
Well, but you *don't* retune the HackRF by generating a chirp in
software.
This is were I get lost. In my opinion, if for example the
Osmocom Source sees the band from 900MHz to 920MHz is because
the center frequency of the block is set to 910MHz (and sample
rate of 20MHz),
yes,
so I just have to make this parameter change (center freq) to
see the "unknown signal" you're talking about,
yes,
because the hackrf can see much further in the spectrum.
Isn't changing the center frequency of the Osmocom Source
equivalent to "tune the hackrf" ?
It is. But it has nothing to do with generating a chirp.
Let me ask this a tenth time: What were you planning to do with your
chirp?
Best regards,
Marcus
On 01/13/2017 06:59 PM, Marc Pàmies
Massip wrote:
Okay, I am new using
the mailing list and I didn't know if I had to answer you
individually or by doing a broadcast.
I don't get what you say yet. What do you mean with "tell
the hackrf to re-tune"? The only way that I see to do this is
by software (using gnuradio).
You can also think about it this
way: The Osmocom source only gives you what it sees. Those
are the 20 MHz. There's nothing in the world that you could
multiply to something that doesn't contain the unknown
signal you're interested in to make it show you that unknown
signal.
This is were I get lost. In my opinion, if for example the
Osmocom Source sees the band from 900MHz to 920MHz is because
the center frequency of the block is set to 910MHz (and sample
rate of 20MHz), so I just have to make this parameter change
(center freq) to see the "unknown signal" you're talking
about, because the hackrf can see much further in the
spectrum. Isn't changing the center frequency of the Osmocom
Source equivalent to "tune the hackrf" ?
Marc.
On 13/01/2017
13:34:59, Marcus Müller <address@hidden>
wrote:
Hi Marc,
I'll be taking the list back into the loop, if that's OK
with you; I think there's general knowledge in here that
we might want to share.
> Correct me if I am wrong. If I want to find, let's say,
the 10 strongest signals in a rf-band which is longer than
the BW that my SDR peripheral can look at, I have to tune
the device to inspect all the band step by step.
Exactly!
> And the way to implement it in GNUradio is using a
Multiply block with two inputs: one coming from the Osmocom
Source (real life spectrum) and another coming from a Signal
Source (sinusoid generated by software), so that the output
would be a part of the GSM band tuned at the frequency of
the sinusoid. Am I right?
No!
As I said:
That chirp is *inside GNU Radio*, ie. it's a
sequence of numbers inside your computer. The GSM signals are on the
air. So what you need to do to combine the chirp with these signals is
one of
1. Use some sort of SDR device to convert the >= 45MS/s stream
containing the linear chirp from digital domain to actual analog signals
in order to mix the two, or
2. Use some sort of SDR device to convert the >= 45MHz of analog GSM
signals to the digital domain in order to multiply the two.
Either way, you need something that can deal with 45 MS/s!
You can also think about it this way: The Osmocom source
only gives you what it sees. Those are the 20 MHz. There's
nothing in the world that you could multiply to something
that doesn't contain the unknown signal you're interested in
to make it show you that unknown signal.
So, what you need to do is tell the HackRF to re-tune.
Best regards,
Marcus
On 01/13/2017 11:24 AM, Marc
Pàmies Massip wrote:
Hi Marcus,
In that case (GSM band of 20MHz) I wouldn't have to
tune the hackRF because just by setting the Center
Frequency in the middle of the band I would be able to
see all the spectrum... When I said "sweep" before I
meant inspect/analyse a part of the spectrum (for
example using a block that can detect peaks or some
kind of threshold).
Correct me if I am wrong. If I want to find, let's
say, the 10 strongest signals in a rf-band which is
longer than the BW that my SDR peripheral can look at,
I have to tune the device to inspect all the band step
by step. And the way to implement it in GNUradio is
using a Multiply block with two inputs: one coming
from the Osmocom Source (real life spectrum) and
another coming from a Signal Source (sinusoid
generated by software), so that the output would be a
part of the GSM band tuned at the frequency of the
sinusoid. Am I right?
On
12/01/2017 20:55:46, Marcus Müller <address@hidden>
wrote:
Hi Marc,
On 12.01.2017 20:14,
Marc Pàmies Massip wrote:
I want
to make sure that I can inspect the whole GSM
band.
The
reason is that I want to passively detect
pedestrians by means of their cellphones
emissions, but those emissions can be at any
part of the spectrum. As I have no information
of which frequencies are going to be used to
establish communication with the BTSs I have to
sweep the whole band.
Why do you need to *sweep*? You get 20 MHz at once,
containing all the channels therein. Let's simplify
our problem and assume that *all* GSM happens within
these 20 MHz.
So, what do you mean with "sweep"? What is the
reason you sweep, what is its advantage?
Cheers,
Marcus
Is this
what you were asking? Maybe it sounds strange to
you because the way I am trying to achieve this
is not the right one?
Marc.
On
12/01/2017 20:05:32, Marcus Müller <address@hidden>
wrote:
Hi,
> Starting from the fact that by
multiplying a signal by cos(2*pi*f*t) you
are displacing it f Hz in the frequency
domain, my idea was to center the Osmocom
Source at 835MHz (with a sample rate of
20MHz it would cover the range 825M-845M)
and evaluate that part of the spectrum.
That sounds right. You could, for example,
simply connect the osmocom source to a Qt
GUI Waterfall sink and watch the GSM channel
activity "scroll by".
> Then, to change the center frequency of
the band to be analysed I supposed that I
had to multiply the output of the Osmocom
source by a sinusoid, but now you are making
me doubt jeje.
So, *why* do you want to do that? I think
there's probably a very good idea behind
that, but I'm not quite getting the bigger
picture. What is it that you want to
*achieve*?
Best regards,
Marcus
In the first email I was trying to
do it multiplying the output by a
sinusoid of frequency 1Hz, then 2Hz,
then 3Hz, .... until 45MHz, and then
it would have 1Hz again to start over.
But with your answer I realised that
it was not possible to change the
frequency of a sinusoid generated by a
Signal Source block.
Then I thought that you were
proposing to multiply it by a chirp
because somehow it is a sinusoid which
frequency increases progressively...
But I am wondering if it would work
now.
Do you know of any way to do this
discrete step process using some
GNUradio functionalities? I mean a way
to do some kind of radio frequency
scanner.
Thank you again,
Marc.
On 12/01/2017
19:33:36, Marcus Müller <address@hidden>
wrote:
Exactly, you tune the HackRF to
the lower part, then tune it to
the next part, and so. That's a
discrete step. You get e.g. 20
MHz at once, and you decompose
these into channels. Why would
you want to multiply it with the
chirp? What is the benefit
you're trying to achieve by
doing so?
On
12.01.2017 19:25, Marc Pàmies
Massip wrote:
Yes! Sorry, my
answer was not complete. I am
using a SDR peripheral
(HackRF) with the appropriate
antenna to listen the GSM
bands. But as it is not
possible to look at the whole
spectrum at once to find the
biggest peaks, I want to do it
by parts. So first I start
looking at the lower
frequencies and then go up
progressively in the frequency
domain until the end of the
GSM band.
I think that the maximum
sample rate this hardware
can deal with is 20MHz. So I
just want to get 20MHz with
the device all the time, and
displace this 20MHz
multiplying the chirp with
the output of the Osmocom
Source Block (which outputs
whatever the HackRF
captures). Am I missing
something?
Marc.
On
12/01/2017 19:12:49,
Marcus Müller <address@hidden>
wrote:
Hi,
On 12.01.2017 19:06, Marc
Pàmies Massip wrote:
>
> Regarding to your
last question, I'm trying
to make a GSM-sensor to
> detect the signals
sent from mobile stations
(MS) to base stations
> (BTS). I should
detect phones that are not
currently being used, but
> the signals sent by
these are really weak. For
this reason I want to
> previously scan the
downlink channel (signals
sent from BTS to MS are
> easier to detect) to
find the frequencies of
the most powerful BTSs,
> and with this I would
have an idea of where the
weakest signals sent
> by MS could be. So
the chirp will be used to
modulate in order to
> sweep the whole
GSM-band. At the moment I
am just starting so there
is
> not much to say...
but that would be the
idea. I don't really know
if
> there are better ways
of scanning a wide band
using GNUradio, but your
> chirp idea sounds
great.
>
I still don't understand.
That chirp is *inside GNU
Radio*, ie. it's a
sequence of numbers inside
your computer. The GSM
signals are on the
air. So what you need to
do to combine the chirp
with these signals is
one of
1. Use some sort of SDR
device to convert the
>= 45MS/s stream
containing the linear
chirp from digital domain
to actual analog signals
in order to mix the two,
or
2. Use some sort of SDR
device to convert the
>= 45MHz of analog GSM
signals to the digital
domain in order to
multiply the two.
Either way, you need
something that can deal
with 45 MS/s!
Best regards,
Marcus
|