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.

Definition Stages

Many engineering and software teams skip these steps and figure it out as they go.  When the schedule is tight (as it usually is), they are anxious to dive in and start the “real” work of design and coding.  But that can be a big mistake, like traveling without a map and a plan.  Sure, you will get there (or somewhere!) eventually.  But you might waste time wandering all over the place.  And you might miss key steps and features that should have been included and are hard to add later.

Changing your mind in the definition stages is cheap.  Changing your mind or having to correct for poor architectural decisions later in a project can be costly.  You want to minimize the chances of having to scrap expensive tooling and hardware by more carefully thinking it all through up front.  And software changes can be costly too when they involve thousands of lines of code and the changes create a confusing mess.

This is not to say that you might not want to do some rough exploratory designs and prototyping up front to test out some ideas.  You can see what is possible, what features make the most sense and do some customer testing to gather valuable feedback.  But realize that these are just throwaways and not your final product.  It is often better to toss these and start over once the product is fully defined, and incorporate the lessons you’ve learned in the final design.

Think about it.  Would you rather tear up a few pages of your plans and start over, or rush in and then have to scrap tens of thousands of dollars of tooling and prototype hardware or time invested in programming?  Time spent wisely on the front end can save a lot of time and money in the long run.

Concept

At this stage, you are trying to figure out what the product is and not how to design and make it.  Concentrate on the features and goals.  Brainstorm. Build some quick mockups.  Think about who the target audience is and their needs. Get input from marketing or the customers themselves.  Once the concept comes into focus, you should be able to capture it with a few diagrams, a short description, some feature lists or whatever is appropriate.

It is great when I can be involved in this early stage of the development. I can help expand your vision of what is technically possible and create some quick mockups and prototypes. And I have a proven history of innovative ideas to add to yours.

Architecture

In the architectural stage, you are starting to piece together a design, but only in very broad strokes.  Think about how all the pieces will fit together at a very high level.  And focus on what key pieces of technology you will need, such as special software modules, communications (hardware and protocols), data storage, sensors.  Investigate the tradeoffs between different options with an eye towards creating a simple and elegant solution.

A system or product architect should have a broad range of knowledge or experience, the ability to see several steps ahead, and a healthy dose of creativity. This allows them to quickly see the pros and cons of different approaches. And it allows them to see outside the box and bring in ideas that are different than the standard way of doing things. Traditional methods are often the best, but sometimes a simple but key switch in the approach can lead to some big breakthroughs.

This is one of the areas of my work that I am the proudest of, and the huge impact it has made for many of our customers. Click to read blog posts about the significance of a clever architecture in some of our projects and others.

Design Specification

The design specification dives much deeper into the details, typically in a more formal document.  Some of the design specifications may be useful in a customer or product specification later, but the main purpose at this point is to guide the developers.   Whereas the architectural documents explain to everyone how the main pieces fit together, the design specification tells the engineers and programmers more about how to make it work and their requirements and constraints.

Here are some examples of items to include in a specification:

• Power supply requirements
• Measurement precision and accuracy
• Operating and storage temperatures
• System response times
• Security
• Communication protocols (custom and/or industry standards)
• Data storage

Take more time documenting the different modules and their interactions if they will be assigned to different programmers.  This will allow the programmers to work more independently and efficiently.  And that saves time and money.

One of the most important parts of this document is the functional specification.  It should describe how the product is expected to operate and respond to various conditions and inputs from the user or the rest of the system.  And don’t forget to address possible error conditions and how to handle them.

The design specification is often a living document, with additions and changes as the project progresses.  Make sure that everyone has access to the latest copy and is aware when changes are made that might affect them. (A version control system can automatically highlight what was changed and when.)  Put it in writing rather than relying on verbal communications to make sure everyone is working towards the same goals.

Hardware Path

Hardware Design

The hardware engineer will create schematics (circuit diagrams) to capture the design.  Schematics specify which components (transistors, chips, etc.) are used and how they are connected logically.  The engineer may also use circuit simulations at this stage to check and fine-tune the design, especially for analog circuits such as power supplies, amplifiers, and filters.

Circuit Board Layout

A schematic represents the logical connections in a circuit.  The board layout converts that into a physical design that specifies the board dimensions, where all the parts go on the board, and the routing of the circuit traces that make the physical connections between the pins of the different chips and components.

A printed circuit board consists of layers of etched copper traces separated by insulating substrate layers.

The hardware engineer will specify constraints to guide the layout process.  These constraints are important to:

• isolate sensitive signals
• minimize noise
• meet timing requirements
• provide adequate current capacity
• isolate analog and digital grounds
• provide proper circuit protections (against ESD and EMI, for example)
• meet mechanical needs such as connector placement
• etc.

The hardware engineer works closely with the person doing the layout and checks and approves their work when done.  A mechanical engineer may also be involved to make sure that mounting points, hole sizes and other dimensions match up with the housing where the board will be installed.  Some layout issues may arise that require changes in the schematics, such as swapping gates or pins on a chip to improve the signal routing.  This close interaction between the two roles often makes it easier and better for me to handle both.  My CAD software ties the schematic and layout designs together.  And handling both roles lets me quickly see the issues, make decisions and changes on both the schematic and layout and keep the project moving.

A good layout requires the ability to visualize the signal flows around the board and to see ahead to anticipate where the bottlenecks will be so just enough space is left between the parts. Simple boards have just one or two layers of copper signal traces, but many if not most boards have 4, 6, 8 or more layers, like a big 3D puzzle maze. One of the best layout engineers I’ve ever met (and the person who trained me) is also an expert chess player. That ability to see many moves ahead, and analyze all the alternatives, is an important skill.

Each signal is routed through a board by finding the best paths between pads, components and other signals. A signal will often jump back and forth between different layers (using a via) in order to cross over or under other signals and parts in its way. Design rules are set so the software can automatically check your work and make sure the signals don’t get too close to each other, to any pins or the edge of the board.

The CAD programs can also do auto-routing, automatically finding ways to route the signals through the maze. That can save a lot of time, but can also create a mess if not used properly. I find that a combination of manual routing and auto-routing is often the best solution.

Once the layout is complete, the design is ready to be turned into physical circuit boards.  Typically a small prototype or pre-production run is made in order to test the design before committing to a larger production order, as described in the following steps.

Bill of Materials

The hardware engineer will create a bill of materials listing all of the parts that will be mounted to the circuit board and any attaching cables and other devices.  For a prototype run, they will create a quick list to get the parts ordered for the prototypes.  For production, more time is taken to match the parts with the customer’s existing parts management system and part numbers.  Alternative parts and multiple source options are also checked and approved in order to give the purchasing and manufacturing departments more flexibility.

Parts Procurement

Your in-house or manufacturer’s purchasing department is skilled at making large purchases at a low price.  But it is usually faster and easier for us to handle the purchasing for you for a low volume prototype run.  If I am arranging the board fabrication and assembly, I typically have the parts drop shipped to the assembly house or our technicians to save some more time.

Board fabrication

A board fabrication house will take the layout files (mechanical drawings, Gerber files, etc.) and convert them into a physical circuit board.  We can work with your in-house or contract manufacturers.  But for prototypes our customers often have us arrange this through board manufacturers that specialize in small runs and quick turnaround time.

Automated bare board testing is sometimes used to check for any faulty boards before sending them to the assembly stage. Board faults can include opens and shorts deep within the layers of the board that may be impossible to see or repair from the outside. There might only be one faulty board in a batch (and usually none), but you waste valuable time if that is the one you spend a week building as your first prototype board before you find the problem. Such faults are rare, but if a board has internal layers with fine or tightly spaced signal traces then the chance of faults is higher. If the cost of the following board assembly (labor and parts) is high, then the small cost and extra time to do bare board testing is good insurance. If the board is simple and all the signals are on the outside (1, 2 or 4 layer board) then there is far less risk if this testing is skipped.

Board assembly

Once the bare circuit boards are ready, the circuit components are mounted and soldered onto the board. For surface mount parts (the most common nowadays, as opposed to thru-hole parts), a silkscreen printer deposits a shaped blob of solder paste on all connection pads on the board.  Then a high-speed robotic pick and place machine precisely places the miniature components on the board. Reels of tape hold the parts to feed the machine. A robot arm with a tiny vacuum tube uses suction to snatch each part from the tape, move it into position, press it down and then release it.   Each leg of the chips and components gets pressed into its own miniature dab of sticky solder paste which will hold it in place temporarily until the solder is melted in the next stage.

We provide the necessary files to the board assembler to create the solder paste silkscreen and to guide the robot part placement. Watch a high-speed pick and place machine in action:

The boards then travel through a wave solder machine or infrared reflow oven (like a fancy Easy-Bake Oven) for soldering.  Sometimes there is additional hand soldering of some components.

Machine vision systems and humans check the boards for any misplaced or missing components.  And electrical tests are also available to verify all the connections.  Some electrical tests require special pads to be included in the design and layout.  Electrical tests are sometimes skipped to save money and time on a tight prototype schedule since the boards will be manually tested by the engineer.  They can be important for full production runs of some types of boards, however.

board testing

The prototype boards are returned to the hardware designer for careful testing to make sure that the design is right and that it is built properly.  If design mistakes are discovered, they are usually fixed through a simple circuit patch.  That patch fix is either incorporated into the design of the next iteration of the boards or continues into production.  My clients tell me they are amazed at how often my designs work the first time, but mistakes do happen.  So testing each board is important before assembling into the final product or larger system.

