Usrp2_rx_cfile.py issue

GNU Radio
1

Hello all,

I am here once again and would like to bother you a bit.
I am using the usrp2_rx_cfile.py command to get the IQ data from usrp2.
I am
using the following command

sudo python usrp2_rx_cfile.py -f 800M -d 496 -s -v -N 10
/home/gnuradio4/Desktop/observed_data/test.dat

And I am getting the following output:

Network interface: eth0
USRP2 address: 00:50:c2:85:35:7d
Using RX d’board id 0x0053
Rx gain: 15.75
Rx baseband frequency: 800M
Rx DDC frequency: 0
Rx residual frequency: 0
Rx decimation rate: 512
Rx sample rate: 195.312k
Receving 10 samples
Writing 16-bit complex shorts
Output filename: /home/gnuradio4/Desktop/observed_data/test.dat

In the above, it shows that the sample rate is 195.312k. I want to raise
this rate but it seems that decimation rate has a limit upto 512 so i
cant
do that.
Can you suggest me any other way to raise the sample rate?
In fact I want the time difference between each sample to be around
100us,
but sample rate 195k gives me 5us.

Thank you.

–
View this message in context:
http://old.nabble.com/usrp2_rx_cfile.py-issue-tp32860995p32860995.html
Sent from the GnuRadio mailing list archive at Nabble.com.

2

On Thu, Nov 17, 2011 at 2:33 AM, hasanimam [email protected] wrote:

And I am getting the following output:
Receving 10 samples
Writing 16-bit complex shorts
Output filename: /home/gnuradio4/Desktop/observed_data/test.dat

In the above, it shows that the sample rate is 195.312k. I want to raise
this rate but it seems that decimation rate has a limit upto 512 so i cant
do that.
Can you suggest me any other way to raise the sample rate?
In fact I want the time difference between each sample to be around 100us,
but sample rate 195k gives me 5us.

“Decimation” means the ratio by which the 100MHz main clock is
divided. 100MHz / 512 = 195.312kHz. Try using a lower decimation.

–n

3

On Thu, Nov 17, 2011 at 8:28 AM, Nick F. [email protected] wrote:

Rx sample rate: 195.312k

“Decimation” means the ratio by which the 100MHz main clock is
divided. 100MHz / 512 = 195.312kHz. Try using a lower decimation.

Oh, I think I misunderstood your question, sorry – you don’t want to
raise the SAMPLE rate, you want to raise the DECIMATION. In that case,
you can use Gnuradio blocks such as the decimating FIR filter to
decimate additionally by however much you like.

–n

4

Hello Nick,

Thanks for your reply.

“you can use Gnuradio blocks such as the decimating FIR filter to
decimate additionally by however much you like.”

Could you please tell me how can I do the above thing? Actually I am
very
new to gnuradio. I will really appreciate your help.

Thanks.

5

On Thu, Nov 17, 2011 at 6:41 PM, Hasan Rajib Imam
[email protected]wrote:

Thanks.

Hasan,

You can use the gr.fir_filter_XXX(decim, taps) or
gr.fft_filter_XXX(decim,
taps). The taps are generally defined using gr.firdes.low_pass_2(gain,
sample rate, bw, transition, attenuation, window). The ‘decim’ parameter
for these blocks is an integer.

fft_filter:
http://gnuradio.org/doc/doxygen/classgr__fft__filter__ccc.html

fir_filter:
http://gnuradio.org/doc/doxygen/classgr__fir__filter__ccc.html

firdes:
http://gnuradio.org/doc/doxygen/classgr__firdes.html

Tom

6

Hello Tom & Nick,

Thanks for your help. I am here to ask another question.

I am using the following command
sudo python usrp2_rx_cfile.py -f 800M -N 1000 -d 100 -s -v output.dat

After that, I converted the .dat file using octave command
(read_complex_binary).

However, the values I am getting are ambiguous.
I am getting lots of 0 (zeros) and lots of Nan (dont know what does it
mean though)…I have no idea about it.

Here is the snapshot of what I get. I would really appreciate if
somebody can give any idea about this. Thank you.

