Spectral Analysis on Beagleboard

GoogleGroups
1

Hi everyone,

I have taken the plunge and bought one of these. The hardware looks
great but I'm getting increasingly worried about my abilities to
actually write the software I need in a format that the board can
use. Let me fill you in on what I'm trying to achieve and hopefully
some of you far wiser than me can offer some much needed advice.

I have chosen the beagleboard as a platform on which to base a part of
my final year electrical engineering project. What I basically have
to do is provide feedback to a musician about the current tuning of
their timpani (tuned drum). The front end data collection side is not
a concern and is already completed. Basically what i have to work
with is a line level (500mV pk-pk) signal on a bandwidth of 50-1kHz.
As such, my plan was to read this analog signal via the beagle boards
audio line in, and perform basic FFT spectral analysis on it. From
this I need to return to the user a note (Via frequency map),
corresponding to the highest peak seen in the spectrum, I was planning
on returning this via LED's and 7-seg diaplays run from the GPIO pins,
but time permitting wouldn't mind experimenting with a graphical
interface out of the VGA output.

Alongside this, I need to output audio from the Audio output port that
is a line level signal sweep from 90-500Hz, sweeping through its
bandwidth linearly with a period of about 1 second.

I have got a system more or less working as I want using matlab and
real time audio port management, but I now need to make the move onto
a freestanding system.

Everything I have read about writing code for the board is seeming to
confuse the hell out of me, and as such I desperately need some help
getting a better understanding of the board, and how to write software
for it that uses the on board resources.

I'm hoping the main reason I'm finding things confusing is because of
my limited exposure to Linux platforms. Any and all advice will be
much appreciated, as it seems all of my lecturers are complete idiots
and unable to understand hardware that is newer than 1989.

Cheers

Josh

2

Hi Josh,

Start with setting up a Linux box (PC), you can use that for SW development and if things are stable you can cross-compile for the Beagle (setup as mentioned on the various Wiki pages). You probably need to interface with ALSA for the audio-in/audio-out.
I’m not quite sure if the current Beagle Kernel supports a working ALSA implementation, but am sure someone else on the board can answer this answer.
Probably the ARM core is fast enough to do what you want, otherwise you have to use the DSP co-processor. I think you must forget using the DSP because it’s far more complex… (as far as I know)
Try to avoid using floating point because I’m not sure if the ARM has a floating point unit (someone please confirm).

Wkr,
Joep

2009/9/23 Joshua Brittain <brittain.joshua@gmail.com>

3

Hi Josh,

Start with setting up a Linux box (PC), you can use that for SW development and if things are stable you can cross-compile for the Beagle (setup as mentioned on the various Wiki pages). You probably need to interface with ALSA for the audio-in/audio-out.
I’m not quite sure if the current Beagle Kernel supports a working ALSA implementation, but am sure someone else on the board can answer this answer.
Probably the ARM core is fast enough to do what you want, otherwise you have to use the DSP co-processor. I think you must forget using the DSP because it’s far more complex… (as far as I know)
Try to avoid using floating point because I’m not sure if the ARM has a floating point unit (someone please confirm).

Wkr,
Joep

2009/9/23 Joshua Brittain <brittain.joshua@gmail.com>

Hi everyone,

I have taken the plunge and bought one of these. The hardware looks
great but I’m getting increasingly worried about my abilities to
actually write the software I need in a format that the board can
use. Let me fill you in on what I’m trying to achieve and hopefully
some of you far wiser than me can offer some much needed advice.

I have chosen the beagleboard as a platform on which to base a part of
my final year electrical engineering project. What I basically have
to do is provide feedback to a musician about the current tuning of
their timpani (tuned drum). The front end data collection side is not
a concern and is already completed. Basically what i have to work
with is a line level (500mV pk-pk) signal on a bandwidth of 50-1kHz.
As such, my plan was to read this analog signal via the beagle boards
audio line in, and perform basic FFT spectral analysis on it. From
this I need to return to the user a note (Via frequency map),
corresponding to the highest peak seen in the spectrum, I was planning
on returning this via LED’s and 7-seg diaplays run from the GPIO pins,
but time permitting wouldn’t mind experimenting with a graphical
interface out of the VGA output.

Alongside this, I need to output audio from the Audio output port that
is a line level signal sweep from 90-500Hz, sweeping through its
bandwidth linearly with a period of about 1 second.

Here are few pointers : Might be useful for you

  • Refer [1] to get the schematics of Beagle board. Please refer Audio subsystem [ TWL4030 ↔ OMAP McBSP]

  • TWL4030 Refer [3] → Companion chip containing Audio Codec . Note that TWL is similar to TPS65950 and [3] holds good here. Chapter on Audio will give

  • OMAP has McBSP , the I2S controller . Refer TRM [2] to know details of McBSP

  • Personally, i prefer to have mcbsp and t2 registered to sysfs and user space can access them directly for your project as ALSA adds complexity here for your requirement .

