Subject:
|
Re: another comparison
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Thu, 25 Jan 2007 09:16:03 GMT
|
Viewed:
|
3677 times
|
| |
|
|
In lugnet.robotics, Juergen Stuber wrote:
> Hi Claude,
>
> "Claude Baumann" <cbaumann@ci.educ.lu> writes:
> >
> > We have compared the sampling and computing speed of NXT
> > and RCX. NXT uses standard firmware 1.03 and is programmed
> > with the LabVIEW toolkit. RCX is programmed with ULTIMATE
> > ROBOLAB. Both bricks do the same thing: computing the DFT
> > on a small dataset of 128 points that are read from the
> > legacy light-sensor on a shaft encoder that is rotated
> > with a legacy motor.
>
> do you have the DFT algorithm in some programming language like Java or C?
>
> I'm just guessing, but maybe it could also be useful for speech recognition?
> Or maybe telling the cat from the dog?
> (The sound sensor should be usable as a microphone.)
>
>
> Cheers
>
> Jürgen
Hi Jürgen,
The document, where I develop the theory of the algorithm has some text-pseudo
code ( a mixture of C and PASCAL) that you easily can convert to anything. Since
the document is math stuff, I largely prefer the := notation for assignment.
Note that the RFT algorithm is a recursive interpretation of the DFT. This means
that essentially it can be used as a point-to-point algorithm. The good thing is
that with it you can very easily implement the DFT on any device, even very
restricted in memory. The second new idea in the algorithm is that sines and
cosines are not calculated, but are stored as scaled fix-point values in a
look-up table. The reflections behind are that the number of samples is fixed at
program start. Having a fix number of samples N, I show in the document that
only N different sine or cosine values may appear in the DFT calculations. By
consequence, an N-sized constant array may be used. Another quality of the
algorithm is that you don't loose samples. Normally you sample N points, then
you operate the DFT. During the calculations you won't update your sample array,
unless you use a switching algorithm, engaging more than one data array...
making the code complex.
Now, what are the speed limits. The LabVIEW toolkit example uses the RFT
traditionally only after having sampled N-values. The Ultimate version
calculates the new twiddle factors at each iteration. So, with Ultimate we can
do 5.2ms (even 3.4ms, if the code is optzimized) per sample. As you can see in
the comparison the actual NXT firmware and the toolkit compiler need some work
to improve the timing. Anyway, applying the RFT in a point-to-point manner won't
allow audio sampling. But you certainly can do it, if you sample N values and
then apply the algorithm. Through the look-up table the algorithm is faster than
normal DFT and much shorter than FFT.
-Claude
|
|
Message has 1 Reply:
 | | Re: another comparison
|
| Hi Claude, (...) thanks, I found it at (URL) . And pseudocode is fine with me, Java or C were just meant as examples for textual languages. (...) :-) Best is to avoid assignment and modifiable state whenever possible. Jürgen (17 years ago, 25-Jan-07, to lugnet.robotics)
|
Message is in Reply To:
| | Re: another comparison
|
| Hi Claude, (...) do you have the DFT algorithm in some programming language like Java or C? I'm just guessing, but maybe it could also be useful for speech recognition? Or maybe telling the cat from the dog? (The sound sensor should be usable as a (...) (17 years ago, 24-Jan-07, to lugnet.robotics)
|
11 Messages in This Thread:
 
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
