The (in)famous channel 0 not receiving error

GNU Radio
1

Hi everyone,

I recently compiled and installed gnuradio.

I then tried to find the usrp2:

#find_usrps
00:50:c2:85::3b:5c hw_rev = 0x0400

Next I tried to plot an FFT of the GPS L1 signal (note that my
daughterboard
is a dbsrx2)

#usrp2_fft.py -f 1.57542G
usrp2: channel 0 not receiving
usrp2::rx_samples() fail

Where am I going wrong? I have seen other posts with people facing the
same
problem but they are from way back in mid-2010 and with different
daughterboards from mine.

Additional information:

  • daughterboard is a dbsrx2
  • usrp2 was ordered sometime in October 2010
  • I have the uhd driver installed but figured that it can exist with the
    “usual” Ethernet driver
  • Are there any firmware and/or fpga upgrades I am supposed to make?

Nick

2

daughterboard is a dbsrx2)

http://www.ettus.com/downloads/uhd_images/

Further, the UHD provides a different API than “classic”, and
usrp2_fft.py uses the “classic” API.

You can synthesize the functionality of usrp2_fft.py, using an UHD
source, within Gnuradio Companion,
in about five minutes.

With the DBS_RX2, you have no choice but to convert to UHD (or back-port
the DBS_RX2 support into
the “classic” USRP2 interface).

All new hardware from Ettus will only be supported using the UHD
interface, and UHD is now robust enough
that I recommend all new users use it.

3

Marcus:

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?

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

Thanks.

Steve McMahon

— On Wed, 1/12/11, Marcus D. Leech [email protected] wrote:

From: Marcus D. Leech [email protected]
Subject: Re: [Discuss-gnuradio] The (in)famous channel 0 not receiving
error
To: [email protected]
Date: Wednesday, January 12, 2011, 1:15 PM

Hi everyone,

  I recently compiled and installed gnuradio.



  I then tried to find the usrp2:



  #find_usrps

  00:50:c2:85::3b:5c hw_rev = 0x0400



  Next I tried to plot an FFT of the GPS L1 signal (note that my
  daughterboard is a dbsrx2)



  #usrp2_fft.py -f 1.57542G

  usrp2: channel 0 not receiving

  usrp2::rx_samples() fail



  Where am I going wrong? I have seen other posts with people facing
  the same problem but they are from way back in mid-2010 and with
  different daughterboards from mine.



  Additional information:

  - daughterboard is a dbsrx2

  - usrp2 was ordered sometime in October 2010

  - I have the uhd driver installed but figured that it can exist
  with the "usual" Ethernet driver

  - Are there any firmware and/or fpga upgrades I am supposed to
  make?



  Nick

Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

When you go to UHD, you have to change the firmware on the USRP2,
which is available here:



http://www.ettus.com/downloads/uhd_images/



Further, the UHD provides a different API than "classic", and
usrp2_fft.py uses the "classic" API.



You can synthesize the functionality of usrp2_fft.py, using an UHD
source, within Gnuradio Companion,

 in about five minutes.



With the DBS_RX2, you have no choice but to convert to UHD (or
back-port the DBS_RX2 support into

 the "classic" USRP2 interface).



All new hardware from Ettus will only be supported using the UHD
interface, and UHD is now robust enough

 that I recommend *all* new users use it.





--

Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

-----Inline Attachment Follows-----

4

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

Marcus:

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.

5

On 01/14/2011 03:43 PM, Steve M. wrote:

6

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 [email protected] wrote:

From: Marcus D. Leech [email protected]
Subject: Re: [Discuss-gnuradio] The (in)famous channel 0 not receiving
error
To: “Steve M.” [email protected]
Cc: [email protected]
Date: Friday, January 14, 2011, 3:36 PM

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

    Marcus:

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.

7

On 01/14/2011 03:43 PM, Steve M. wrote:

You say that "the UHD provides a different API than "classic",
using GRC to create a flowgraph, the interface change?

Yes, with an up-to-date GnuRadio and UHD installation, you use the “UHD”
blocks, use a
“single-USRP source” or “single-USRP sink” block, from the UHD blocks
in GRC.

If you don’t have the UHD blocks in GRC, then you aren’t up to date.

Also, you’ll need to use the UHD firmware in your USRP2 hardware.