Please see tracker issue 157 for the beggining of the story.
I think that there is definitely a PPM encoder problem.
I thought at first that my APM board was faultly. Chris kindly sent me a replacement board, a 1280 board instead of the original 2560. After connecting it, loading the latest firmware, radio setup and so on, i did again some tests.
After playing with the throttle stick, all was ok. suddenly after a couple minutes, i loose CH3 input again.
I lost it when i was pushing the transmitter stick quite fast to the max. Motors outputs stayed at a quite low RPM and no more possibility to change it.
After checking, my receiver output 3 was perfectly normal. Going to CLI radio test, i had no more Ch3 input.
Scope analysis have shown that when the problem exhibit :
1) the receiver CH3 output is always ok
2) the ppm encoder output is missing output CH3.
After resetting only the PPM encoder AVR chip, i get back CH3 input.
Conclusion :
I think that there is definitely a problem with the PPM encoder. Certainly a software problem.
For those tests, i've used an USB isolator to be sure that there was no ground loop between the computer and the board.
The board was powered by a Castle creation BEC, at 5.1 V.
The reason of this malfunction is quite obscur, perhaps a variable overrun in the ppm encoder ?
If this occur during fly, this is assured crash.
Replies
I did a few more tests, this time i was using a 4.8V NiMh batery instead of the switching BEC.
No more loosing Ch3. I thought that the switching BEC was the cause of the problem. But after about 8 minutes, i did loose Ch4 (YAW) input.
Switching to CLI, no more CH4 input...
There is definitively a PPM encoder problem.
My assumption is that there is a PWM aliasing problem, producing a variable overrun somewhere in the PPM encoder code. It seems that each time the problem occur, it is when i push a stick quite fast.
I remember that i had lost Ch1 and Ch2 as well, quite rarely, because i'm mostly making ESC and motors tests since the beginning mainly with Ch3 stick. This prouve that the problem does not come from an AVR input dead or bad solder on the board.
I think that only debug mode on the PPM encoder can show where is exactly the problem, using a JTAG probe.
Rarely, only a couple times, i have seen the PPM encoder unlock by himself, but most of the time when a lock occur on a Channel, only a PPM encoder reboot does solve the problem.
Could someone used to the PPM encoder code verify that all variables are limited, and no possibility to have divide by zero or weird things like this in the code ?