We Keep Coding

Is there a class for Arduino in C++ that is similar to the Minim class in Processing?

I want to be able to take in a file for music, analyze it and then make lights light up to the music. The only problem is, with the board that I built, using Processing has a big delay on the code that runs and it has maybe a obvious 10 ms gap. I need a way to either bring the program back into Arduino, or somehow lower the response time. Any ideas?

It's unclear how you're dealing with the serial communication and where the bottlenecks would start to show up (audio processing/serial comms/both/something else/etc).
Regardless, if you want to do sound analysis on Arduino alone, that will be a challenge, as you'll have a lot less resources to do the FFT number crunching on an 8-bit micro controller.
I would go either of two ways:
Do the sound analysis as efficient as possible on the computer and map it to lights so the software(Processing) only sends minimal data to the firmware(Arduino)(just light data, on a need to know basis). If you have a ridiculous amount of lights you might want to use a serial converter than can handle higher baud rates, but in most cases you shouldn't need that.
Do a minimal sounds analysis on Arduino. If you got your light animations right, you can make something sound reactive using just the amplitude and a bit of easing without getting into FFT/MFC or anything fancier. If you really really want light responsiveness to frequencies consider using a 7 band frequency analyser chip like MSGEQ7. There are Arduino breakouts that make that easier.

Having problems getting Weight Data with Android from a BLE Scale

I'm currently developing an android app for a weight scale I received that transmits data through bluetooth low energy.
I was looking at documentation and if I got the information correctly, there are specific UUIDs for data. I received a BLE scale with a Chinese protocol document found here: http://www.anj.fyi/protocol.pdf
I found and was able to get a functioning scanner working that lists the device name and the UUIDs it broadcasts.
Lets say I want just the weight data to show up in the UI, nothing else and nothing more.
I don't know what UUID they used for the weight data, and there are a lot of UUIDs. Probably 20+. I checked a UUID compilation and the usual weight data UUID does not show up.
How do I get the data from those UUIDs?
I'm thinking it might be the ones that are notifications, indications or read properties.
Looking at the UUID for example, f000ffc2.
How would I get data from that characteristic? Would anyone have an example code to grab the data from those UUIDs, or tutorials because I'm terribly lost right now.
I really appreciate it.

There are no weight information on the document you list http://www.anj.fyi/protocol.pdf, it is only shows the BLE module hardware interface spec, i.e. it does not specify the detailed service and characteristic.(I an a native Chinese speaker).
Regarding to the UUID you want to know which is the one to represent the weight, yes you are right it should be the read/notification feature without write permission. Can you use the apps e.g. lightblue on iOS to receive the notification(meanwhile change the value on your device) to test it? this will help you to understand which characteristic is the one you want.

How to handle the high data rate of fluorescence microscopy camera?

I have a question how I can learn to handle (with perhaps java) high data rates. My task is:
I will have a fluorescence microscopy camera with around 1Gigabyte/s and number of images between 100/s and 1000/s.
The image data should be written uncompressed as raw data on the disk. The storage system is not yet decided and should be dimensioned based on the needed performance. During the data acquisition a more or less live image should be shown.
Has somebody some suggestions for books or lecture notes for me?

