No, you can't convert a python flow graph to a GRC flow graph –
Python is simply able to do things like "if (foo) then connect
these two blocks", which you can't represent in GRC.
Best regards,
Marcus
On 01/16/2017 11:51 AM, Marc Pàmies
Massip wrote:
Hi,
Sorry for the late response, I was out during the weekend.
Thank you both for your advice.
I have take a look to the file osmocom_spectrum_sense and I
think it can be very useful to me, but I was wondering if it
is possible to see the flowgraph somehow (there is no .grc
file). Is it possible to generate the grc file from a python
file?
Marc.
On 14/01/2017
0:58:50, Patrick Sathyanathan <address@hidden>
wrote:
Hi Marc,
You could take a look at osmocom_spectrum_sense which is
part of the gr-osmosdr package. It does exactly what you
seem to want to do. Running it with "--help" lists the
command line options. It is a python script so should be
relatively easy to figure out.
--Patrick
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
|