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 ?
ArduPPM should be able to encode even aynchronous signals, or signals with simultaneous fronts.
I have a multicopter where i have two different receivers connected, asynchronous (two different unlinked transmitters), and ArduPPM can encode that flawlessly.
So if we have glitches with some FAAST receivers, i suspect something quite uncommon in their output to get this effect.
Anyway this need to be checked in the lab with the same hardware.
Having looked at your logs (2012-10-23 17-32 1.log), although you seem to have an issue on your throttle in trace, the other PITCH IN, ROLL IN and YAW IN seem fine where as I'm seeing the spikes across all channels.
Its also good you have the same Tx / Rx combo as me.
I noticed in one of the other threads you changed your PPM firmware back to APM 2.x PPM Firmware v2.2.65, is that still the case ?
Your offers are very kind indeed Arild, thank you.
For the time being I would like to see what the developers can do. I don't really want to take my brand new (and expensive) T8FG apart and swap modules quite yet.
I'd like to keep my current setup as ultimately it could be used to test any new software releases.
I'm so keen to get flying :-)
No need for opening your brand new T8FG :-)
I thought of making an arrangement which you only plug the FrSky module into the trainerport on the back. This would automaticly disable the internal FASST module.
Opening my T8FG was a good thing as the FASST module did not work and hanging the FrSky module outside is not a permanent solution. If you change your mind send me a pm.
Interessting thoughts from the devs here.
Just a shot in the dark (as I am in the dark as to how Serial Bus is implemented and integrated into the Rx's) but the RX's I am using are also Serial Bus Rx's.
Could this have anything to do with these spikes, as I see them on all _IN channels.
Good to hear you might be narrowing this down. I'll try my 6208 on the ardu, just stripped it from another frame
I have twitches on the R6014HS which is no sbus..... :-(
Until we have the right hadware to know exactly what's going on here, we will eventually send you a debug ArduPPM version so that we can check if the problem do come from the ppm encoder, or from the decoding side in the AVR 2560 chip.
The APM log is not usefull here to give us the exact problem location.
We discussed a lot about this problem in the dev team but unfortunately without deeper testing we are just guessing the root cause.
I'll come back with hopefully better news.
No i just saw it. Thanks this is very interesting information.