Power versus Energy

First, some definitions. Power is a measure of how much work can be done in a given amount of time, and in electronics it is typically measured in Watts. It is an instantaneous value that can change over time, such as when a house’s electric power meter spins at different rates as various appliances turn on and off. Energy, on the other hand, is a total of power multiplied by time. In the case of your house, energy is a count of how many times the electric power meter wheel spins around, totaled up on those little dials the electric company reads to know how much to bill you. In small electronic devices the power is much smaller than your house, often measured in milliwatts (one thousandth of a watt) or even microwatts (millionths of a watt) or less, but the principles are the same.

Shorter power bursts = less energy = lower average power

Since power can change over time, energy readings provide only an average or total of the power readings. For example, if you turn on a 120 W lamp for only an hour a day, the total energy for the day is 120 Watt-hours, and the average power was 5W = 120W-hrs / 24 hours.  As you can see in the plot above, the area of the actual power usage plot (black) and the average power plot (red), since they represent the same total energy.  The shorter the burst of power, the less it contributes to the average.  Thus your toaster might use a whopping 1500 W, but if it is only used for a few minutes, then it might raise your average daily power usage very little, less than a Watt.

Which brings us back to the main reason for the flashing bicycle light… At night a bicycle headlight can produce a steady beam to allow the rider to see the road and obstacles. And the power level required is low enough that a good battery has enough energy to keep the light burning long enough for most rides. But during the day in the bright sunlight, when the main goal is to be seen by cars, the required power may be tens or hundreds of times higher than at night. That causes two big problems: The battery would run down in a few minutes. And the LED, battery and other circuitry could possibly overheat and burn up.

Average Power calculations

The solution is to turn the light on for very brief periods. If the light is on for only 1/100th of each second (1% duty cycle), but the power is 100 times higher for that split second than the night time steady level, then the average power is the same! Result: good battery life and a bright enough flash to be seen.

1% * 100 = 100%

The calculations can be extended to more complex cases. Suppose, for example, that you want a nighttime mode where the headlight has a steady beam AND flashes. If the base steady level is X Watts, and the flash power is X*100 Watts  for 1/1000th of each second (a quicker flash than during the day), then the average power is:

99.9% * X + 0.1% * X * 100 = (99.9% + 10%) * X = 109.9% * X

In other words, adding the quick flash to the steady beam will increase power (and decrease battery life) by about 10% in this case.

Applying power switching to complex circuits

On a more complex electronic circuit design, this power management technique of briefly turning devices on only as needed is a good way to save energy, and can bring a host of benefits such as extending battery life, keeping the device cooler (which can extend life, reduce cooling costs, etc.), reducing power supply costs and so forth. But is it as simple as turning an LED on and off? Unfortunately no.

First of all, some devices have built in power switching, while others will require external transistors or other switching circuits. Thus while selecting the components there can be tradeoffs to consider in cost, board size, complexity, reliability, and more. And one big issue that is often overlooked is timing, as illustrated by this example:

Suppose you have a need for an Analog to Digital converter (A/D) to read various sensors on your board (accelerometer, temperature, pressure, light). You narrow the parts choice down to two competing A/D converters that have virtually the same specifications in terms of cost, speed of conversion, resolution, noise level and so forth, and they both have a pin to power them down when not in use to save energy. The only difference you really notice is that chip A one draws half as much power as chip B when it is turned on. You should choose A, right?

It’s a matter of timing

Well, not so fast (hint, hint). Both of these use successive approximation type A/D circuits and serial ports, and these complex modules require internal digital clocks to coordinate the timing of the conversion steps and serial port signals. Clock circuits take some time to start up and stabilize after a chip is powered up, and the amount of time can vary greatly depending on the cleverness and goals of the chip designer.

Suppose that both chips can perform an A/D conversion in 1 microsecond (1 millionth of a second), but chip A requires 100 microseconds for its clock circuit to stabilize before you can do a conversion, while chip B is ready in only 5 microseconds. If P is the power draw of chip A, and chip B draws 2*P, then the amount of energy to start up and perform N analog to digital (A/D) conversions for the two chips is:

Chip A energy = (100 + N) * P
Chip B energy = (5 + N) * 2 * P

Even though chip A uses half the power to perform a single A/D conversion, from the time it turns on through the first A/D conversion it will burn 101P, while chip B uses only 12P, over 8 times less energy! If the requirement is to take 1000 A/D readings per second, one every millisecond, then chip B is the clear winner. (The chip would be on for 6 microseconds of every 1 millisecond, or only 0.6% of the time, while chip A would be on for 10.1% of the time.)

On the other hand, if the circuit needs to take 100 sensor readings at a time every time the A/D chip is powered up (i.e.- N = 100), then the total energy is 200P for chip A versus 210P for chip B. Chip A wins in this unusual case of so many sensors, but not by much.

Power isolation

If the circuit designer isn’t careful, some power management choices can lead to hidden problems that might cause mysterious failures and reduced product life, and higher than expected power drain.  For example, shutting power off to an integrated circuit while it still has voltage signals applied to some of its input pins from another part of the circuit board can cause unexpected power flow through the input pins and internal damage to some ICs.  Proper isolation or component selection can avoid these problems.

Analog and Power circuits

Analog circuitry also prevents challenges and new considerations for good power management.  Filter and amplifier circuits need time to stabilize and may not work properly if switched on and off rapidly, but clever design can find the right combination of components and circuit topologies to make drastic cuts in power consumption here as well.

Finally, the components that control the power flow, from discrete transistors to special power distribution chips all have their quirks and tradeoffs that need to be considered to make sure that they don’t waste energy themselves or cause other problems such as adding noise, glitches or voltage drops to the power supplying sensitive analog circuitry.

Good power management can produce remarkable results

This just scratches the surface of some of the things you need to think about to minimize average power levels in order to maximize battery life, but the results of a careful design can be amazing.  Our iBike power meter bike computer design, for example, takes thousands of sensor readings and performs many thousands of complex calculations per second, yet through careful power management it can run off a single tiny CR2032 coin cell battery for many months to a year.

The post Flashing Lights and Power Management appeared first on Cunningham Consulting.

The products were expensive laboratory grade instrument modules (costing tens of thousands each) that were designed to be stacked and work together to gather and consolidate data.  But there were problems with the communications between the modules and the host PC.  Customers would spend hours preparing for a test, and a few more hours to run it.  But partway through the test, the system would suddenly hang up, data would be lost, and the test would need to be run over again from scratch.  And there were all kinds of other mysterious and problematic symptoms that were hard to find and even harder to explain.

The individual instruments were extremely reliable, and had been for years.  The problem was with the added inter-module communications, both the hardware and the software.  The instruments were designed to talk to a single host, not a network.  So the company designed add-on boards to allow for a mini-network of instruments using CAN bus communications hardware and a proprietary communications protocol.  The new boards also provided a USB connection for a host PC to monitor and download the test data.

There were many problems, but here are the main ones:

Poor protocol design

When communications problems exist, I look for two things — the documentation describing the protocol and some tools to capture and analyze the communications bus traffic to see what is really going on.  They had neither.

A protocol is a specification of the formatting of the data and messages that will travel between devices.  The design of the protocol will usually provide a way to minimize the chance of errors and detect them when they occur, typically through some form of checksum or error correcting code.  And it will anticipate the different errors that might occur and describe how to handle them so normal communications can resume.  A protocol document allows all the scenarios to be thought out ahead of time, and for peer review and corrections to polish the plans to provide a bulletproof scheme.

They didn’t have a protocol specification document.  And they had never gone through the design process.  Instead, the ad hoc protocol evolved over time with more and more patched on to it as new issues arose, with little to no documentation.  If anyone had ever seen the big picture of what was being created, they would have realized that it was a mess and a minefield of problems waiting to happen.

Since all of the original programmers were gone, we spent months trying to understand what it was supposed to do, while also trying to figure out why it kept failing and how to fix it.

In an ideal situation, you would have a well thought out and documented protocol specification and tools to sniff the communications and capture snapshots of any faults.  Within days you would find the problem and solve it.  Instead, the days or weeks they saved by skipping these steps meant months of time spent on the back end trying to clean up the mess.  Even worse, there was some serious damage to the company’s reputation and sales.

Lack of safeguards

The system included thousands of individual settings for calibration and configuration.  But these settings were unprotected and could be wiped out or changed accidentally in an instant by an errant command, all without any warning or indication that it had happened.

The protocol had no provision to identify what type of data packet was being sent, such as a packet wrapper describing the contents.  The receiver was supposed to know when the sender was changing states from, for example, a command mode to a file transfer.  But if the mode switch was lost or delayed, the receiver could see the file and try to interpret its bytes as commands, potentially wreaking havoc as it went nuts doing all kinds of random things it wasn’t supposed to do, such as overwriting critical settings.

Bottlenecks

There was a big problem with getting the data out of the system.  After a four hour test, it could take an hour or two just to transfer the data file to a PC for analysis.  There were two big bottlenecks:

First, the CAN bus connection between the modules was being run at 125,000 bits per second.  That might sound like a lot, but standard USB speeds are nearly 4000 times faster.  So a file that takes only a second to transfer over USB would take over an hour on the CAN bus!  (Actually, it is even worse than that since the CAN bus has a very high overhead, using 5 to 8 bytes of wrapper around each tiny 8-byte packet.  So the effective data rate is close to half of the bit rate.)

The diagram above shows the communications flow between the different components.  Each module consists of a laboratory instrument and an interface board which includes an MCU and a CAN and USB interface.  The different modules in a stack talk to each other through the CAN bus backbone.  And a host PC could monitor or download the data through a connection to one of the modules’ USB ports.

Since you could never know which module the PC might be plugged into, the programmers decided to make each module keep a copy of every other module’s data.  This would avoid the bottleneck of using the CAN bus to do large file transfers since every MCU could send it all directly to the USB port. But it didn’t work, and everyone was scratching their head wondering why the PC transfers were so slow. One other bottleneck had been overlooked.

The product specs could say that they had a USB 2.0 standard port, capable of 480 million bits per second rates.  But do you see the black line that transfers data from the MCU to the USB adapter?  That is a standard serial port line limited to only 230 thousand bits per second, about 2000 times slower than the USB port.  It’s like trying to supply a firehose with a narrow IV tube.  The flow will never be more than a dribble.

File transfers took so long that customers would instead attach a dedicated PC throughout the test to download the data as it happened.  Or they would take the modules apart to get to the CompactFlash memory cards that were hidden inside.

Eliminating the communications problems

One thing that became clear over time was that the problems were even worse than we thought.  It seemed like a bottomless pit of new issues to discover and fix.  New product plans were in motion, so it was time to step back and consider changing the architecture rather than perpetuating such a troublesome design.  My proposal was accepted, so I stayed on for another year to implement the new system.

fast and powerful at a low cost

When I first started designing electronics years ago I noticed something interesting.  Some chips that had way more features and capabilities could be far less expensive than some less capable alternatives.  The reason was volume.  If a chip was used in a high volume product like phones or personal computers, then the volumes would drive the price way down and I could take advantage of that even in a low volume product.

The smartphone market has made some incredibly powerful, tiny and highlight integrated chips available at extremely low prices.  System-on-a-chip devices with a powerful CPU, DSP, Video, Audio, Ethernet, USB and more are available in a single chip costing just a few dollars.  Add some memory, connectors and an operating system and you have a powerful computer.  That has led to the creation of powerful single board computers covering just a few square inches, perfect for dropping in an embedded system.

For the next generation of this troubled product, we decided to replace their proprietary hardware and communications with an off-the-shelf single board computer that cost a fraction of their old design, yet had way more capabilities.  The included standard Ethernet was capable of 100 million bits per second, a 400 to 800 fold increase in speed over the CAN bus and throttled USB ports on the old board.  And the PC would connect to the Ethernet bus, not a specific module, so all modules could be reached equally as fast.  The revised communications bus structure is shown below:

Linux Operating System

The boards also ran Linux, the open source (and free) operating system that is already widely used in a lot of complex embedded systems like DVR’s and cable boxes.  That gave us several big advantages.

We were able to completely replace the troubled proprietary protocol with standard Internet protocols (TCP/IP), all included with Linux.  Since these protocols drive the Internet and local area networks, they are obviously well documented, robust and proven, and there are excellent tools (such as Wireshark) to debug any problems during development.

A more modern User Interface

Another huge advantage of Linux is that includes a web server.  (This website runs on Linux.)  My client’s old system was also burdened by a native Windows PC host application that nobody liked and had a number of its own problems.  We created a new user interface with a web application hosted on one of the Linux boards on a private network (not on the Internet).  Since the application now runs in a browser, it is cross-platform and can be used on Windows, Mac, Linux and any other device that has a browser, and it can now be viewed by more than one person at a time.  With the addition of an integrated WiFi hub, the user interface is also available on tablets and smartphones for quick control and monitoring during a test.  In fact, an iPad was included with the new system to highlight this useful feature.

The new product is a big success.  The communication problems are gone, the speeds are fast, and the user interface is a big improvement.  And the new architecture can serve as a platform for adding new modules and creating new products from different combinations for years to come.

Lessons

This story illustrates the value of a few themes that I promote:

• Take the time to design and properly vet a system on paper before you dive into the final implementation.  It will save you time and headaches in the long run.
• Use a highly qualified and experienced person to design the system, or at least to review the plans.
• Write performance specifications and test to confirm they are met.  It was embarrassing that the high-speed USB port was almost uselessly slow and made it to market like that.
• If the system is complicated, take the time to gather or create the tools to analyze it and prove that it is working according to spec during development.  This client should have created a tool like Wireshark for their custom protocol to analyze the data on the bus.  They would have quickly identified many of the problems and fixed them before the product was shipped.
• Consider using existing industry standards.  They are proven, robust and well supported.  There are times when a proprietary scheme is appropriate.  But designing your own encryption algorithm or file transfer protocol is probably a bad idea.

The post Networking Products with Embedded Linux appeared first on Cunningham Consulting.

Hewlett-Packard founders Bill Hewlett and David Packard are two of my heroes. Their company was literally started in a garage and became one of the first big success stories of Silicon Valley. Steve Jobs also admired them and had a summer job at HP when he was a kid.

So I was very excited when Hewlett-Packard asked me to apply for a job at their calculator division in Corvallis, Oregon. Scientific and financial calculators were relatively new at the time (1980) and HP calculators were arguably the best. I had been studying both electrical and mechanical engineering but decided to focus on mechanical at the time, so they wanted me to be designing buttons and switches and so forth.

As a GM Scholar, General Motors had paid for my last two years at Cornell and gave me interesting summer jobs where I had invented a new type of engine control that could dramatically improve fuel economy.  GM gave me a $300,000 budget and flew me back and forth to Michigan every week to build a prototype of the invention during my senior year of college. So I already had some fame at GM and a great job offer to design future production engines, work on racing engines and serve as a liaison to outside inventors. Designing plastic calculator buttons just didn’t seem as exciting. Still, it was the legendary Hewlett-Packard, so I flew to Oregon for the interview.

Every member of the HP engineering department gave me a short quiz, an engineering problem to solve. At the end of the day, I was apologizing to the head of the department for taking longer than I normally would have to answer some of the questions due to the pressure of having people watching as I worked out the solutions. I was also trying to explain that I wanted to be doing higher level system architecture work, not just designing tiny elements of the calculators. He laughed and told me that they were all amazed because I was the first one to ever answer all of their questions correctly. Nevertheless, their policy was to rotate new engineers through all the lower level design positions to gain more experience before getting a chance to move up.

Then he presented one last quiz question. Their high-end calculators allowed programs and data to be stored on magnetic strips. He described the motor and gear train that pulled the strips through the reader, along with their rotational inertias, gear ratios, torque specs and so forth. My job was to determine how quickly the drive wheels got up to the right speed to read the cards.

I stared at him for a minute before he asked why I was hesitating. “Do you not understand the problem?” I responded that what I didn’t understand was why they would do it that way.  If they used a stereo tape head they could record two tracks, one for data and the other for a reference timing track. Then the user could just pull the cards through at whatever speed. That would eliminate the motor, capstan and all the gears. It would simplify manufacturing, improve battery life significantly, and reduce cost, size, and weight.

He stood up and gave me a shocked look. “We just thought of that two weeks ago, and it will probably be in our next line of calculators. Maybe you could be a systems architect for us after all!”

The post HP Calculator Memory Strips appeared first on Cunningham Consulting.