Avoiding Excessive Engineering – Top Ten Tips for Doing More with Less

Gears of ProgressAvoiding Excessive Engineering – Top Ten Tips for Doing More with Less

I have often said, “Just because you can, doesn’t mean you should” and in the realm of engineering it is very applicable.  I often examine systems that have thrown everything but the metaphorical “kitchen sink” into the design “just in case”.  Interestingly enough, those same designs lacked proper engineering of the power supply or enough ESD protection on exposed connectors.  So here’s my top 10 list of tips for doing more with less… in reverse count-down, so no reading ahead!

Tip #10 – Think “Energy Efficiency”. This is one of my favorite topics in engineering systems design (they don’t call me the “Energy Zarr” without reason).  In fact, I often rant about waste in solving a problem with brute force.  Now… with that said, sometimes a hammer is more effective when dealing with a nail, but in general, what goes in, must come out… and most of what comes out is heat.  Take the quintessential LCD display like the 60” version sitting in your living room.  That beauty has white LEDs for a back-light so it must be “green” right? Well, did you know that up to 80% of the light emitted by those LEDs is absorbed by the color filters on the LCD glass? It might be “thin” but it is definitely not efficient with the back-light energy.  Technologies such as OLED or Sequential Frame LCD (SFLCD) do not use filters.  OLEDs are self emitting and draw zero power when off.  SFLCD technology still uses a back-light, but they are RGB LEDs.  Each color frame (red, green, blue) is switched at such a high speed that the eye integrates the image into the proper colors.  Each pixel is now larger and brighter with less power.  How much less?  Try 80 watts for an SFLCD TV versus 350 watts for the traditional LCD. Energy currently is a limited resource, so innovate where you can to save it.

Tip #9 – Revisit your System.  I love it when engineers use a microscope when they should take a few steps back to see the big picture.  It is so common and as an engineer I understand how that can happen.  We often focus on a problem such as “how do I get the noise out of my analog input? The 20th order filter I designed cannot be realized…” instead of taking a step back and saying, “due to the high noise environment surrounding this system, we should use full differential signaling to improve the SNR”.  Take the time up front to define these things and you won’t need 10 op-amps to fix the problem.

Tip #8 – Communicate. In systems with many pieces it is extremely important engineers communicate with each other.  It is very easy to get a specification and then go off and design to that “exact” specification… it’s what we do.  Give me a specification of what goes in and what needs to come out and I’ll design you the circuit.  The problem with this approach is what I call the “Isolated Brain” syndrome.  It can lead to system creep and add additional “weight” to the design.  Ask yourself this, “If I were the only engineer designing the entire system, would I still build this block the same way?” If you have control of the other blocks, you may not… so talk to your peers and let them know your intent… it just might simplify the entire system!

Tip #7 – Don’t Reinvent. I once had a funny discussion with a patent attorney about the redundancy in engineering.  He told me a story about a company that designed the same circuit (and patented them) over a dozen times.  Now that may sound like the company was on the leading edge and producing amazing intellectual property, but in effect, they designed the same  function over and over.  If someone there would have cataloged what had already been done, then maybe they would have spent more time innovating then replicating… just saying.

Tip #6 – Analog is your friend.  I remember talking with the late Bob Pease about the state of the art in digital techniques for solving complex problems.  He politely let me babble for a few minutes and then laughed, “Yep, I solved that same problem 10 years ago with two op-amps”.  I wanted to crawl under something, but his office was completely full of every magazine he had ever received… but that’s another story.  He was correct – sometimes a straight forward analog solution can not only be the most elegant, but also the most efficient. Sometimes you need the power of a DSP processor when systems are non-linear or the signal processing is not realizable in the analog domain. However sometimes simple analog circuitry can solve the problem.  Don’t forget your roots.

