Tag: How To

DMM – Testing for open fuse. (No current mode)

Posted by on November 16, 2011

I see this one a lot,

People wondering why their current modes “aren’t working at all” on their multimeters. Well, chances are the fuse has been blown. Why? — Perhaps you tried to perform a parallel measurement in current mode, which would’ve caused a short.

However the point of this entry is not to point fingers, instead I’d like to remind you of the industry standard test for open fuses on multi-meters:

  1. Put your DMM in Continuity mode, if it doesn’t have one just use the lowest Ohm range (In case it’s an auto-ranging DMM, just select Ohms)
  2. Connect your red probe to the suspect banana jack. In this case the uA/mA input
  3. If you get a low ohms reading, the fuse is fine. If you get an open circuit, it’s blown
  4. Repeat step 2 for the “A” (Amps)  input and follow up with step 3.


Why it works

What you are actually measuring is the current shunt, through the fuse. If the fuse is open, it stands to reason you wouldn’t be able to measure anything!


That’s it, I can’t believe how many people opt to open up their DMM just to check for a bad fuse instead of doing this; blows my mind…




MSP430 Launchpad: Random Software Delays

Posted by on December 13, 2010

The goal: to “randomly” flash the on-board LEDs at P1.0 and P1.6

The weapons: CCS, Launchpad, Cookies (you may choose your favourite ones)

The reason: To familiarize yourself with the coding environment, or just for the heck of it.

The library:

That’s our random library, it’s grand.h

The “g” prefix is one I often use privately, it’s simply the first letter of my name. However because there may be other routines in the future with a similar naming convention, having “g” prefixed is not a bad idea; without having to fall into namespace gibberish.

The PRNG is an old standard. No need to discuss it.

You may recognize those macros, yes! They’re from Quake3! — Although we aren’t using them I left them there for future reference on how to obtain usable value ranges from the PRNG. There’s a lot to be said about floating point values and whatnot, But I’m going to restrain myself in this case.

Now to the main code:

No external hardware is required, just make sure both P1.0 and P1.6 jumpers are set.

As you can see we’re simply toggling the LEDs with a random delay, the delay_ms(); function was taken from here.

Like I said there are quite a few topics to explain, however I decided to keep this one as simple as possible (Alright, I’m in a rush!)

So… Compile, run and enjoy!

Once I get the time I’ll put together some utilitarian code libraries and lengthier explanations, promise.

For those interested, you may download the entire project directory from here: Random Software Delays.