Sample rate nomenclature

GNU Radio
1

Hi guys,

Q1: When using USRP source_c (complex) with decimation == 8, am I
getting 4 million complex samples per second? 64Mhz / 8 = 8MHz floats =
4MHz complex

Q2: If I saved that data to a file and shared it with people, would I
advertise it as “Complex data, 4 million samples per second”?

Q3: If someone read that in using file_source(gr.sizeof_gr_complex,
“file.in”) and wanted to perform an FFT, what would he specify as the
sample rate to the fft_sink_c(sample_rate=x)? My guess is
sample_rate=4e6.

Thank you!

Chris

2

Chris S. wrote:

Q1: When using USRP source_c (complex) with decimation == 8, am I
getting 4 million complex samples per second? 64Mhz / 8 = 8MHz floats
= 4MHz complex

No.

64 MS/s complex samples / 8 = 8 MS/s complex

Q2: If I saved that data to a file and shared it with people, would I
advertise it as “Complex data, 4 million samples per second”?

Call it 8 MS/s complex.

Q3: If someone read that in using file_source(gr.sizeof_gr_complex,
“file.in”) and wanted to perform an FFT, what would he specify as the
sample rate to the fft_sink_c(sample_rate=x)? My guess is
sample_rate=4e6.

8e6.

Matt

3

Also, gr.file_sink stores data native-Endian, so you may want to include
the Endian-ness in the description.

-Dan

4

Matt E. wrote:

Q1: When using USRP source_c (complex) with decimation == 8, am I

64 MS/s complex samples / 8 = 8 MS/s complex

Okay. That’s certainly easy to remember. Does float act the same way?
I was under the impression you sacrifice something (samples per
second) when you move from float to complex sampling.

source_c, decim == 8: 8 MS/s
source_f, decim == 8: ? MS/s

Thanks,

Chris

5

Chris S. wrote:

source_c, decim == 8: 8 MS/s
source_f, decim == 8: ? MS/s

There is no usrp.source_f – the USRP source blocks output complex
floats (32-bit floats) or complex shorts (16 bit ints).

Matt