I have started this dedicated thread at the suggestion of another contributor.
This issue has was raised on the main 'Arducopter 2.8 / 2.8.1 released' thread and can be viewed here.
I'm still puzzled by this twitching, however look at the latest log from today and in a little more detail I can see a very small change in the THR IN trace which appears to be directly connected at the time all the motors twitch (see below).
Is the THR IN trace taken straight from the Rx ?
Not only have I done the things as detailed in the main thread, but I have also:
Grounded the aircraft (in case of interference)
Repositioned Rx to top stack
Reprogrammed all ESC
I have attached the latest log.
Would dropping the ESC Update Speed in MP from 490 - 400hz help ?
Any suggestions would be appriciated, in the mean time i am trying to get hold of a duplicate Rx. Any chance it could be the APM ?
Can you post a log and screen shot of your spikes as I have done please Mike.
Although its a problem, I'm glad I am not alone and it is now being looked into :-)
Thanks Helitrasher, although I am running the latest firmware (version 5) on my T8FG.
Have you tryed the capaciter on one of the RX channels ?
I did try this but the more efficient is a small inductor you put in serie on the signal line before to enter in the APM.
You can use a 4.7 mH (milliHenry) value. Those components are like 1/2 watt inline body resistors. Then the internal AVR pull-hi resistor will form an efficient low pass filter.
Using a capacitor in parallel between ground and signal line can have only a very small effect if the source impedance is low.
You can try to put such an inductor on all channels, or only on ch3 and see if it helps. Could be a momentary fix before to go deeper.
You could try as well opto isolation if someone can lend a 8 channels isolator to you.
Here are 3 traces from 3 tuning flights yesterday.
It seems the twitching for Futaba radios have been elevated by the developers - great and thanks!
I only have the twitching in the air - which has been some expensive and the winter in Norway will give me slow testing speed if I should contribute in this problem.
Since you see the twitching on the bench - would you accept my offer to send you a FrSky DIY module and receiver for testing? Or I could send you a Hitec Eclipse7 with a 35 module or an assan 2.4 module which I am not eager to have returned back :-) I will do a test first of course.
The 617's CH6 signal starts at the same time as its CH1 signal. The probably confuses the PPM encoder of APM. It is known to be notoriously hard to encode several PWM signals with unknown mutual phases back to a single PPM signal.
Actually it is better not to split and reassemble the signal at all - by using a receiver with a PPM output.
I use the FrSky TFR4. It's an 8 channel RX with only 4 PWM connectors on it. When shorting out 2 of these with a jumper, the remaining 2 will be PPM and RSSI. Perfect for the APM.
According to some detective work, the R6208SB Rx only could be the root of the problem.
We need now to find why this receiver exhibit glitches with the APM. I'm interested to know if you have some enhancements with parallel caps (around 10 nF), serial inductors (4.7 mH) or opto isolators.
But i'm afraid we'll need to wait that someone in our team will be able to check those receiver outputs to get the root cause of the problem.
One of our developer is using similar Futaba 9C & TM-8 TX but with a different receiver and it's working flawlessly.
Only the receiver is different compared to Mike Boland setup.
That is quite strange because ArduPPM has been designed to manage this correctly.
For example it is able to perfectly encode Multiplex / Hitec FM receivers PWM signals where we have this kind of simultaneous fronts on different channels.
I'm afraid we need to check what's going on with a scope on real hardware.