I do not usually write lab notes on specific programming issues. I try to keep my web site general so many people can understand it. This note is an exception, its a real simple software related issue. Over the years of writing software I keep coming back to DeMorgan’s Theorem. It was one of those things that in college I never thought I would use, but it seems to pop up on a regular basis at work. I think this is fascinating stuff, particularly when academia meets the pavement.

First, the background. DeMorgan’s Theorem states:
.
DeMorgan’s theorem cannot be proved or reduced using math. The only proof is a brute force proof. At this point your probably thinking, "how can this academic theorem prove to be useful at work?" Let me show by example.

This is going to be a real simple contrived example to demonstrate DeMorgan. Suppose the programming job is to read two switch inputs and to turn a motor on if both switches are closed. Perhaps to drive the motor ON we also have to output a LOW. It is common in computer to have negative I/O logic. Here is a schematic for this. We can see that if either switch is closed the input to the computer will go low.

I can now write software to implement the required function.

If ( SW1 = 0) AND ( SW1=0)
THEN MOTOR = 0
ELSE MOTOR =1

Do you see the correlation between this software statement and DeMorgan’s Theorem? Now we can simplify the programming statement using DeMorgan’s. Two simplifications make the statement easier to read. We take advantage of BOOLEAN type's and we can switch around the THEN and ELSE part to get rid of a NOT operator.

If (SW1 OR SW2)
THEN MOTOR =1
ELSE MOTOR =0

An astute programmer might note a further simplification by writing a single algebraic Boolean expression for this statement such as

MOTOR = SW1 OR SW2.

Understanding and using DeMorgan’s Theorem has simplified the programming, if only a little here. In larger applications we would get a larger return on our simplification investment.

Even though many compilers will reduce expressions internally, simplifying your programming pays rewards in understandable code. ALWAYS simplify code and remember to use DeMorgan.

A couple months ago I ran across a circuitry problem that may interest those with a little electronics knowledge. We were getting failures on a high percentage of new product, but not on all of them. The product was warning that its internal -15v supply was out of tolerance (and faulting). A manual check with a voltmeter showed the -15v supply was within the required +/-10% tolerance. Other internal supplies were monitored as well by the computer and they never exhibited this issue. Below is a schematic of the components involved, what I found and the interesting solution.

What this schematic is showing is three resistor divider circuits that divide down the +15, +5v and the -15 volt supplies to feed the A/D converter inputs (there is some additional filtering and protection not shown). This A/D converter can resolve a range of 0v to +3v signal thus the need to divide down the voltages before conversion. Additionally the -15v rail voltage is "translated" to a positive voltage by raising it with the +5V. The code in the computer then reads the A/D converter and looks to see if the value read is out of +/-10% tolerance.

There is a problem though with the -15v divider circuit. Do you see it? The -15v circuit is dependent on the +5v voltage as well. So for instance if the +5v rail is 8% too high (within spec), and the -15v signal is 8% too low (also within spec), the resulting divided/translated voltage may be more than 10% out of whack (this is a highly technical term).  The unit would then erroneously fault. 

I found a simple software change that put this issue to rest. We need to first read the +5 rail voltage.  Then the -15v rail voltage is read and we subtract out the component of +5v rail voltage from the -15v reading.  To do this requires some math and Kirchoff's voltage law. 

V_AD3 = V_+5v - ( V_+5v - V_-15v) R₅ /( R₅ + R₆)

Next we have to solve for V_-15v :

V_-15v = (V_+5v - V_AD3)(R₅ + R₆)/R₅ + V_+5v

I implemented this equation in the firmware of the computer and it worked like a charm!  I implemented it, but did not consider this solution to be optimal. In subsequent designs I made sure we did not use the +5v supply to translate the -15v supply voltage, but for this product this software solution had several benefits:

• Easy fix for units already in field.  No recall.
• No waste for already manufactured inventory.  We can use existing stuffed pcb's.
• We did not need to delay an already delayed product.
• No additional cost for the pcb NRE.

When I am troubleshooting new PCB's I have a unique technique for finding shorts on PCB's.  I actually have to hand the credit for this technique to a business partner, Dr. Ed Kafrissen.  He came up with a few non-traditional ways of doing business, and this is one of them.

So let me set up a scenario for you, and then show you Ed's solution.  Suppose you have a client and you need to deliver 100 PCB's to him/her quickly.  You have someone stuff the boards for you, now you have to verify they work.  One of the first tests we would do is to apply power to the new PCB and bring the voltage up slowly.  If the power supplies load down, then you got a problem to solve.  You got a short on the PCB.

Ed came up with unique solution.  We had this old humongous power supply lying around that was capable of suppling 30v at up to 5 amperes.  This technique only works if the power supply, like ours, has an adjustment to limit the voltage and current.  We would set the voltage to necessary voltage and the current all the way down.  Ed would then hook up the PCB, which immediately loaded down the current limited supply.  He would turn up the current on the supply and feel on the PCB for a hot spot!  Invariably some IC would be stuffed in backwards that our visual inspection did not find, or we would get a PCB which was not completely etched.  In those days we got horrendous PCB's.

Anyway, that was Ed's solution to quickly find shorts on a PCB.  And it worked well as long as you were careful enough to not burn yourself!  Yeow!

I would like to offer a concrete example of simplifying the programming of a product.  Years ago I was privileged to be given the opportunity to realize the programming and design of a home automation controller.  This was the DHC Toscana home automation controller, still being manufactured by Leviton Mfg. Co..  When we first sat down with management, marketing, sales and all the other interested entities at that company I was literally buried in the number of features on this product.  One of the other senior engineers and software guru's there, Dr. Michael Ostrovsky, helped me along and gave me a simple suggestion that cut my project in half!

To understand his suggestion I have to give you a brief technical description of the product.  As you can see from the picture the device has a number of buttons and user interface elements to control lights, fan's, switches and other electrical devices you might find in a home.  It also has a communications interface where it can receive remote commands from other interfaces devices in the home to control the same electrical devices.  Therefore, an engineer might think he had two intertwined overlapping tasks to accomplish.  First would be to control the electrical devices from the unit's front panel and transmit that command to other keypads in the home.  The second task to control those same electrical devices from the commands received over the communications interface.  The contention that could develop from controlling the same devices from several inputs is a classical problem.  Mike suggested a better way.  Mike was old school, Mike was from Russia.  He knew how not to do the same task twice.

 He suggested I split my project into two simpler tasks.  The first was react to one of the front panel switches being pressed and to transmit the appropriate command indicating this on the communications interface.  The second, separate task, was to receive a command over the communications interface and to turn on the light, fan, device or what not.  To complete this scenario I had to let the device receive its' own commands, the one it just sent out!  This way I only had to debug two separate smaller paths, that were more or less independent.

Recently I have been thinking about the projects I have been involved with and what helped them become sucessful.   I think I finally have something to report to you here in my laboratory notes as to MY 1 best secret to sucessful software.

My first thought was to look at the details of programming languages and techniques.  I then thought about on a higher level how the architecture of the software was more important.  Then I figured that even more important than architecture was the project management.  I think I finally have a root cause to successful projects.  Keep the project 'simple.'  Now that word is a relative term.  The exact nature of  'simplifying a project' depends on the skill of the software team.  Second, it does not follow that a simple project produces a simple product.  Read On. 

I have  developed a basis for this claim that this is the 1 most important ingredient to a successful project.  As the number of  requirements in a project grow, the software complexity grows exponentially (albeit this is a simplistic view) as the following chart shows.

The trick is then to define the project in simple terms yet design a dynamite product.  What I want you to think about is where you want to focus your effort:  Eliminating elements from the X axis of the chart above or troubleshooting program paths on the Y axis.

About 2 years ago I did some shopping for a Bluetooth car speaker phone.  I hit upon what I considered the most perfect speaker phone, the Nokia HF-6W.  It cost me over $120, but it was worth it (while it lasted).  It had a powerful 6w speaker and several microphones that tracked the sound source.  It worked great as well.

About a year ago it died.  I assumed it was a 'normal' failure.  I returned the unit to Nokia returns and they sent me a new unit.  This second one failed in the same manner.  Further, after doing a search on the internet I found other people are experiencing the same failure of the Nokia HF-6W and here.  Nokia's warrenty only covers the unit for one year.  This is a design flaw.  Nokia should admit it and do right by their customers.

The way the HF-6W speaker phone fails it that no sound comes from the speaker.  The speaker is dead.  Second, the unit will not reset itself.  When the power button and volume up buttons are pressed simultaneously while the device is off, the unit is suppose to revert to its default state.  The green and red LED's are suppose to blink as well.  I cannot seem to get it to reset.  The unit seems to work otherwise, bluetooth connects, etc. 

Now my wifes unit, unit #3, failed the same way.  Have you stumbled upon my post and are having the same problem?

[UPDATE 02/04/08]
Nokia replaced my HF-6w with their HF-33.  It has a much smaller speaker and no built in retractable phone charger.  The retail price is about 1/2 that of the HF-6w.  I am accepting this replacement under the condition that it simply WORK.

During 1997-1999 period I was working for Philips Consumer Communications. It was a joint venture between Lucent and Philips and we made telephones. We had the sole right to sell phones under the AT&T logo. I had a magnificent apartment on the ocean in Long Branch, NJ. This was at the Sea Verge apartments.

I worked with a great team of firmware engineers. My managers were Ken Kasiske and Trey Weaver. I was on the 'Ocelot' team. We were tasked to make their very first 900Mhz all digital cordless telephone. What a son-of-a-gun this project was. The heart of the project was an 8051 based base-band chip called the Phox by AMD. We took their DECT reference design and modified it for our project. The reference software did not come fully debugged. With a little sweat my team, Grady Brosier, Bassam Chamoun, Ken Bocan and I, got it working! I was the lead on this team, I was in charge of the firmware for the phone base station, Caller ID, and communications stack. I was also the only one with significant prior 8051 experience.

The most interesting thing I remember about this job is that I found the most difficult bug I have ever encountered there in my life. Briefly I will describe what I found. The DECT protocol is an acknowledged protocol between handset and base. The state machine that controls when the transceiver re-transmits or acknowledges was getting into a wrong state. This state was represented by several variables so first we had to recognize this part of the problem. The transceiver would get in this state only intermittently. If you used the phone heavily for 15-20 minutes, it would lock up. We would set breakpoints in the software, but it took forever to reproduce the problem.

Finally, we found how the transceiver state machine could get into this state. Out of tens of thousands of lines of code an interrupt had to occur only between two sequential (tiny) 'C' statements that were setting two semaphore flags. It took us weeks to understand the state machine and weeks to trap this problem. My firmware partner and I were pressing buttons on the phone for hours to reproduce the problem.  Like I said, we finally got the phone working 100% to spec, and on time, with some hard work! The problem had come in on the reference design.

Cindy Price (our project manager) had some challenges to work through toward the end of the project on the hardware front as well. The hardware guys were led by Brian Kim and Paul Newland. Paul came out of Lucent's Bell Labs. The were (are) two of the best engineers I have ever met. I had a lot of respect for them. It seems the hardware guys found that the front end of the radio was being saturated by RF near the 900 Mhz frequency. This was an issue because if the customer lived near a paging tower his cordless telephone would not work. The solution was to include a SAW filter on the front end. A SAW is a narrow band filter.

Then end of this story is that we all got the phone out, but VTech wound up purchasing our division a couple years later. They bought the whole division so they could use the AT&T brand name and logo!

In 1992 my then business partner Ed Kafrissen and myself had the fortune to contract with a company that specializes in ergonomic design, our customer.  One of the things an ergonomic engineer does is collect demographic and population data. So they would know the ideal size for a hand held device to fit in (for example) a typical human hand.  This company worked with Industrial designers and artists to make sketches and mock ups of the products before Ed and I turned them into actual products.  We 'owned' the soft side of the ergonomic design as well.

Below is a design sketch of the "Hand Held Stress Meter".   We turned this into reality for the customer.   It is a biomedical device for collecting biomechanical data.   If you think about the placement of the user interface elements in the sketch, there was some thought that went into it.  For instance the 'volume dial' was where your thumb would land.  Designed by biomechanical engineers for biomechanical engineers.

In 1996, a few years later, I worked for a major Fortune 500 manufacturer.  I arranged a meeting between my engineering department and the Ergonomic design house I had previously worked for.  They had no in-house ergonomic engineers.  This was, is, a LARGE corporation.  I take it as my failure that I was unable to get the attention of the management there and illustrate the value of ergonomics [If you are following these series of laboratory notes you will notice that I am endeavoring to bring my communication skills to a higher level]. 

In subsequent laboratory notebook entries I should illustrate the significance of design.

I am going to steal a little trick I learned from Joel Spolsky and give you a little blog test.  This is a simple fill in the blank.  Designer is to Engineer as Architect is to ____________ .
To see the answer 'magically' appear select the area below with your mouse.

Engineer

Is that a trick question?  Yes Architects and Designers both require Engineering to create their designs.  Of course Architects create building and Designers create products, but they both share the same set of 'tensions' that shape their designs as the picture illustrates.

Some people might take exception with the 'art' element.  I have used art instead of the more specific case of industrial design.  Industrial design has the functionality, cost and ergonomics elements built into it.

Designers are not necessarily engineers, and Engineers are not necessarily designers. 

Creating a programming language for your product requires a knowledge of your customer.  Years ago I had a job designing robots.  Now there are, or were, various languages and systems for programming of the robot to do its assigned task.  Most of those languages at the time required the person doing the robot programming to have computer programming skills. I had a great idea on how to program my robot.  I had just learned about the FORTH language and figured everyone would love to learn FORTH.  I wrote a FORTH interpreter. If you are familiar with FORTH you will know its designed around reverse polish notation.  I quickly found that not many people wanted to learn to program my robot because it required them to learn a language with this mental hurdle that only a few engineers were familiar with.

For my next robot we put in a BASIC interpreter.  BASIC at least was based on regular arithmetic expressions.  We sold quite a few of these motion control systems, but what generated more interest was when we put a GUI front end that looked like a spreadsheet.

You see, much more people are familiar with spreadsheets than programming languages.  It was the only motion controller for a robot at the time that was really easy to program by using a familiar metaphor.  What we did was to filter the technology to a wider audience.

I realized that the GUI I designed into the product had an impact on sales.  Imagine that.

My next project was another automation project aimed at a consumer with no programming experience.  To make the task more difficult the product only had a multi line LCD character display.  After our design team put our heads together we came up with what I think was a novel approach.  The use of Wizards.  Most product with LCD's, that I have seen, use menu's and setting that require the consumer to have some knowledge of where in the menu structure to find a particular setting.  Our concept was to first break down programming into TASKS.  We would have a wizard for each TASK.  Each wizard led the consumer by asking questions until a TASK was programming.   In addition, we created an underlying model that was similar to the existing products in the market.

It wasn't a perfect design, the small LCD was limiting, we were not able to customize the key layout, the consumer was led into fixed tasks, but it was an improvement over the existing products. 

You can always make the consumers programming task easier by limiting consumer choices.  Thats too easy.  You know your successful I think when you don't limit choices, but in fact have many ways to accomplish a task without making your customer think about how to accomplish their task.

Assume a consumer has never seen your product before or read the manual.  The consumer has pre-existing notions about how they might accomplish a task with your product based on their past experiences with other products, even those products that are quite different such as VCR's, iPods, Outlook, automobile cruise controls, ....  If you can determine those most appropriate notion(s) and make your design fit to create a metaphor the consumer might find your product easy to use because they already know what to do. 

A good underlying model, and a GUI metaphor, don't limit choices but expand the consumers uses.

"Meanwhile, scant attention was paid to Friendster's users. Lunt remembers marveling sometime in early 2004 at how Friendster's traffic would mysteriously spike at 2 a.m. Intrigued, he started looking at the site's log. Oh, my God, he thought, everyone is from the Philippines. [...] In fact, more than half the site's traffic was coming from Southeast Asia.

From a business standpoint, the revelation was devastating. Friendster, it turned out, was paying millions of dollars a year to attract eyeballs that were effectively worthless to its advertisers. Says Abrams: "We needed to make a tough decision"--either spin off the Asian business or become the No. 1 Filipino social network."

"Unbeknownst to Abrams, Sassa, and Friendster's investors, demand for social networking was changing. The lure of Friendster--and, to a much greater extent, MySpace--was not the elegant web of connections but rather the opportunity to gawk at strangers. Rather than using Friendster to make dates, most of its users were simply cruising around and looking at the weird interests, pictures, and blog-droppings of strangers (including so-called "fakester" profiles of Jesus and Burt Reynolds). Real-life connections, the core of Abrams's vision, were not quite as relevant as he'd imagined. Thus, the free-spirited MySpace,... took off. The site surpassed Friendster by the end of 2004 after only a year in business. A mere nine months later, it would be clocking 22 million unique users per month in the U.S., compared with 1.1 million for Friendster."

There seems to be two ways (at least) to innovate.  I will let you decide which way makes more sense from a business standpoint.   I will not try to influence which way you feel is the better path to innovation.  The first way I call the 'propeller head' way.

In the propeller head method we look for interesting technology.  We then develop new products and ideas from these technologies.  Perhaps we apply these new technologies to existing products.  Once we find interesting applications of the technology we design products or demonstration systems using these technologies.  Products are designed for manufacture and prototypes are made.  Pricing is determined by the Cost of Finished Goods using standard markups.  Marketing creates sales material, and salesmen push the product onto the customers and sales channels.

The Apple I was developed using this method.

The second method I call the 'I just want to make money and I am not sure I really know what my customer wants' approach.  What enables this path is a desire to please and delight your customer.  In this method you first define what your companies and staff strong points are.  You next look at your customer and how they make their purchasing decisions.  You look to see how they are accomplishing their tasks.  You look to see how they are using your existing products.  You look for opportunities with the customers.  You look for new customers.  You look at your competitions customers.  You define your sales channels and explore new ways to distribute merchandise.  You haven't designed anything yet, but at this point you may start getting some ideas of where you could be going.  Before you even start to design you define what the price of the product will be and what the total sales will be.  At this point you can decide if and how you might protect the product with patents or trade secrets. To create patents you know what are the existing IP.   Finally, with this information in hand, you then can then start to define how the product might be implemented and all the drawings and paperwork required to make it.  You can make suggestions on technological improvements and cost reductions because now you have defined your customer.

Do you know who your customer is? ...And how well?

Finally, I want to add, the "I just want to make money..." approach does not have to be some big marketing program.  It could be as simple as watching the step's that production goes through in burning in your existing products.  That might lead to changes in how the firmware boots up.  That is a worthwhile task.

[Interviewer] The biggest ones, not very much.

[Rich Templeton] The fact is, if it's a point or a point and a half, that's very little. And so when people sit back and ask why there isn't anything new, it ought to be an obvious answer. The PC companies aren't investing. When I say I think it's wonderful that there are companies like Apple (AAPL) investing in R&D, improving the user interface, new features, [and] companies like Nokia, Ericsson, Motorola all working on R&D, that's all good stuff because when those people are doing that, it's going to lead to new ideas and growth. And the last time I checked, chip companies can't grow if the people they sell to are not growing accordingly.

[And engineers can't grow if their companies are not growing. - Damon ]

• Forty-four percent of these households say they are not interested in anything on the Internet.
• Twenty two percent say they cannot afford a computer or the cost of Internet service.
• Seventeen percent said "I'm not sure how to use the Internet".
• Fourteen percent gave the response "I do all my e-commerce shopping and YouTube-watching at work".
• Three percent said the Internet doesn't reach their homes.

This is an important point I believe for an engineer to understand.  Follow me on this and don't laugh.  I believe the questions are sometimes more important than the answers. 

Sometimes the answer flows, or can be deduced from, the question.  Sometimes it's the question that is the real 'eureka' moment.

Suppose for example you manufacture a device that is dangerous if people or animals touch it.  A real eureka moment might be when you ask the question "How do I protect people from touching it if when they touch it its' too late (they get shocked or worse)?"

Now ask any engineer that question and they may come up with many solutions.  For instance, proximity detectors or motion detectors.  Or how about detecting disturbances in the electric field?  There are now $1 chips to do this.  These solutions are non-contact methods to detect the presence of people or object before they become an issue.

Now consider you are a manufacturer and implement this solution in your next product.  What happens next?  If it's successful then all your competitors follow suit.   They now also recognize the question.

This is a case of where the question is more valuable than the answer.  Unfortunately the US patent office does not allow protection of the question, only the answers, and that's a whole 'nuther story and a whole 'nuther future laboratory note entry here on damon4.com.

A Company may have may marketing channels for its customer.  This is part of the companies supply chain, and your customers are within these channels.

This week I attended the CES show.  I have been thinking of what type of lab note I should enter here when luck landed right in my lap.  Luck has been good to me here in Vegas. By coincidence I had dinner tonight at the Japanese restaurant at the MGM and seated next to me at the sushi bar was an executive from Warner Brothers (a division of Time Warner).  We talked about CES.  Warner Brothers debuted at the show a dual format HD-DVD and Blue-Ray disk.  On one side is the Blue-Ray format and on the other side is HD-DVD!  Many of the other studios and retailers are VERY interested in the format .... EVERYONE ELSE (the electronics manufacturers) is upset at them!

Let me explain why.

Think about who wins.  First you need to know that Warner Brothers has a patent on this new disk format. The rest of the industry is about split on support of the two formats.  Both sides (Toshiba camp and Sony camp) have poured tons of money into winning.  In one fell swoop Warner Brothers has made both formats a commodity.  It does not matter which player the consumer purchases.  The consumer can, and will, purchase the cheaper player if the disk will play on either one!  Think about poor LG electronics who spent a ton of money to develop and launch at CES a dual format player which will retail for $1200.  There is no need for the consumer to purchase that now.

This dual format disk has gotten support from the major retailers (Circuit City, Best Buy, Amazon..) and some of the other major studios.  In addition Warner Brothers is claiming they can also include standard format DVD on the same disk sometime in the future.  It looks like they certainly have shifted the momentum toward their direction and the ensuing royalties.

Oh, one prediction before I end this.  Expect much negative PR about this new dual format disk from both the HD-DVD and Blue-Ray consortium's. They got a lot to lose.

[Update 1/17 - I have found out the actual recording mechanism is more sophisticated than one format on each side.  The formats are actually laid on top of each other in different depth layers. I was probably getting a novices description but it's irrelevant to the point of this lab note.]