Tip #5 – Software is Your Friend Too. Having knowledge of both digital and analog design is absolutely a bonus when solving complex engineering problems. The software engineers across the hall can sometimes help with some of the heavy lifting to keep the overall system bloat under control.  I have found talking with the software designers about the problem can often lead to a much simpler hardware implementation that uses less space and power… as well as less cost.  If you already have a microcontroller in the system, maybe utilizing this capability can solve some really tough problems.  For instance, I once was working on a simple RF receiver circuit that had issues with range. I was struggling with limited SNR due to spurious noise in the demodulator – mainly caused by jammers in the spectrum.  I had limited additional space for a filter, but I did have my little microprocessor.  The solution was a very simple uniformly weighted discrete-time FIR filter.  It sounds complicated, but in reality, when all the coefficients are all 1’s, then the multipliers go away… it was implemented with a simple bit summing function (if you want to know more, drop me an email: energyzarr@list.ti.com). My SNR went up and the range met the requirements… only a software change.

Tip #4 – Design with the User in Mind. This topic, probably more than the issues discussed in tip #10, is my greatest hot button (the one that is illuminated red and marked “never push this button – ever”). I see bad user interface designs everywhere I look – my favorite is the child-proof cap on arthritis medication… I’m sure grandma loves using the meat tenderizer hammer to open her meds.  Software user interfaces are some of the worst offenders of over engineering and can easily be overdone on so many levels.  I wrote a blog post years ago on this topic and I think I’ll write another one in the near future since some designers still didn’t get the memo. I must say that some manufacturers such as Apple and BMW as well as others study how people use their products… and it shows.  Others (who will remain nameless – you know who you are) think that by giving the user hundreds of options and a multitude of controls is helpful… maybe, but most often not.  System designers are most often in control of this specification.  Think carefully about attributes such as color – avoid using low contrasts such as yellow on gray – color blind people cannot see this.  Use color only when necessary and place controls in logical groups.  Think “Less is More” here.  Can a single control be combined? Can some be hidden in an “advanced” tab or disabled in a minimized view.  Ask yourself, if my mom had to use this, could she figure it out (and if you’re mom is a super computer designer, disregard that last question).

Tip #3 – Get the Latest Information. The Internet is an amazing machine and it can provide you with the latest data sheets and design notes in literally seconds.  There is really no excuse anymore not to have the latest information at hand and also to see what is new and applicable to your problem.  There may be a new device available that is more “functionally efficient” which can lead to a simpler design, less board space and better energy efficiency. So before you start drawing schematics, check out TI’s website for the latest info!

Tip #2 – Use Tools.  It’s amazing how many tools are available to aid engineers in designing more efficiently and many of them are free.  Case in point, Ti’s Webench tool can not only solve complex point-of-load (POL) power architectures, but can also help design filters, LED drivers and other circuits.  There are other down-loadable tools as well such as TI’s Clock Design Tool that are extremely useful when designing clock distribution architectures. These tools can assist in minimizing clock distribution networks and provide insight into the best way to distribute high speed clock signals throughout a system.

**edit: As Tom Hoffman so brilliantly pointed out, TI offers two other tools that can help you with your design: TINA-TI, a circuit design and simulation tool, and FilterPro which allows designers to create and edit active filter designs easily.

Tip #1 – Learn. I have an insatiable appetite for learning new things especially when it comes to technology and engineering. One thing I have found in my 30+ years in this industry is the need for a mentor.  I have had several in my career and they have taught me many techniques for more efficient designs in both hardware and software.  I also encourage readers to pick a design topic unfamiliar to them and learn about it.  This additional knowledge outside of your expertise will be helpful when in the midst of a system architecture review. TI has this great on-line school to provide training on many topics.  

BONUS TIP! – Pass it On. The most important tip I can give you is to share your knowledge.  This is a way of improving your personal efficiency by helping less experienced engineers develop designs that are more powerful while requiring less energy – and less of your time reviewing and modifying their designs.  We all carry a great deal of information from our experiences, so I fundamentally feel this as being one of the most important functions senior engineers can provide.

I hope you have found these “Top 10 Tips” for avoiding excessive engineering useful or inspiring… or if nothing else humorous.  Look for more of my Top 10 Tips in future blogs! Till next time…

Rick Zarr  

Contact me: energyzarr@list.ti.com 

Index of all Energy Zarr posts.

 

  • Thank you for your post Rick.  Every time when I'll  design a new product I will check your tips and a special the bonus one :)  And yes I deep believe will inspire many engineers. Thanks again :)

  • As a keeper of 10 Author's Certificate-s (kind of patent) in former Czechoslovakia; I found as most pictoresque point #7 in above Tips.

    Maybe the mentioned company wanted to protect their circuit for more than 17 years, which is the term of validity of US patents.

    If the word "dozen" is true, they could theoretically prolong protection of their circuit to 12x(17 - 3) = 168 years :), (3 years: an average  patent pending) by periodical patenting the same circuit every 14 years, with eventual changes of the  name of circuit, names of authors and patent classes.

    Another possibility (extreme) could be to find 12 different names for the same circuit; to permutate the relevant patent classes and to modify the schematic diagrams by using left-to-right ordering of devices, inverse ordering, then bottom-up, etc, etc.

    In this case the company could proudly announce keeping of 12 different patents having a life-time of 17 years.

    (My patents concern 10 different circuits.:))

  • Regarding Marian's comment... that does make sense if the intention was to extend the period of a particular patent.  This is a very interesting concept.  In Tip #7, I was referring to an accidental situation where all the parties invented almost the exact same thing, but started from scratch each time.  They did not leveage the knowledge of their peers.  Even if the intent was to extend the patent, it would be nice to know what you had already done... in this particular case, no attempt was made to see if a solution already existed.

  • Hi Richard, I'm not a native speaker and just a senior student, so I don't get these words:

    I often examine systems that have thrown everything but the metaphorical “kitchen sink” into the design “just in case”.

    _Does it mean that there're designs in which inappropriate components are used?

    _The word "ESD" stands for engineering system design,doesn't it?

    Could you please enlighten me?:| I really want to translate this article into my mother tongue, so that I could somehow help young engineers to know what is good for them.

    Regards.

  • Regarding Long's comments above, the reference to "Kitchen Sink" was a jab at designs that were ill conceived.  That is, designers didn’t really know what problem they were solving, so they insured the design would work for the application by including additional circuitry “just in case”. Additionally, ESD in this context means Electrostatic Discharge.

  • Thanks a lot, Mr. EnergyZarr, finally I get the point. Really appreciate your help!!!

    Btw, I think you should check your TI mail regularly, since I first mailed you but received no answer :( I guess there wouldl be someone who also mail you to ask things they don't understand.

    Regards.

  • On Tip #2 - Don't forget TINA-TI and FilterPro!  These are great (and Free!) tools found under the 'Tools Tab' from www.ti.com.

  • Regarding Long's Comment on email: Yes, you are correct.  There was a problem where external email was not being forwarded to me... it is now fixed.  Thanks for your comments!

  • Regarding Tom Hendrick's comment above... nice reminder.  We will add that to the post for future reference.

  • I just discovered this excellent post.

    #1 was always driving me for my whole life. Literally. And #4 was the next one I adopted, in my early teenage days, when writing my first software intended for not only internal usage. Unfortunately, many developlents are done with the author focusing on his own intended usage of the product, inlcuding his way to see the world, the problem and how he would like to handle it. And the product is barely usable without the internal knowledge the creator has - but the external user hasn't.  Especially for a large part of the linux world, this is still true (cryptic commandline options, condensed documentation - if at all - etc.)

    Most of the others came to me during the following decades. And I think I'm  theliving proof for the bonus tip :)

    However, Tip #4 is a partly dangerous. Yes, usage of tools is a good thing. But be sure to use the right tool. Using an iPhone with a hammer app for driving a nail surely won't give you satisfctory results. And it is as important to know the tool. Just using it because it is there is almost as dangerous as it might be useful. I see many threads in the MSP forum where people using the debugger and discover strange things - simply because they don't know how the debugger works and what side-effects debugging has.Totally valid software seems to be broken just becasue a debugger is used to check whether it is working correctly. Or single-stepping through code makes it work but wihtout debugger it won't - simply because the single-stepopign process caused so much delay that the code wasn't outrunning the external hardware.

    This smoothly fits to the story of the test pin that was making an ASCI sucking the backup battery dry in days insted of years, once it left the test socket.