# Uhd\_fft differences with different wire-format **URL:** \ **Category:** GNU Radio\ **Created:** [January 5, 2015, 8:25pm UTC](https://www.ruby-forum.com/t/uhd-fft-differences-with-different-wire-format/233717 "2015-01-05T20:25:57Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\ **Post date:** [January 5, 2015, 8:25pm UTC](https://www.ruby-forum.com/t/uhd-fft-differences-with-different-wire-format/233717/1 "2015-01-05T20:25:57Z")
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 ---
**Author:** ![AndersonS\_Douglas\_J](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/53a042/32.png) [@AndersonS\_Douglas\_J](https://www.ruby-forum.com/u/AndersonS_Douglas_J)\ **Post date:** [January 5, 2015, 8:39pm UTC](https://www.ruby-forum.com/t/uhd-fft-differences-with-different-wire-format/233717/2 "2015-01-05T20:39:36Z")
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](http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com) ---
**Author:** ![AndersonS\_Douglas\_J](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/53a042/32.png) [@AndersonS\_Douglas\_J](https://www.ruby-forum.com/u/AndersonS_Douglas_J)\ **Post date:** [January 5, 2015, 8:40pm UTC](https://www.ruby-forum.com/t/uhd-fft-differences-with-different-wire-format/233717/3 "2015-01-05T20:40:13Z")
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: > **[Member Data Documentation - USRP Hardware Driver and Device Manual:...](https://files.ettus.com/manual/structuhd_1_1stream __args__ t.html#a4463f2eec2cc7ee70f84baacbb26e1ef)** > > \#include \ – Marcus L. Principal Investigator Shirleys Bay Radio Astronomy Consortium > **[Live Draw HK Tercepat | Result HK | HK Pools | Live HK | HK Prize Hari Ini](https://www.sbrac.org/)** > > Temukan live draw hk tercepat melalui halaman hk pools yang resmi dan dapatkan result hk prize melalui live hk secara langsung di situs kami. ---
**Author:** ![AndersonS\_Douglas\_J](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/53a042/32.png) [@AndersonS\_Douglas\_J](https://www.ruby-forum.com/u/AndersonS_Douglas_J)\ **Post date:** [January 5, 2015, 9:15pm UTC](https://www.ruby-forum.com/t/uhd-fft-differences-with-different-wire-format/233717/4 "2015-01-05T21:15:37Z")
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 > **[Live Draw HK Tercepat | Result HK | HK Pools | Live HK | HK Prize Hari Ini](https://www.sbrac.org/)** > > Temukan live draw hk tercepat melalui halaman hk pools yang resmi dan dapatkan result hk prize melalui live hk secara langsung di situs kami. ---
**Author:** ![AndersonS\_Douglas\_J](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/53a042/32.png) [@AndersonS\_Douglas\_J](https://www.ruby-forum.com/u/AndersonS_Douglas_J)\ **Post date:** [January 5, 2015, 9:11pm UTC](https://www.ruby-forum.com/t/uhd-fft-differences-with-different-wire-format/233717/5 "2015-01-05T21:11:16Z")
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