Time for some fun!

The first thing I did was break the plastic housing off the mic and exposed the sensor, I snipped off the headphone socket and taped up the rest. It’s not the prettiest bit of electrical tape you’re likely to see, but it does the job:

I then taped the mic to the airlock roughly at the area where the bubbles will be, then taped the whole thing up to make it a bit more water-resistant.

Okay, now onto the fun bit: writing the software

The easiest way to get sound from the mic port is to use ALSA‘s arecord, which comes as part of alsa-utils and should already be installed on your distro. Run amixer from the command line to find the correct input and unmute it if required, but in most cases just running arecord will work. I set my volume levels to be 100% (unamplified) as I want to be the only person messing with the data.

I’m after a raw stream of data without any of that WAV header nonsense, so throwing a stream of raw longs to stdout looks a little like this:

gaz@beast:~$ arecord --format=S32_LE --file-type=raw

The next task is detecting the bubbles in this raw data. The mic is touching the airlock so the bubbles are very loud and high pitched, so plugging in a high pass filter might help get rid of any background noise. I found that using Audacity’s high pass filter managed to keep the bubble track intact while filtering out most of the the sound of a vacuum cleaner, which is pretty impressive. I didn’t write my own high pass filter as it seems to work okay without one, maybe I’ll make an FFT-based one in the future.

For the moment though, I simply defined a bubble-part as a volume reading that is two standard deviations away from the mean, where the mean is taken by summing the distance of each sample from the base line; waves always add up to 0, so we need an absolute measurement from the base line or the average will always be 0. If this bubble part is more than t milliseconds from the last one, then we have a new bubble.

My limited testing shows that the bubble count appears to be roughly right even when I’m playing music in the background, but it will probably need some tweaks before it works in all cases. So far it’s only been tested with my 25 litre plastic wine fermenter, so I have no idea how it will perform on demijohns. I can think of a number of things that are wrong with the algorithm too.

For a start it’s adaptive, so if you simply unplug the cable then the odd bubble will be detected. A minimum bubble length may help here. Secondly, the averages are taken from the last listening period so it’s all dependent on the length of this window, moving averages might be better, but would be more processor intensive (as if Python wasn’t processor intensive enough) and I have no idea what that does statistically, but I imagine it’s not good from a purist perspective. Finally, it’s using average volume of each |sample value| but it actually uses peak levels to detect bubbles, so I guess that it ought to be using the maximum |sample value| over N samples where N is equivalent to some minimum frequency.

Ignoring all that it appears to work okay. Here’s a graph that shows it in action along with my thermometer, the dip is caused by me dismantling it while taking the photos above.

You can download or fork the the code over github.

Happy brewing!

Thankfully, a search for the device ID (0c45:7401 Microdia) finds ruby bindings for Temper.c by Michitaka Ohno, which conveniently includes the reverse-engineered USB protocol. So I’ve forked this on GitHub, removed the Ruby bits, edited the unit test wrapped it up in a little script that logs the time and temperature to a CSV file. It currently only supports one device, which will change if I ever get another one of these devices (spoiler: I probably will)

To start logging your TEMPer1′s data in Ubuntu just

 # install dependencies
 $ sudo apt-get install git build-essential libusb-0.1.4 libusb-0.1.4-dev
 # clone the logger
 $ git clone git://github.com/bitplane/temper.git
 # build it
 $ cd temper
 $ make clean
 $ make
 # start logging!
 $ sudo ./log.sh > temperature.log

Now I’m just waiting for my USB clip-on-mic to arrive. Once it does I can log the bubbles from the airlock on my beverages along with the temperature, and make some pretty graphs.

Watch this space!

Expect lots more activity there in the future

If you fix any bugs, please send a pull request and I’ll do my best to merge them in, but keep in mind this is also my first attempt at using git; expect schoolboy errors there too!

I guess I’d better make a promotional image for Market and update the screenshots so they actually look like recent versions of the app!

• a) Using Float.parseFloat(String): 1516.449ms
• b) My own parseFloat(String): 654.882ms
• c) …and my own isDigit(char): 449.622
• d) …and isDigit written inline: 295.865ms
• e) …copying the string into a char buffer and avoiding all string access and method calls: 254.527ms (112ms spent copying the characters!)

So in theory, if the method took a character buffer and length it could be as short as 135ms, over ten times faster than Float.parseFloat. I’m currently using option d as gives a nice performance gain without breaking my design, but when performance tuning the entire API later this may see some huge changes. Here’s the function I cooked up:

public static float parseFloat(String f) {
	final int len   = f.length();
	float     ret   = 0f;         // return value
	int       pos   = 0;          // read pointer position
	int       part  = 0;          // the current part (int, float and sci parts of the number)
	boolean   neg   = false;      // true if part is a negative number
 
	// find start
	while (pos < len && (f.charAt(pos) < '0' || f.charAt(pos) > '9') && f.charAt(pos) != '-' && f.charAt(pos) != '.')
		pos++;
 
	// sign
	if (f.charAt(pos) == '-') { 
		neg = true; 
		pos++; 
	}
 
	// integer part
	while (pos < len && !(f.charAt(pos) > '9' || f.charAt(pos) < '0'))
		part = part*10 + (f.charAt(pos++) - '0');
	ret = neg ? (float)(part*-1) : (float)part;
 
	// float part
	if (pos < len && f.charAt(pos) == '.') {
		pos++;
		int mul = 1;
		part = 0;
		while (pos < len && !(f.charAt(pos) > '9' || f.charAt(pos) < '0')) {
			part = part*10 + (f.charAt(pos) - '0'); 
			mul*=10; pos++;
		}
		ret = neg ? ret - (float)part / (float)mul : ret + (float)part / (float)mul;
	}
 
	// scientific part
	if (pos < len && (f.charAt(pos) == 'e' || f.charAt(pos) == 'E')) {
		pos++;
		neg = (f.charAt(pos) == '-'); pos++;
		part = 0;
		while (pos < len && !(f.charAt(pos) > '9' || f.charAt(pos) < '0')) {
			part = part*10 + (f.charAt(pos++) - '0'); 
		}
		if (neg)
			ret = ret / (float)Math.pow(10, part);
		else
			ret = ret * (float)Math.pow(10, part);
	}	
	return ret;
}

This is of course a very crude method, it requires a well-formed number and will return 0 or partial numbers instead of raising exceptions, it doesn’t work with hex floats or parse NaNs or Infinity and it doesn’t use doubles internally so the accuracy is not perfect. It does however work for my purposes, so I thought I’d share it with the Internet.

My main problem is that Java is a horribly verbose and restrictive language. To do the simplest things you need to implement at least three interfaces and extend a couple of abstract classes (after reading the documentation for each of them and their alternatives of course). Something which could be written in Python in three lines of code and two minutes takes fifty lines and twenty minutes in Java. Perhaps that’s just me, maybe I’ve been spoiled by dynamic languages and expect to be able to do things a hundred different ways by just typing whatever comes to mind, rather than carefully considering the available options and planning every step of my app. In my short journey through Java development I’ve suffered a lot of pain because I make assumptions and choose a design pattern which is incompatible some point later down the line, so I end up refactoring everything ten times before I even get a working prototype. I’m slowly learning not to fly by the seat of my pants (even if it is the most fun way to fly) and perhaps that’s a good thing.

My other gripe is the UI editor and XML format, their steep learning curve makes the design stage a huge time sink. I’ve now spent a fair bit of time banging my head off my keyboard while attempting to make the simplest of interface, which still don’t look like they do on paper, but I think I’m getting the hang of it.

Anyhow, so far I’ve managed to knock out 3 applications which are available in the Android marketplace:

Anonypic

This little app just adds an extra option to your share menu, and will upload an image to bayimg.com, the anonymous image sharing service by the creators of The Pirate Bay. Images have their EXIF data removed, so you can share images without leaving a trail of metadata leading back to your phone.

Rainwatch

Rainwatch is an alternative viewer for the BBC’s Maps Presenter, the Flash application available on their weather site. It’s far from complete but is good enough to predict the weather, so I’m quite happy with it (as are my 1500 active users)

MC Mail

MC Mail, or Missed Call Mailer is a little app which sends you an email when you get a missed call. The back-end is written in PHP and MySQL, the front-end is mostly just a service which monitors your call log. Useful if you’re a hospital or call centre worker who has access to email but can’t use a phone in work, or if you always forget your phone. It usually only works while the phone is in silent mode.

Next steps?

I’ll make a couple more apps and maybe a game, then learn the Native Development Kit and port Irrlicht using Christian’s OpenGL ES driver. I haven’t done any Irrlicht code in ages, so that’s certainly on the agenda.

http://favicon.bitplane.net/

read more…

Since the video is generated from the SVN version history it starts at the point where Niko gave hybrid and I SVN access (June 2006), so misses out years of development leading up to the 1.0 release.

code_swarm is a really cool tool, one thing which is exciting is the fact it supports MediaWiki. It would be really nice to show a small wiki coming together.. or maybe one day Wikipedia’s entire changelog (we can dream!)