Electromagnetic Energy Grand Challenge. Mr. Fusion has not been invented yet to replace your battery, maybe soon?

Almost daily I have to tell people that Mr. Fusion has not been invented yet, as people add massive displays, GPS modules, 1W radios, to a product that never increases in size nor gets a larger battery to run all of these new features.

Jeane Manning, author of several books in the area of Free Energy,  has posted on her blog an open letter from Dr Fred B. Wood; Dr. Wood is formerly Adjunct Professor, Georgetown University Communications, Culture, and Technology Program; Senior Associate, US Congressional Office of Technology Assessment; and Research Scientist, The George Washington University Program of Policy Studies in Science and Technology.

Dr. Wood's letter to the White House cites some of the pioneering works by people that are virtually forgotten and unknown today, in the hopes of convincing 'Them' to spend our tax dollars on Electromagnetic Energy Research.

To  one of the points in Dr. Wood's letter, always be suspect when someone cites Bearden. His older works, say before 1983, are worth a read, few of which are on the Web. Don't waste your time on the stuff after that.

I'd also add James H. Rogers work to the 'Grand Challenge' list of things to investigate. Rogers work is known by a few other names and related research such as the Aharanov-Bohm Effect (Physics), Poynting Vector (Mathematics), Scalar Waves (Pseudoscience). The differences comes down to issues of geometry but I've not got my head wrapped around all of that yet.

Finally note that "Cold Fusion" has never died, it has only been renamed.

Let me know where to pick up my new Mr. Fusion please...

How not to save I/O pins at the expense of safety: "There ain't no more up!"

Picture Kentucky Coal Miner on the phone, with thick Kentucky accent, to the maker of their Man-Hoist ("Coal Miner" for open air elevator, beats any Amusement Park ride, only next to the 'Man-Trips', the Roller-Coaster like ride that takes you into the Mine, where you may lose your head at any moment).

"Our Hoist only goes up. We've run out of cable, it is all on the spool. There ain't no more up!"

I'm sure you have experienced the frustration of needing just one more pin on your Micro. Here is why you don't let the Boss force you into take shortcuts to increase company profits today, only to be lost ten fold next month.

Seems the Hoist designers used two inputs one for Run/Stop and one for Up/Down. Up/Down faulted to 'Up', no mater what you wanted it to do, you only went up.

They should have used four inputs, Run,Stop,Up,Down. Up and Down together, or the absence of both would indicate a fault which could be dealt with before jamming up the machinery.

The morale of this design tip: Don't take short cuts, people ultimately pay the price. Warrant Repairs are expensive when you have to travel to the mine.

Exercise and Computer Use May Prevent Mild Cognitive Impairment

A new Mayo Clinic study, Exercise and Computer Use May Prevent Mild Cognitive Impairment, found that physical exercise and computer use may help protect against mild cognitive impairment, a disorder of the brain that affects nerve cells involved in thinking abilities. So if you are stuck trying to solve a programming problem, get up and move!

In the area of Cognitive Impairment is something I also want to mention: Pernicious Anemia.

Pernicious Anemia comes about due to the lack of the Vitamin B12. Mostly in the Elderly whom can no longer absorbed it, and have used up their store of B12. Strict Vegetarians or Vegans are also prone to not getting proper amounts of B12. Programmers living on Junk Food come to mind here as well. In a paper I read some years ago, it said that fifty percent of people diagnosed with at least mild Alzheimer's Disease were in fact suffering from B12 deficiency. Give them a B12 shot or two and they became 'normal'. Who defines 'normal' is a debate for different blog...

Also I've covered a couple of other Computer/Health related items in the past:

• Long hours link to dementia risk.
• Computer Programming is an unhealthy career.

Medical Device Software Safety, Validation, Verification and Effectiveness. Wednesday, August 4, 2010 : 2:00 PM to 3:50 PM

Carolyn Carroll of Stat Tech Inc. will be presenting Medical Device Software Safety, Validation, Verification and Effectiveness on Wednesday, August 4, 2010 : 2:00 PM to 3:50 PM, at the 2010 Joint Statistical Meeting. Held July 31-August 5, 2010, at the Vancouver Convention Centre, located at 1055 Canada Place, Vancouver, BC, V6C 0C3, Canada.

"JSM (the Joint Statistical Meetings) is the largest gathering of statisticians held in North America. It is held jointly with the American Statistical Association, the International Biometric Society (ENAR and WNAR), the Institute of Mathematical Statistics, the Statistical Society of Canada, and the International Chinese Statistical Association, and the International Indian Statistical Association."

Abstract:

"Software either in medical devices or used to design, manufacture or test devices must be verified and validated. The process of specifying, designing, developing, testing, verifying and validating software are inter-related processes. A bad job of requirements specification leads to problems in the entire development cycle and makes thorough testing difficult if not impossible."

"Validation techniques commonly employed in software development environments involve static methods such as design reviews and inspections and dynamic techniques such as scenario based testing. Unfortunately, these methods rely on clear and correct requirements specification and good software development techniques. They are also difficult and time consuming to implement. When newer devices with adaptive functioning are implemented validation will become still more complicated."

Crossing Power Domains to Reduce Sleep Current. Why didn't you hook up the A/D power pin?

Them: "I can't get my sleep current below 50 uA."

Me, while looking at their schematic: "Why is there no connection to the AVcc pin on the micro?"

"I was not using the A/D, so I did not hook it up, to save power. I have it turned off in my software."

"What does that do to the part internally? Doesn't that make a lot of odd impedances and sneak-paths? The data sheet says AVcc must be with 0.3V of Vcc."

"I don't know. [Shrugs.]"

A board revision later...

Them: "To get the sleep current down to nothing, I added this NAND Set/Reset Flip-Flop driving the regulator's Enable input, but it is not working."

Me: "What does 'not working' mean? [Don't you just hate it when people are vague with problems?]"

Them: "Regulator shuts down, but then the system boots up again right away."

Me, while looking at their schematic: "You have the Set input of your Flip-Flop hooked up to one of the Micro's pins?"

"I have that pin programmed as an input. I use the button to change the menu after the unit turns on."

"You are turning the power to the Micro on when you drive that pin low."

"Yes, that is what I want it to do."

"What happens to the impedance of your input pin on the Micro when you remove the Micro power?"

"I don't know. [Shrugs.]"

The high impedance input is no longer high when power is removed.

Moral of the stories: Always hook up all of the ground and power pins, as the data sheet tells you to hook them up. Even if you are not using a function block of the part. Don't create feed back paths from unpowered pins. It is impossible to know what kind of impedance an unpowered circuit is going to present to the powered section of the circuit.

The other thing to be on the look out is feeding power to an I/O pin on a device that has no power, or feeding a voltage that is higher than the Vcc voltage. At best this wastes power, at worse parts are destroyed.

Analog Devices has a related application note that you should read if you are interested in saving power by turning things off: Protecting Off-Amps by John Ardizzoni.

Update on IEC 60730 Self-Tets. Added Microchip

I updated my previous post on IEC 60730 Power Up Self-Tests, to add Microchip to the list of vendors supplying IEC 60730 compatible libraries.

Evaluating Software's Impact on System and System of Systems Reliability from SEI at CMU

Carnegie Mellon University Software Engineering Institute (SEI) has published a new White Paper: Evaluating Software's Impact on System and System of Systems Reliability by John B. Goodenough.

Alas I have to say the title is more impressive than the paper itself. I'd sum up the paper as saying "We need to define our terms to Contractors and Sub-Contractors when we talk about software to them".

There is one paragraph in the paper that I do think is particularly important:

"Hardware engineers typically think that software failures are deterministic because certain inputs or uses can reliably cause a failure. But although all software failures are deterministic in the sense that they occur every time certain conditions are met, the likelihood of the conditions being met becomes, eventually, a function of usage patterns and history, neither of which are deterministic. In effect, after egregious software faults have been removed, failure occurrences become non-deterministic. In fact, certain types of software failure are inherently non-deterministic because they depend on more knowledge of program state than is typically available. For example, failures due to race conditions and memory leaks typically depend on usage history and, for race conditions, subtle details of system state. Although these are removable design deficiencies, their occurrence appears to be random (although typically the frequency of such failures increases as the load on the software system increases). In short, it is not unreasonable to think of software failures as eventually mimicking hardware behavior in their seemingly non-deterministic occurrence."

The above describes why it can be so hard to write correct software, and even harder to test it. "Perfect Software" is something that only exists in theory.

Maybe a particular bug only manifests when the non-deterministic timing of the application has interrupts nested three or four levels deep (Some Atmel and Zilog parts let you do this), while turning on the radio, turning on the left turn signal and pressing on the brake simultaneously, and the unit has been running continuously for over 18 hours and 12 minutes, during a ESD event...

Software Bug or Electrostatic Discharge? Maybe the humidity was to high for the Cat for a good test?

Have you ever had a field report of a problem with a product that makes no sense, and is impossible to reproduce?

This type of problem falls into the class of problems known as Single Event Upset. SEU incidents can be caused by energetic Cosmic Rays, which I've seen people use as a excuse for their buggy software unfortunately. If you are designing equipment for operation *in* outer-space or near other ionizing radiation sources this is a real problems that needs dealt with, here on Earth not so much. However today's shrinking geometries are increasing the levels of susceptibility.

What is a real everyday problem that does not get addressed enough is "Static Electricity". The chain of custody from raw components to a finished product in the customers hands must consider the issue of Electrostatic Discharge (ESD) for the entire life cycle of a product.

If at all possible visit the contractor assembler or supplier of your hardware, with a critical eye to their handling and storage of boards during the entire assembly process.

What is important to understand is that ESD mitigation during building of a product is about culture and training, it is not about the parts and the assemblies.

What you should see:

• Any person that has contact with components or assemblies is wearing static dissipative smocks, and heal straps.
• Any person working at a bench working with an assembly is wearing a wrist strap. The exception being working with High Voltage or non-isolated line power supplies for personnel safety.
• Wrist-strap testers and a daily log of them being tested. Test at each shift change.
• All board assemblies are being held in appropriate static dissipative containers.
• Board assemblies are not touching each other. This can cause ESD as well as mechanical damage.
• Static dissipative chairs and floor mats.
• Static dissipative coatings on the floor, and logs of application of the coatings.
• In a design lab, a Electrostatic Gun, to create repeatable ESD events.

What you should not see:

• Inappropriate clothing like Wool Sweaters.
• Inappropriate furniture.
• Boards piled on top of each other.
• Boards being transported in cardboard trays.
• Boards being transported on Teflon coated cookie sheets, in the assumption that is an improvement over cardboard.
• Large number of random failures or reports from the floor of "bad parts".
• Large number of random failures in warranty repairs; indicative of latent ESD damage.
• Few wrist straps. No sign of wrist strap replacements.
• No wrist strap testers.
• Cats. Rubbing a Cat to make static is not a replacement for a Electrostatic Gun.

ESD really does effect the bottom line, so make a case from the bottom line point of view. If you'd like something that you can inflict on Management to try to get them to change the ESD culture, start with chapter seven from the US Air Force Directive General Shop Practice Requirements for the Repair, Maintenance, and Test of Electrical Equipment.

For more in-depth treatise of the subject start with the six part series from the Electrostatic Discharge Association:

ESD Fundamentals:

• Part One--An Introduction to ESD.
• Part Two--Principles of ESD Control.
• Part Three--Basic ESD Control Procedures and Materials.
• Part Four--Training and Auditing.
• Part Five--Device Sensitivity and Testing.
• Part Six--ESD Standards.

Keep in mind that a 25 Volt ESD event to our nano-sized components might be the equivalent of a large Oak Tree getting hit by Lightning at our Human level scale...