Production Test fixtures

For larger volume production, test fixtures can streamline testing, programming, and calibration of the boards.  We will often create test fixtures, or their precursors, during the prototyping stage.  These can then be ruggedized and refined for higher volume production.

These production fixtures might be stand-alone, controlled by a PC, or attached as adapters to more sophisticated generic board testers.  Whatever their form, they need to be designed and may involve some sophisticated electronics.  I can handle this for you too or provide the specs for your own factory test engineers.

Factory test and calibration software

The factory fixtures for testing, calibration, and programming will also typically need some form of software or configuration.  Again, I can provide that service or assist your staff or your manufacturer.

Many of the boards I design have self-test and self-calibration procedures built-in for operation in the field.  In that case, then the factory equipment can use or augment that to simplify the factory requirements.  For example, the factory setup might provide an accurate reference signal, trigger a calibration, record the results in your database and then tell our firmware to write the manufacturing date, serial numbers and other details in its memory.  That setup could be as simple as a PC, a simple program and a serial cable to the product.

Manufacturing documentation

Formal documents are created to record the various factory procedures that have been worked out.  These are assembled with all of the other production and design files such as schematics, layout, board fabrication and assembly files, firmware releases, etc.

Release to manufacturing

Once all the documents are in place, I will work with your manufacturing and document control departments to make sure that everything is properly recorded in your systems.  And I will be available when full production first starts to help iron out any kinks.

Software and Firmware Paths

The Gantt chart above shows very simplified software and firmware development paths.  Typically these are divided up into more steps to highlight and track different modules and functions of the software, and to mark intermediate milestones.

The chart shows an example where the boards have embedded firmware that makes them function, and a companion application is created to talk to the device.  For example, this product might be a lab instrument or factory control module.  And the software is a PC or web application that provides a user interface to monitor and control the device remotely.

The same basic steps also apply to a software-only project (including the concept, architecture and specification steps that precede these).

Programming

This is the bulk of the work, turning the specification into actual code in whatever programming language is used.  Many projects nowadays use several different languages, each with their own specialty, for different parts of the system.

The chart shows the programming, testing, and documentation phases in sequence.  But often it is more efficient to do a lot of the work in parallel.  For example, you can write test code for a module or routine while or before you write the main code.  Then you have a built-in test that tells you immediately if you have made a mistake.  And testing small sections of code like this makes it easier to find certain bugs than trying to find the needle in a haystack of thousands of lines of code later.

Similarly, tools exist to allow the programmer to include bits of documentation as specially marked comments throughout the code as they write it.  The tools then scan the code and compile the bits into a larger document.  Future programmers can then use this document to understand the overall structure and function of the program.

Testing

Thorough testing is important to minimize the chances of any bug getting out to a customer.  Testing also is used to compare the operation against the specifications and make sure that all the requirements are met and features are implemented.

The complexity of today’s systems means that sometimes a change in one area might break something else.  So it is often worth your time to automate the testing process to make it easy to repeat tests over and over again to not miss anything.

Documentation

As I mentioned earlier, the programmer may scatter documentation fragments throughout the code.  These can then be extracted and compiled into a master reference document for programmers.

You may also need documentation written for other audiences such as users (user manuals), management, marketing and so forth.

And don’t forget to record ideas and plans for possible future revisions or additions to the product or product line.

Release

A formal release process is important to ensure that you know exactly what was in the code at that point.  This allows you to track changes between different versions for your release announcements.  And it allows you to go back in time to track the source of any bugs that might have been introduced.

A release should assign version numbers, and store the present state of the code into a source code management system (also called a version control system).  Any user manuals, specification documents, and other affected documents should be revised to match the new features and functionality of the release, and then also stored in the version control system.  Record the compiler version and settings so you can fully recreate the release conditions in the future.  And if there is a related hardware change, then throw in the revised schematics too.  This creates a time capsule of sorts for the whole project.

Final Release

Once all the pieces are complete, and the product is out the door, you can finally wrap things up, celebrate, and prepare for the next project…

The post Product Development Stages 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.

Motivation

Sunbeam was in trouble due to the disastrous management by “Chainsaw Al” Dunlap that left them with two billion in debt.  Jerry Levin had taken over and was looking for ways to save the company.  He explained that while running Revlon, he had the R&D department develop a new lipstick that would last all day, far longer than the competition.  It worked, and their sales margins and profits increased dramatically.  And Revlon rose from third to first in cosmetics market share.  My job was to do something similar for Sunbeam’s appliance lines to give them a boost.

