[Top][All Lists]

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

Re: [Discuss-gnuradio] GR, USRP, and GPIB measurements

From: Gayathri Ramasubramanian
Subject: Re: [Discuss-gnuradio] GR, USRP, and GPIB measurements
Date: Fri, 22 Aug 2014 00:50:38 -0700


Thank you for previous note.
I removed the FFT block and made my flow graph similar to yours. It works now :)
It is the first time I am working with the QT GUI widgets so kindly help clear the foll doubts.

1. I do not have the QT_FREQUENCY_GUI_SINK BLOCK you have used only the QT_GUI_SINK which gives the frequency spectrum. This is because of the  
lower version ( I suppose.  
For a USRPN210+WBX board I got the calibration factor to be as follows:
@ 400 MHZ, K = - 62.8
@ 900 MHz ; K = -58.8

@ 1.8 GHz ; K = --52.5 

I tested for 3 devices (USRPN210+WBX) and got around same result . The Gain was set to 0. This does not match the value you had obtained with your test.
Is there a major difference in the working b/w QT_Frequency_SINK and QT_GUI_SINK that would affect the final result?If so, Can you suggest a work around. .

2. The channel gain value seems to add to the transmitted power from signal generator. So the calibration factor also needs to have channel gain added to its value for getting same result.
So it seems like the channel gain affects the signal power like a LNA and hence increases the strength of the signal wrt to the noise. Then how is it different from RX gain.? Im a little confused on 
where the gain parameters actually impact the value of the signal.

2. The QT block also seems to do an internal FFT default size of 256 and send out a signal. However this value does not match the value seen on WX FFT GUI ( the CUrsor on QT SINK actually gives a vlue very close to actual signal generator reading). is there major difference in signal processing of QT widgets as compared to WX widgets. I found some previous threads stating whats the difference as per the software processing level in GRC not about the way it processed the received signal.

3. Why is there a difference in the channel_power_dBm value and the value seen on the spectrum using the cursor. (refer the picture). The cursor shows -81.42 dB @ 0.0 Khz offset from centre freq, while the channel_power_dBm shows a value of -17.5 dBm

4. Since This gives the channel power, I suppose this cant be used to find the intermodulation's power with two tone test. Is my understanding correct?or is there a work around for it too?

Kindly clarify the above doubts.
Look forward to your response.


On Sat, Aug 16, 2014 at 12:41 AM, madengr <address@hidden> wrote:
You don't need to take the FFT to get the power.  See my attached example (in
GR 3.7).  Just take the output from the USRP, complex_to_mag_squared,
integration with decimation to 1 Hz, 10*log10() + k, and probe at 1 Hz rate.

I'm using an N210 + WBX with gain=15 dB.  That gives me a calibration factor
of k=-34.8 dB.  I can vary power of my signal generator from -50 dBm to -10
dBm with less that 0.1 dB error in the calculated power.





Gayathri Ramasubramanian wrote
> Hi
> Thank you for your note.
> I am trying to get the power of received signal using the blocks you had
> suggested previously.
> I have attached a flow graph snapshot ('uhd_fft_DK.grc.png").
> I am using the UHD:USRP Source to receive the signal which in turn sends
> the signal in the foll path
> "complex to Mag^2" block --> "integrate and decimate" block -->  "10 log
> +k"  block---> "signal probe" block.
> However there are errors mainly referring to the in-compatible I/O sizes
> of
> source (complex to Mag ^2 block) and sink (Integrate and Decimate block).
> The I/O size of "Complex_Mag^2" block is said to be 4096, while the I/p
> size of i"ntegrate and decimate" block is 4. ==> error as not compatible.
> Should I change the Vector length? I am not quite sure?
> The error propagates to other blocks if I change anything.
> Kindly help solve this.
> I have also attached another flowgraph (flowgraph screenshot.png) which
> works but it doesn't have the "integrate and Decimate" block or the
> Log10+K
> block but it works and receives the signal (developed by someone else
> previously in our lab). Now since the "Log10+K" block is missing, does it
> mean the output is given in mwatts instead of dBm?
> I cant seem to use this version on as the "probe_signal_vector" block does
> not seem to be supported in GRC which is the version in my system.
> I tried using simple probe_signal block instead but again faced the I/o
> size incompatibility error?  Is there a work around for this "probe signal
> vector" block?
> Also could you explain briefly how to approach and solve there I/o size
> errors.
> Look forward to your response
> Thanks
> Gayathri

View this message in context: http://gnuradio.4.n7.nabble.com/GR-USRP-and-GPIB-measurements-tp49727p49981.html
Sent from the GnuRadio mailing list archive at Nabble.com.

Discuss-gnuradio mailing list

Attachment: Screenshot from 2014-08-21 22_39_57.png
Description: PNG image

Attachment: Screenshot from 2014-08-21 23_19_53.png
Description: PNG image

reply via email to

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