[Top][All Lists]

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

Re: [Discuss-gnuradio] The (in)famous channel 0 not receiving error

From: Steve Mcmahon
Subject: Re: [Discuss-gnuradio] The (in)famous channel 0 not receiving error
Date: Fri, 14 Jan 2011 12:43:42 -0800 (PST)

But I still don't understand what it is that has to change in GRC to use UHD. Do you mean that the "USRP2 Sink" and "USRP2 Source" blocks are only for the raw Ethernet interface, and to use UHD you would need to use a different block in your GRC flowgraph?

Thanks again.

--- On Fri, 1/14/11, Marcus D. Leech <address@hidden> wrote:

From: Marcus D. Leech <address@hidden>
Subject: Re: [Discuss-gnuradio] The (in)famous channel 0 not receiving error
To: "Steve Mcmahon" <address@hidden>
Cc: address@hidden
Date: Friday, January 14, 2011, 3:36 PM

On 01/14/2011 03:28 PM, Steve Mcmahon wrote:

You say that "the UHD provides a different API than "classic", and usrp2_fft.py uses the "classic" API." I'm brand new to UHD and just getting started with it. Could you explain in a little more detail about the two APIs and the differences between them?
UHD provides a more uniform, device-independent, interface for applications to use, including GRC.

I'm using raw Ethernet now with a USRP2+WBX, so why would, when using GRC to create a flowgraph, the interface change?

GRC supports both "classic" and UHD API for USRP2.

I recommend UHD for all new users, since they have nothing to be backwards compatible with, and
  the UHD is an all-round better API for Gnu Radio applications to be using, since it supports
  USRP1, USRP2, N210, E100.  Further new daughercards and baseboards will only support UHD,
  so it make sense to switch to UHD.

Most of the examples in Gnu Radio haven't yet been updated to use the UHD interface, and that includes
  things like usrp2_fft.py.

Principal Investigator
Shirleys Bay Radio Astronomy Consortium

reply via email to

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