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 <wp...@hotmail.com> 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 >> >> ------------------------------------------------------------------------ >> *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> 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> >>>>>> 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> 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> 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> 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> 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
