Alert UPDATED -- Futaba 6EX and 7C Serivce Advisory

[antennahead]

What we have to understand is that although Krysta is our only immeadiate contact to futaba through this board, she works for the distributor and as a distributor I feel their response to this problem so far is more than adquate, they are notifying us of the potential problem and ways to work around it for now. until the MANUFACTURER knows exactly what is wrong and a permanent solution is reached then there's not much she and her employer can do. Our blame should rest with Futaba japan and not with the distributors. the distributors are probably even more upset about the problem than we are. the distibutors hands are tied until the manufacturer has a solution.

My biggest concern is dealing with the uninformed people at the flying field that heard something was wrong (even though they have no idea what the problem was to begin with) and won't let me fly with my 2.4 radio. once a permenant solution is achieved how would anyone at the field know if a pilot shows up with a tested system or not? There should be a permenant marking or plate attached to the radio confirming that it has been tested and is good to fly, then if one shows up without that marking then precations with that particular radio/pilot can be taken.

[Unterhausen]

sounds like a memory device that's not properly protected from writes during a low power state.

[XJet]

I design and implement microcontroller-based systems (including telemetry and control) so the issues surrounding power cycling are well-known to me.

They *can* be problematic but I'm really surprised that Futaba seems to have done such a poor job of implementing their systems in this regard.

EEPROM/FLASH writes must always be protected from brownout/power-cycles or data corruption can/will occur.

So how do you do this?

Well it's not rocket science.

Most microcontrollers have analog inputs that can be used to sense a falling voltage (such as when a power switch is turned off) and interrupt the currently executing program to perform some emergency action. They also have a "brownout detect" that can do the same thing -- but is less flexible in terms of early-recognition of a power-loss situation.

But what if the power drops too low before the emergency action can be completed?

Well this can be avoided in a number of ways.

Firstly you can use a whacking great capacitor across the +5 or +3.3V supply so that you get several seconds (or longer) of safe CPU operation even after the input voltage has completely disappeared. This method does have a few drawbacks (hi-current regulators required to deal with the initial surge and/or a slower-boot cycle must be implemented for example)

Secondly you can use a "soft" power switch. This doesn't actually disconnect the power from the electronics but simply provides a signal that is then used to turn the power off -- kind of like when you click "shutdown" on your Windows PC and it doesn't actually turn off the power until it's done saving stuff to the drive.

That Futaba apparently hasn't chosen to (adequately) implement either of these options comes as a surprise to me (and probably many others who design embedded systems).

In respect to the current GUID problem -- Futaba is wrong if they suggest the problem is minor and unlikely to affect many users. If a EEPROM updates aren't being properly firewalled from power cycling then the problem will eventually effect *every* system if it's turned off/on enough times.

It's a bit like the lottery -- your chances of winning a prize this weekend are pretty remote -- but if you buy enough tickets over a long enough period then you're sure to win something eventually.

Your radio may not lose its GUID today, tomorrow, next weekend or even next year -- but it *will* lose it eventually.

Futaba's advisory not to rapidly cycle the power switch is designed to reduce the chance of it happening (probably because they *know* an EEPROM rewrite is guaranteed to be taking place during that initial window but will only be at relatively infrequent occasions after that.

The big problem with this is that there's still the chance for two or more people to find themselves flying zero GUID transmitters at the same field.... for example:

You buy a new receiver, install it in a new plane, turn it (and your transmitter on) then go through the binding process. What if your transmitter came up with a zero GUID during that power-cycle. You wouldn't notice it because you expected to have to bind the new receiver anyway -- nothing suspicious there.

You get to the field and go flying -- unaware you're now using a zero GUID. A friend turns on his transmitter which also wins the lottery (and thus has a zero GUID). Before he realizes somethings wrong (his receiver doesn't work), you're digging your model out of a deep hole because he shot you down.

Futaba ought to recall all the units with this design fault and redesign/retrofit them so that the EEPROM/FLASH write operations are protected from power-cycling.

Unfortunately (call me a cynic) I have a feeling that they may simply upgrade the firmware to simply display a fault code if your transmitter loses its GUID -- requiring a "return to base" repair to have the GUID re-programmed.

This is better than nothing (since it would stop people being shot down) but I would expect consumers to be less than impressed with such a feeble solution.

[Daemon]

Originally Posted by Silent-AV8R

Can we apply the same standard to the endless speculative comments being made by people who are not actually involved with working on a solution?

You are free to apply whatever standard you want. When it comes
to this issue though, Futaba has been behind the curve, and they still
are if they continue to deny the severity of the power switch cycle
problem (despite their very own warnings), and the low voltage problem
which has now happened two at least 3 people.

As for the speculation.
The folks in the UK who first saw this problem, were told that it was
impossible. Of course we know now that it's not.
Following the first reported case in the US, we speculated that somehow
multiple Tx's were ending up on the same GUID, and as it turns out,
that is exactly what happened, although nobody had initially guessed
how serious it would be (that not only were a couple Tx's sharing the same
GUID here and there, but all affected Tx's were using the very same Zero'd GUID)
Following reports that some people had mysteriously had to rebind their Rx's
we speculated that this was not just a manufacturing or QA problem
but that it might be resetting to ZGUID in the field due to a power issue.
Turns out, that also appears to be true, and at least Ripmax in the UK
has reproduced it even if Futaba in the US has not.
We've speculated that if it can be made to happen purposely (even if
rare) then it can also happen randomly by accident, and Julez experience
shows that is also true. He turned his Tx on, and it stopped working
with his existing bound Rx's.

As for solutions. Even before Futaba announced that people would be
able to test their Tx's at their local LHS, we suggested that once
a ZGUID Rx was identified, then anyone could test whether they had a
ZGUID Tx quite easily by seeing if they could control a servo plugged
into a ZGUID Rx. To that end, it was speculated that all new unbound
Rxs might be ZGUID bound, and that also appears to be true.
So basically someone can walk into any LHS with Futaba gear *today*
and test their Tx, based on our proposed solution.
Anyone want to speculate on what Futaba's testing device will be?

So far most of the speculation, based on the available evidence,
has been pretty close to the money, and the solutions offered
are only as good as the tools available to us. It's up to Futaba to
offer a more permanent solution. Them telling users "don't do that"
isn't enough, because 1. they'll do it anyway 2. it will happen by
accident. Proven by the fact that 1. they've already done
it on purpose 2. it's already happened by accident.

ian

[richard hanson]

Originally Posted by Silent-AV8R

SweetPea:

From the 14MZ manual:



and

And how to reset:



There is also a master reset button behind the battery for a worse case reset.

If this turns out to be a necessary precaution for the 6EX, I can't see how it is a big deal MANY electronic devices have similar precautions.

I for one -really appreciate the thorough explanation -tho it really did surprise me )
to be candid tho -- these situations affect ONLY the tx at hand -
The knotty issue is "what does switch fiddling have to do with changing codes?"

precaution 2 says Don't do it !
Or what?

[Silent-AV8R]

Originally Posted by Z06kal

I think the large response of many users on multiple forums should make it obvious to Futaba how upsetting the situation is and how they need to take care of "us" and make it right. Futaba if you are reading this make sure you treat us right otherwise every upset user will tell 20 of their flyer buddies and pretty soon the Futaba name will be dragged right through the mud.

What has Futaba failed to do so far that you think reflects that they are not "taking care of us"??

Within 1 week of receiving the effected US units Hobbico and Futaba have issued a clear statement and reported the progress they have made. This included free two way shipping and replacement of any and all effected units.

They have also committed to getting testing equipment into the field and have reported the results of their in house testing to date. So far I'm pretty impressed with the response.

I'm going to tell 20 of my buddies how impressed I am at how proactive and transparent Futaba and Hobbico are being about this situation. How about you??

[Silent-AV8R]

Originally Posted by richard hanson

I for one -really appreciate the thorough explanation -tho it really did surprise me )
to be candid tho -- these situations affect ONLY the tx at hand -
The knotty issue is "what does switch fiddling have to do with changing codes?"

precaution 2 says Don't do it !
Or what?

And so there is no confusion, the quotes from the 14MZ manual that I posted have NOTHING to do with with the issue that is the current topic of conversation. My point was that being careful about the switch on/off procedures is nothing new and I cannot see how it should be an issue IF it turns out to be necessary in the case of the 6EX/7C FASST/TM-7.

[Silent-AV8R]

Originally Posted by Daemon

You are free to apply whatever standard you want. When it comes
to this issue though, Futaba has been behind the curve,

Well you are certainly free to look at it that way if you so desire. Behind the curve? Really. Less than a week after getting the TWO problem transmitters in hand they issue a clear advisory and make it clear they take it seriously. Apparently you think they have failed. Oh Well.

[Silent-AV8R]

Originally Posted by XJet

I design and implement microcontroller-based systems (including telemetry and control) so the issues surrounding power cycling are well-known to me.

They *can* be problematic but I'm really surprised that Futaba seems to have done such a poor job of implementing their systems in this regard.

Based on your experience is this something that may be an unanticipated error caused by some oddity in the chips, etc.?? In other words could the design "flaw" be that Futaba failed to take into account that they might at some point be supplied some part that does not meet specs and this is how it manifests itself??

Or is this unequivocal evidence of a basic design flaw??

[Daemon]

Ok, lemme see if I can summarize why people are not yet satisfied with their response.
1. Futaba has so far admitted to nothing more than we already knew, and still denies other things that we know to be true.
2. Their suggestion that users test their Tx's doesn't solve the underlying problem, which is that this can happen in the field to anyone at any time. Test it today, it may still break tomorrow.
3. We already knew how to test for ZGUID Tx's before they told us they'd be creating a procedure for users.
4. Their inability to reproduce the problem while others have already done so, means it's still impossible to know if only some, or all FASST systems can be affected.
5. Telling users "Don't do that" won't make it not happen.

ian

[pilotpete2]

Originally Posted by Daemon

Ok, lemme see if I can summarize why people are not yet satisfied with their response.
ian

I get an entirely different take or spin on their response.
1. How can they be expected to know more than we know yet, they just got the stuff in their hands.
2. I fail to see why anyone would interpret this as the fix.
The company I worked for, for 36 years was the pioneer in corporate sales and technical education, staring in the 19th century. The golden rule of trouble shooting is Verify, Isolate, Repair, Test. Takes time folks Whaddya thinks involved in getting a recall of an automobile started
5. No, I think they are telling you how to possibly avoid the problem, until a fix is implemented.
No way can futaba "fix" the problem by telling users not to turn the Tx on/off in a certain way, due to the serious implications of a blown GUID.

This may sound OT, but how many Spektrum transmitters will be sent back by users due to blown programming as a result of letting the battery die in the tranny with it turned on, I have seen more than one post on the forums with DX7 users getting an error "backup err" after this occurred, no choice but to send it in to be reprogrammed.
If this is a reasonably frequent occurrence, do you think there will be a real fix , or just reprogram and send it back out. I realize that while very similar from a technical point of view, the Futaba problem would have liability implications if not corrected, so it will be fixed, but it takes time.
Just my 2 cents, well a bit more than 2 cents forgive the rant.
Pete

P.S. I agree with SilentAv8tor, but he says it better, than I ever could

[Daemon]

I will say this though.
If you are the concerned owner of a FASST system, there's one relatively
foolproof way to ensure that you will not ever be shot down, from now
until the time Futaba comes up with a permanent fix.
Pick yourself up a brand new Rx and do not bind it to your Tx.
Mark it with a big Z and keep it and a spare servo with you.
This is your ZGUID Rx. Check your Tx against it regularly.
Check it before you launch your high dollar turbine into the sky
for instance. Demonstrate how you use it to the CD at events. This
will ensure that you *will not be shot down*.
When you get to the field and see others flying FASST systems, power up
your ZGUID Rx first and see if it moves. If it does then you'll know whether
anyone *else* is has a ZGUID Tx. If they do, then don't turn on until you
find them. That will ensure that when you turn on your Tx (even if it
has reset since you last used it), that you will not shoot anyone else down.

Yes we're talking about extremely small odds, and yes it'd be annoying
to have an Rx around that you can't use for anything else, but it's a
small price to pay if you're flying high dollar aircraft and want to protect yourself.

ian

[village_idiot]

Sounds like Futaba needs to build a CHEAP device that you can use that will display the GUID of a TX. That and a decent spectrum analyzer seem to be required devices at contests.

Maybe they should even sell a computer interface so that the TX can be reprogrammed by the end user (snow ball's chance where?).

[pilotpete2]

As I said
pete

[village_idiot]

I just asked that this be made a sticky, hope everyone agrees that this is probably important enough to be sticky.