DeweyAXD said:
If you think of CPU ram for a moment... they print it all in mass at a certain spec, then they test it for speed... what speed each set tests at dictates what clock speed it is sold as. Personally I don't think this is the main problem for flyaways (just my opioin) but if they are selling 20000 Phantom units a month as they are right now (let alone standalone NAZA's), there is always going to be a percentage of bad eggs in the nest... just simple chaos theory! :mrgreen:
Silicon chips may hit conditions that they weren't designed for, ie extreme thermals but clock speeds for chips like CPU's, GPU's, memory are all set with margin built-in. They test these things in special thermal clamps/chambers where they artificially force the temperature to maximum operating temp, eg. 95'C, then run the most intensive memory or other virus type apps to push the silicon to its limits and then sweep through the frequencies until it starts failing. They then build in some amount of margin and set that as the frequency for the silicon. There are also all types of other scans and sorting that happens on the wafers and on the chips to bin them based on leakage etc. Anyways.. none of this is relevant to the discussion other than to state that these things aren't arbitrarily set with the expectation that some percentage will fail in the field. Bad chips are discarded up-front. That's not to say that chips don't fail in the field, but if you get even 0.1% failure in the field, you have a big and costly problem. Hopefully we can all agree that it's HIGHLY unlikely that fly-aways are caused due to chip failure.
marcus_canada said:
That's actually my contention

ArshadR is talking about chinks in the programming which he wants to take a look and fix.
I say that sometimes hardware freaks out, you can't program around that, how can you ?
Hardware shouldn't ever randomly "freak out" . Not only can you design SW and FW to deal with all manner of failures, it's actually best practice to make sure you implement this type of failsafe in the code. When you encounter intermittent failures, it's not uncommon to trace this back to poorly written code that does not have the hooks to handle these unforeseen scenarios.
Anyhow, going back to my original point, there could certainly be bugs in the silicon or (more likely) in the firmware which could cause problems. These problems could also manifest themselves in very rare situations due to interference from external signals, spurious interrupts, race conditions, etc. I'm not claiming that there are indeed problems with the firmware or that I am qualified to find and fix them but I do have 30+ years experience in the field and might be able to provide some insight.
My contention is that it's plausible that fly-aways are caused because the NAZA thinks it's either getting an RF command when it's not or it's going to failsafe and heading off in a direction that is not the home point. Both can be due to bugs in the FW.
Anyhow, I think we've beaten this one to death. If I do make any headway on this, I'll update the thread.