Would that be so that you could tell how bad a connection was??? The whole thing is beginning to sound a lot like "feature bloat", that syndrome where a useful, easy to use product gets changed into a piece of junk by adding so many marginally useful functions that it is tedious to use. When would anybody ever need a tester like that???
Besides, the very simple battery and bulb continuity checker already does that: A bit of resistance and the bulb is not as bright. Those testers have been available in hardware stores for at least 60years..
And long ago I met a farm kid who made a tester that used a six volt tractor battery and a horn. It was good for finding opens in electric fence wires, with the shock power off. HE had just added connections to the horn button on the old tractor. A weak beep indicated a rusty splice.

Yes- agreed!

It's so easy to succumb to feature creep disease and muck things up.
The whole point of this tester is it's simplicity and robustness, those are the two concepts that must be honored without compromise.

 

Yes- agreed!

It's so easy to succumb to feature creep disease an muck things up.
The whole point of this tester is it's simplicity and robustness, those are the two concepts that must be honored without compromise.

I did mention my suggestion was pure feature creep—yet there are two mitigating factors:

• The use of an MCU, I think, it actually a simplification when its ability to allow modifications without hardware redesign is considered.
  
  
• The fact that using the MCU is effectively a no-cost change means even if the core functionality of a go/no-go tester is the only thing that’s ever done with it, there is no loss while the tweaks to the behavior (even only core) is surely a gain.

The other thing to consider is what I have found to be one of the most effective strategies for system design: think big, scale down, build from the ground up.

The idea is to allow feature creep in the leading edge of the design phase to provide some idea of what is possible. That is, to imagine what something could be. This provides the ability to provide accommodations for future enhancements at the start, of course with a filter of cost-benefit.

The list of these notional future abilities form a sort of virtual road map that—most importantly—prevents making design choices that block future expansion when accommodating it would have been cheap or free if it had been considered at the outset.

Next is to constrain the actual design to what is practical. This is where the blue sky of the first step is reduced to what should be. This is where disciplined adherence to the core functionality either means throwing out good sounding ideas from the the (relatively) unconstrained imagining of the possible/could phase becomes the action item list for the practical/should embodiment of the idea.

The value of this “precognition” is in its ability to do two things:

• Identify practical features that can be trivially and cost-effectively included in the first iteration of a design even though they were not anticipated in the naïve first impulse of the invention, and;
  
  
• Identify possible directions of future evolution that can be trivially and cost-effectively accommodated or at least not blocked by the choices made initially.

So, the device may never do more than light up and beep on continuity—but adding an MCU and an RGB(W?) LED doesn’t materially increase complexity or cost while it does increase flexibility and adaptability.

Similarly, something like providing a place in the case design that would accommodate one of the ubiquitous cheap-as-dirt OLED displays would seem like a good idea. It would never have to be used, but it would also allow for adding a very nice enhancement in the future. It might even allow the case to be used for more than one kind of instrument.

In summary my process looks like:

• Think big—map out the world in which the design lives to get an idea of where it might go.
  
  
• Scale down—actually include only the core, the cheap, and certainly the free. Like building a house and framing out some basic walls without covering in the basement for the owner to possibly use in the future. Adding them at the start costs very little since everything needed is on the job site during construction, but if they were never used there would be little loss. On the other hand they will provide great savings and a good head start is a finished basement is desired in the future.
  
  
• Then, build it from the ground up so the foundation is sound.

And, that is why “feature creep” is part of my design process—but only in a way that always distinguishes could from should. In my academic career I always said what I admired most about serious engineers was that they could put their head in the clouds while keeping their feet on the ground. This is a manifestation of that.

 

I did mention my suggestion was pure feature creep—yet there are two mitigating factors:

• The use of an MCU, I think, it actually a simplification when its ability to allow modifications without hardware redesign is considered.
  
  
• The fact that using the MCU is effectively a no-cost change means even if the core functionality of a go/no-go tester is the only thing that’s ever done with it, there is no loss while the tweaks to the behavior (even only core) is surely a gain.

The other thing to consider is what I have found to be one of the most effective strategies for system design: think big, scale down, build from the ground up.

The idea is to allow feature creep in the leading edge of the design phase to provide some idea of what is possible. That is, to imagine what something could be. This provides the ability to provide accommodations for future enhancements at the start, of course with a filter of cost-benefit.

The list of these notional future abilities form a sort of virtual road map that—most importantly—prevents making design choices that block future expansion when accommodating it would have been cheap or free if it had been considered at the outset.

Next is to constrain the actual design to what is practical. This is where the blue sky of the first step is reduced to what should be. This is where disciplined adherence to the core functionality either means throwing out good sounding ideas from the the (relatively) unconstrained imagining of the possible/could phase becomes the action item list for the practical/should embodiment of the idea.

The value of this “precognition” is in its ability to do two things:

• Identify practical features that can be trivially and cost-effectively included in the first iteration of a design even though they were not anticipated in the naïve first impulse of the invention, and;
  
  
• Identify possible directions of future evolution that can be trivially and cost-effectively accommodated or at least not blocked by the choices made initially.

So, the device may never do more than light up and beep on continuity—but adding an MCU and an RGB(W?) LED doesn’t materially increase complexity or cost while it does increase flexibility and adaptability.

Similarly, something like providing a place in the case design that would accommodate one of the ubiquitous cheap-as-dirt OLED displays would seem like a good idea. It would never have to be used, but it would also allow for adding a very nice enhancement in the future. It might even allow the case to be used for more than one kind of instrument.

In summary my process looks like:

• Think big—map out the world in which the design lives to get an idea of where it might go.
  
  
• Scale down—actually include only the core, the cheap, and certainly the free. Like building a house and framing out some basic walls without covering in the basement for the owner to possibly use in the future. Adding them at the start costs very little since everything needed is on the job site during construction, but if they were never used there would be little loss. On the other hand they will provide great savings and a good head start is a finished basement is desired in the future.
  
  
• Then, build it from the ground up so the foundation is sound.

And, that is why “feature creep” is part of my design process—but only in a way that always distinguishes could from should. In my academic career I always said what I admired most about serious engineers was that they could put their head in the clouds while keeping their feet on the ground. This is a manifestation of that.

Wow - well put- thank you for this.
I'd like to believe I know this already, but the clarity of your words is very helpful.

 

Wow - well put- thank you for this.
I'd like to believe I know this already, but the clarity of your words is very helpful.

Thank you for the kind words—this particular idea has been central to my professional life and to my success in an atypical rôle as a generalized ”expert”. Most of my career(s) have relied on my systems-based thinking and this is a basic reduction of one view of that.

It sometimes takes a lot of fighting to get good designers and builders to consider the fully expanded world of a system because—quite correctly—they fear feature creep as they have seen it destroy projects. It is the opposite of the unskilled to whom feature creep seems like a positive move since it adds cool stuff.

But in practice, my methodology has the tendency to squelch feature creep since it’s all been considered and the things that were discarded had reasons to be left behind while the things included can satisfy the need to know that things were not missed.

Psychology is part of this, as in every human endeavor. One of my rules is “don’t try to stop behaviors outside of your control, instead entrain them by allowing them and in judo-like fashion directing their energy into good places“.

(I’ll stop blathering now, there is no end in sight…)

 

One interesting consideration is that the current used to sense continuity varies quite a lot with the application. For checking vehicle lighting system wires half an amp is good, while for testing microphone cables just a very few milliamps is more appropriate. So the current and open circuit voltage selections are very much application dependent.

 

Thanks for sharing. This is a great project. I will have a crack at this when I get back to base.