# Beagleboard Inquiry

Hello,

My name is Trent Fougere, myself and my partner are working on a
senior project in the electronics field. Our project involves
tracking a turtle species. The turtles transmit in a frequency range
of 150-152MHz. We are mixing the incoming signal with 150MHz to bring
it down to baseband 0-2MHz. We are looking to use a DSP and do an FFT
on this range.

Is the beagleboard able to do this for us? Any information would be
greatly appreciated.

Thanks,
Trent Fougere

That is a great deal of bandwidth. What is the signal that you are
processing?

Hi Trent, It will better if you can figure your requirements in number of
Multiplications and additions required per second. It will be easy to make
a decision.

Hello spec,

The signal we are looking to process is transmitted at very low power,
i believe it is 100 microwatts and it pulses approximately every 3
seconds.

To clarify on the frequency of the signals: each transmitter has a
different frequency in the range of 150.000MHz to 152.000MHz. So
turtle A could be transmitting at 150.456MHz and turtle B at
150.460MHz. The separation of the transmitters is no less than 3KHz.
It is important for us to determine the exact frequency we are
receiving so that we can determine which turtle we have.

Trent

Hi Trent,

I think the main questions in order to help you forward are:

1) How long is the pulse transmitted from the turtles? (i.e. 10ms every 3
sec?)
2) Do you need to capture all pulses or would it be OK to miss some of them?
3) With a 2 MHz analog bandwidth you would need a sample rate (according to
Nyquist) of minimum 4MHz plus space for a roll off filter in the analog
domain => Practical sample rate in the range of 5-10MHz

With a 8MHz sample frequency you would need a 8000 point FFT in order to get
a 1kHz resolution in your frequency domain, which I guess is maximum you can
live with(?) in case the turtles' transmitters are as close as 3kHz.

The big questions is now, how many 8000 point (rounded to 8192) FFT's
(including windowing and pre-/postprocessing) can the BeagleBoard handle in
a second? Anybody having any kind of idea (DSP/ARM)?

Another question: How do you intend to get the 8-16 bit(?) 8MHz samples into
the beagle board? Using HS-USB? You would need an actual sustained
throughput of 64-128Mbit/s, which I could fear rather high? Does anybody
have any numbers on actual USB throughput?

Best regards
Søren

-----Oprindelig meddelelse-----

Hello,

Sorry for my delayed reply. I'm on Christmas Break and i'm home with
my family so i won't be around to respond to the questions. I do
really appreciate all the help I am getting and will be back on in the

Thanks Again and Happy Holidays,
Trent

Hi,
My name is Chris and I'm working with Trent on this project. I can
the questions regarding our needs now.

1) The signal has a pulse width of 21ms at a rate of 35ppm.

2) We don't necessarily need to capture every pulse but every second
one would be great, every 3rd at a minimum.

As for whether we can accomplish this with the BB I have no idea, I
guess thats what we are trying to figure out.
Thanks
Chris

Hi Chris,

1) The signal has a pulse width of 21ms at a rate of 35ppm.

Should this be read in the way, that the pulses have a width of 21ms, and
are sent every 21ms/35*100000 sec = 600 sec = 10 minutes?

Have you considered the 3rd question from my previous answer, with respect
to how to get the data into the Beagle Board?

@Anybody: Does anyone know if the BeagleBoard can support 1000 8192 samples
1-dimentional FFT's per second? My *guess* - straight out of the box - would
be yes, but I don't know for sure...

Best regards
Søren

According to SPRA884A[1], a C64x can perform a 8192 point, 16-bit FFT
in around 70,000 cycles. So, it would only need to run at about 70MHz
to execute 1,000 of them in 1 second. It operates up to 430MHz on the
BeagleBoard. I'm not sure if there are improvements for the C64x+ or
if this is the right kind of FFT for the question.

Hi Trent, Chris and Jason,

@Jason: Thanks for guiding me to this document. I think it's the right kind
of FFT you selected - Might be for easiness they should use the
fft16x32-type instead. According to the same document, that one takes around
33% more resources, but might be easier to handle due to 32 bits inputs and
outputs...

With this kind of number the only question is if a 1kHz resolution is enough
to distinguish the 3kHz signals clearly from each other under all
circumstances?

- I.e. how much noise/interference do you expect in the area?
- How many turtles would stay around?
- What is the risk, that two turtles with frequencies next to each other
will swim together?
- Etc?

Since the pulse-width is 21ms, you might be able to do a 32.768-point FFT
instead, and thereby increasing the spatial resolution by 4 to ~250Hz, but
on the cost of only capturing ~4-5 independent FFT-windows within the 21ms
pulse width, which however shouldn't cause any problem as far as I can see.
This would require around 320kcycles/FFT, but only be needed 250 FFT/s =>
80MHz for execution

As you case see, there should be plenty of DSP headroom to process the
data...

Please let me know in case you need further info?

Best regards - Good luck
Søren

Hey guys,

Thanks for the info, its going good.
@Soren, I'm pretty sure the ppm meant pulses per minute, making it
just under 2 seconds but from personal use it is certainly much closer
to 3 seconds.
It looks like the BB can certainly handle our signal processing.
As for the questions:

- I.e. how much noise/interference do you expect in the area?

Our noise expectations are low, it is a remote location with no
phone,power and a little to no cell service but as it is remote we
have not been out to test for interference sources.

- How many turtles would stay around?

We can expect anywhere from 0 to at most of about 5 in our receiving
range.

- What is the risk, that two turtles with frequencies next to each other
will swim together?

Rather light as only a handful of the turtles in each habitat are
tagged and perhaps with some concious effort this could be reduced
further.

The next thing we have to determine is which method to use to input to
the BB. We will post our results and if anyone has any extra info or
advice on this matter it'd be greatly appreciated.

On that note, I was reading wikipedia before posting and for what its
worth it states usb 2.0 has a speed of 480Mbit/s. So it looks like
that would certainly be possible. Now its a matter of connecting our
signal to the usb. Any knowledge of whether this is a simple process
or not?

Regards,
Chris

Hi Chris,

@Soren, I'm pretty sure the ppm meant pulses per minute, making it
just under 2 seconds but from personal use it is certainly much
closer to 3 seconds.

Hmm - Didn't catch my mind for a single second - I'm living in a world,
where ppm means "parts per million" - I however totally agree, that "pulses
per minutes" makes much more sense in this use case
I as well had a little trouble believing that a pulse every 10 minutes would
do, but the math lined up very nicely in the 10 minutes

Seems, that the assumptions might hold - Little to no noise - Not too many
turtle senders etc... Great

On that note, I was reading wikipedia before posting and for what its
worth it states usb 2.0 has a speed of 480Mbit/s. So it looks like
that would certainly be possible.

It's right, that data signaling of USB is at a speed of 480Mbit/s.
This is however only the physical link itself - Not including SW for USB
can't handle the data at these speeds a lot of "NAKs" (not acknowledges) are
send on the link causing retransmissions and thereby severely hitting
performance.

The big question is now: What is the maximum sustained USB bulk (? - Bulk is
the "fastest" USB transfer type) data rate in Linux with OMAP3? I bet it's
more in the range of 100-200Mbit/s than it's close to 480Mbit/s, but I
really don't know for sure...

Does anybody have any recent measurements?

Now its a matter of connecting our signal to the usb.
Any knowledge of whether this is a simple process or not?

1) Which kind of signal do you have? An analog signal 0-2MHz and with which
amplitude?
2) Or do you already have a digital signal source (Analog to Digital
Converter?)
3) How many systems would you need for the project? Only at one place or at
hundreds?
4) How do you plan to power the complete solution? - By electricity or
batteries?
5) What's the timeline of the project - When do you need it?

further forward as well

Best regards
Søren

Hi Trent, Chris and Jason,

@Jason: Thanks for guiding me to this document. I think it's the right

kind

of FFT you selected - Might be for easiness they should use the
fft16x32-type instead. According to the same document, that one takes

around

33% more resources, but might be easier to handle due to 32 bits inputs

