Oscione – an open source Android Oscilloscope

Hello everybody, it has been a while since our last post, nevertheless we are proud to introduce our new project:

Oscione – an open source Android Oscilloscope.

The project consists of both a custom hardware front-end for data acquisition and an Android application for visualizing the collected data samples to the user. Data is transferred over USB to the Beagleboard running Android, and then plotted on an external screen. As mentioned, the whole design is entirely open source, therefore everybody is highly encouraged to rebuild and further develop both the hardware and software parts of the application. Source code and layout files are all included in the above link. Furthermore, the Android application is considered to be a stand-alone Oscilloscope UI, with the ability to visualize other data sources such as the microphone input of an Android mobile phone.

In the above link, you will also find a technical report with detailed explanation of both hardware and software development.

Oscione User Interface
Oscione User Interface
Oscione custom hardware front-end
Oscione custom hardware front-end

11 Replies to “Oscione – an open source Android Oscilloscope”

  1. Impressive work guys! I was trying out your application on my Android phone and there do seem to be some issues though. The rendering seems to freeze just after a few seconds for audio source. And, the channel gain buttons are not visible. Have you had a look into this? Any suggestions on how to correct this bug?

    1. Thank you very much Jiv!

      The Channel Gain functionality is only supposed to work with our hardware front end since it issues commands to the USB Device and adjusts “real” hardware gain.

      Although it would not be that complicated to add Audio-Gain functionality…
      If you are familiar with the sources:
      the native function:
      copyVertexInt() found in ./jni/vertexCopy.c should take another parameter (float scale, for example) and then multiply the scale with the sample for the result in the vertex buffer.

      ….
      for(i = 0; i < len; i++){
      ch1buf[2*i] = (float)i;
      //old ch1buf[2*i+1] = (float)ch1carr[i];
      ch1buf[2*i+1] = scale*(float)ch1carr[i];//new
      ….

      The first issue you describe sounds new to me, can you maybe link some adb log? It might be, that our buffer size does not work with every phone 🙁

  2. Thanks for the amazingly prompt reply Manuel! Certainly cleared a few doubts. Earlier I wondered how the x-cordinate information was supplied to openGL. Your reply cleared that up as well. Still finding my way around Android..

    I’ll try to get hold of the adb log soon. Unfortunately, something went wrong with my phone and i’ve had to make do with the emulator for the past few days 🙁

    Anyways, i seem to have detected another issue. The rendering completely stops after changing the screen orientation or even re-selecting the same source. It seems the sine source is not able to re-start properly. In the logcat the events “mCurrentSource start ()” and “mCurrentSource start terminated” occur one after the other in these cases whereas earlier, when the app started, there was significant initialisation activity in between them.

    Any idea how to correct this? Would it be necessary to kill and restart the app every time the screen orientation changes? Grateful for your help..

  3. Hey Jiv!

    Wow! I am impressed with your interest in our App 🙂 You can also connect to your emulators console with the command “adb shell”.
    I am well aware of the Generator-Issues 🙁 and I thought I fixed the problem with the orientation but it looks like it is not done yet :(.

    The Problem lies in the Activity Life-Cycle handling which is done rather lousy in the Oscilloscope.

    I believe the source of the error is the reference to the Service from the Activity. Therefore when the Activity goes into the background the service should be stopped and started again in the onResume() … Or alternatively onResume should assure, that the Service does not get restarted as long as it is still running.

    Also the AudioSources “stop” method might not do what it is supposed to… I had very little time in the project to seriously implement the Audio Source.

    I hope I could help you a tiny bit.

    Cheers
    Manuel

  4. Impressive work ! I have just found the project and I am reading it .
    Could you please tell me if the sampling board-FX2 it’s behaving like host to android computer ? (beagleboard ?) I have seen that you have compiled LibUsb for Android. This means that the beagleboard will behave like host to sampling board ?

    Kind Regads,
    Daniel

  5. Hi Daniel,

    The Beagle Board is the host and the FX2-Board plays the role of the device.
    Therefore we mounted the usbfs on Android so we can use Libusb.

    Cheers
    Manuel

  6. I am very impressed with the project and also with the care which you took in documenting and reporting your experience. I would like to thank you for this – your document has been extremely useful to me in evaluating Android as embedded OS.

    I am starting up a development project using Android as the software underpinnings for a system as part of the Artificial Pancreas Project. I have been looking closely at the Beagleboard as a development platform. I love the level of developer support but need something in an enclosed case. Are you aware of any currently available Android tablets which provide a similar level of support for embedded developers?

    Thanks!
    Patrick

    1. Thank you so much Patrick!

      As a matter of fact we are exactly looking for the same platform. I am actually worried that we will not see an “open” tablet in this year. An alternative would be to “root” a tablet that is currently available and then build Android on top. I really hope there will be a developer tablet on the market any time soon!

      Cheers
      Manuel

Leave a Reply

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


*