There have been several occasions where i have seen random uncommanded servo movement and twitching while in manual mode. I’ve seen this on an X8 installation and the Skywalker while in the air and on the ground. It is difficult to find such a moment in the logs because its a bit of a needle in a haystack. Yesterday I had a very severe occurrence during pre-flight. It was actually so bad it toasted one of my aileron servos. I can’t be certain what caused the aileron servo to fail, but it happened at the same time.
I pulled the logs and here is just one example:
[attachment=1]Uncommanded movements.jpg[/attachment]
I labeled all the channels in the screenshot. You can see that the negative spike on the left is uncontrolled, and the movement on the right was commended. Notice the Blue line for Rudder, it is slaved to the aileron and when I command aileron, it moves proportionally. The left spike does not move the rudder, but it does move the flaps all the way down (Magenta), it even moves the OSD screen changing signal (Cyan). The Flaps are just a pass through, and not controlled by the APM. It also moves the Mode from Manual to RTL which I never observed until looking at the log. I don’t know how long this event lasts because the “show point values” only has resolution to the minute. The reason i know that an RTL event didn’t cause these movements is because it wouldn’t have moved the flaps or OSD, and would have moved the rudder.
Here is my set up:
2013 Skywalker 1900
APM 2.5.2 using Plane: 2.76
APM powered by separate UBEC
Servos powered by another UBEC on a separate bus
DragonLink PPM
FPV 1.3Ghz 800mW Tx. Disconnected during problem, but problem continued.
Thoughts:
It can’t be related to the servo power or signal lines because the OSD has no servo.
Vcc looks solid at a range of 5230 to 5214
The throttle never drops into the fail-safe range of 950. But maybe its a PPM issue?
Hi Iskess,
The most common cause of servo jitter is RF pickup on the servo cables, but that is not what is happening here, as that causes the servos to move without anything appearing in the logs.
Your log clearly shows the jitter is being received as input to the APM, so the bug has to be in one of the following places:
[ul]bug in the PPM decoding in APM
bug in the DragonLink PPM receiver
RF interference getting past whatever CRC the DragonLink uses
bug in the DragonLink transmitter module
[/ul]
Unfortunately to work out which it is can be quite tricky, and may involve the use of a logic analyser to look at the PPM signal.
You can try the usual thing of swapping out parts, or you can try and borrow a logic analyser and start staring at traces!
Cheers, Tridge
Thanks Tridge. I’ve tried a different Rx. I’ll try to borrow a friends Dragonlink Tx.
If no one else is reporting similar issues, I’ll assume it’s not the APM PPM decoder. If anyone else who has seen something like this please post here.
[quote=“iskess”]Thanks Tridge. I’ve tried a different Rx. I’ll try to borrow a friends Dragonlink Tx.
If no one else is reporting similar issues, I’ll assume it’s not the APM PPM decoder. If anyone else who has seen something like this please post here.[/quote]
The closest thing I can think of was the issue with Frsky receivers a while back. Basically enough channels had high values then the PPM signal didn’t fit in the frame size (I think the frame size may have been 22ms?). That means the decoder could get out of sync, and get channels mixed up.
I haven’t heard of any specific Dragonlink issues with APM, but that doesn’t mean there isn’t one. It might be worth asking on the Dragonlink forums and see if anyone there has run across it?
Can you configure the Dragonlink to send less channels? If it is a PPM decode issue that could make a difference.
Cheers, Tridge
I can lower the channel number in Taranis OpenTx, then rebind with the Rx. I’m currently using 11 channels at 30.5ms 300u +.
It will be hard to give up channels, but I’ll give up a couple for the experiment.
What frame rate should I target?
OpenTx gives me the following defaults:
11 Ch = 28.5ms
10 Ch = 26.5ms
9 Ch = 24.5 ms
8 Ch = 22.5 ms
I don’t know what the 300u means, but that can be changed in increments of 50.
I’m guessing a bit, but perhaps the 300u is a 300 microsecond inter-pulse gap?
If you had 8 channels and all 8 channels were sending 2100 usec, then you would have the following:
[ul]8 pulses of 2100 microseconds, each separated by 300 microseconds
a total frame width of 22.5ms (from your table)
8 * (2100 + 300) = 19200
a inter-frame gap of 3.3ms (22.5 - 19.2)
[/ul]
My Frsky receiver uses an inter-frame gap of 400 microseconds. 300 should be fine, but perhaps you should try making it a bit wider.
So try 8 channels with an inter-pulse gap of 400u and see if that is any better in a bench test.
[quote=“iskess”]I can lower the channel number in Taranis OpenTx, then rebind with the Rx. I’m currently using 11 channels at 30.5ms 300u +.
It will be hard to give up channels, but I’ll give up a couple for the experiment.
What frame rate should I target?
OpenTx gives me the following defaults:
11 Ch = 28.5ms
10 Ch = 26.5ms
9 Ch = 24.5 ms
8 Ch = 22.5 ms
I don’t know what the 300u means, but that can be changed in increments of 50.[/quote]
my calculations were wrong in the above, sorry.
The 300usec negative pulse is counted as part of the channel. So if a channel is putting out 2100 with a 300usec negative pulse then what you get is 1800 usec of high signal followed by 300 usec low signal.
So 8 channels at the max of 2100usec and a frame width of 22.5ms will give 8*2.1 ms, followed by an inter-frame gap of 5.7ms
As a follow up, I dropped a channel so I have a total of 10 channels now. I used the OpenTx default of 26.5ms and 300u. I reduced all end points that were over 100 (pan&tilt).
I then re-binded the DL Rx.
Today’s test flight was successful with now signs of jitter.
It’s still a bit of a mystery to me why this started happening since I had successful flights with the same setup previously.
Hopefully this is the end of this issue.
Tridge, thank you again for steering me in the right direction.