MP3 file for earlier post - the original attachment does not appear to have worked.
when i heard something close to that from mine i ended up replacing the speed control. you might want to redo the calibration. do the cal where the speed control is hooked up to the reciever.
do the manual cal.
hope this helps.
Michael Thanks for your reply. I've tried the re-calibration and I'm not getting any of the tones or sequences described. In Auto mode on the second lipo connection it plays all sorts of tunes and just doesn't stop! Paddy
I get the same noises. It comes from the way the code works for the ardupilot. While there are claims of a 200hz main loop, common sense says serial write commands are variable as part of that main code loop so it will not be a consistent 200hz. In that main loop, we obviously send out the PWM signals to the motors (just like an RC receiver does) in sequence like a demultiplexed signal (in other words, a brief pulse down each channel). This is the first thing I learned in a microcontroller class in school when we were making tone generators. Serial writes coming from an 8 bit microcontroller will always hang the main loop (serial writes like the ones for telemetry) and you'll get clicking or distortion in the main tone. I would have to think polyphonic (AKA descrete PWM signals sent out different ports) would experience this even worse than a single tone as we did in class. This is the fundamental problem with a single non-threaded CPU, that cannot do more than one process at a time. Everything is in a loop and however long that function takes, everything else is not happening. I'm sure an O-Scope would verify this glitch in the signal and further, the way they test the main loop speed is the same way, toggle an output pin at some point in the loop, then read with an O-scope.
Most of the time, even in normal RC, glitches like this occur and the servos and ESCs are designed to hold the last position on loss of signal for a very short time period. In extreme cases, you are hearing the glitch as timing wise, the ESC read it as different than the previous PWM, and a rapid attempt to change speed occurs.
FYI, this is the same reason a second CPU is used to decode the PPM from the RC receiver as a single function and nothing else. This way, loop speed is maximised and both the input and the output of the PPM decoder provides consistent output rather than periodic noise. What we are seeing is that same separate CPU could improve performance in this respect.
Vernon - Thanks for the very detailed explanation - most of which I have followed and it makes sense. If it were not coupled with ESC calibration problems I'd be happier. But thanks for the trouble you took with the detail. Paddy