and

outputs...

With this kind of number the only question is if a 1kHz resolution is

enough

to distinguish the 3kHz signals clearly from each other under all
circumstances?

- I.e. how much noise/interference do you expect in the area?
- How many turtles would stay around?
- What is the risk, that two turtles with frequencies next to each other
will swim together?
- Etc?

Since the pulse-width is 21ms, you might be able to do a 32.768-point FFT
instead, and thereby increasing the spatial resolution by 4 to ~250Hz, but
on the cost of only capturing ~4-5 independent FFT-windows within the 21ms
pulse width, which however shouldn't cause any problem as far as I can

see.

This would require around 320kcycles/FFT, but only be needed 250 FFT/s =>
80MHz for execution

As you case see, there should be plenty of DSP headroom to process the
data...

Please let me know in case you need further info?

Best regards - Good luck
Søren

On

Behalf Of Jason Kridner
Sent: Monday, January 05, 2009 4:18 AM
Subject: [beagleboard] Re: Beagleboard Inquiry

According to SPRA884A[1], a C64x can perform a 8192 point, 16-bit FFT
in around 70,000 cycles. So, it would only need to run at about 70MHz
to execute 1,000 of them in 1 second. It operates up to 430MHz on the
BeagleBoard. I'm not sure if there are improvements for the C64x+ or
if this is the right kind of FFT for the question.

bstractName=spra884a

> Hi Chris,

>> 1) The signal has a pulse width of 21ms at a rate of 35ppm.
> Should this be read in the way, that the pulses have a width of
> 21ms, and
> are sent every 21ms/35*100000 sec = 600 sec = 10 minutes?

> Have you considered the 3rd question from my previous answer, with
> respect
> to how to get the data into the Beagle Board?

> @Anybody: Does anyone know if the BeagleBoard can support 1000 8192
> samples
> 1-dimentional FFT's per second? My *guess* - straight out of the box
> - would
> be yes, but I don't know for sure...

> Best regards
> Søren

> ] On
> Behalf Of Tobin14
> Sent: Sunday, January 04, 2009 6:37 PM
> To: Beagle Board
> Subject: [beagleboard] Re: Beagleboard Inquiry

> Hi,
> My name is Chris and I'm working with Trent on this project. I can
> the questions regarding our needs now.

> 1) The signal has a pulse width of 21ms at a rate of 35ppm.

> 2) We don't necessarily need to capture every pulse but every second
> one would be great, every 3rd at a minimum.

> As for whether we can accomplish this with the BB I have no idea, I
> guess thats what we are trying to figure out.
> Thanks
> Chris

>> Hi Trent,

>> I think the main questions in order to help you forward are:

>> 1) How long is the pulse transmitted from the turtles? (i.e. 10ms
>> every 3
>> sec?)
>> 2) Do you need to capture all pulses or would it be OK to miss some
>> of
> them?
>> 3) With a 2 MHz analog bandwidth you would need a sample rate
>> (according
> to
>> Nyquist) of minimum 4MHz plus space for a roll off filter in the
>> analog
>> domain => Practical sample rate in the range of 5-10MHz

>> With a 8MHz sample frequency you would need a 8000 point FFT in
>> order to
> get
>> a 1kHz resolution in your frequency domain, which I guess is
>> maximum you
> can
>> live with(?) in case the turtles' transmitters are as close as 3kHz.

>> The big questions is now, how many 8000 point (rounded to 8192) FFT's
>> (including windowing and pre-/postprocessing) can the BeagleBoard
>> handle
> in
>> a second? Anybody having any kind of idea (DSP/ARM)?

>> Another question: How do you intend to get the 8-16 bit(?) 8MHz
>> samples
> into
>> the beagle board? Using HS-USB? You would need an actual sustained
>> throughput of 64-128Mbit/s, which I could fear rather high? Does
>> anybody
>> have any numbers on actual USB throughput?

>> Best regards
>> Søren

>> -----Oprindelig meddelelse-----
>> ] På
>> vegne af trentfoug...@gmail.com
>> Sendt: 20. december 2008 23:28
>> Til: Beagle Board
>> Emne: [beagleboard] Re: Beagleboard Inquiry

>> Hello spec,

>> The signal we are looking to process is transmitted at very low
>> power,
>> i believe it is 100 microwatts and it pulses approximately every 3
>> seconds.

>> To clarify on the frequency of the signals: each transmitter has a
>> different frequency in the range of 150.000MHz to 152.000MHz. So
>> turtle A could be transmitting at 150.456MHz and turtle B at
>> 150.460MHz. The separation of the transmitters is no less than 3KHz.
>> It is important for us to determine the exact frequency we are
>> receiving so that we can determine which turtle we have.

>> Trent

>>> That is a great deal of bandwidth. What is the signal that you are
>>> processing?

>>>> Hello,

>>>> My name is Trent Fougere, myself and my partner are working on a
>>>> senior project in the electronics field. Our project involves
>>>> tracking a turtle species. The turtles transmit in a frequency
>>>> range
>>>> of 150-152MHz. We are mixing the incoming signal with 150MHz to
>>>> bring
>>>> it down to baseband 0-2MHz. We are looking to use a DSP and do
>>>> an FFT
>>>> on this range.

>>>> Is the beagleboard able to do this for us? Any information would
>>>> be
>>>> greatly appreciated.

>>>> Thanks,
>>>> Trent Fougere- Hide quoted text -

>>> - Show quoted text -

No virus found in this incoming message.
Checked by AVG -http://www.avg.com
Version: 8.0.176 / Virus Database: 270.10.2/1874 - Release Date:

04-01-2009

16:32- Hide quoted text -

- Show quoted text -

No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.176 / Virus Database: 270.10.3/1878 - Release Date: 06-01-2009
07:56

Hello Everyone,

Hope everyone had a wonderful holiday. Thanks again for all of your
continued support. Chris and I have been collaborating and we are
having problems figuring out how we can get our analog signal into the

@Soren

1) Which kind of signal do you have? An analog signal 0-2MHz and with which
amplitude?

Our signal is indeed analog 0-2MHz and we're not 100% on our amplitude
range yet. Likely very small, not sure on our maximum yet. We are
still working on the front end of our signal reciever so more
information on amplitude will follow, we need an LNA with a very high
gain since as stated before our trasmitter output is very small, 100
microwatts.

2) Or do you already have a digital signal source (Analog to Digital
Converter?)

We do not currently have a ADC but we have found one on TI that is 12
bit with 10MHz sampling which should be more than enough according to

3) How many systems would you need for the project? Only at one place or at
hundreds?

We're only looking at one place, however we're planning on making it
hand held.

4) How do you plan to power the complete solution? - By electricity or
batteries?

The use of batteries since we're looking at hand held.

5) What's the timeline of the project - When do you need it?

This is our senior year of our program and we need to have a "working
prototype" by the middle of April 09.

So right now we're looking at using an external ADC and sending the
digital output serialy through the USB 2.0 into the Beagleboard.
(Assuming of course that the USB is fast enough - Still need
information on that).

We ordered a Beagleboard from digikey today, we decided that even if
we don't use it for this project, we will use it down the road since
it is an awesome piece of hardware.

Hi guys,

Upon further discussion, would the BB be the best choice for this
project? There would probably be a simpler and cheaper EVM that may
our processing needs. Any products come to mind for anyone? Our BB
arrives tomorrow but we were originally under the impression that it
but it would obviously be simpler if we had a pre-assembled package.
Any thoughts?

Hi guys,

Upon further discussion, would the BB be the best choice for this
project? There would probably be a simpler and cheaper EVM that may
our processing needs. Any products come to mind for anyone? Our BB
arrives tomorrow but we were originally under the impression that it
but it would obviously be simpler if we had a pre-assembled package.
Any thoughts?

The Overo has more ADC line connections than does Beagle, but Beagle
does have a stereo audio-band ADC. It is also possible to add
requirements and someone might chime in if they have a board that fits

