Mitochondrion mark 4 – First public spin

So I quietly set myself a deadline of having the the Mitochondrion mark 4 ready for this weekend’s dance party (after having missed the deadlines for Kiwiburn and the Juggling Festival, and having taken the mark 3 apart more than two years ago). As of last Monday, it finally all came together, so here’s the first public spin, at Saturday’s Circillumina dance party:

A decent number of people asked me what brand it was or where I bought it, which is the level I’m aiming for.

It lasted an evening of dancing about, or rather, it lasted longer than my arms did, coz it’s a lot heavier than the mark 3, what with the twenty batteries in there.

The mark 3 ran off a Picaxe with 23 bytes of memory for variables, so all it did was through pre-processed patterns at the LED drivers. The mark 4 runs on Arduino Nano, at Atmel 328P with two thousand bytes OMG the hugeness! “2000 bytes ought to be enough for anybody.”* The LED drivers are now one driver per LED, rather than one per five, and can cope with 127 independent levels of red, green, and blue for each LED, rather than a horrible mess of dependent levels leading to about four possible colours per LED. Thus this can do smooth fades of brightness and hue on any LED. And structurally, the mark 3 was a mess of circuit boards, bits of wood, and dodgy wiring. This version has two aluminium spines inside the polycarbonate tube, with 3D printed parts holding the batteries and end pieces (Thanks to Patrick Herd and Shapeways.)

The software is C++ not BASIC and I’m exceedingly happy about that. It’s running a minimal co-operative multitasking framework where particular tasks can be set to run at particular points in the future. So the supervisor code can just tell the battery sensor object to run again in five seconds time and not have to worry about it until then. Message passing between tasks is mostly a bunch of globals for things like msg_isSpinning and msg_batteryFlat. (Thanks to ferrouswheel and He Who Cannot Be Named on the Internet for code design help.)

There’s enough computational grunt to generate patterns, although I’ve spent all my coding time on the background code and hardly any on the pattern generators. So in this pic, one task is just painting the length of the staff a dim blue, the other is drawing the two moving white blobs. With two trivial pattern generators running, it’s pushing out about fifty frames per second. I want it faster.

Next software job for me is profiling all this code and speeding things up, then writing some pattern generators that are driven by the audio and motion sensors and that use textures and icons stored in the 128 kB EEPROM chip that I’ve also squeezed in there. And rewriting the supervisor so that there can be N pattern generators, so that the microcontroller is always fully loaded, rather than two and only two. Next hardware job is to work out why the 24V to 5V DC-DC converter isn’t turning off when the Arduino tells it to turn off, leading to a standby mode that flattens the batteries in a day. Oh, and there’s a couple of loose wires in one socket, and that and that and a few other things…

But hey, MVP. It goes.

* – Most of the crashes in development were down to this memory limit. All the debugging text gets stored in the SRAM, along with all the variables, arrays, and objects. Running out of SRAM causes a silent crash. So when something is making it crash, what do you do? Well, the only debugging is to print out text via the serial line, so you add more debugging text and… you’ve now caused it to silently crash for a second reason. Grr….

7 thoughts on “Mitochondrion mark 4 – First public spin”

  1. I apologise in advance for the lame formatting I know LJ is going to do, given the choice of editor offered 🙁

    (The list of things it doesn’t do is still longer than the list of things it does)

    Isn’t that true for any thing in existence? The only things with a longer list of things that they “do” than than the list of things they don’t do are vapourware. Just saying.

    [….] coz it’s a lot heavier than the mark 3, what with the twenty batteries in there.

    We do know someone interested in providing wireless power to devices… and there’s also at least one other external energy input into the — working — device, in the form of motion in a gravity field, which doesn’t rely on batteries. “Just start spinning it to turn it on” does have a certain Cool Factor ™ on a feature list 🙂


  2. True, but whenever I think “hey wouldn’t it be cool if it did X” then I shunt that idea off into the plans for mark 5. There’s a finite list of things that I designed the mark 4 to do and I’m not half-way through it yet.

    And I think the answer is lithium batteries, which requires me to ask myself the following question: “are you sure that it won’t catch fire?”

  3. Hi, I’m a fellow staffer/glow tinkerer and I’ve seen your work over the years, and can’t say how happy I was to see you’re on the path of arduino/addressable strips/sensors/bluetooth 😉 I have been thinking over doing this combination for a couple years, but unfortunately won’t start a build for another couple due to newness to MCs and an analog staff project for my next step… All the same I would love to keep in touch and hopefully gain some wisdom when I do take the plunge!

    My dream is that POV-like instruments like this can be programmed together by the community, so I thought I’d ask about your longer term goals for this project… you have probably come across development in glow hoops with bluetooth features but nothing that is arduino and I’m guessing open-source orientated. All merely food for thought at this stage I suppose but would make a huge difference in the long run…

    Also if you’re researching power sources at the moment I do believe li-ion/IMR are the only choice, just reading about power and capacity reports from candlepowerforums, an endless source of info.

Leave a Reply

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