And Understanding Linux device drivers is important .

Regards,
Shankar

[1] http://beagleboard.org/static/BBSRM_latest.pdf

[2] http://focus.ti.com/general/docs/wtbu/wtbudocumentcenter.tsp?templateId=6123&navigationId=12667

[3] http://focus.ti.com/docs/prod/folders/print/tps65950.html

4

Joshua Brittain wrote:

I'm hoping the main reason I'm finding things confusing is because of
my limited exposure to Linux platforms. Any and all advice will be
much appreciated, as it seems all of my lecturers are complete idiots
and unable to understand hardware that is newer than 1989.

I hope they are not able to read this mailing list either...

5

Joshua Brittain wrote:

Hi everyone,

I have chosen the beagleboard as a platform on which to base a part of
my final year electrical engineering project. What I basically have
to do is provide feedback to a musician about the current tuning of
their timpani (tuned drum). The front end data collection side is not
a concern and is already completed. Basically what i have to work
with is a line level (500mV pk-pk) signal on a bandwidth of 50-1kHz.
As such, my plan was to read this analog signal via the beagle boards
audio line in, and perform basic FFT spectral analysis on it. From

ok

this I need to return to the user a note (Via frequency map),
corresponding to the highest peak seen in the spectrum, I was planning
on returning this via LED's and 7-seg diaplays run from the GPIO pins,
but time permitting wouldn't mind experimenting with a graphical
interface out of the VGA output.

ok

Alongside this, I need to output audio from the Audio output port that
is a line level signal sweep from 90-500Hz, sweeping through its
bandwidth linearly with a period of about 1 second.

ok.

The good news is that you can prototype that almost 100% on a desktop
Linux PC, using the very same APIs as on the BB. Using std Linux
audio drivers will give you audio in and out, lots of sample code
on that to be found on the internet.

Also, a simple (even text) based UI should be coded quickly.

So the only thing that you need to get running/fine tune on the BB
is the CPU horsepower needed for your actual algorithm...

I have got a system more or less working as I want using matlab and
real time audio port management, but I now need to make the move onto
a freestanding system.

I'd advise to move that to a std Linux first, could even be a Linux running
in a virtual machine (given that is has ok audio in/out.

6

Hi Josh,

Start with setting up a Linux box (PC), you can use that for SW development
and if things are stable you can cross-compile for the Beagle (setup as
mentioned on the various Wiki pages). You probably need to interface with
ALSA for the audio-in/audio-out.

I'm not quite sure if the current Beagle Kernel supports a working ALSA
implementation, but am sure someone else on the board can answer this
answer.

Having worked on a quite similar audio processing project before, I
would strongly recommend JACK[1]. Working directly with ALSA is a bit of
a bear and is really unnecessary for what you are doing. JACK provides a
very nice interface and as an added benefit you get very low latencies
and excellent configurability.

Probably the ARM core is fast enough to do what you want, otherwise you have
to use the DSP co-processor. I think you must forget using the DSP because
it's far more complex... (as far as I know)

I would definitely start with the ARM. You know what they see about
premature optimization. Moreover, it's a pretty quick core.

Try to avoid using floating point because I'm not sure if the ARM has a
floating point unit (someone please confirm).

I believe the NEON extensions have floating point support. I would just
use an existing fft library (fftw comes to mind, although it doesn't
appear that it directly supports NEON[2]).

[1] http://jackaudio.org/
[2] Re: FFT on NEON

Wkr,
Joep

>
> Hi everyone,
>
> I have taken the plunge and bought one of these. The hardware looks
> great but I'm getting increasingly worried about my abilities to
> actually write the software I need in a format that the board can
> use. Let me fill you in on what I'm trying to achieve and hopefully
> some of you far wiser than me can offer some much needed advice.
>
> Everything I have read about writing code for the board is seeming to
> confuse the hell out of me, and as such I desperately need some help
> getting a better understanding of the board, and how to write software
> for it that uses the on board resources.

Trying to write code for the board is your first mistake. The reason why
(sane) people choose not to implement projects like this directly on the
hardware (besides being entirely unnecessary with MCUs as cheap as they
are) is that there's simply too much to think about at once (at least
for a school project).

Don't think of it as coding for the board. You are writing software for
a Linux box. There is no reason why you should need to worry yourself
with hardware details (except, perhaps, when interfacing with the
7-segment display and even then this should be properly abstracted). If
you have used the right abstractions, your software should be able to
run on your laptop just as easily as it does on the board.

>
> I'm hoping the main reason I'm finding things confusing is because of
> my limited exposure to Linux platforms. Any and all advice will be
> much appreciated, as it seems all of my lecturers are complete idiots
> and unable to understand hardware that is newer than 1989.

Yep. This seems to be a trend among CS/EE professors. Amazing, isn't it?
Tenure---sigh.

Good luck,

- Ben