Computing stuff tied to the physical world

Input Plug, oh my

In Hardware, Software on Jun 19, 2010 at 00:01

More fallout from the bad ISP programmer. As reported on the forum, there is a problem with the Input Plug. Fortunately, it’s fixable in software.

The problem is that the ISP programming of the ATTiny45 chip on the Input Plug had the same problem as the recent, ehm, Murphy debácle: the fuses weren’t always set properly.

So the ATTiny starts up running at 1 MHz i.s.o. 8. And hence the timing is off when driving pulses to it to control the analog multiplexer.

The solution was to add a “fix” parameter to the InputPlug class in the Ports library. It defaults to 0 (no fix needed), but when set to non-zero, the timing is adjusted to slow down by a factor 8. That way, channel selection will take a bit longer – but at least it’ll work:

InputPlug myPlug (3, 1); // plug on port 3, slow down for wrong ATTiny fuse

This code has been added to the Ports library. There is a downside: the fix means that channel slection now takes roughly 900 µs, instead of the intended 100 µs.

Next question is: how to make sure this won’t happen again? – Answer: build a test jig, so all plugs can be tested fully before shipping. Trouble is, all Input Plugs ship as follows (this is an early hand-soldered unit):

Dsc 1732

Without headers!

My mistake was of course that I would wing it, and avoid the testing. Bzzzt. Time to build a little test contraption:

Dsc 1733

The other side is filled with 17 tiny 1 kΩ SMD resistors, creating a voltage divider with 16 different voltage levels. Soldering this was quite a challenge, btw:

Dsc 1737

And now I can take advantage of the fact that everything is gold-plated. So the following will make contact, just with the pins being pushed in and pressing lightly against the board:

Dsc 1735

I’ve been using the same trick for some time now, to test other plugs. Here’s how to connect the whole thing to one of the ports:

Dsc 1736

Below is a little readout test – a better test setup would be to simply perform the check and display a go / no go signal, but for now I’m just reporting the 16 values:

Screen Shot 2010 06 16 at 19.00.21

Sample output:

Screen Shot 2010 06 16 at 20.24.30

As you can see, the selection is now working reliably (once connected).

So that proves the bug and gives me a new tool to test Input Plugs before shipping. And of course I’ll re-flash the ATtiny45 chips on all remaining Input Plugs in stock at Jee Labs. For those already out there: you can either use the software fix, or send your Input Plug(s) back to me and I’ll fix the fuse settings to make selection snappier, as originally intended.

Problem solved. Phew.

Does it feel good to have to confess to another goof-up on my end? Of course not. But worse than that would be to keep quiet on this – and I won’t. I’m human, I make humiliating mistakes (LOTS!), I occasionally cut corners, but I do my best to learn and deal with it all. There is no doubt whatsoever in my mind that every person and company goes through these sorts of mishaps. It’s just usually not out in the open for everyone to see. Well, at Jee Labs, it doesn’t work that way – this is open source: software, hardware, goofs … e v e r y t h i n g !

  1. Hi, you might want to use ‘Pogo pins’. see http://www.sparkfun.com/commerce/tutorial_info.php?tutorials_id=138

    have fun building the testbed.

    RJ

    • Thx. I’ve seen the Pogo pins, but haven’t used them yet. Thanks also for the tutorial – great link!

  2. Hi,

    my 3 input plugs are working fine with your software patch. No need for me to send them back.

    I was playing with low power stuff and learning things from your rooms demo. My jeenode has 3 input plugs connected. When going power-down the power consumption drops to 2.8 mAmps (rf12 is sleeping also). When no input plugs are connected power usage drops to 30 microAmps.

    I’m wondering if the extra power usage comes mostly from the ATtiny45 chips or from the CD4067 chip. A powerdown or sleep mode for those ATtiny45 chips would be cool. No idea if this is possible. Ofcourse this would certainly mean a new custom soft in the ATtiny45.

    • Whoa – Input Plug power savings, I never thought of that! Yes, what you’re seeing is very likely from the ATtiny45 – normal mode draws 2.5 .. 3.0 mA @ 8 MHz. Yours is running at 1 MHz, then the current draw will be about 0.7 mA.

      I could easily add switching into idle mode, then the current goes down to 0.8 mA @ 8 MHz. Switching to full power down would reduce that to 2 µA, but then the protocol needs to be changed, a pulse to wake up the chip, then some idle time, then the channel selection bits.

      And yes… a change will require re-programming the ATtiny chip. I now use the Flash Board for this, but any ISP programmer will do, of course.

  3. JC,

    I was wondering about another approach. What if I would drive power to the input plugs via a digital output. I have one other port available for this. I think the digital out can take 2.8 mAmps no? Ofcourse I need to cut the 3.3V line to the input plugs.

    [10 minutes later…] I just tried this approach. It works:-) I’m now drawing 260 microAmps in sleep! And not to forget: when awake (and writing 1 to the digital output) my input plugs work and perform their task. Great

    • Great trick! Now you’ve got me wondering where “all” those 260 µA’s are going… :)

  4. Now you’ve got me wondering that too;-)

    [15 minutes later…] Cool now I’m back to my 30 to 20 microAmps! I got my analog inputs for the input plugs configured with internal pullups. That caused the extra power drain. So now before sleep I disable the pullups and after sleep, before measuring & processing, I re-enable the pullups. Much like the rf12 sleep on/off. Cool stuff these things.

Comments are closed.