Mitochondrion blathering – v3.6 or v4.0?

Listing my projects on tatjna’s blog reminded me that I have a Project 0 – keeping the Mitochondrion working. Currently, the reset port needs replacing. It’s a two quid part, but an hour job to tear down the end and replace the old one.

This is forcing me into choosing between fixing the latest problem with the v3.5.4 and making a newer, shinier one. The current one has been banged around enough that I’ve fixed most of the fixable flaws, and it’s reliable enough to work through Kiwiburn and then Foocamp without surgery, and that’s not bad, considering what it does.

Still, there’s some fundamental limits and problems with the current one:

  • Unreliable hardware.
  • Unreliable software. Naked pointers in BASIC and only 26 bytes of variables?
  • Last generation driver chips. Slow PWM means no smooth colour fades, limited colour choice per LED, and no good way of resetting driver crashes.
  • Slow microcontroller, to the point where generating patterns based off sound isn’t going to happen. Hell, displaying any patterns that aren’t preo-processed isn’t going to happen. It’s running interpreted BASIC, ffs.

Thus there’s going to be a new one (after I’ve finished the house, Fannies, My Dick, and possibly a few other things). The question is, should I go for the v3.6 or the v4.0. V3.6 would just be an incremental improvement on the existing model. The new LED driver chips (PCA9635‘s) are much the same, just with faster PWM, better colour control on each LED, and an external reset line. Light board designs won’t have to change much. I could use the new model of Picaxe (Picaxe 40X2, the microcontroller than runs it all), twice the speed and more memory, same development environment and will drop in to the existing board designs. New ends and circuit boards can be made by others (Ponoko & Olimex), using stronger materials and better precision than I can manage in my kitchen, which will help the reliability. And that would be nice.

But there’s a nagging in my brain. The LED spacing is set by the need to fit the driver chips in between them, and the new chips are only 10 mm long, so the LED spacing can come down and I could squeeze a over hundred LEDs in there, not forty. Enough of the new drivers can fit on the internal network (I2C) that the microcontroller could control all those LEDs. But then, the Picaxe would need to feed out fifty times as much info when it’s only twice the speed of the old one. So I really should put an Arduino in there, which means new development environment, new language, all new code. And if I’m going to do that, then I might as well implement the better status display and better battery management too.

So it all leads naturally to the version 4.0, which will be a major step up, and not the minimal evolution that I wanted to build. Ah well, I can only console myself that it’s not the version 5, which may require metal-cored circuit boards for heat-sinking, active cooling, and possibly a welding visor for the user.

In the meantime, can anyone tell me why no-one sells a red-green-blue-amber LED that’s not phuge*? I just want a 20 milliAmp LED. RGB is nice, but RGBA just looks so much better.

* – Yes, there’s this monster 40 Watt RGBA in a 9×9 mm package. That one LED kicks out more light than the whole of the current Mitochondrion. It also requires major heatsinking to stop it melting and four constant current drivers per LED to feed it exactly the right kind of electricity. Thus lots of hassle. I’ll save that for version 5.

9 thoughts on “Mitochondrion blathering – v3.6 or v4.0?

  1. It’d be easier to do in software. I’m so helpful.

    Also, when you mentioned RGBA LEDs I laughed, since that acronym usually means red-green-blue-alpha in graphics programming.

    1. I’d be up for red-green-blue-alpha LEDs. Can’t seem to find a stockist though…

      Actually, RGB-White LEDs are just coming onto the market, giving colour mixing and better control of brightness. I’d like a better gamut, coz I like my cherry reds and deep violets and RGB just doesn’t cut it. I’d also like the ability to kick out lots of UV, coz shiny. Ah, let’s face it, I just want a universal electricity to light converter. Tunable free electron laser please?

  2. I’m stuck in the same place with the NTP server. I reworked the design to use a different (but similar family) Ethernet chip, since I (a) didn’t put enough decoupling caps on the last board for it, so I needed a redesign of the board anyway; (b) the new chip is SHINIER and moar awesome. Way more RAM (8->24kB), parallel access instead of SPI, does 100M, does autoneg, does hardware crypto, etc etc..

    But then my wandering eye caught the STM32F107x line, and for similar amounts of money I could have 72MHz CPU, 384kB flash/64kB of RAM, hardware USB support (including a bootloader in ROM that implements the USB DFU spec), Ethernet MAC built in, and it’s ARMv7 Cortex-M3 so the dev environment is fairly well known.


  3. Smartleds!

    (An RGB led, with an ATTiny on the back and a few diodes, caps and resistors. Manufactured on a board with maybe 100 of them and then snapped off. Sequence instructions sent over the power.

    Should be buildable at around USD5 each.

    I’ve done some modelling and all this is feasible. Next step is to prototype the hardware and see how it runs.


    1. Hmm… one problem is addressing them. The PCA9635s can have 126 drivers on an I2C bus, 4 RGBAs each, that’s 500. Addressing in hardware requires either 7 bits to be physically set, or some kind of address setting process in software that persists through on-board EEPROM or something. Then there’s the need to be able to enable/reset them all, and the writing of code to run on the ATTiny to handle data in, state management, and PWM (or BAM, or whatever is shiny).

      In the end, I just keep coming back to using someone else’s driver chips, coz they’ve done all that for me. Drivers are less than NZ$3 each, and require nothing more than an LED to run. That kind of price (and board space requirement) adds up when you’re wanting to do hundreds.

      1. What I’m thinking is that each device will have a 32-bit address / serial number set in production, which will be labelled on the back.

        Also, there will be an 8, 12 or 16 bit short address, which can be set by a broadcast message (e.g. plug one device only into a controller). This will go in EEPROM or Flash.

        1. Also, I has AVR assembler skillzors. The DDJ does its encoder processing and related stuff in assembler. (It’s way faster than even a modern C compiler).

  4. Why arduino rather than raw avr? Fast and small: if you’re up for a challenge you can get the same processor as an arduino in a qfn that’s like 4mm on a side.

    1. Easier development environment and getting to use other people’s code? Please correct me if I’m wrong, coz I know little about this.

Leave a Reply

Your e-mail address will not be published. Required fields are marked *