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
have
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?
Regards,
Nathaniel ~KD2DEY










Tags: 2.5, APM, ATMega32U2, PPM

Views: 5264

Reply to This

Replies to This Discussion

I assume this is all for 2.4GHz Futaba radios and doesn't affect any of the older 72MHz stuff right? I just ask because I use a 9C for FPV work and will be installing the APM 2.5+ in a plane and tricopter. From what I gathered, it's likely only a newer 2.4GHz issue but it would be good to know if I really need to care about this.

I used Spektrum for any of my 2.4GHz stuff so at least that shouldn't be affected.

My list is based on some assumptions so take it with a grain of salt, and don't think that it is an all inclusive list. As far as I know this is only affecting newer receivers and yes they all are 2.4 GHz. That is not to say that there couldn't be any issues with some 72 MHz system out there. The issue is really with the receivers however the receivers listed ship with the transmitters shown so they are related. The best thing to do would be to view your CH input and output in the MP with the tuning option checked and look at the signals over a period of time say maybe an hour? If your traces don't exhibit any spikes you can't explain then your probably OK. Either way there really shouldn't be any negative to updating the firmware of the PPM encoder. So if you want to be sure.....upgrade it!

Regards,

Nathaniel ~KD2DEY

No, it's just the latest 2.4GHz receivers (released in the last year?) with more than 8 channel. It doesn't affect any of the Futaba gear I've got, which is mostly 7C. 

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.

R608FS:

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.

OrangeRX FASST:

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?

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.

John

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

@John

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.

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.

No, that was most likely a APM control/mode logic flaw. I haven't been involved in that particular case, but I would be very surprised if it hasn't been fixed a long time ago.

A PPM glitch will recover the next radio input cycle, meaning that the throttle spike will only last about 1/50 of a second. Enough to get a visible shake in the copter, but nothing serious like dropping to the ground, or a runaway.

RSS

© 2014   Created by Chris Anderson.

Badges  |  Report an Issue  |  Terms of Service