Uhd_fft differences with different wire-format

GNU Radio
1

Hi all,

I’m trying to understand the impact that changing the wire-format of a
USRP has on the uhd_fft script provided by GNURadio.

Using UHD_003.008.001-42-g8c87a524 and GNURadio built by pybomb a few
weeks ago (3427a667c).

On a USRP N210 with 50 Ohm load, I ran
uhd_fft --wire-format=sc8 -s 25M -f 700M
uhd_fft --wire-format=sc16 -s 25M -f 700M

With sc16, I get a mostly flat FFT with slight roll-off toward the ends,
as I’d expect.

With sc8, I get a dip at the center frequency that increased by about
10dB on either side as it moves out from the center freq.

The way I understood it is that wire-format is just the format used over
the ethernet cable, but that in both cases the internet representation
in GNURadio is unchanged (I used fc32).

Could someone help me understand why the wire format affects the FFT
shape in such a strange way?

I can attach screenshots if my description was unclear.

Thanks!
-Doug

2

Hi Doug,

you’re right, the wire format is only used between device and host
computer, and shouldn’t change the values you’re seeing, so I’d actually
be curious about that screenshot. I have a suspicion that what you’re
seeing might be a raised noise floor due to quantization noise becoming
increasingly relevant at 8bits, and the dip you’re seeing might be the
successfull DC offset correction. If my suspicion is correct, the 0Hz
magnitude would be largely unchanged, whereas the average level around
it would be raised; is that true?

However, since this is more of a USRP related problem than a GNU Radio
topic, it might be wise to post your reply to the USRP-users mailing
list[1].

Greetings,
Marcus

[1] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

3

On 01/05/2015 02:04 PM, Anderson, Douglas J. wrote:

With sc16, I get a mostly flat FFT with slight roll-off toward the ends, as I’d
expect.
-Doug

Try specifying a stream-arg of “peak=0.1” and see if that changes your
results.

Conceptually, there are 16-bit values (derived, on the N2xx from a
14-bit ADC) coming out of the back of the decimation filters. That then
has to be
mapped into an 8-bit value to be carried over the wire if you’re
using sc8. That’s a loss of 48dB of dynamic range. Which means, in
order to get
good results, you have to tell it which part of the dynamic range
you’re interested in, and the “peak=” stream-arg is the way to do this.

See:

http://files.ettus.com/manual/structuhd_1_1stream__args__t.html#a4463f2eec2cc7ee70f84baacbb26e1ef

–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

4

On 01/05/2015 03:09 PM, Anderson, Douglas J. wrote:

Marcus,

Thanks for the reply. I’m attaching the screenshots so that future mailing list
searchers can better see the problem and solution.

Marcus L.'s suggestion to set peak=0.1 in stream_args did the job.

This has been really helpful for me to better understand how data moves from the
USRP through GNURadio.
Glad to be of help.

Thanks to both of you Marcuses (Marcii?)
The Marcii. Like the biblical Magi, only with less frankincense and
myrrh.

–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

5

Marcus,

Thanks for the reply. I’m attaching the screenshots so that future
mailing list searchers can better see the problem and solution.

Marcus L.'s suggestion to set peak=0.1 in stream_args did the job.

This has been really helpful for me to better understand how data moves
from the USRP through GNURadio.

Thanks to both of you Marcuses (Marcii?)

-Doug