Re: question regarding usrp_fft.py

Hi,

— On Sat, 7/11/09, adib_sairi [email protected] wrote:

so if the bin of fft is treated as individual, what is the relationship > between fft_size and the db calculation? what is the usage of fft_size
in the calculation?

Ok let me explain. Let x(n) = cos(2nPI*f/fs) , n=0,1,2,…,N

Now take the FFT 3 times with N = 256, N = 1024 and N = 2048.

You will see that the output of the FFT X(n) will be different in
magnitude for the same input sequence because of different FFT size. The
spectrum shape is similar in the 3 cases, but the the amplitude of each
spectrum bin is different.

if i choose to monitor the 2.5G center frequency, so the evt.data[0] is
the place where the 2.5G is right? if the fusb is 4Ms/s and our
fft bin is 256, so our bandwidth of monitoring is only 2MHz right? and
evt.data[1] to evt.data[128] is the positive side of my signal while
evt.data[129] to evt.data[256] is my negative side… am i right?

No some numbers are wrong. Assuming complex samples, when Fusb is 4MB/s
the bandwidth is 1 MHz (2 bytes for I and 2 for Q). For FFT 256,
evt.dat[0] is the center frequency (2.5G in your case) evt.data[1] to
evt.data[127] is the positive side and evt.data[128] to evt.data[255] is
the negative side.

BR

Firas

thank you very much firas… I have another Question regarding the
usrp_fft.py, what is the effect of the average option? is it only
average on
the display of the graph only or is it on the value of the power
receive?
how much sample it use to do the averaging?

Adib


View this message in context:
http://www.nabble.com/question-regarding-usrp_fft.py-tp24440532p24466469.html
Sent from the GnuRadio mailing list archive at Nabble.com.

Firas A. wrote:

evt.dat[0] is the center frequency (2.5G in your case) evt.data[1] to
evt.data[127] is the positive side and evt.data[128] to evt.data[255] is
the negative side.

BR

Firas

Good day every one,
I am trying to calculate the sensing time for my system with using
usrp_fft.py as the core of my sensing method. my fft bin is 256 with
Fusb =
4MHz and my bandwidth is 1MHz.

with this parameters, each sample of 256 bin FFT will take 1 second. am
i
right? means, between one evt.data[0] to the next evt.data[0] will take
1
second. this is due to the maximum USB BW that i use for the sensing.

but i can see that in the usrp_fft GUI, the update of the plot is much
faster than 1 second. so i think my calculation is wrong but i am not
sure
what i miss.

i see in some paper, they divide the Fusb to the number of their bin.
for
example if the Fusb is 4MHz and the FFT bin used is 128, then they
divide
4MHz with 128 which give them 31.25kHz of sensing speed (0.032s). but i
think we cannot divide like that because the FFT is being done in GNU
Radio.
USRP dosent know about this is it? what bin number we choose i think the
speed is the same (1 second) because the speed of the data flush from
USRP
to PC is only depend on the decimation we choose not the FFT bin…FFT
bin is
only take place inside GNU Radio… am i right?

so what is the actual way to calculate the sensing time if i am using
usrp_fft as my core (to be more specific, i use the fft_nongl as the
basic
code and do a modification from there).

please help and guide me for this… thank you very much in advance…

Adib


View this message in context:
http://www.nabble.com/question-regarding-usrp_fft.py-tp24440532p25165037.html
Sent from the GnuRadio mailing list archive at Nabble.com.

besides my last two post (which unfortunately i still don’t have any
answer)
, i have another question… any help will be very appreciated.

if we transmit using benchmark_tx.py, we can change the amplitude of the
transmission by changing the --tx-Amplitude and this parameter max value
is
9830.1 .what is this magic number? and if i change this value, what is
the
actual parameter in my radio that will be change? is it only the DAC
value?
or it will involve the gain? if it involve the gain, which gain is
actually
affected?

Adib

View this message in context:
http://www.nabble.com/question-regarding-usrp_fft.py-tp24440532p25393881.html
Sent from the GnuRadio mailing list archive at Nabble.com.

adib_sairi wrote:

from USRP to PC is only depend on the decimation we choose not the FFT

i have one more question with usrp_fft.py. in the GUI, it show that if i
choose my decimation to be 16, the Fusb become 4MHz (due to 64MHz/16)
and
the BW of the measurement should be 1MHz right? but why in the x-axis it
show that the frequency range of measurement is 4MHz; if my fc =
2.45GHz, it
give the minimum value of x-axis = 2.4480GHz and the maximum value of
x-axis
= 2.4520GHz (BW = 4MHz)? is it this labeling is miss or is i had miss
somewhere? i suppose the BW of the display should be 1MHz right?

Adib


View this message in context:
http://www.nabble.com/question-regarding-usrp_fft.py-tp24440532p25165916.html
Sent from the GnuRadio mailing list archive at Nabble.com.

On Thu, Sep 10, 2009 at 07:26:56PM -0700, adib_sairi wrote:

affected?

Adib

Instead of waiting for one of us to look at the code and figure out
the answer to your question, have you considered looking at the code
yourself and figuring out the answer?

http://gnuradio.org/trac/wiki/ReportingErrors

Eric

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs