The Art of Engineering

Does that pull–up/down resistor really have to be 1k? Could it be 10k or more? There are always engineering trade–offs to be made. Increasing resistor size increases noise and can make your design more susceptible to EMI, but there are many cases where resistor values can be increased with no discernable effect. Think about this, at 3.3V a 1k resistor will burn up 11mW, change that to 10k and the power consumption drops to 1mW. Your signal line should be in the correct default state (high for a pull–up and low for a pull–down) to ensure no energy is being spuriously expended.

We (I) often use LEDs for debugging purposes, such as internally on an enclosed board. It helps us get some visual information about the system while debugging. Did you remember to turn those off in your release version? LEDs can consume a significant amount of power (1.5V @ 10mA = 15mW) which adds up for each LED that is needlessly left on.

LEDs that provide visual information to the user can be dimmed or blinked to reduce power consumption. Try to determine whether those LEDs are really necessary in the first place – are there other indicators which are providing the same information? A laptop typically has a power LED and a screen which both provide feedback that it is on, while cellphones have no power indicator other than the screen. Does the laptop really need the power LED to be on all the time? What if it was only on when the screen was turned off, or flashing while in sleep mode? What if the battery indicator flashed when the laptop was off and the battery was full instead of being permanently on? How else can you convey the same information?

Microprocessors are often waiting for an event such as a timer or communications interrupt. It is normally a simple task to put a device to sleep while it is idle. Some simple code can reduce the power consumption (and extend the battery life) of your device.

Microprocessors usually have a number of peripherals which are either not used, or not used all the time. If unused peripherals are clocked that means that energy is being banished to heat just to clock something that is idle. Not all devices support this, but more and more are coming out with these features (such as the Luminary Micro range).

Duh! That may seem obvious, but take some time to look at the quiescent current of the components you choose when designing. Faster components (like high speed op–amps) typically require more power when idle, while slower components require less. Consider using a slower op amp or lower power transceiver.

When you are running long wires (e.g. power bus around a warehouse) use the highest voltage that is practical. This will help reduce power loss due to copper losses. It also means you can use thinner cable, or run more units from a single cable (if cable current is a limiting factor).

Have you considered using a lower system voltage (e.g. 1.8V instead of 3.3V)? The limiting factor is often peripherals which require certain voltages, but you can consider other peripherals or use level translators. There are a lot of trade–offs to consider here, so use your engineering wisdom to come up with the best solution.

Normal relays require a continuous current flow to keep them in the on position, while latching relays only require a short pulse to switch from one position to the next. You will have to consider cost and a small amount of extra circuitry, but these are particularly valuable where there are power supply limitations.

This is a short report which gives everyone some preliminary ideas to work from. I like to start with this as it is a small investment in testing the idea, and provides a lot of information for the path forward.

The initial report or specification has already identified the options, now all the options are investigated in detail. This entails reading datasheets and application notes, speaking to distributors, and really understanding whether the available options will provide the required solution.

There are two ways to go here, either develop a proof of concept using evaluation boards, or dive straight into the custom hardware design – which is better depends on the risks involved. The risks are a function of the project and the amount of experience with similar designs. Wherever possible it is nicest to speed things up, but a detailed proof of concept can take a lot of risk out of the later stages.

After a full proof of concept it is quite clear how all the pieces fit together. At this stage we should have system block diagrams, communication protocols, component choices, disposal planning and a whole lot more down on paper. The framework for our creation is in place, now we need to make a real prototype.

All the concepts and ideas have to be put down into technical drawings (an electronic drawing is called a schematic). Once this is done we have a schematic, a BOM (bill of materials), and other technical files needed for the next steps.

The schematic output is used to generate a printed circuit board (PCB layout). The physical size is determined and the components are placed and connected together with tracks. Any mechanical design which is required (e.g. a casing) is also done along side with this step so that the PCB will fit nicely. This can be a time consuming step, as a lot of checking is required, such as tolerances, spacing and component patterns. A set of gerber files are generated which are used to manufacture the actual PCBs.

Before a prototype can be built, you need all the components that will be placed on the PCB. This step is really happening in parallel with all the other steps to ensure that everything arrives at the right time. Electronic component lead times can vary significantly (from 1 to 16 weeks or more), so a fair amount of planning and scheduling is required.

A PCB manufacturer (such as WHCircuit or Trax) makes the PCB's according to the gerber files. The PCB is then populated with the components either by hand or machine. For a first prototype I like to populate the board by hand (where possible) so that I can test each part of the system as I build it up.

The amount of effort that goes into making a system work properly is really quite big, but depends on the complexity of the system and the amount of detail that went into all the proceeding steps. It must be shown that each block of the system works and that it all works together properly. Firmware (software that runs on the system) must be tested and developed to a fully functional level. Any bugs that are detected need to be resolved and noted for the future.

Once all the functionality is working it must be fully tested, both to check that it is working correctly and to also stress the system to find out if any real world events could break things. Careful attention must be paid to test as many usage cases as possible, and more. Certain countries require specific certifications and any required tests must be done to ensure all the necessary specifications are met.

All of the testing and development will either have proved that the design works exactly as desired, or indicated areas that need to be improved before going ahead with manufacturing. Steps 4 to 11 are repeated until the product meets the requirement.

Manufacturing can bring its own challenges to the product from solderability through to the programming and testing of the product. To avoid major manufacturing disasters it is normally better to have a small initial run to iron out any problems in the process.

Once all the manufacturing issues have been resolved it is time to go into full production. This can be a big investment and the quality of the work that has gone before will determine how successful the product is.

There are always things to improve. Wherever possible I try to build in mechanisms that allow easy upgrading of products (such as in–field upgrading of firmware), but it is sometimes necessary to go through some redesign to meet a new requirement or fix a manufacturing issue. Once a product is out in the field you start to get a feel for how it is really used, which teaches you a lot about how to improve the quality.