The Project

Today (Nov 2012) – Osciprime, An Open Source Android Oscilloscope

After the success of the Bachelor Thesis in 2010, we decided to create our own product “OsciPrime” with our start-up company Neuxs-Computing GmbH Switzerland.

OsciPrime Oscilloscope

Website of OsciPrime.

Second Project 2010 – An Open Source Android Oscilloscope

Brief Overview

Our second project (Bachelor Thesis) is an open source Android Oscilloscope. Following features outline the project and final product:

  1. Open hardware Front End from scratch samples at 6 Msps, 8 bit, and high res at 48 Msps
  2. CPLD feeds the Cypress USB FX2 micro controller to transfer data.
  3. The Beagleboard is connected to the Front End with USB and runs Android
  4. Our application processes and visualizes the samples that are acquired using libusb
  5. The data is rendered using OpenGL

Find out all details in our technical report:
To the post

First Project 2009/2010 – The Android Spectrum Analyzer

Brief Overview

Our sample application is a spectrum analyzer.
Here is a brief abstract of what we do.

  1. We are sampling a signal with ~12 kSamples/sec.
  2. These samples are read by our USB FX2 Dev Board over the I2C Interface.
  3. We then send these samples to the Beagle Board over USB.
  4. We then pass the samples to our Android application and calculate the FFT.
  5. Finally we present the spectrum on the display to the user.

Detailed Overview

Core Hardware Components

  • FX2 Dev Board
  • A/D Converter with I2C Interface
  • Beagle Board

Core Software Components

  • FX2 Dev Board Application
  • Android Kernel for Beagle Board
  • Android Root File System Build from Google
  • Libusb for Android
  • fxload for Android
  • Android Spectrum Analyzer

From the samples to the spectrum – our hardware/software path

Peripheral Hardware, FX2 Dev Board and A/D Conv.
Peripheral Hardware, FX2 Dev Board and A/D Conv.

We aquire the source signal samples from the A/D Converter on the right in the picture and pass them to our FX2 micro controller over the I2C Bus. The Board on the left is a FX2 Development Board providing our USB Interface. The samples are then stored in the USB-Bulk Endpoint Buffer. As soon as our Beagle Board sends an IN-Packet to the endpoint the buffered samples will be sent.

Beagle Board running Android
Beagle Board running Android

Our Android application runs on the Beagle Board and consists of two parts. We require to access our USB-Interface – this is done with a native C-Application using libusb 1.0 which we had to port to android. The native application starts the bulk transfers to the FX2 Board and gets in return the requested samples. On the other hand we have a Java Activity running on Android which needs the A/D samples to display and to calculate the FFT. Via JNI the Activity gets the sample buffers from the native C-Application and presents the results on the screen.

pre alpha version of our spectrum analyzer display
Pre Alpha version of our spectrum analyzer's surface view

On the display we visualize the FFT of the acquired samples. We are also creating a brief user interface and some basic spectrum analyzer functions.Γ―ΒΏΒ½ As soon as our application is created we start to tune and benchmark all our software components recursively and find out what capabilities Android can provide in terms of delay, stability and preemptivity.

20 Replies to “The Project”

  1. 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 …


  2. 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?


  3. 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.


  4. 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.

  5. Hey Bishoper,

    We have both implementations, one in Java and the other one in C (port of the kiss fft found here: 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 πŸ™‚


  6. 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++) {

    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.

  7. 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.

  8. 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?

  9. 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?


  10. 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.

  11. Pingback: fft algorithm
  12. 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.



  13. 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 :D)

  14. 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 πŸ™‚


    1. 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

      1. Hey Manuel,

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


Leave a Reply

Your email address will not be published. Required fields are marked *