Thursday, March 14, 2013

Oops

I messed up.

Oooh it hurts to say that but it's true. I should say it again.

I messed up.

Ah, still stings a bit.  Maybe it will get better if I explain just how I messed up.

My last post linked to my overview of design considerations in voltage regulator circuits.  In that writeup I staunchly defended the circuit I had designed to power my costume.  Here's the block diagram:


The general idea is that a 9V battery powers two separate voltage rails (5V and 3.3V) which are generated from linear voltage regulators.  The 5V rail powers the microcontroller and LEDs and the 3.3V rail powers the accelerometer.  Hopefully some of you will have raised your eyebrows at this point regarding my design and noticed a few things:


  1. Two voltage rails?  That seems like needless complexity. Why not drive the microcontroller from 3.3V?
  2. The microcontroller and accelerometer have different voltage sources.  Doesn't that make it difficult to interface them?
  3. You're using linear voltage regulators in a battery-powered application?  Don't they waste a lot of power?  Isn't that bad for battery life?  
  4. Why drive the LEDs from a regulator? Aren't they high current devices? Won't that force you to choose a more capable linear regulator and dissipate a lot more heat through the regulator?  
  5. What's that cool graph paper you use?  It looks all retro engineering-y!
I pretended I had good answers to these questions.  There are two rails because I need the microcontroller to run on 5V because then it can use a 20MHz clock rate.  Don't you want that extra performance in case you need it?  You know... for the complex maths and large amounts of data this costume will be processing? And no, it isn't a problem to interface the microcontroller and accelerometer because it's an analog accelerometer, so the 3.3V levels it produces can be easily read by the A/D on the microcontroller no problem!  Yes, I know I don't get to use the full range of the A/D (0-5V) to read the accelerometer because they're using different operating voltages.  I could always connect the A/D reference to 3.3V and get that extra precision back.  No, I didn't actually do that and no I can't directly manipulate any of the control lines on the accelerometer to change the measurement range or put it to sleep.  I'm sure I'll never need to put it to sleep - this is a battery-powered application! How important could that be?

Linear regulators? They're fine!  I've been using them forever! Why change now?  My calculations indicate they're 80% efficient in this application!  Why add all of those extra components like inductors and zener diodes for a mere 16% more efficiency?  Oh, oops.  I guess I did my math wrong and the linear regulator is only 55% efficient.  But hey, 40% more efficiency that... that can't be... worthwhile, right?  In a battery-powered application?

But the LEDs - those need to be power from 5V!  The green LEDs have a forward voltage of 3V - way too close to the voltage rail to allow me to properly bias them. I think.  I didn't really check.  Wait, power them directly from the battery and avoid the voltage regulators?  I cant... I can't do that... because... because the battery voltage will decay as the battery drains!  They LEDs will get less bright as that happens if I drive them directly from the battery!  Of course, I am already using PWM to dim them, so as the battery dies I could increase the duty cycle to compensate.  But I can't do that because I didn't monitor the battery voltage on the microcontroller via the A/D.  Because... because...

Because I'm an idiot.  There I said it.  It hurts less now. Supposedly, scientists say that sometimes your brain subconsciously makes a decision and then only afterwards you consciously justify it. (I ate that pie.  All of it. Because I had low blood sugar. Yeah I did kinda feel grouchy...) That's exactly what happened here. I wanted to start making circuits, soldering things and etching boards so I decided first and thought later.  I pulled up an old circuit from my past, used it without thinking and paid the price for it.  While testing the board I was always checking the 5V regulator to make sure it wasn't getting hot.  I was tearing through 9V batteries during testing too (20 minutes of run-time?  That will be an impressive Halloween costume!).  I saw all the signs of a poor design but was able to justify them until I actually sat down and started writing an article about the decisions real engineers are supposed to make when designing circuits like this.  The article just wasn't coming together - I couldn't make all of the pieces fit.  Nothing seemed to make sense.  Because it didn't - I hadn't followed my own advice.

At big companies with complex, involved processes for running projects they love to collect Lessons Learned.  What did we do wrong on this project?  What can we do better in the future?  What worked? What didn't?  While most processes and 'learning experiences' like this at big companies seem useless and painful, Lessons Learned is one tool that you should utilize everywhere you work.  We're all imperfect and we all have a lot to learn.  We all need to own up to our mistakes so we can correct them and become better engineers.

This means sharing - a perhaps uncomfortable amount of sharing.  Honestly I can't say I'm comfortable admitting my mistake like this.  I knew switching regulators existed, I knew microcontrollers could run from 3.3V.  But I wasn't basing my design decisions on engineering - I was pretty much basing them on nostalgia (Ah, the LM7805!  Reminds me of my childhood!) and inertia.  This is a trap that all of us will run in to when we work on projects alone.  With no one to watch our back and call us out when we make terrible decisions we will create less awesome stuff.  Some of it will be downright embarrassing.  All of it we will want to hide.

If we want to be better engineers and make more awesome stuff we're going to have to venture way out of our comfort zone and share our mistakes.  Trust me, you haven't seen the last of mine.



No comments: