Successful Endeavours - Electronics Designs That Work!

Electronics Design for Green Manufacture

This is not as straight forward a topic as it might at first seem to be.  And this is because there isn’t yet a unified agreement on exactly what Green Manufacture means.  And like most Design Issues, you cannot do Electronics Design without clear requirements.  So what are the requirements?

Here are some Green Manufacture requirements or targets:

  • reduce product Power Consumption
  • reduce manufacturing Power Consumption
  • add Renewable Energy options to the product
  • add Renewable Energy options to the manufacture process
  • reduce pollution or waste in the manufacture process
  • reduce energy involved in upstream or downstream processes
  • reduce pollution or waste in the upstream or downstream processes
  • increase product life
  • increase product utility
  • increase manufacturing plant utilisation

I guess you can see the dilemma.  It can be hard to know which target to aim for.  Am I doing the Electronics Design with the product, process, life cycle or ecosystem issues as the primary concern?  And how do I balance these concerns?

Here is one excellent article that also discusses this topic Green Supply Line.

Electronics Design can be Green

One major thing we can do is reduce the product Power Consumption.  We are coming out of a phase where a mains plug pack power supply was considered an ideal way to avoid compliance costs when designing new products.  This has led to a proliferation of low efficiency always on powered devices.  A recent look under my desk reveals the problem we have as Product Developers where every device I use is either USB Powered or mains plug pack powered.

So a first step is to review this whole approach to supplying power to devices.  We have made steady gains in the area of Power Consumption reduction for the devices themselves.  Now it is time to do a similar thing on the Power Supply side.

Energy Harvesting

This is a new area that hasn’t yet reached mainstream development.  The idea is that you can utilise the ambient environment to get power for free.  Or at least you aren’t directly requiring extra Power Generation.  Hence the name, Energy Harvesting.

How you do it and the Electronics Design and Electronics Technology required to make it work are still being defined but there has been some interesting new progress.  Some key players are:

Linear Technology – new Energy Harvesting Integrated Circuit

Enocean – are front runners in bringing Self Powered Wireless devices to the market

What is Energy Harvesting?

This is where we use Electronics Design and Electronics Devices to generate power from the Ambient Environment.  The result is a product that doesn’t need to be plugged in and recharges itself automatically. Some of the Energy Sources that are used are:

  • Light
  • Thermal differentials
  • Vibration
  • Chemistry
  • Pressure differentials
  • Air Flow

One example of a product that does this is the Enocean Light Switch where you can just put it where you want it.  And if you change your mind, just move it. Now wiring required.

Right now the technology is still more expensive and so take up is slow.  But as it develops and the price comes down that will change.

We are in for some interesting times.

Ray Keefe has been developing high quality and market leading electronics products in Australia for nearly 30 years. For more information go to his LinkedIn profile. This post is Copyright  Successful Endeavours Pty Ltd.

Electronics Design To Save Energy

We have looked at how Low Power Electronics is a green strategy because it reduces the amount of power that has to be generated.  And then we looked at a range of options for Reducing Electronics Power Consumption.

Now we are into specifics.  The last post looked at Sleep Modes For Microcontrollers and how extending the Sleep Period and reducing the Sleep Current could dramatically Reduce Electronics Power Consumption.

Saving Electronics Power When Awake

The next logical step is to ensure that Power Consumption when awake is also reduced as much as possible.  This can be a little tricky to get right as it can sometimes eliminate all the benefits you built up with you sleep strategy.  The reasons for this are:

  • you can use Analogue Electronics to reduce software power requirements but it has to be turned off during Sleep Mode
  • if you do turn the power off to Analogue Electronics then there is a Settling Time after it is powered up
  • using Smart Electronics Chips can increase overall Quiescent Current
  • unless the Startup Time and Shutdown Time are quick, these can dominate the Power Consumption

Now there are some Software Architecture issues that affect these, especially the last one, but we will look at that in another post.  For the last part of this post we will address the Electronics Design issues that have been raised here.

Electronics Design – To Save Power

Electronics Design can address these Power Consumption issues.  Here is an example of a Power Consumption curve where an RC Time Constant must be taken into account to minimise average Power Consumption.

RC Time Constant affect Power Consumption

RC Time Constant affect Power Consumption

Here is a list of general strategies to select from to reduce Power Consumption:

  • using the lowest feasible Clock Rate so Clocked Devices use less power
  • using shorter Settling Times particularly by controlling RC Time Constants
  • select semiconductors for lowest overall Quiescent Current taking awake and sleep operation into account
  • ensure streamlined Startup and Shutdown operation

The overall Quiescent Current issues often gives the most difficulty.  This can be addressed through Design Simulation either by SPICE, Software Modelling or a spreadsheet.  For simpler systems the spreadsheet is often the easiest solution to implement.  For very Software Intensive Systems the Software Modelling approach is the most reliable method.  This will allow you to construct scenarios and be able to predict the Power Consumption implications for each of them.

For our Electronics Design and System Test methodology we often create a full system Software Model and so it is easy to use this same Software Model to accumulate the power consumption as it runs.  This can also be automated and so simulate months of operation very quickly.

Next we will look at the role of Embedded Software in ensuring Power Consumption remains as low as possible.

Ray Keefe has been developing high quality and market leading electronics products in Australia for nearly 30 years.  For more information go to his LinkedIn profile. This post is Copyright © Successful Endeavours Pty Ltd.

How Does Sleep Save Energy?

For this post, we will look specifically at Embedded Software techniques to save power and energy.  This is a well known Power Saving Strategy which doesn’t always get the recognition it deserves.  It is also something you have to design into the Power Management Plan from the beggining.

For this example, we will use the MSP430 from TI which has some of the best Power Saving and Power Consumption figures in the industry.  We have used them to create devices that run from a pair of AAA batteries for 2 years and which have time based control algorithms so that they can’tbe used in a purely event driven mode.  Here is how it works:

Low Power Sleep Mode

Low Power Sleep Mode

This shows the power consumption versus time.  In Low Power Sleep Mode the consumption is close to zero.  Almost no power consumed.  Then depending on what is happening it wakes up to varying degrees.

Get the best Electronic Sleep

So this is how you take advantage of this:

  • make the time between wake ups as long as possible
  • make the time awake as short as possible
  • only turn on the peripherals needs for a particular wake period

Now if you system only has to wake once every minute then you can get low power operation from a lot of different processors.  If it wakes many times a second then you need a processor that gives you lots of ways to reduce power during wake, reduce the time awake, and increase the interval between wakes.

MSP430 Sleep

So back to the MSP430. It has Power Conservation features that allow it to do all three better than most.  Here is the list:

  • Digitally Controlled Oscillator DCO allows it to wake and run quickly
  • Can run a Timer from a 32KHz crystal making interval timing very low power
  • Can use the DCO to set the run speed and so shorten the wake time
  • Lot’s of Power Down Modes so you can always find one that suits your application
  • Peripherals can be Shut Down when not in use
  • Can run down to 1.8V – more on that later but it can also help here

Low Power System Architecture

To take advantage of all this, you have to develop the System Architecture so that  takes advantage of this.  An example from a very long life application we did runs like this:

  • 32Hz Oscillator runs a timer that generates a 1 second wake
  • User input keys set up to wake on change of state from high to low
  • Use DCO at 1MHz to quickly wake, execute & sleep again
  • Use State Machines to allow modules to execute predictably with eratic timing
  • Have early exit tests to prevent unnecessary Code Execution

The result is an application that runs a process with User Interaction, LED Indicators, and a 2 week cycle where the average Power Consumption is 20uA at 2.7V or 54uW.  Of this, less than half is the processor executing the software and the single biggest energy use is the intermittently flashed LED Indicators.

To learn more, check out this more comprehensive article on “Low power MCU selection criteria and sleep mode implementation” from embedded.com which provides more examples.

Ray Keefe has been developing high quality and market leading electronics products in Australia for nearly 30 years.  For more information go to his LinkedIn profile. This post is Copyright © Successful Endeavours Pty Ltd.

What is so good about Low Power Electronics?

If you read my last post, you would have noticed that this has the potential to reduce overall Power Requirements.  Up until now,  only Battery Operated Devices have really cared about Power Consumption.  If you could plug it into a wall outlet then all was OK unless you were consuming more power than a standard circuit allowed.

Today, things are different.  Climate Change is a global concern and reducing the Carbon Footprint for a product is important, regardless of what sort of power it consumes.

If we can reduce the Power Consumption of an appliance by 50%, then provided it’s Electronics Manufacture does not add that back again, we have a net Carbon Footprint gain.  In fact, if we can do this across all products then we will meet our Global Carbon Reduction target of 50% by 2050 with this strategy alone.

How to reduce Electronics Power Consumption

This is not a new topic, and much of what I present here represents the combined experience of the Electronics and Embedded Software industry.  Here is the short list:

  • reduce the Supply Voltage for Microcontrollers, Microprocessors and CMOS Circuits in general
  • use Sleep Modes and keep the Wake Periods as short as possible
  • replace High Power Consumption Devices with Low Power Consumption Devices
  • replace high utilisation Digital Filters with Analogue Electronics equivalents
  • replace Polled Operating Modes with Event Driven Operating Modes
  • use Low Power Smart Peripherals that Wake the rest of the System only when required
  • reduce the Time To Wake and the Time To Sleep
  • optimise the Software Execution Flow
  • use Energy Harvesting
  • Remove power from sections of Electronics Circuitry when not in use

There is overlap and interdependency between these but that is a good starting point.

Next I will start look at specific examples.

Ray Keefe has been developing high quality and market leading electronics products in Australia for nearly 30 years.  For more information go to his LinkedIn profile. This post is Copyright © Successful Endeavours Pty Ltd.

 

In this post we will look at the Product Development Process and how to get improved outcomes.  But first here is a fun graphic made from our logo.

Successful Endeavours - Making Electronics and Embedded Software Work

Successful Endeavours – Making Electronics and Embedded Software Work

Product Development Process

The Product Development Process is intended to reliably deliver new products for manufacture or distribution.  This is a critical component of a Product Strategy where you are creating the product rather than sourcing it from a supplier.   So you would think that it should be a highly optimised, well oiled machine that reliably delivers successful products. Alas that is not always the case. With 30 years of experience in Developing Products for a wide range of industries I have seen my share of projects handled well and not so well. Here are some general principles I have gleaned from my experience in Successful Product Development Projects:

  • Risks must be identified and managed.  Track them and eliminate them as soon as possible.
  • Anything clever or tricky needs to be checked by someone else.
  • Everything else also gets checked.  Design reviews, code walk-throughs and prototypes save time, money and heart ache later on.
  • Hold the timeline.  Foster an attitude that slippage is not acceptable.
  • Test and check everything.
  • It’s not finished until no-one has to do another thing to it.

So six core principles.  They are inter related of cousre.  Let’s look at how these work out in practice.

Successful Product Development Principles

Lets look at how each of these priciples can be used to improve the likelihood of a Successful Product Development Project.

Risk ManagementRiskManagement

Risk Management is an old idea.  Not surprising since risks have always existed. Did you know that during the Manhattan Project it was determined that there was a chance that a fission bomb could ignite the whole atmosphere ?  Having got contradictory reports the argument was eventually settled by a report showing that although it was possible, it was unlikely.  How comfortable would you feel running that risk ? Fortunately the average Development Project is dealing with much more mundane risks such as achieving Technical Requirements such as:

  • Power Consumption
  • Unit Manufacturing Cost
  • Performance Criteria

But the approach is still the same:

  • Identify the risk
  • Work out how to ameliorate the risk – reduce it – or eliminate it
  • Do tests to confirm the risk has been dealt with
  • Iterate until it is no longer a risk

Review the clever bits

Test Everything - Clever Design Needs Test

Test Everything – Clever Design Needs Test

Where possible, any particularly clever or tricky areas of the project need to be reviewed by someone not involved in the everyday work of the project.  This is primarily to ensure that assumptions are challenged.  If you can’t get an outsider to do the review, use a process like Six Thinking Hats by Edward De Bono which can allow team members to step outside their emotional and assumptive predispositions.  Unchallenged assumptions are unmanaged risks.

Review the rest of the project

Test Everything

Review Everything

The astute amongst would have noticed that I am proposing everything gets reviewed.  But the tricky bits get extra review.  This section is for the regular bits. Reviews are an essential tool to find mistakes early and eliminate problems down the track.  You don’t have to solve a problem you don’t have.   Or as Jack Ganssle famously quipped “Skip Bugging To Speed Delivery“. The whole article refers to using Code Review and Design Review to find problems early and fix them so they don’t become much bigger problems later on. Imagine a scenario where a Software Bug causes an electric motor to try and spin backward every now and again and then corrected itself almost immediately.  You would get a momentary shudder or jerk followed by correct motion and it would only happen every now and again.  How would you determine that this was a software fault and where the fault lay?  It could be symptomatic of any number of issues including Mechanical Design and Electrical Design. How about this similar real world case.  I won’t mention the company, but their elevators had an Integer Overflow problem in the motor controller that caused the elevator to go in the wrong direction, about once a month, for half a floor.  Very disconcerting to the passengers if they pressed up, and promptly dropped half a floor before then going up.  Fortunately they found it and fixed it before it happened to someone at the top or bottom floor. All the Software Industry Metrics show for that for Software Development; Design Review, Code Review, Unit Tests and System Simulation save money and time.  And yet in many projects they don’t happen enough or are done after the event as a Quality Assurance box ticking activity where they add mostly cost and little in the way of value.  Lean Coding argues that you can reduce your Software Development Budget in particular by doing Code Inspections during the project as part of the Risk Management and Quality Management process. By reducing the bugging, you can reduce the debugging.

Stick to the Timeline

Project Development Timeline

Project Development Timeline

An attitude that the schedule slipping is normal can be very costly.  Some examples of how to avoid this are:

  • Develop and Simulate the Software before the Hardware is ready
  • Prototype early and thoroughly
  • buy in IP where it makes financial sense – this can also reduce risk
  • get expert assistance with areas outside your competence
  • review regularly and honestly

As someone who has done a lot of team leading and project management, I have learned to ask about progress in more than one way.  I find the following to be very common: Manager: “This module is estimated as 10 days of work to complete.  How complete is it”? Developer: “About 80%”. Manager: “How many more days of work are required to fully finish everything”? Developer: “To fully finish everything, I would think 6 more days would cover it all”. The discrepancy is easy to spot.  People estimate high on progress because they want to please.  They also like to finish well so they tend to estimate conservatively on required effort.  In practice the real answer lies somewhere between the 2 extremes.  If the task had already consumed 6 days of effort then it is likely to run late. If you have ever built a house you might have experienced the knock on effect it has when one trades person doesn’t turn up and everyone else misses their scheduled action time because they are now waiting on a predecessor task, the trades person who has to come back again, before they can start their task.  The same thing happens on projects. So fight hard to hold to the schedule.  It is better to over resource a task (according to the plan) and get it done than to let everything and everyone slip which usually costs a lot more. Additionally, it is quite common that the later you are in the market, the lower the overall profit.  So it is worth holding the schedule for this reason as well.

Test and Check Everything

 
Test Everything

Test Everything

This is another Risk Management related principle. Don’t assume it will be OK.  Even if you have done it 100 times before, test it again this time.   Make sure it really is OK.  This ensures it really is 100% complete. This also implies that you are going to design things so they can be tested.  Another principle.  Design For Testability or somestimes called Design For Test. Do it.  It will save you time, effort, money and sleep. Test Driven Development is another example of a Modern Development Methodology where you set up the test first then develop the product so it passes the test.  If the Product Requirements change, you change the tests first, show that the old Product Design fails the test, then update the Product Design until it now passes the test.

It is not finished until no-one has to do anything else to it

Many tasks are called complete but they aren’t.  The documents might be checked into the Revision Control System, also known as a Version Control System or Version Management System,  but it isn’t complete until it is 100% tested, 100% integrated, 100% reviewed and 100% signed off and no-one has to do another thing. This also means that when tasks are identified that weren’t thought of in the original Project Plan, you then add them and don’t try and fiddle them into existing tasks.  This is different to working out the fine detail of a task and realising it is under resourced or over resourced on the Project Plan. You also want the extra tasks visible on the Project Management Plan so when you do the next project you have evidence that they were required last time and can make allowances for them.

Trip Assurance for Developers

Satisfaction Guaranteed

Satisfaction Guaranteed

In marketing, the term Trip Assurance refers to the client having a clear expectation of this transaction or experience being a good one, just like every other one has been.  I think we can begin to develop some of the same as developers whereby projects can be routinely good experiences and likely to be so each time.

 This post is also available as an eZine article with Expert Author classification.

Ray Keefe has been developing high quality and market leading electronics products in Australia for nearly 30 years.  For more information go to his LinkedIn profile. This post is Copyright © Successful Endeavours Pty Ltd.

EDN Innovation Awards Finalist

EDN Innovation Awards

EDN Innovation Awards
EDN Innovation Awards

This is a bit of a different post.  I’m pretty stoked that we are finalists in the 2009 EDN Innovation Awards in 2 separate categories.  The award categories are:

  • Best Application Of Analogue Design
  • Best Application Of Design Software

Here is a list of the EDN Innovation Awards Finalists and we are in the 2 categories at the bottom of the page dealing with Analogue Design and Design Software.

So I thought I might let you know a bit more about the project, and also give a public thanks to Pablo Varjabedian of Borgtech for allowing us to put the project forward. We design Electronics and Embedded Software products primarily for Australian Electronics Manufacturers.  Our focus is outstanding Electronics Design that will propel them into a world class competitive position while delivering improved profit margins.  Low Cost Electronics Manufacture but with outstanding performance and reliability.

We routinely use non-disclosure agreements, NDAs, with our clients and so don’t usually get the chance to put our design work forward for awards because we will never disclose a client’s Intellectual Property, IP, without their express permission.  In this case Borgtech gave us permission and so we were able.  As you can probably see, there is a real benefit to the client in allowing the award application because they also get recognition for the product.

This is also not an unusual project for us. We have done a lot of outstanding work over the 12 years we have been in operation.  So it is good to have some of it recognised by the Industry we are so passionate about.

Electronics Design Details

This project was an example of our Project Priorities Perspective in action.  In this case Performance was the primary concern with cost coming second and time coming last.  We spent the time to get the performance up and the cost down.  There was an earlier post on one aspect of this project where we looked at Analogue Electronics as a way to improve battery life in a Low Powered Electronics Data Logger.

The Electronics Design trade offs were:

  • OH&S or Operational Health and Safety – must protect users from hazardous voltages
  • Low Power Electronics – operates from 3 AA cells for up to 6 months
  • Convenience – Analogue front end completely Software Controlled
  • High Reading Accuracy – millivolt resolution over +/-10V range with 60dB Mains Rejection

There were many other Design Requirements but the above list are the core Electronics Design Requirements addressed as part of the award nomination.  Below I will look at each of these in turn.

Protection From Hazardous Voltages

Now lets look at the hazardous voltage issue in a little bit more detail.  The voltages in questions were:

  • 5000V, 5KV, for 2 seconds
  • 250VAC continuously

These come about due to the conduction of Lightning Strike Transients or Mains Leakage Voltages onto the Pipelines and Storage Tanks monitored for Corrosion Protection status.  The Analogue Electronics front end had to provide protection against these cases while meeting all the other Design Requirements.  And of course quickly settle so that only the readings during the disturbance were affected.

It also led to the use of an 802.15.4 RF Telemetry Link because this meant the monitoring PC could do Real Time Monitoring without hazard.  Many other products in this industry use RS232, RS485 or even I2C connections for monitoring, configuration and upload of the Data Logger Records.  In the case of the Borgtech CPL2 you can put it in place and then configure it and start the logging with no danger to the operator apart from the moment of electrical connection.  And the initial part of the run can be monitored to ensure everything is correctly set up.  Otherwise you could get a months worth of data that was useless.

And finally, because of the power budget and the possibility of the batteries going flat, the Analogue Electronics had to survive the above Abuse Voltages unpowered!

Low Power Electronics

The Borgtech CPL2 is a Battery Operated device.  There are several reasons for this but the 3 most relevant are that it is:

  • IP68 sealed against water ingress – it is often installed in a pit that can flood
  • Must operate remotely from a convenient power source
  • Protects the operator and PC from Transient Voltages since there isn’t a direct electrical connection

But this is also part of the challenge.   For convenience it used off the shelf batteries you can buy at any service station.  But to get 6 months life required a strong Power Management approach including powering down anything not in use including the Analogue front end.  If you are taking a reading every minute over six months then most of the device is off most of the time.  In this mode the average Power Consumption is 37uA.

Analogue Electronics – Software Controlled

The Borgtech CPL2 handles both Current Shunt and voltage mode readings. The Analogue Electronics were designed to have a software selectable full scale range of +/-10VDC and +/-150mVDC so that is could do either mode of operation from the same input. The previous model required a different connection for each of these modes and most other models on the market are the same.

And all of this while maintaining accuracy, abuse voltage protection and low power operation.

High Reading Accuracy

By the standards of an Agilent (I still want to call them Hewlett Packard) 6.5 digit laboratory multimeter our millivolt, mV, resolution at +/-10VDC isn’t rocket science.  But for a device with the Voltage Abuse Protection and Low Power Electronics requirements we had to meet, it is pretty good. Another small twist you might not recognise is that it is +/-10VDC.  This means you can monitor it with the polarity inverted and fix it up later on by inverting all the readings. The previous model was unipolar and so you couldn’t do this meaning you could have just wasted a month.  And then there is the live monitoring so you can see what the readings look like before leavign the unit to log away in the background.

EDN Innovation Awards

On 17 September 2009 we know the final outcome but either way I am pretty happy to have the recognition this project has already received.

Ray Keefe has been developing high quality and market leading electronics products in Australia for nearly 30 years.  For more information go to his LinkedIn profile.This post is Copyright © Successful Endeavours Pty Ltd.

 

When it comes to selecting a microcontroller for Electronics Manufacture, the field to choose from is quite large.  And while there is no one right answer to this, there are some basic steps to take to ensure you are using the right core component in your latest Electronics Development Project.

For this post I will walk you through how we go about this process.  As I said earlier, there usually isn’t one right answer but this will give you an idea of the process we use.

The first priority to determine is which of the following is critical:

  • power consumption
  • speed or processing power
  • peripherals
  • cost

This is how we go about the selection process:

If it is Power Consumption that is most critical, then we go for the TI MSP430 family.  These have been designed from the ground up for low power with good processing ability.  They also have excellent ADCs and they are fast at 200kSPS.

If it is processing power you want, then the ARM Embedded Processors are great value.  They are 32bit and most need dual power supplies but they really deliver when its comes to performance.  They also come in a wide range of flavours with peripherals to suit a plethora of applications.  We particularly like the offerings from Atmel SAM7 and NXP LPC2000.

If it is peripherals, then it depends on the level of performance and if there are any specific applications.  For automotive you will often want a LIN or CAN peripheral and the processing power will depend on whether it is a simple ECU, Body Computer or Engine Management Unit.  If it is networking you want then you can get away with an 8 bit processor for some tasks but it is hard to beat an ARM MCU with on board ethernet controller.  For this selection criteria, carefully map out what you need and the performance required then look at the secondary factors such as processing power, power consumption and cost.

For cost, we like the Atmel AVR processors.  These are also our work horse 8 bit processors.  And they also have a good range of peripherals, on board EEPROM as standard, and good power management capabilities.

Now let me also make one other point about cost.  It’s not just the component cost, but the complete cost equation.  So development costs, part costs, manufacturing costs, and product life cycle support costs.  Although there are other parts out there that have lower unit component costs, we find the overall cost to be very good with these MCUs.

So that is a very cursory look at the process of selecting a microcontroller.

Ray Keefe has been developing high quality and market leading electronics products in Australia for nearly 30 years.  For more information go to his LinkedIn profile. This post is Copyright © Successful Endeavours Pty Ltd.