Rest In Peace Bob Pease

Does the Universe have a sense of irony? Sadly it seems so. Another analog legend Bob Pease died in a car crash while returning from Jim Williams private memorial service.

What is even more ironic is that Bob wrote the book How to Drive into Accidents - And How Not to, and he was not wearing his seat-belt!

To me not wearing a seat-belt is simply incomprehensible. There is no rational argument that you can come up with to justify not wearing one. Buckle Up!

I had the pleasure of meeting Bob in Cleveland at one of his seminars. We struck up a conversation on 'Floobydust' of all things...

Floobydust is a contemporary term derived from archaic Latin miscellaneous, whose disputed history probably springs from Greek origins (influenced, of course, by Egyptian linguists) -- meaning here "a mixed bag." -- National Semiconductor Audio Handbook, 1976 Corporation.

Rest In Peace Jim Williams

This week has been a sad one for anyone doing analog design. Jim Williams of Linear Technology died suddenly and unexpectedly from a stroke on June 12th. More on Jim here.

Jim is survived by his wife Siu and son Michael. His family requests that donations in Jim's memory be made to The Parkinson's Institute, 675 Almanor Avenue, Sunnyvale, CA 94085.

Archive of Jim's analog design collected writings can be found here and here. After reading those you will understand why we have lost the best among us.

I once had my own Jim Williams encounter, back at the height of the Dot Com Bubble around 1998, when I was writing Circuit Cellar Online Resource Pages. Out of the blue Jim called me up to tell me that I was miss applying his LT1088 (Yes it was his design, that he had to convince LT to make it), RMS wave form to Heat converter. We had a lengthy discussion on how to measure esoteric wave forms from even more esoteric sources (always work with First Principles if you can, like heat in the LT1088).

We never know when our own number is going to come up. Find an industry that lets you spend more time with your family and less time at work...

Will Cold Fusion or the solar powered bikini, the iKini, power your next embedded system?

The term 'Cold Fusion' has lots of baggage with it today, so most of the research takes place under the term Low Energy Nuclear Reactions or Chemically Assisted Nuclear Reaction, or simply LENR-CANR.

A summary of Andrea A. Rossi's Cold Fusion Generator has been put together by Sterling D. Allan and Hank Mills.  Nickel and Hydrogen in the presence of proprietary catalyst under pressure  are claimed to produce 15,000 thermal Watts output with 400 thermal Watts input.  There have been independent tests to confirm numbers like this.

From what I've gathered a company operating under the name AmpEnergo is going to distribute Rossi's technology in the Americas.  There are a couple of different web sites calming to be AmpEnergo's and it is not clear to me which one is the legitimate one.  From an official document issued by the Ohio Secretary of State, Jennifer Brunner, AmpEnergo is apparently registered to operate in Ohio.

A lot more details can be found in the "April 2011, updated May 2011" LENR-CANR News.  Decide for yourself if this technology looks 'real'.

I have little background in chemistry, other than what I've learned related to batteries, however to me Rossi's stuff looks more like a thermogenic compound, than 'Cold Fusion'.  That is, a compound that generates heat.  In Harold King's novel, that I've mentioned before,  Red Alert a couple of different thermogenic compounds are used.  One based on Aluminum powder and one based on Iron powder.  A line from the book: "How do you know the big one [the Iron based one] has not gone off yet?  Because we are still here!"...


If 'Cold Fusion' is not 'hot' enough for you then maybe this hot little number by Andrew Schneider will be.  He has created something that might power your next Embedded System. A solar bikini, known as the iKini. Your imagination might come up with some interesting tests for the system model.  Not sure what more I could possibly say about this here?  I do hope he is better at hardware design than web design as neither of his web sites rendered correctly in any browser I tried.

Myself if I was doing a practical solar design I'd use some  Ixys IXOLAR^TM High Efficiency Solar Cells that can be handled by normal pick-and-place equipment.  They can be gotten from Mouser.  The cells would be followed up with a Maximum Power Point Tracker from either ST, SPV1040, or the Linear Tech LT3652 chip or LTM8062  μModule.

A good friend of mine, the late John Draper, had a patent 4,651,080 "High Efficienty Battery Charging System"; March 17, 1987, that put solar cells in a unique series-parallel combination to match the inherent impedance of a Lead Acid cell.  If any one is interested I'll post the internal test documents of SylCell, the company that was going to promote this technology before John's untimely death.  Tests showed large increases in charging efficiency.

Software Quality and Software Costs by Capers Jones

"An occupation where failures and disasters are the top cost drivers is not a true engineering discipline.  To become a true engineering discipline, software engineering needs better quality control, better quality measures, and better economic analysis than current norms." - Capers Jones in ASQ/SQP June 2011.

This month's (June/2011) issue of the American Society for Quality's Software Quality Journal, has a 'Must Read' article, "Software Quality and Software Costs" by Capers Jones where he explores the application of two metrics frameworks - software cost of quality and software defect containment. Both to model and manage the cost and quality consequences of poor requirements and spending time on debugging, instead of not putting the bugs in the first place.


Some ASQ/SQP articles are member only, and a few are available with a free registration.  Some articles such as the one we are discussing here are made available as PDF's under 'Open Access'.  The system may ask you to register with a name and email address, then you may be directed to a page saying you must purchase the article.  However if you click the link again, the article should open due to it being an Open Access article.


Jone's metrics are based on the International Function Point Users Group (IFPUG).  Using Function Points allows for measuring defects across different languages, and in requirement documents where measurements of "Lines of Code" are useless.


To summarize: The Bad, and alas the typical development process today:

• Either inadequate estimation or the arbitrary rejection of accurate estimates by clients who then imposed unachievable schedules; [Clients refusal to listen to accurate estimates on development time, usually being driven by an unmovable trade show deadline].
• Inadequate status tracking by management that concealed problems until too late to recover.
• Poor change control combined with creeping requirements in excess of 1 percent growth per calendar month; [The Creeping Feature Creature is a powerful task master, as late addition requirements contain more bugs].
• Poor quality control.
• Testing alone is not very efficient in finding bugs.  Less that 35% effective.

The good, that is proper project planing and management (Always make a case from the point of the bottom line to get the attention of the Bean Counters):

• The high-quality project schedules will be shorter by about 15 percent.
• Software Quality and Software Costs in defect removal efficiency will cost about 20 percent less to develop than identical projects with poor quality.
• Cumulative Total Cost of Ownership of high-quality applications from the start of the first release through five years of maintenance and enhancement will be about 30 percent lower than identical projects with poor quality.
• Annual maintenance costs will be lower by about 40 percent.
• For large applications, high quality levels will minimize the chances of failure.
• High-quality applications tend to have quicker testing schedules and hence quicker overall schedules.
• The economic value of excellent quality is directly proportional to application size. The larger the software application, the more valuable quality becomes.

"No true engineering discipline should have defect repairs and canceled projects as the two top cost drivers.  For software engineering to become a true engineering discipline, quality control will have to be much better than it is in 2011."