20 thoughts on “The Project”

1. Pingback: Using Android in Industrial Automation » Project Overview

2. Evan Feng December 9, 2009 at 05:41

   Amazing project

   I just want to know, when the signal data meet ~384k + Samples/sec , can the OMAP3530 handle this (FFT) ?

   Thanks ^^

   Reply ↓
3. Manuel Di Cerbo Post authorDecember 9, 2009 at 14:04

   Thank you very much Evan

   At the moment we are at a sampling rate of 9.5 to 10 ksamples/s. The display can still handle that load.
   Say you want to do a 1024 order FFT at 400kSamples, if your samples are buffered, you would then have 1/400’000*1024 [s] to execute the FFT which leaves us at roughly 2.5[ms].
   Well with the kiss_fft I get a time of 0.0102 [sec] (ofc this is not a deterministic system) …
   So you would have to tweak a bit or use the DSP …

   Cheers
   Manuel

   Reply ↓
4. Evan Feng December 10, 2009 at 15:23

   @Manuel Di Cerbo

   Thank you very much Manuel. Your answer is really helpful for me. I think I should learn how to use the DSP core first.

   Thanks
   Evan

   Reply ↓

5. Pingback: beagleboard « ?????

6. Biosopher January 6, 2010 at 00:18

   Hi Manuel,

   I was curious if you’re performing your FFT using Android or not. We’re analyzing audio recorded from an Android phone’s microphone and then performing 256*2048 FFTs on it. The FFTs are taking 10 seconds to process in Java. We’ve considered reimplementing in native code to hopefully get better performance. It seems Android’s Dalvik VM is optimized for memory footprint rather than processing speed.

   How fast would you expect your own FFT algorithm to run for 256*2048 FFT? Is it coded in Java or using JNI?

   Thanks

   Reply ↓
7. Manuel Di Cerbo Post authorJanuary 6, 2010 at 00:24

   Hi Biosopher!

   I will be back in school tomorrow and perform an 2048 FFT with the kiss_fft library. 10 Seconds for 256 FFTs sounds a lot. I am pretty sure we are faster even with our Java implementation.

   I will post some results and code here tomorrow.

   Cheers
   Manuel

   Reply ↓
8. Biosopher January 6, 2010 at 01:01

   Thanks Manuel,

   I’m guessing your kiss_fft is in C though…not Java. Or did you port the kiss_ft to Java? We rewrote our FFT code in Java but it’s currently too slow on Android’s JVM. We’re considering reverting back to our C FFT and running it using Android’s native interface.

   Reply ↓
9. Manuel Di Cerbo Post authorJanuary 6, 2010 at 01:53

   Hey Bishoper,

   We have both implementations, one in Java and the other one in C (port of the kiss fft found here: http://sourceforge.net/projects/kissfft/) which we access over the Java Native Interface. For our application both implementations run fast enough on the Beagle Board.
   Yet I am still pretty confident that the JVM should be able to handle the load

   Cheers
   Manuel

   Reply ↓
10. Biosopher January 6, 2010 at 18:52

    Hi Manuel,

    It seems that basic operations are incredibly in the Dalvik VM used on mobile phones. For example, this VERY simple iteration over an empty method takes 1.4 seconds even though it doesn’t do anything:

    public void performanceTest5() {
    for (int i = 0; i < 2000000; i++) {
    emptyMethod();
    }
    }

    private int emptyMethod() {
    return 0;
    }

    Doing something a little more complex like calculating the imaginary component of a complex conjugate 2 million times takes 3.2 seconds:

    public void performanceTest7() {
    for (int i = 0; i > 16) * ((c <> 16)) + (((a & 0X0000FFFF) * ((c <> 16)) >> 16);
    y = -y;
    y += ((b >> 16) * (c >> 16)) + (((b & 0X0000FFFF) * (c >> 16)) >> 16);

    }
    }

    It appears the Dalvik VM has substantial overhead for even basic computational operations.

    I’m curious though how fast these same operations take on the Beagle Board.

    Reply ↓
11. Manuel Di Cerbo Post authorJanuary 6, 2010 at 19:47

    I tested the performance with the native implementation and get around 21.9 [ms] for one 2048 fft.

    With our java implementation 256 ffts of the length 2048 take 14.3 seconds… so yeah … seems really slow

    I’m a bit disappointed, I hoped the jvm was quicker.
    It seems to me that you have to go the native way unless there is a trick to make the jvm faster.

    Reply ↓
12. Biosopher January 6, 2010 at 20:14

    Great! Well…great that you were kind enough to test and validate those performance numbers for me.

    So the native solution is fast but not incredibly so: 256*21.9ms still equals 5.6 seconds. That means the native solution is only 2.5 times faster. Or perhaps there’s some start up overhead for that single native fft and the other 255 ffts would perform faster native than 5.6 seconds?

    Reply ↓
13. Manuel Di Cerbo Post authorJanuary 6, 2010 at 21:19

    I doubt that there is a major overhead. The only thing that might be overhead is the memory allocation of 2048 bytes. I can’t imagine that this has a large influence on the performance.

    However, what you can try to speed up the process is to use only fixed point arithmetic. Although this wouldn’t be as exact as floating point operation and therefore result in “noise”. Depending on your application, this might still be a suitable solution.

    The really “nice” way to calculate the FFT would be to access the OMAPs DSP and do the calculation there. Although it might be a bit of a challenge to access the methods of Texas Instruments’ “dsplink” over JNI.

    All in all I say the only way to go if you need speed is through the DSP. Our goal is create another post of how we managed to access it with dsplink but our method is still not complete (we struggle with the fixed point arithmetic) yet. Hopefully we will be able to post a complete “howto calculate a fft with dsplink on the beagleboard using android” by the end of the month.

    May I ask what hardware platform you are using?

    Cheers
    Manuel

    Reply ↓
14. Biosopher January 8, 2010 at 01:46

    Hi Manuel,

    I’m performing my tests on a Motorola Cliq and HTC Hero. I’ve just started implementing my FFT code with Android’s NDK, but so far, my performance tests are looking much better….more like C-performance as expected.

    Reply ↓

15. Pingback: fft algorithm

16. rahulkatariya July 7, 2010 at 17:57

    Hello Biosopher,

    I am Rahul, student in Uni Of Surrey UK.
    For my project I need to find FFT of sensor data samples.
    I really appreciate your work.
    Can you please help me with your NDK FFT code.
    It will be a great favour.

    Cheers,

    Rahul

    Reply ↓
17. An.Tran December 12, 2010 at 04:54

    Hi Biosopher,

    cool project , I also want implement your design by my self , but i think i can’t , cause i have no knowlege on Android field . i’m firmware engineer with 10 years experience in data acquisition and DSP , for your hardware , i subject you using DSPIC33FJ16GS502 , this chip have High speed ADC (4MHz) and 4 DAC , by using this chip you could integrate Function generate (signal generate ) on your project . (i hope , i you allow , i can help you program this chip )

    Reply ↓
18. Nitish March 4, 2013 at 13:39

    Hi Manuel,

    First of all hats off to the OsciPrime team, you guys have done a wonderful job. I’ve recently forayed into open source development and I just downloaded the OsciPrime(current) source code from your website. I imported the code into Eclipse but can’t locate the layout xml file for UI elements(or are you instantiating the layout elements at runtime) , can you please help me out? I just wanted to have a closer look at the GUI implementation

    Cheers
    Nitish

    Reply ↓
    1. Manuel Di Cerbo Post authorMarch 4, 2013 at 13:55

       Hey Nitish!

       Thank you so much
       You want to have a look at res/layout/main.xml where everything is in a framelayout and nested into a relative/linearlayout.
       The SurfaceView is then added during onResume, since I did not want to reference it in the xml at the time.

       Hope it gets you started

       All the best
       Manuel

       Reply ↓
       1. Nitish March 5, 2013 at 08:01

          Hey Manuel,

          Thanks for the help. Much appreciated. It worked, now hoping to fiddle a bit with the OsciPrime code.

          Cheers,
          Nitish

          Reply ↓