Hello Marcus,
If I may, I would like to ask for your guidance please. I have been
experimenting with gr-scan via command line and QSpectrumAnalyzer GUI as
well.
After injecting -15 dBm signal with 20 dB attenuator at 2412 MHz WiFi
channel, somehow I am seeing -53 dB peak power with gr-scan and -5
Hello Everyone,
Does anyone know about gr-scan gain control options if available?
Thanks,
--
View this message in context:
http://gnuradio.4.n7.nabble.com/usrp-spectrum-sense-py-tp63994p64239.html
Sent from the GnuRadio mailing list archive at Nabble.com.
Hello Marcus,
I am trying to learn python so I do apologize and would appreciate your
guidance.
All I need is to do some minor tweaking on osmocom_spectrum_sense.py which
is already giving center freq and power components after wideband scanning.
That is why it was suggested sweeping through th
As I said, your "metrics" aren't clear for different kind of signals.
What's the bandwidth of a rectangular pulse-shaped OOK? is it only the
main lobe? Is it multiple lobes? where do you cut off? What about spread
spectrum? What about multicarrier systems?
You use things like "dynamically adjusted"
Hello Marcus,
Here is the requirements. I was planning to modify osmocom_spectrum_sense.py
code for these requirements and would appreciate your guidance/support. I am
very new to python and think that there needs to be minor modification such
as adding another class for decimation.
• Tuning Rang
> Does it give
> me the metrics that I need?
No, but that's because the metrics you *describe* are not the metrics
you *need*. Your application is totally underspecified, and because
there can be no single proper estimator for all kinds of modulations, as
I tried to explain in my lengthy answer t
Hello Marcus,
Could you please tell me your thoughts about hackrf_sweep code? Does it give
me the metrics that I need?
Thanks
--
View this message in context:
http://gnuradio.4.n7.nabble.com/usrp-spectrum-sense-py-tp63994p64111.html
Sent from the GnuRadio mailing list archive at Nabble.com.
Get a newer Ubuntu.
On 23.05.2017 21:24, MuratCA77 wrote:
> Hello Marcus,
>
> Thank you so much for your guidance. When I tried to close gr-inspector, it
> said the following:
>
> "CMake 3.1 or higher is required. You are running version 2.8.12.2"
>
> I was wondering what seems to be the issue. I
Hello MuratCA77:
What do you mean by "close gr-inspector"? If you meant building &
installing it, yes, you may have to update your cmake package. Ubuntu 14.04
does come with cmake 2.8.12, which is older than what gr-inspector asks for
(CMakeLists.txt says: cmake_minimum_required(VERSION 3.1) ).
S
Hello Marcus,
Thank you so much for your guidance. When I tried to close gr-inspector, it
said the following:
"CMake 3.1 or higher is required. You are running version 2.8.12.2"
I was wondering what seems to be the issue. I am running Ubuntu 14.04.
Best,
Murat
--
View this message in conte
Hi Murat,
a few quick comments:
On 23.05.2017 20:24, MuratCA77 wrote:
> The current outputs produced by the usrp_spectrum_sense.py code do not
> provide the bin metrics that are required for my application.
Yeah, usrp_spectrum_sense hasn't aged all that well. I think if I were
to implement that t
, it scans almost 2
> Mhz and drop 3.6 Mhz. I don’t understand what is the reason behind those
> results and how can I improve them.
>
>
> Please if you have any ideas, give me a hand!
>
>
> Best Regards
>
> Soumaya
>
> 2017-01-16 14:24 GMT+01:00 Soumaya el bar
Best Regards
Soumaya
2017-01-16 14:24 GMT+01:00 Soumaya el barrak mailto:elbarrak.soum...@gmail.com]>:
-- Forwarded message --
From: Soumaya el barrak mailto:elbarrak.soum...@gmail.com]>
Date: 2017-01-16 12:48 GMT+01:00
Subject: Re: [Discuss-gnuradio] usrp_spect
me a hand!
Best Regards
Soumaya
2017-01-16 14:24 GMT+01:00 Soumaya el barrak :
>
> -- Forwarded message --
> From: Soumaya el barrak
> Date: 2017-01-16 12:48 GMT+01:00
> Subject: Re: [Discuss-gnuradio] usrp_spectrum_sense.py input parameters in
> USRP B200
&
Hey Mallesham,
I don't have the time right now to check your code but have you also
adjusted block [1] accordingly like I mentioned in my last mail?
It now needs to operate on complex float data.
[1]
http://gnuradio.org/doc/doxygen/classgr_1_1blocks_1_1bin__statistics__f.html
On 01/14/2017 11:48
Hi Soumaya,
could you please keep the mailing list in the loop?
Well, on USB2, the maximum sampling rate is, if I remember correctly,
somewhere between 8 MS/s and 10 MS/s. Maybe the raspberry Pi isn't the
optimal platform for broadband signal observation...
$((2**16)) gets evaluated by your shel
Hi Soumaya,
while tuning, there will simply be transients, mostly of oscillator
energy leaking into the receiver. You cannot use the data that you get
while tuning.
You might want to define "strange power values"; 2.4 GHz is an ISM band,
so a lot of traffic is to be expected there, and that traff
Hi Soumaya,
the B200 tunes slower and might need up to half a second when tuning
further.
You should hence minimize the amount of tuning, and instead of 4MS/s use
a higher rate, a larger FFT size, and tune less often.
The power normalization is truly, 100%, arbitrary. Since these dB are
all "rel
Hi Julian,
That's a lot of info. Thank you so much. Yeah, I have realized that flow
graph is not sufficient. I am going through the first approach that you
mentioned. Thanks a lot again.
On Fri, Jan 6, 2017 at 4:18 AM, Julian Arnold
wrote:
> Hi Mallesham,
>
> I meant that with your B210 you can
Hi Mallesham,
I meant that with your B210 you can only capture up to 56 MHz of real
time bandwidth (in theory).
> By whole WiFi band, I mean from 2.401G to 2.473G,
However, you require over 70MHz at once. I didn't realize that you still
want to use the sweeping approach.
In that case, the flow gr
Hi Julian,
Thank you so much again. I am able to collect the raw IQ samples using USRP
source and File sink with gnuradio-companion. But, I am confused why you
said that I will run into additional problems.
On Wed, Jan 4, 2017 at 12:22 PM, Mallesham Dasari wrote:
> Hi Julian,
>
> Thank you so m
Hi Julian,
Thank you so much for the response. By whole WiFi band, I mean from 2.401G
to 2.473G, which is complete WiFi band. Is it possible to sweep entire band
by using the approach you mentioned? I thought using gnuradio-companion, we
can scan only one or few channels depending on the sample ra
Hi Mallesham,
the easiest way would probably be to create your own simple flowgraph
using GRC like so:
|-| |-|
| USRP Source | --> | File Sink |
|-| |-|
However, remember tha
Hello,
I am writing the raw IQ samples (m.raw_data) from usrp_spectrum_sense.py to
a file. I would like to bypass the FFT overhead, which I will do later. I
want to scan the whole wide band of wifi as fast as possible. Can anyone
throw some light on how to take only raw samples without FFT?
--
B
Anyone know how to deal with this case? I need your help.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Hi, all,
Has anyone used usrp_spectrum_sense.py to sweep frequency band and get the
channel's power? I need your help.
When I use "self.connect(self.u, s2v, fft, c2mag, log, stats)", the FFT bin
values I got are all zero. But if I use "self.connect(self.u, s2v, fft,
c2mag, stats)", some FFT bin v
Hi, all,
Has anyone used usrp_spectrum_sense.py to sweep frequency band and get the
channel's power? I need your help.
When I use "self.connect(self.u, s2v, fft, c2mag, log, stats)", the FFT bin
values I got are all zero. But if I use "self.connect(self.u, s2v, fft,
c2mag, stats)", some FFT bin v
The frequency band ranges from 470MHz to 806MHz, each channel's frequency
band is 8MHz, so we have 42 channels in total. Channel 1,3,5,7 are analog
channels, others are digital channels.
I want to set the value of parameters in usrp_spectrum_sense.py as follows:
fft-size: 2048
channel-bandwidth:8
Thanks, Mike. Then how should I calculate the power for each channel?
We have analog and digital channels.
已通过MOTOBLUR™连接
-原始信息-
来自: Mike Jameson
收件人： Jincheng Zhang
抄送: "discuss-gnuradio@gnu.org"
已发送: 2013-04-07, 周日, 16:39:05 格林尼治标准时间+0000
主题: Re: [Discus
Hi,
For your application, please experiment with the following command:
./usrp_spectrum_sense.py -A TX/RX --fft-size=25 --samp-rate=25e6 --gain=15
--dwell-delay=0.25 --tune-delay=0.25 --channel-bandwidth=8e6 470e6 800e6
Note that 'freq_step' should remain unchanged at '0.75 * usrp_rate' in the
s
Thanks Mike. I'm a little confused. The parameters are listed as follows:
sample-rate:
channel-bandwidth:
freq_step:
fft_size:
You mean that I should set sample-rate be 25e6, channel-bandwidth be 8e6,
freq_step be 8e6 and fft_size be 25?
If we set the fft-size be 25, then which 8 bins I should s
Hi Jincheng,
Try setting the UHD sample rate to 25e6 and the number of fft bins to 25
which will give you 1e6 Hz per bin. Adding up the magnitude of 8 bins
(1MHz * 8 = 8MHz) will therefore give you the wanted channel power in
decimal format (magnitude).
In case you are confused, I recently updat
I want to use usrp_spectrum_sense.py to sweep the Hong Kong TV band which
ranges from 470MHz to 806MHz and get every channel's power in dB. Each
channel's frequency band is 8MHz.
Now I'm using USRP2 with TVRX2 daughter board. I have installed the latest
gnuraio and uhd. But when I use the usrp_spe
2013/2/22 Juan Daniel Fernandez Martinez :
> Hi everyone,
> There is a new version of usrp_spectrum_sense.py that works with UHD instead
> of USRP?
>
> Thanks for your attention :)
GNU Radio 3.6 ships with the usrp_spectrum_sense converted to use the
UHD interfaces.
Tom
_
There has been a lot of discussion about getting useful output, most
of the threads never go anywhere ( or at least not enough ). What I
believe really must be done is remove the python <-> C++ callbacks and
re-write it in one language ( Something that wasn't possible when it
was written ), and it
On Tue, 20 Dec 2011 20:24:28 -0500
Tom Rondeau wrote:
On Tue, Dec 20, 2011 at 11:02 AM, Thomas Tsou
wrote:
On Tue, Dec 20, 2011 at 5:11 AM, Sebastian Döring
wrote:
>>
--
>> #0 0x0013a455 in
On Tue, Dec 20, 2011 at 11:02 AM, Thomas Tsou wrote:
> On Tue, Dec 20, 2011 at 5:11 AM, Sebastian Döring
> wrote:
> >>
> --
> >> #0 0x0013a455 in sem_post@@GLIBC_2.1 () from
> >> /lib/tls/i686/cm
On Tue, Dec 20, 2011 at 5:11 AM, Sebastian Döring
wrote:
>> --
>> #0 0x0013a455 in sem_post@@GLIBC_2.1 () from
>> /lib/tls/i686/cmov/libpthread.so.0
>> #1 0x0810ab61 in PyThread_release_lock (lock
On Tue, 20 Dec 2011 11:39:39 +0100
Matthias Wilhelm wrote:
Hello,
judging from the log, it seems that a value conversion
to float is going wrong, but my (uneducated) guess the
root cause is a race between threads (this script starts
quite a number of threads ..?).
I would try to enter lar
Hello,
judging from the log, it seems that a value conversion to float is going wrong,
but my (uneducated) guess the root cause is a race between threads (this script
starts quite a number of threads ..?).
I would try to enter larger values for the delays (tune, dwelling delay) and
see whethe
Your getting into basic python questions now, maybe check out some
python tutorials first. The "tap" in that for loop just iterates over
each value in mywindow. The += is the assignment by addition operator,
it adds the value of "tap*tap" to the value of power.
Tim
From: [EMAIL PROT
Berndt Josef Wulf wrote:
> Is usrp_spectrum_sense.py suppose to work with 3.0.3RC1?
No.
> I suspect that it isn't part of this release yet.
It only works on the trunk, which will eventually become the release 3.1
branch. The release 3.0x branch is only receiving bug fix and very
minor enhancem
Hi Eric,
Thanks for getting back to me. I'll look into the fftw docs and the
links you gave to understand the details.
--Shravan
I suggest that you take a look at the docs on www.fftw.org. Our fft
block uses FFTW to do the work, and the output is exactly as they
specify.
http://www.fftw.org
On Tue, Nov 21, 2006 at 06:06:58PM -0600, Shravan Rayanchu wrote:
> Hi,
>
> I am new to DSP, so I am finding it a little difficult to understand
> exactly whats going on in the usrp_spectrum_sense.py code. When I
> print out m.data[0], m.data[1] along with m.center_freq, this is what
> I get:
>
>
44 matches
Mail list logo