The ADS804 you are looking at has a parallel interface. If it was
serial, you could probably connect it over the McBSP. Given that it
is parallel, and you need the DSP, you might look at something like
the http://www.logicpd.com/products/som/ti/omap35x.

Hi all,

I don't want to disencourge you all, but when talking about audio codecs
then to me this appears to be the wrong direction.
If a signal with 2Mhz is to be captured with about 12bits then this
means, depending on the final ADC being choosen that you need a bandwith
for interfacing of > 2*2e10*12 resulting in a data rate bigger than
50Mbit/s...

for USB this means Hi-Speed required!
SPI Interfaces generally work reliable up to 20 MHz (you furthermore may
need additional bits for control which is increasing datarate)...
Parallel interfacing with Beagle is not available to my knowledge,
besides you would manage to make the 'C' revision read from LCD Port
which is probably not designed for input..

4-6 MSamples/s of 12Bit data from a low energy signal is a real
challenge on its own...

So you are likely faced with a subsystem that will run conversion of ADC
and transfer Data by USB Highspeed interface.
In this case you will have to implement Hi-Speed USB driver for the
Subsystem and BB-Linux for this 'special' data streaming device...

In case you don't have *very* experienced developers on design side
well as on sw development for the drivers, April 09 sounds almost
impossible to me.

best regards,
A. den Toom

Jason Kridner schrieb:

Don’t forget the MMC interface on the Beagle expansion header which can do up to 40MB/S.

Gerald

Hi Gerald,

very good point, but 40MBit/s will be only good for about 9Bit
resolution just to meet nyquist poorly at 2MHz...

But in MMC Mode the interface could be 8 bit wide, or am I mistaken?
This could do the job with much less complications,- except for the
receiver and aquisition part of data capture, which remain a challenge
anyway.
Sorry, but I'm not to much into MMC interfacing just played around with
SD (4Bit)...

best regards,
A. den Toom

Gerald Coley schrieb:

It is indeed 8Bit. SD is 24MHZ at 4b, so that gets it to 96Mb/S. I was looking at using the MMC as the data channel and converting the ADC data to the 8bit wide format. It could even be a 16B ADC. It will require some glue logic, such as an FPGA to convert it to the MMC interface. Basically I see the FPGA scanning the ADC and placing it in internal FPGA RAM and having the MMC interface read it back out.

Gerald
.

Hi Gerald,

is it possible to get some OMAP-DMA channel to poll a block of data from
MMC at up to 10MBytes per second?
Then feading the 12 to 16Bit data (as 2 Bytes) to the OMAP is at least
possible. If there is no DMA channel for transport, then you might end
up at high ISR frequency which in turn may introduce heavy system load.
Linux of course has much more overhead on handling each isr than having
no operating system.
Annother question will be how to synchronize the conversion to start the
read operation. MMC may not provide a data ready indication (other than
polling -> very big buffers...), so it will be necessary to find a way
to start read operation by interrupt.
I'd expect the FPGA design to provide alternating buffers (may be
controlled by CMD Line?).
Depending on system latency the size of the alternating buffers inside
FPGA may be determined. Of course it must be ensured that reading of the
completed buffer is faster than conversion speed (latency + time for

However I am not familiar on how to design the receiver. Filtering and
precision conversion at 2MHz could easily end up in bad issues if I had
to to it. Coupling from Data interface ADC - FPGA - OMAP might easily
introduce noise as reading from FPGA by OMAP is not synchronized to
conversion...
For sure cheap standard devices will not be a good choice. Only positive
issue about the ADC part is that dc performance is obviously not
necessary. In the marine environment with harsh temperature environment
I'd expect this be hard to handle with respect to the fast signal and
required conversion speed.

I'd recommend to use a higher resolution ADC (14-16Bit) and save some
money on opamps for filtering and conditioning.
But this is only my 2 cent, I'm not too familiar with these measurement
requirements.
Had to handle about 12 bits at several kHz, but automotive environment
and dc precision, so offset did matter a lot...
Cheap and low offset opamps that perform over automotive spec doesn't
really combine to well :-).

regards,
A. den Toom

Gerald Coley schrieb: