The Mitochondrion 3.5 – An Excessive Glowstaff (5 of 8)


Pic by Marla at Kiwiburn 2009

I don’t like dumb objects. I don’t like noticeable user interfaces. I want shiny things that just do what I want, without me telling them what I want. And anyway, given that any physical connections to the outside world will have to come out through the tiny, busy ends, then it’s not like I can cover this staff with buttons unless I want to drill holes in the polycarbonate tube, making horrible stress concentrators and greatly reducing the toughness of the tube. Hence I wanted to squeeze a whole bunch of sensors into the Mark 3.5.

I wanted the Mitochondrion to wake up when spun, and gradually chill out when not spun. Hence there’s two accelerometers in there, I used the Pololu ones, good to 6g. Using two mounted along the axis allows me to subtract the readings from each, cancelling out all translational accelerations and picking up just the centrifugal acceleration to tell me how fast it is rotating.

Accelerometers give pretty noisy data to start with, let alone when spun around. So these readings from these get chucked into a eight-reading buffer in the scratchpad on the Picaxe. When that buffer fills, the Picaxe sums the readings, does a fast shift to divide the total by eight to give an average. I know nothing about digital signal processing, but this works well enough.

I wrote this code, got it working, and the next weekend, that laptop got nicked. So, backup more than once per month. I haven’t had the heart to rewrite it.

Getting fancy
This set up can work out how fast the thing is spinning, but I’d love for it to be able to detect which way is up. Then, it can start to display POV images that don’t rotate in space. However, this turns out to be tricky.

If the mitochondrion is stationary, picking up the direction of gravity is easy, that’s what controls the hue in the screensaver mode. However, when spinning, the 1 g signal from gravity is superimposed on the multiple g signal from the centrifugal force. Added to that, I’m spinning this by hand, so it’s not rotating smoothly around a fixed point.

At some point, I’d like rig it to dump a good pile of acceleration readings to the 32 kB EEPROM, bring that data over to the laptop, and have a play with algorithms, so see if the gravity signal can be extracted from that noise. And then there’s seeing if it can be extracted from that noise with the somewhat tiny computational resources that a Picaxe provides. I’m not hopeful.

Ultrasonic range finders

A transmit/receive pair will just about fit into one end of the tube. Bingo, these can detect it they’re pointing ground vs. sky and provide the reference mark needed to locate the Mitochondrion in space. I tried with a SRF005, works lovely. However, that uses 20 mm diameter transducers and they won’t fit into the ends. Replacing these with the 10 mm transducers that would fit, just didn’t work. Crap range, like less than 20 cm, and huge noise. I couldn’t find any info about why they weren’t compatible, so I gave up on this one.


There’s an electret microphone at one end, a two-stage audio amplifier based on an LM358 op amp, all connected up to the ADCs on the Picaxe. One ADC connects to one amplifier stage, then the feed from that goes into the next amplifier and then to a second ADC. This should give me a decent volume range for sound responsive patterns, It’s there, it works, but I haven’t written the code to respond to that signal, nor has the Picaxe got enough spare programming cycles to cope.

Overall – it’s dumb

So, the accelerometers worked but were noisy, the ultrasonics didn’t fit, and the audio was too much for the Picaxe to deal with. In the end, the Mark 3.5 turned out dumb. Hell, that’s one reason why I’m building the Mark 4.

11 thoughts on “The Mitochondrion 3.5 – An Excessive Glowstaff (5 of 8)”

  1. Re: Excessive Glowstaff

    There’s assorted ways to do wireless links to microcontrollers for this kind of use. Some are even small enough to fit, like wixel or bluesmiRF. In the end, I just like having cables coz debugging is very much easier.

    The Picaxe doesn’t have that averaging built in. Would be nice if it did. Sadly, for something like the battery voltage where you want 10 bits of precision, I’ve yet to work out a clever way to read, buffer, average, and compare without using two 2-byte words of data. That uses up four of my precious twenty-eight bytes of variables just to do something simple and necessary like track the battery voltage. So bugger that, I’m using an Arduino for the next version, whereupon I will roll around gleefully in the vast room available for data.

    Oh, and (mostly) internal sensors away from the crowded ends.

    1. Re: Excessive Glowstaff

      FWIW, you can get a very “seats of the pants” decaying significance average by doing something like:

      average[n+1] = ((7 * average[n]) + new_value) / 8

      (optimising for easy divide, since divide is much more expensive than multiply; multiply by 7 is just two shifts and three adds, and depending on code space could be worth unrolling if the chip architecture multiply sucks.)

      This is mathematically and scientifically relatively imprecise, but it’s very cheap to implement, and relatively quickly will start to drift towards a new permanent value, particularly if you’re sampling quicker than expected change. Some tuning of weighting might be required for expected differential (eg, 6 + 2; 5 + 3, 13 + 3, etc.)

      But using a microprocessor with more than 1970s levels of storage registers and CPU power also works too 🙂


      1. Re: Excessive Glowstaff

        Since putting the Mark 3 together, I’ve been reading chunks of this and this.

        There should be a useful library of really basic DSP tools to help amateurs navigate the treacherous waters between sensors and microcontrollers. I’m not volunteering to write that myself coz I’m too busy getting shiny things out the door (and also I don’t know that much about the topic).

        1. Re: Excessive Glowstaff

          The “maker” movement might have something along these lines (although most things there that have come to my attention are currently a bit more basic than that).

          I’m periodically surprised just how much of the knowledge I’ve gained over 25 years working with computers (yes, literally 25 years) is relevant again later on. And very grateful that much of the more esoteric knowledge was gained at a time when it seemed feasible to “understand everything” about these computer things — something which looks basically impossible now. The “maker” movement is the closest to creating that early “small systems, know everything about making it” sort of philosophy.


          PS: Now that you’re not building a house, surely you need another mammoth project? 🙂

  2. Would it work to have a third accelerometer mounted in the middle, and take the differential output signal to get an idea of where down is? No way you’d have it at the actual center of rotation, but at least with inputs along the length, you could probably computer the CoR and likely get some idea of which accelerations are due to gravity and which due to rotation.

Leave a Reply

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