== Edit 2/15 ==
I've replaced the 2.9 APM_RC libraries with the libs from 2.8, and commented out some code in radio.pde that referenced those libraries. The issue's disappeared using this workaround so at least I can fly on 2.9 using PPM.
I'm running 2.9 on a Crius V1.1 board with HobbyKing 30A SimonK (bs_nfet.hex) firmware. Motors are NTM 2826 1200kv motors with 8x4 carbon props. Receiver is a TFR4-B running in PPM mode.
This is all on a tricopter with an AUW of 1180g.
As the video shows - there are random power surges in the front 2 motors. For some reason the tail motor doesn't see these surges. I've verified that both front motors and escs are working properly by hooking them up directly to the receiver, so solder connections are all solid. I only see the power surges when it's hooked up to the flight controller (could there be a problem with the header pins?)
At the instruction of Aleksey - I played around with RC_SPEED which defaulted to 490hz. I tried 400hz and 125hz. Lowering the refresh rate to 125hz actually made the defect larger. It surged harder and longer before it caught itself and settled down to the right speed.
At this point - the only thing I can think to do is swap out flight controllers - but that's going to take some time. I thought I'd throw this out there to see if anyone's ever seen anything like this.
I'm attaching tlogs from both a flight and the most recent bench run. My board can't do raw sensor captures, so all I have is whatever standard telemetry gives me. All I can tell from the logs is that channels 1 and 4 go high and low at random intervals.
This was a problem with Futaba RX and there was an update for the PPM encoder in the Ardu. Since you are using a PPM signal I'm not sure its valid however you might want to review this problem and see if it solves your issue
A buddy suggested I swap out the RX for a regular one in PWM mode and see what happens. Won't be able to do that for a couple of days - but assuming that's the case - I'd have to translate those instructions for my board.
Appreciate the assistance.
I have a 10amp eagle tree that I can toss in, but that still wouldn't account for why the ESCs are getting random high and low pulses as seen in the logs.
Someone suggested potential ground loops, but I've broken the system down to the bare components - battery -> esc -> flight controller -> rx -> motor. It's possible that they might not be compatible, but these particular escs have been used in several documented builds which was part of the reason I chose them.
Appreciate the ideas - keep em coming and I'll try what I can.
You're getting glitches in the radio input to the APM so you're on the right track with the suggestions to swap out the receiver or upgrade the ppm encoder. Below are roll (ch1), pitch (ch2), throttle (ch3) and yaw (ch4) and you can see that even though you weren't touching the other channels in your tests (assuming that the tlogs are taken at the same time as the test) you're getting jumps in the roll and pitch as soon as you raise the throttle above zero.
Our ppm encoder couldn't handle the update rate of the new, very fast futuba transmitters which have over 8 channels so I'd upgrade that first. It's also possible that the ppm receiver you're using can't read the futaba updates quickly enough but I'm less sure about that.
You're proof that evolution doesn't work, because if it did - you'd have 4 hands. Man how do you keep track of everything and be able to respond to little issues like this?
I really appreciate you looking into that. I'll swap out the rx's and try PWM on the next go around and report back. If it's a PPM encoder issue - I may just nix the update and swap it out for a proper APM, which was on my to do list anyway.
And thanks for all your hard work on the project - I want to get my rig up in the air as fast as possible to feed the testing machine :)
PS - one note I left out - I'm running a Futaba 10CHG - I didn't think I'd run into the issues that the 8J guys were seeing - but who knows. I have almost this exact same setup on a quad except for ESCs (Quattro 4-1 in the quad) and that worked fine so whatever this issue is will probably end up coming down to one faulty part.
I had exactly same symptoms with APM2.5 and 2.9.1. Using Spectrum DX8 and PWM. I think I have solved the problem when I went to the Transmitter SYSTEM SETUP menu and changed FRAMERATE (from 22ms) to 11 ms. Have tried a lot of times now without symtoms. I dont know why it work, but when I set it back to 22ms, the symtoms start again.
Just swapped out the RXs with a known working one. Same issue.
It looks like that PPM encoder issue the dev team recently released an update for, but in my case - I don't have an easy way to update the Crius.
I'll reach out to Aleksey and see what options I have (short of swapping back to pwm). I'll start prepping up that Arduflyer in the meantime.
I've never even seen that board before. To be honest, I wish all the people selling the clones would also contribute to providing support. it's hard enough supporting the 3dr hardware let alone the clones :-(
No I absolutely understand. You've gone about as far as anyone could rightfully expect, so thank you again for that.
Crius team is looking at this so I'll just report back with whatever's found. For what it's worth and to anyone that may be affected by this, there is a patch available for anyone running a tx/rx with more than 8 channels. Apparently there was a bug with channel 9 mixing with channel 8 and causing random spikes. My issue's a little different.
Again - thanks for your help Randy, that was unexpected but much appreciated.
I solved the problem when I changed transmitter FRAMERATE from 22ms to 11ms (better described few posts above).
Is this an interesting findings in the work to try to permanently solve the problem?
Unfortunately I don't have that capability with my 10CHG, but it's looking like I'll probably swap this out for a proper APM with updated PPM encoder and move this to a debug rig.