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 ________________________________ From: Discuss-gnuradio <discuss-gnuradio-bounces+wpats=hotmail....@gnu.org> on behalf of Marcus Müller <marcus.muel...@ettus.com> Sent: Friday, January 13, 2017 10:43 AM To: Marc Pàmies Massip; discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] input of Signal Source blocks 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 <marcus.muel...@ettus.com><mailto:marcus.muel...@ettus.com> 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 <marcus.muel...@ettus.com><mailto:marcus.muel...@ettus.com> 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 <marcus.muel...@ettus.com><mailto:marcus.muel...@ettus.com> 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 <marcus.muel...@ettus.com><mailto:marcus.muel...@ettus.com> 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 <marcus.muel...@ettus.com><mailto:marcus.muel...@ettus.com> 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 <marcus.muel...@ettus.com><mailto:marcus.muel...@ettus.com> 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
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
