You're telling me that for 3 months nobody noticed that the system "occaisionally crashed" only during a thunderstorm? And nobody noticed a link between "thunderstorm" and "electrical interference" ? There are only two possible explanations for this:
1) Your software guys were pure software, with no knowledge of hardware (not credible) or
2) that your installation (like the PDP-11/VAX computer rooms I worked in when I wore a uniform) were situated underground.
As amazing as it sounds that they couldn't see the connection between a thunderstorm and a system crash...those software guys simply could not think outside of the box. They were so busy defending the performance of the system that they couldn't see the obvious. Sometimes people get tunnel vision and need someone from the outside to point things out.
I read somewhere that Florida is the most lightning-active area in the USA. I suppose one can get used to anything... And apparently the computer crash didn't happen with every thunder crash, so it's understandable why the software guys didn't catch it as being a hardware problem.
Nancy you made me think more about the problem. What's not said is that the data transmission often had errors caused by the lightning and CRC testing would catch them. Also I would guesstimate there could be over thousand hits a day ( a "single" bolt of lightning probably created multiple data hits). At 1ms per data packet there were almost 100 million packets/day so a 1000 packets a day being thrown out was not a flag of concern but an indication the system was working correctly.
With a 100 nS window of opportunity in a 1 ms time window that suggest probably only 1 out of 10000 hits could corrupt the CRC protection (note the lightning had to hit only the last 100 ns not before; if it hit before it would be detected and thrown out by the CRC detection). That in turn suggests that only once every 10 to 100 days there would be a crash. As I recall a three week interval between crashes was an interval was once spoken too. Also Florida was considered the lightning capital of the world (Congo beats them out) with Tampa recording 21,000 cloud-to-ground (Ju 93); cloud-to-cloud probably affected our system too. For a perspective a bolt of lightning can exceed 50 KA and have rates of change of 40 KA/s. The source voltage behind this gets very high.
It was a hardware function that was not implimented correctly. I suspected the person who designed the circuit did the test verification that showed it worked correctly (:|) repeating a conceptual error. The system had been well tested in CA without many problems.
The system design spec was good and in this respect if it had been met there would not have been a problem. The spec specified the digital data receiver inhibit the data input during the interrupt interval. The hardware implimentation somehow missed doing what was specified although I believe the designer thought he/she? had met the reguirement.
Truchard will be presented the award at the 2014 Golden Mousetrap Awards ceremony during the co-located events Pacific Design & Manufacturing, MD&M West, WestPack, PLASTEC West, Electronics West, ATX West, and AeroCon.
In a bid to boost the viability of lithium-based electric car batteries, a team at Lawrence Berkeley National Laboratory has developed a chemistry that could possibly double an EV’s driving range while cutting its battery cost in half.
For industrial control applications, or even a simple assembly line, that machine can go almost 24/7 without a break. But what happens when the task is a little more complex? That’s where the “smart” machine would come in. The smart machine is one that has some simple (or complex in some cases) processing capability to be able to adapt to changing conditions. Such machines are suited for a host of applications, including automotive, aerospace, defense, medical, computers and electronics, telecommunications, consumer goods, and so on. This discussion will examine what’s possible with smart machines, and what tradeoffs need to be made to implement such a solution.