Sure! That sounds pretty possible :)
I'm not so much of an expert on the osmocom source, myself, but
you can just use a variable (like you would with a slider) for the
frequency.
You'd then probably programmatically change that from within
python; the problem really is that you can never tell when the
effect is going to take place in the sample stream (because the
HackRF and your PC run asynchronous to each other – you tell
gr-osmosdr to change the center frequency, it calls libhackrf,
which sends a USB packet to the hackRF, which changes the
frequency – but all the while,the normal streaming operation goes
on and you simply don't know which sample the tuning happens at).
So you'll need to include a lot of "blanking time" where you
ignore the samples coming out of the osmocom source, because you
don't know whether they're still from the old frequency or already
from the new one.
If you want to contribute to the gr-osmosdr project (and
potentially make Dimitri happy), I'd recommend you add a message
port to the osmocom source and made that react to the same type of
messages as other blocks (dictionaries of command-value pairs),
and use that to issue your tuning commands – that way, you could
stay within the GNU Radio framework and wouldn't have to modify
the python code the GNU Radio Companion generates out of your
(graphical) flow graph.
Cheers,
Marcus
On 01/13/2017 07:23 PM, Marc Pàmies
Massip wrote:
Ah! I see
it now. I don't want the chirp... Initially I was asking to
tune the HackRF with a simple sine or cosine wave whose
frequency changes automatically (not manually with a slider,
for example). Then you suggested me to implement a chirp
(because in that first message you didn't know what I was
planning to do) and for some reason I thought that it could
work... but obviously is not possible to tune the device using
a chirp signal.
I think
there's been a misunderstanding between us, maybe I should
have changed the original question because it was quite
confusing. What I intend to do is to "automatically" re-tune a
HackRF so that it can scan a whole GSM band doing discrete
steps. Can it be done in GNUradio?
Marc.
On 13/01/2017
19:08:27, Marcus Müller <address@hidden>
wrote:
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
|