discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] input of Signal Source blocks


From: Marcus Müller
Subject: Re: [Discuss-gnuradio] input of Signal Source blocks
Date: Fri, 13 Jan 2017 19:08:24 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0

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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]