Your question is pretty open ended, but I can give you advice based upon my past experience building multi-camera, real time data acquisition systems.
Typically these data acquisition systems require (though you may have to purchase it separately) a video capture card. the cards typically buffer some number of frames and the frame rate you can support depends on home long you need to run the acquisition system and the slowest data transfer rate in the "camera->capture card->hard drive" chain. These cards typically come with a documented API (typically in a C variant, I've never seen a Java variant but that doesn't mean it doesn't exist) and libraries that you can compile against that support code using the documented API functions to record data to storage.
When I have worked on systems that just needed a full motion video frame rate (~ 30 Hz) a windows box with a capture card has sufficed just fine. I am pretty sure you can get cards that will sample in the 1kHz range or higher (depending on your camera resolution), but you may be limited on the duration you can sample (given the limited available storage) during the acquisition process if you are sampling data faster than the buffer can clear it to final storage.
Also there is no reason for you to display >30 Hz at one time, no display system is going to support a 1kHz refresh rate, and the human eye can't process >30 Hz anyway.
Unfortunately in my experience these systems are put together piece meal because they are highly specialized which limits the market and disincentivies a standardized approach. The bottom line is that you are probably looking at either using a capture card manufacturer provided API interface (I'd advocate against wrapping it in JAVA because you'll just be adding extra latency that you can't afford at the acquisition rates you are talking about) or having an Electrical Engineer custom fit your solution. If I were in your shoes, I'd be searching for a capture card that meets my requirements, perhaps from the microscopy camera manufacturer.

On Android/Java, how many bytes has a connection downloaded?

An Android app I'm writing involves quite a lot of downloading of content (think podcatcher/RSS).
I would like to be able to give the user an indication of how many bytes they've downloaded, so they can make the decision whether they want to use Wifi or not.
To this end, I have found a way of counting the number of bytes read by the app, by wrapping an InputStream in a simple CountingInputStream.
However, this does not take into consideration basic things like packet headers and HTTP headers. More importantly, it does not take into consideration any compression that content may be encoded with.
So, how many bytes did my application download over the network? I'm not so interested in the number of bytes uploaded, but if know how, don't be shy.
I have gone down a fairly low level approach as I am feeding the input stream into an XML PullParser. I will also be needing to do a similar exercise with dumping bytes (images in this case) straight onto the SD Card.
Is this the best approach? What am I missing?

ufff... I think this is pretty transparent to underlying protocol, so you can't count all these bytes used in session or link layer, and operators like to charge even for control bytes which are not in any way visible to end user. Also they count traffic in both directions (your reqest to server takes also some), so - good question is: how to measure needed traffic/money for downloading that picture... ?

This isn't a direct answer, but you could try asking someone who has solved a similar problem before, e.g. a data counter application. I've used NetCounter by Cyril Jaquier (http://www.jaqpot.net/netcounter/), and he claims his software is open source. I couldn't get his download link to work, but there's a contact email address. If you got his source code, you should be able to use the same method as him.

As I know, there are two ways to count data traffic. One is /sys/class/net/{interface}/statistics as mentioned in android app named netCounter, the other is /proc/net/dev which is used in android app named wifi-tether. But I don't know the difference between these two methods nor which is better.

The number of bytes received by a particular app is stored in /proc/uid_stat//tcp_rcv where app_uid is the uid of your app on the particular device.

Sound Processing - Beat Matching Music Player on Android

So I want to make a new music player for Android, it's going to be open source and if you think this idea is any good feel free to let me know and maybe we can work on it.
I know it's possible to speed up and slow down a song and normalize the sound so that the voices and instruments still hit the same pitch.
I'd like to make a media play for Android aimed at joggers which will;
Beat match successive songs
Maintain a constant beat for running to
Beat can be established via accelerometer or manually
Alarms and notifications automatically at points in the run (Geo located or timer)
Now I know that this will fall down with many use cases (Slow songs sounding stupid, beat changes within song getting messed up) but I feel they can be overcome. What I really need to know is how to get started writing an application in C++ (Using the Android NDK) which will perform the analysis and adjust the stream.
Will it be feasible to do this on the fly? What approach would you use? A server that streams to the phone? Maybe offline analysis of the songs on a desktop that gets synched to your device via tether?
If this is too many questions for one post I am most interested in the easiest way of analysing the wave of an MP3 to find the beat. On top of that, how to perform the manipulation, to change the beat, would be my next point of interest.
I had a tiny crappy mp3 player that could do double speed on the fly so I'm sure it can be done!
Gav

This is technologically feasible on a smartphone-type device, although it is extremely difficult to achieve good-sounding pitch-shifting and time-stretching effects even on a powerful PC and not in realtime.
Pitch-shifting and time-stretching can be achieved on a relatively powerful mobile device in realtime (I've done it in .Net CF on a Samsung i760 smartphone) without overly taxing the processor (the simple version is not much more expensive than ordinary MP3 playback). The effect is not great, although it doesn't sound too bad if the pitch and time changes are relatively small.
Automatic determination of a song's tempo might be too time-consuming to do in real time, but this part of the process could be performed in advance of playback, or it could be done on the next song well before the current song is finished playing. I've never done this myself, so I dunno.
Everything else you mentioned is relatively easy to do. However: I don't know how easy Android's API is regarding audio output, or even whether it allows the low-level access to audio playback that this project would require.

Actually, you'll have 2 problems:
Finding the tempo of a song is not easy. The most common method involves autocorrolation, which involves quite a bit of calculus, so I hope you've studied up.
Actually changing the beat of a song without pitch shift is even harder, and still results in sound artifacts in the song. Typically it takes a long time to edit audio in this way, and it takes a lot of tinkering to get the song to sound good. To actually perform this in real time would be very, very hard. The actual process involves taking the Fourier Transform of the audio, shifting the frequency, and taking the inverse Fourier Transform. More calculus, this time with imaginary numbers.
If you really want to work on this I suggest taking a class in signals and systems from an Electrical Engineering department.
Perhaps an easier idea: Find the tempo of all the songs in a user's library, and just focus on playing songs with a close beat to the jogger's pace. You still need to do #1 but you don't need to worry about #2.

Changing the audio speed on the fly is definetly doable; I'm not sure if it's doable on the G1.
Rather than writing your own source I would recommend looking at the MythTV source and/or the mplayer source code. They both support speeding up video playback while compensating the audio.

http://picard.exceed.hu/tcpmp/test/
tcpmp did all that you asked for on an iddy biddy Palm Centro... And More, Including Video! If it can be done on a Palm Centro, it sure as heck can be done on the Android!!