Tag Archives: hardware

Geiger Counter Workshops @ Toorcamp

News flash: Hardhack is running the Hardware Hacking Area at Toorcamp this year, which takes place on the Washington coast in just under three weeks!  (The dates are August 8-12, 2012, and tickets are still available.)

I’ll be running two Geiger Counter Workshops.  Come build a Geiger Counter kit!

I’ll have the Geiger Counter ambient music synth I built for Maker Faire set up, and we can all scout for fallout from Fukushima arriving at the campsite!  Whoohoo!

Debugging (David Agans)

I recently saw David Agans’ book Debugging mentioned in one of the many trade journals I receive (I can’t remember which one).  After seeing how much praise it received on amazon.com, I decided to pick up a copy.

Debugging really spoke to me because a large portion of my career has been devoted to finding and fixing hardware bugs.  I finished it in just two or three evenings (it’s a quick, fun and engaging read).  The examples are particularly interesting and relevant to me because many involve issues with embedded systems.  Admittedly, perhaps most fascinating is the one about a living room lamp that turned on anytime the author vacuumed the room.

I highly recommend this book to anyone who regularly  troubleshoots issues with any kind of system, software or hardware, mechanical or electrical.  This includes engineers of all discplines, circuit designers, computer programmers, helpdesk operators, web developers, auto mechanics, etc.

David’s nine rules of debugging are (with my notes):

  1. Understand the system – Knowing how your circuit, code, or widget is supposed to work will help you fix it.  Read the manual!
  2. Make it fail – Knowing how to reproduce the failure is critical to being able to fix it.  Also, stimulate the failure, don’t simulate it.
  3. Quit thinking and look – Don’t jump to conclusions and just fix what you think might be the problem.  This wastes time when you inevitably guess wrong.  Keep an open mind as to what the failure mechanisms could be.
  4. Divide and conquer -Eliminate what is definitely not part of the problem and focus on what’s left.
  5. Change one thing at a time – If you change ten things at once, how will you know which one actually solved the problem?
  6. Keep an audit trail – Being able to reproduce the fix is crucial.  Even if you don’t fix the problem, you might discover a pattern or something you overlooked by looking at your notes.
  7. Check the plug – When all else fails, check the obvious stuff that you probably should have looked at first.
  8. Get a fresh view – Someone else may have more experience with the problem than you do or might see the one thing you’re missing.
  9. If you didn’t fix it, it ain’t fixed. –  Don’t stop when the problem just disappears.  It will surely come back later at the most inconvenient time possible.  We’ve all been bitten by this one before.  Never again!

There’s even a free poster available on the book’s website to help you remember these rules during your next debugging crisis.

mightyOhm.com T-Shirts!

Today I decided to take Zazzle for a spin and created a fun t-shirt for the site.

I used GIMP to create the design and remain impressed with this open source alternative to Photoshop.

Like the design?  Great news! Thanks to Zazzle’s marketplace, you can get one for yourself!

If you order before November 4th, Zazzle will give you $3 off the price of the shirt.  Enter promotional code 3OFFZAZZLETS during checkout.

Update: There is one for girls, too.

Visit my Zazzle Gallery.

Are you as handy with Java as your are with a soldering iron? Do you code by day and flash micros at night? Does writing cycle accurate code turn you on? If you answered any one of these questions with a resounding yes, this stylish shirt is just for you.