------snapshot-----------
(9.183409485952689e-41,0)
(NaN,NaN)
(NaN,NaN)
(NaN,NaN)
(NaN,NaN)
(NaN,9.183409485952689e-41)
(NaN,NaN)
(NaN,9.183409485952689e-41)
(NaN,NaN)
(NaN,NaN)
(9.183409485952689e-41,0)
(NaN,9.183409485952689e-41)
(9.183409485952689e-41,0)
(9.183409485952689e-41,9.183409485952689e-41)
(NaN,NaN)
(9.183409485952689e-41,0)
(NaN,NaN)
(0,9.183409485952689e-41)
(NaN,NaN)
(NaN,9.183409485952689e-41)
(NaN,NaN)
(NaN,9.183409485952689e-41)
(0,9.183269356106256e-41)
(9.183409485952689e-41,9.183409485952689e-41)
(9.183409485952689e-41,0)
(9.183409485952689e-41,0)
(9.183409485952689e-41,0)
(0,0)
(0,0)
(0,0)
(0,0)
(0,0)
(0,0)
(0,0)
(0,0)
(0,0)
(0,0)
(0,0)
(0,0)
(0,0)
(0,0)
(0,0)
(0,0)
(0,0)
(0,0)

7

On Mon, Nov 21, 2011 at 6:31 AM, Hasan Rajib Imam
[email protected]wrote:

I am getting lots of 0 (zeros) and lots of Nan (dont know what does it mean
though)…I have no idea about it.

Here is the snapshot of what I get. I would really appreciate if somebody can
give any idea about this. Thank you.

Doesn’t the -s option output shorts? When you use the
read_complex_binary,
it’s expecting it as complex floats (32-bit float I, 32-bit float Q).
Try
capturing without the -s and try again.

You might also have to turn up the receiver gain.

Tom

8

I tried almost all things. I also tried without -s.
Well, the current situation is I am getting the three kinds of IQ data.

  1. both of the IQ valid signal is achieved.
  2. Either I or Q is valid, the other one is a dead signal (showing ‘0’,
    zero values)
  3. Both of them are dead signal (‘0’ values).

I dont know why I am getting the zero. There should be a value even for
noise. It should not be zero.

Any idea?

9

On 24/11/11 05:38 AM, Hasan Rajib Imam wrote:

Any idea?

Why do you not think that zero is valid?

These I/Q signals are voltage-samples of sinusoidal functions, which
cross zero.

–
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

10

Hello Leech,

Why do you not think that zero is valid?

These I/Q signals are voltage-samples of sinusoidal functions, which
cross zero.

Would you please explain this in a little bit more detail.
In fact I need some strong reason that zero values can be used as value
i.e. the signal is not dead.

11

On 11/24/2011 04:08 AM, Hasan Rajib Imam wrote:

i.e. the signal is not dead.

As wise man once said: “noobs will be noobs”. May I suggest that you
start with some simulation to help your understanding. Textbooks too.

http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#Flying-Blind

-Josh

12

0.0001220703 -0.0001220703
0.0001220703 -0.0001220703
6.103515625e-05 -3.0517578125e-05
0 -6.103515625e-05
0.0002441406 -6.103515625e-05
0 -6.103515625e-05
0.0002746582 0

How is it that you can be a masters student in electrical engineering,
and not know that noise signals are simply the super-position
of a large series of sinusoidal (or near-sinusoidal) functions? Once
again, the ADCs in an SDR receiver are sampling a complex voltage.
That voltage may occupy any values between {-adc_resolution,
+adc_resolution}. In UHD, the ADC values are scaled (normalized)
into the range {-1.0, +1.0} to make things within the flow-graph
somewhat more general, and allow a certain amount of hardware
independance.

In general, the samples of a noise source will be equally distributed
about 0, and in fact you can confirm this by calculating the
running-average of all your samples–they will tend to converge to 0
(in practice, there will be a small amount of DC offset which
will cause this convergence to be not exactly at zero).

But all this should be in course textbooks, etc. The folks here are
generally kind, and patient, but they can’t hope to teach people entire
courses in electrical engineering, RF design, linear and non-linear
circuit theory, and digital signal processing. Although, those who
do, generally charge money for it, in one way or another.

13

On Thu, Nov 24, 2011 at 6:46 PM, Marcus D. Leech [email protected]
wrote:

9.1552734375e-05 0 0.0001220703 -0.0001220703 0.0001220703 -0.0001220703
6.103515625e-05 -3.0517578125e-05 0 -6.103515625e-05 0.0002441406
-6.103515625e-05 0 -6.103515625e-05 0.0002746582 0

Those samples look fine. And remember that ‘0’ doesn’t mean that it has
to
be exactly 0; just a signal too small for the ADC to pick up of to have
any
of it’s bits toggled, so it will be 0 when sampled.

Tom