Is it necessary to (update)flash the Atmega32U2 (PPM encoder) on an APM 2.5 if using a Futaba system?

I'm constantly expanding my understanding of all the options and systems within the APM 2.5 by re-reading the wiki and looking for things that have changed or things that I hadn't considered before.

One thing that has recently caught my eye was the section here in the ArduPlane wiki titled

'How to flash the Atmega32U2 (PPM encoder) through USB'

The downloads section title description states

APM 2.x ArduPPM Firmware v2.3.13 (recommended update for Futaba radio users)

The wiki page was most recently updated almost a year ago (Dec 29, 2011) and doesn't specify what versions it applies to.....I don't know why this text is coming out italicized....I don't have Italics on...anyway the wiki instructions specifically refer to APM 2.0 not 2.x and the images are all of an APM 2.0 board. I realize that this is just a representation of the board at the time but it doesn't
make any reference to APM 2.5.
The downloads section here states
ArduPPM v2.3.13 ATMega32U2 firmware for APM 2.x

So is the upgrade necessary for APM 2.5 or not, and is there a list of Futaba receivers known to
n issue with the stock PPM encoder firmware? So perhaps if someone could clarify this itwould be great, also are the instructions in the wiki still applicable to an APM 2.5?
Nathaniel ~KD2DEY

Views: 7006

Reply to This

Replies to This Discussion

I just ran some Futaba 8ch receiver tests using oscilloscope pass-fail detection on the ppm output signal from the 32u2. I ran the tests on a APM2.0 board with the latest ArduPPM firmware before the glitch patch (V2.2.68). Radio I used is the Futaba 9C Super radio with TM-8 FASST transmitter in 8 channel mode.


This one ran for close to 10 hours without any fail (pass counter wraps). So I think it is safe to say that the TM-8/R608FS combo does not glitch.

Then I ran tests on the OrangeRX FASST receiver that Marco has reported problems with.


I ran it for a couple of hours, and strangely this one does not have any glitches either. Neither normal or high-speed mode seem to make any difference. So I am not able to produce any glitch problems. Perhaps it is my TM-8 transmitter module that makes the difference? But reading the Fr-Sky TRF8 manual it states that you must turn of sail-safe in the Futaba radio and use the internal receiver FS instead. Otherwise you get throttle glitches.

@Marco, can you say if the Futaba F/S was on or off on your radio?

Do you think it effects the 8J? Thats probably what I'm going to get.

A glitch does not automatically make it a problem with the PPM encoder. It might just as well be a bad connector or electronic interference related problems. It might even be a bug in the radio system. Certain OrangeRX/FrSKy FASST receivers for example has a problem with throttle glitches because of compatibility problems with the Futaba radio fail-safe system.

So I what I am trying to say is that "I had a glitch using receiver xxx, fix it" does not really help. If we are not able to reproduce the problem, it can be close to impossible to fix at times. Simply because we might not even know what we are trying to fix.

At current the MULT channel grouping is the only thing that makes sense technically. And confirmed reports of fixing the glitch problem by improving the interrupt system response time, further validates that view.


I spent 48 hours of my life with a pile of legitimate Futaba receivers, cables, and everything needed to rule out RFI, bad receivers, etc etc.

The simple fact is, Futaba receivers of 8 channels or more seem to produce PWM pulses at the same, or very nearly the same, time. This throws the old PPM encoder code. I haven't asked you to fix anything, I don't fly Arduanything any more.

"At current the MULT channel grouping is the only thing that makes sense technically."

And that is exactly what I said in my post. Swapping for a 7ch receiver fixed the problem once and for all, swapping it for another MULT 8 channel didnt.

Hi John, yes i know, the tx failsafe is disabled due the incompatibility with the Orange FASST (as you wrote just read the manual of TFR8), but i use the rx failsafe (press the button with the 8 channel in the desired position).
I use the "TM14" module with my T12FG... it is possible that TM8 and TM14 can cause these glitches?
I also have a T8FG, I might try that and the old ArduPPM.
However I can confirm that with the new ArduPPM I have not had any glitches, and flights also well I will have made ​​at least fifty during the varius tests of 2.9.


I'm not familiar with the 9C Super, does it have selectable transmission modes? In other words does it have a 7CH mode vs a MULT/MLT2 mode? I ask because I know the R608FS is compatible with the MULT/MLT2 modes that I suspect are the cause of the problem. Do you know anyone that has a Futaba transmitter I listed above that you could test the R608FS with in MULT mode?

Best Regards,

Nathaniel ~KD2DEY

Is this something similar to the older PPM vs. PCM on the 72MHz Futaba radios? I remember that on PCM receivers, I believe it sends out 2 channels simultaneously so back in the day of the FMA Co-Pilot, you had to run a servo buffer to delay one of the channels to get it to work properly. Maybe they are doing something similar to the old PCM?

Thanks for the feedback.

My dilemma is this. If you see my previous post, I have been running 8ch tests using the R608FS and OrangeRX FASST receivers for days now. Both reported to have caused PPM glitches, but I have not seen a single PPM glitch from either of them.

The only difference left then is the transmitter module/radio. I am using a 9C radio with a TM-8 transmitter module in 8 ch mode. 8 ch mode is replaced with MULTI-CH mode in the latest Futaba radios. What that really means, Futaba wont say. As usual they are big on PR but seldom give any real technical details. Since 8ch mode vs. multi-ch is the only difference left. Perhaps this affects the receiver output sequence? But I can only speculate.

I think you are on to something here with the MULT-CH mode.

Most of the 433MHz LRS systems also had problems with this and would only work in 7CH mode. There was a workaround for the LRS stuff which involved setting all the endpoints to use either the top or bottom half of the travel. Can't remember the exact details, never tried it myself. It was reported to work but you lost resolution by using the full stick travel with only half the pulsewidth range.

I remember reading something like, that in order to be able to tx more than 12ch ( the 8fg, 12fg etc can produce 14ch or more) the stream had to be compressed to fit into a singe frame. I think that is why JR only had 11ch for a long time.

I can also confirm that these glitches were happening in ppm-sum mode with a 12FG and TFR4 receiver.

I was also getting the glitches on ch 5. Imagine my surprise when I was doing a hand test and heard MP call out " mode changed to RTL, mode changed to stabilize". I didn't know what was going on because it was the first use of a brand new APM2.5, first use of new TFR4 and first use of ppm-sum.

Immediately ruled out the last 2 by going back to the orange receiver and separate channels I had used with the old APM1.4. Thought I had a dud board until I discovered the "motor twitching thread"

So thanks to everybody who reported and fixed the issue

If glitches also happens in PPM-passtrought mode (receiver outputting PPM-SUM directly), then the PPM encoder has nothing to do with it. Then you will have to make sure the receiver is outputting standard 8 channel PPM-sum, since that is the only one tested and supported by the PPM decoder in APM.

I've seen this glitch on quads with an 8FG and an R62208 SB.  I just updated my PPM encoder and I'll keep an eye out for the problem when I put a quad back together.

I used to get twitches on my Tricopter firmware 2.6 using a Futaba 10c fitted with Frsky module

Reply to Discussion


© 2018   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service