When you go to an appliance store to buy a coffee maker or curling iron, you will find very similar products from several different brands.  Since their features are often nearly the same, you buy based on price, looks or reputation.  With stiff price competition, all the appliance manufacturers had slim margins.  But if one of the appliances on the shelf had some cool new feature, it would stand out, sell more and could command a higher price.

So Sunbeam’s idea of making the appliances talk to each other and the Internet had a lot of promise.  Their initial plan of how to pull it off did not.

A Heavy-Handed Approach

Sunbeam’s strategy was to sell a dedicated PC in a box that would serve as the hub for all the appliances, and a gateway to the Internet.  It would connect to the appliances through WiFi.  This was the most obvious and straightforward approach.  But I told them that I thought it would be a commercial failure for many reasons:

• Such a PC would have cost a couple thousand dollars back then.  Who would spend that much to hook up some $30-50 appliances?
• WiFi was uncommon in homes at the time.  So the consumers would have to buy that and figure out how to set it up too.
• WiFi hardware was way too expensive.  If Sunbeam wanted their smart appliances to stay within $10 or $20 of the base product, the manufacturing cost of the extra hardware had to be under a few dollars.
• WiFi used too much power.  In products like their First Alert smoke alarms, the battery would be dead within minutes.
• Their customers were used to products that just plugged into the wall and worked, not that required large manuals and an IT department to set up.

An Improved Architecture

My proposal was to eliminate the PC altogether and use a very inexpensive hub instead.  And we’d replace the WiFi communications with a much cheaper and easy to set up networking scheme.

I argued that an inexpensive alarm clock could take the place of the PC as the hub of the system.  Smartphones hadn’t been invented yet, so nearly everyone still had an alarm clock next to their bed.  It was a logical place to check on the status of everything and turn things on and off when you went to bed or woke in the morning. As a clock, it was perfect for scheduling when your electric blanket turned off and your coffee maker started in the morning, for example.  And with a cheap dial-up modem, we could download weather and traffic information early in the morning, ready for when you woke up.

High-speed communications are important for streaming videos and sending large files, but are overkill for a few dozen bytes to broadcast when the dryer is done or your coffee maker is out of water.  So we would use inexpensive low data rate powerline and wireless communications rather than WiFi.  If the product plugged into the wall, it would talk through the house wiring.  And if it ran on batteries, then it would use short bursts from an ultra-low power radio to talk.

This scheme meant that a customer could get a starter kit of networked appliances for $80 or less, such as an alarm clock plus a coffee maker, or alarm clock and a smoke alarm.  They would try it out, see the benefits, and then start buying more smart appliances to add to the system.

Thalia Products

Sunbeam liked the idea, so I was contracted to create a suite of eight prototype products including the alarm clock and a touchscreen kitchen organizer within five months.  We assembled a team and pulled it off, and were the hit of the annual Housewares Show in Chicago.  I then joined Sunbeam as Chief Technology Officer of their new tech division, Thalia, and later became VP of Technology for the corporation.

My role was to develop the technologies (such as the low-cost communications circuits that we called HLT, or Home Linking Technology) and coordinate the incorporation into the products of the different divisions within Sunbeam and to promote and sell it to other companies.  Consumers would benefit if we were also able to communicate with products from other manufacturers.  For example, we wanted our alarm clock to be able to control Lutron light switches, check that your garage door was closed or tell you when your Maytag dryer was done.  That meant that we needed some standards for both the communications hardware and the messages that were passed between the devices.

AHAM

The Association of Home Appliance Manufacturers (AHAM) organized discussions about smart appliances and how to connect them.  I chaired the committee that was writing the standard for the communications protocols, and we met every two to four weeks.  Agreeing on the hardware was difficult since a company like Maytag or GE would be content with adding $20-30 to their cost for a high-end large appliance like a washing machine, while we wanted to keep it to a couple of dollars for our small appliances.  But we were making good progress on the messaging protocols.

Someday I may write a blog post about my meeting with Bill Gates.  Microsoft was trying to convince the AHAM members that we all needed to use some form of Microsoft operating system and an adaptation of their Universal Plug and Play (UPnP) architecture.  I was arguing that we didn’t need all that complexity and to be paying licensing fees to Microsoft just to turn a light on or tell when your dishwasher was finished, and we had proven that it could be done.  So Bill called me out to his office in Redmond to talk…

Sunbeam’s Demise

Unfortunately, that all came to an end for us when Sunbeam’s financial woes from Al Dunlap’s management caught up to it.  In 2001, less than a year before we would have started selling the new products, Sunbeam filed for bankruptcy. It was sad that we didn’t get to finish, but I was very proud of what we were working on and what we accomplished.

Today, this type of work continues with the Internet of Things (IoT), the Cloud and other technologies to connect more and more of the devices and points of information in our lives.  There are still many opportunities and a lot to be done.

The post Smart Appliances 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.