Photo of the Beagle Board and USRP

I’ve received a Beagle board and started testing the USRP connection.
(Still needs work) I’ve had several requests for more information so I
thought a photo would help people understand the possibilities.

Philip

Hi Philip,

just being curious :slight_smile: what are you going to use the
combo(beagle+usrp) for? use beagle to replace the usrp
host? they are not connected in your pic.

Bob

— Philip B. [email protected] wrote:

I’ve received a Beagle board and started testing the
USRP connection.
(Still needs work) I’ve had several requests for
more information so I
thought a photo would help people understand the
possibilities.

Imgur

Philip


Discuss-gnuradio mailing list
[email protected]

http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

  ____________________________________________________________________________________

Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

Philip-

Long term, I wonder if the ARM NEON instructions are useful for signal
processing. At the very minimum, this is a cheap system for narrow
band signals.

You are talking about the ARM9 core on the OMAP device, right? If so
then you can
run Linux on the ARM core but overall processing capability will be
limited compared
to a Xeon or Core2-something PC. Now if you can migrate signal
processing tasks to
the C55x DSP core on the OMAP, then you’re in business.

For anyone who is wondering, OMAP series devices are widely used in
cellphones and
other very low power consumption hand-helds – the chip series is one of
TI’s major
breadwinners.

-Jeff

On Fri, Apr 25, 2008 at 9:32 AM, Jeff B. [email protected]
wrote:

You are talking about the ARM9 core on the OMAP device, right? If so then you can
run Linux on the ARM core but overall processing capability will be limited compared
to a Xeon or Core2-something PC. Now if you can migrate signal processing tasks to
the C55x DSP core on the OMAP, then you’re in business.

For anyone who is wondering, OMAP series devices are widely used in cellphones and
other very low power consumption hand-helds – the chip series is one of TI’s major
breadwinners.

The OMAP on the beagle board is one of the new OMAP3530 which have a
Cortex-A8 and a TMS320C64x+ DSP core. Features of the OMAP can be
found here:

http://focus.ti.com/docs/prod/folders/print/omap3530.html#features

The Cortex-A8 has the NEON SIMD co-processing available to it.
Details can be found here:

http://www.us.design-reuse.com/articles/11580/architecture-and-implementation-of-the-arm-cortex-a8-microprocessor.html

Another interesting tidbit is the graphics accelerator (which I
believe is really just another ARM core?) may also be able to offload
some of the processing that may want to be done.

It may not be able to handle 4MHz bandwidth serial-tone equalized
waveforms, but you should be able to take a couple FFTs in real time
which is enough for OFDM.

Brian

Brian-

The OMAP on the beagle board is one of the new OMAP3530 which have a
Another interesting tidbit is the graphics accelerator (which I
believe is really just another ARM core?) may also be able to offload
some of the processing that may want to be done.

It may not be able to handle 4MHz bandwidth serial-tone equalized
waveforms, but you should be able to take a couple FFTs in real time
which is enough for OFDM.

Thanks Brian. Yes the 64x+ core is TI’s top of the line. The most
powerful device
they have is a 6-core 64x+ device (look for TCI6486 or TNETV3020) on the
web. But
64x+ sucks more power… so have to see whether the new OMAPs end up in
Nokia phones
or not. In this case TI’s target market can probably be described as
more generic
“wireless terminals”.

If TI would come out with native, factory-supported Linux running on
their DSP
devices, then they could get in the open source game. As it stands
they’re on the
sidelines, and people like ADI and Freescale are working their way in.
On paper the
Beagle board looks like a good candidate for embedded GNU radio, but
taking advantage
of the 64x+ core would take substantial DSP work – a level that only
would apply for
a commercial product.

-Jeff

On Thu, Apr 24, 2008 at 7:52 PM, Bob [email protected] wrote:

Hi Philip,

just being curious :slight_smile: what are you going to use the

combo(beagle+usrp) for? use beagle to replace the usrp
host? they are not connected in your pic.

They really are connected. I added a note to the picture :slight_smile:

Right now, I can load the 8051 and see the LED blink slow down. Then
the USB interface comes unglued. Not surprising since this is really
bleeding edge stuff.

Long term, I wonder if the ARM NEON instructions are useful for signal
processing. At the very minimum, this is a cheap system for narrow
band signals.

Here’s the log from a “usrper load_standard_bits” run. I promise the
cable is connected and I did not fake this :slight_smile:

The Angstrom Distribution beagleboard ttyS2

Angstrom 2008.1-test-20080410 beagleboard ttyS2

beagleboard login: root
root@beagleboard:~# usrper load_standard_bits
usrper: failed to find usrp[0]
[TURN ON POWER TO USRP]
root@beagleboard:~# <6>usb 1-1: new high speed USB device using
ehci-omap and address 2
usb 1-1: new high speed USB device using ehci-omap and address 2
<6>usb 1-1: configuration #1 chosen from 1 choice
usb 1-1: configuration #1 chosen from 1 choice

root@beagleboard:~# usrper load_standard_bits
usrper: found unconfigured usrp; needs firmware.
<6>usb 1-1: USB disconnect, address 2
usb 1-1: USB disconnect, address 2
<6>usb 1-1: new high speed USB device using ehci-omap and address 3
usb 1-1: new high speed USB device using ehci-omap and address 3
<6>usb 1-1: configuration #1 chosen from 1 choice
usb 1-1: configuration #1 chosen from 1 choice
<7>usb 1-1: usbfs: USBDEVFS_CONTROL failed cmd usrper rqt 64 rq 2 len 64
ret -71
usb_control_msg failed: error se<7>usb 1-1: usbfs: USBDEVFS_CONTROL
failed cmd usrper rqt 64 rq 9 len 1 ret -71
nding control message: Protocol <7>usb 1-1: usbfs: USBDEVFS_CONTROL
failed cmd usrper rqt 64 rq 9 len 1 ret -71
error
usb_control_msg failed: e<7>usb 1-1: usbfs: USBDEVFS_CONTROL failed
cmd usrper rqt 64 rq 9 len 1 ret -71
rror sending control message: Pr<7>usb 1-1: usbfs: USBDEVFS_CONTROL
failed cmd usrper rqt 64 rq 9 len 1 ret -71
otocol error
usb_control_msg fa<7>usb 1-1: usbfs: USBDEVFS_CONTROL failed cmd
usrper rqt 64 rq 9 len 1 ret -71
iled: error sending control mess<7>usb 1-1: usbfs: USBDEVFS_CONTROL
failed cmd usrper rqt 64 rq 9 len 1 ret -71
age: Protocol error
usb_control_msg failed: error sending control message: Protocol error
usb_control_msg failed: error sending control message: Protocol error
usb_control_msg failed: error sending control message: Protocol error
usb_control_msg failed: error sending control message: Protocol error
usrp: failed to load fpga bitstream
/usr/share/usrp/rev4/std_2rxhb_2tx.rbf.
usrper: failed
root@beagleboard:~#

Philip B. wrote:

I’ve received a Beagle board and started testing the USRP connection.
(Still needs work) I’ve had several requests for more information so I
thought a photo would help people understand the possibilities.

Beagle board and USRP | The Beagle board connected to the US… | Flickr

Philip

Hello,

The Beagle board looks interesting. I have looked at the OMAP 5912
processor.

Is it available yet? The webpages I found indicate this is a future
product.

73 Eric