Major Glitch in a Futaba SS system!!
#351
Banned
Join Date: Mar 2003
Location: Tokoroa, , NEW ZEALAND
Posts: 3,848
Likes: 0
Received 0 Likes
on
0 Posts
RE: Major Glitch in a Futaba SS system!!
ORIGINAL: Julez
Not necessarily.
My TX lost its GUID after I switched it on exactly the way I did hundreds of times before during the last 6 months.
Not necessarily.
My TX lost its GUID after I switched it on exactly the way I did hundreds of times before during the last 6 months.
As I've posted elsewhere, the odds are that you switched it off during the very narrow window when some EEPROM was being updated - this is something that many people overlook when getting familiar with this technology but I'd have expected Futaba to know better.
The fix may be simple (a couple of resistors and a few lines of code) or it may be more complex (requiring a separate A/D converter to be grafted on if the main processor doesn't have a spare ADC channel) - but either way it's almost certainly going to be a "return to factory" job I'm afraid.
If Futaba simply say "it's fine, just don't play with the off-on switch" then (IMHO) they'll be as bad as Hitec who said "yes, the Spectra module is a loose fit in those Optic 6's and it does cause planes to crash -- so just wrap some electrical tape around it, that'll be fine" (and it wasn't). A proper recall/fix would be extremely expensive -- it's just a case of how much Futaba is prepared to wear in order to protect its reputation as a brand.
I believe, based on what we've seen and on Futaba's own comments in respect to use of the off/on switch, that there is a definite *DESIGN FLAW* in these sets. It's not a matter of "if" your system looses its GUID -- it's a matter of *WHEN*. Given sufficient power cycles, eventually one will interrupt an EEPROM write and then you're toast.
Hitec said the AAAA fault (a similar situation) with their OPTIC 6 was "very rare" -- but that's only because the chances of hitting the EEPROM write window were small. However, all of the Optic 6s I saw with the original firmware did it eventually - buy enough tickets over a long enough period and you'll eventually win the lottery -- it's all about odds.
Futaba may opt to bet that the window is so small that the numbers affected (and planes possibly lost) won't be worth the recall -- as a consumer I don't think I'd be happy with that. One of the reasons many folks have gone to 2.4GHz is to get away from playing Russian roulette with their models -- isn't it?
All consumer electronic devices should be impervious to damage from simply using the switches provided.
#352
RE: Major Glitch in a Futaba SS system!!
i'll stay with band 72 f.m. seems to be working just fine for eighty years. i've scanned through every thread and still dont know what the problem is. can you explain it like im five.
#353
Senior Member
Join Date: Jan 2003
Location: Deep in the Heart Of, TX,
Posts: 602
Likes: 0
Received 0 Likes
on
0 Posts
RE: Major Glitch in a Futaba SS system!!
Wow. How great it is to have all of these experts telling us what has happened, how it should have been designed, what Futaba should be doing now, how to interpret what Futaba is telling us, etc., etc., etc, ad infinitum.
Makes the internet junk mail problem pale in comparison!
Later;
D.W.
Makes the internet junk mail problem pale in comparison!
Later;
D.W.
#354
RE: Major Glitch in a Futaba SS system!!
[All consumer electronic devices should be impervious to damage from simply using the switches provided.
[/quote]
Delete the word "electronic" .
I am baffled by the "Precaution #2"-even tho it does not personally affect me.
It flies in the face of recognized standards for consumer products. Hopefully it will be explained more clearly at some point in time.
Just saying DON"T DO IT-is like saying - "son don't touch that thing -you may go blind
-without clarification - you invite further problems
PS -I had my eyesight fixed.
#355
My Feedback: (24)
Join Date: Jan 2004
Location: Peachtree City,
GA
Posts: 1,351
Likes: 0
Received 0 Likes
on
0 Posts
RE: Major Glitch in a Futaba SS system!!
Call it panic if you want to, but I don't want to "play the lottery"with my planes or my safety. Based on Futaba's statement, I'm calling Tower for a refund. That 9303 is looking real good now.
#359
My Feedback: (90)
RE: Major Glitch in a Futaba SS system!!
Maybe there is different problem with a different Futaba FASST system. Please check this [link=http://www.rcuniverse.com/forum/m_6855523/mpage_1/key_/tm.htm]URL[/link] out (post #24).
The 14MZ 2.4Ghz receiver was interfered by a cell phone call in flight and the plane crashed.
The 14MZ 2.4Ghz receiver was interfered by a cell phone call in flight and the plane crashed.
#360
Senior Member
My Feedback: (133)
Join Date: Dec 2001
Location: Bakersfield,
CA
Posts: 1,243
Likes: 0
Received 0 Likes
on
0 Posts
RE: Major Glitch in a Futaba SS system!!
ORIGINAL: nonstoprc
Maybe there is different problem with a different Futaba FASST system. Please check this [link=http://www.rcuniverse.com/forum/m_6855523/mpage_1/key_/tm.htm]URL[/link] out (post #24).
The 14MZ 2.4Ghz receiver was interfered by a cell phone call in flight and the plane crashed.
Maybe there is different problem with a different Futaba FASST system. Please check this [link=http://www.rcuniverse.com/forum/m_6855523/mpage_1/key_/tm.htm]URL[/link] out (post #24).
The 14MZ 2.4Ghz receiver was interfered by a cell phone call in flight and the plane crashed.
I know a lot more about the cell phone incident and what he's trying to find out. Earlier that day his brand new 14mz 2.4 module and receiver crashed his EF 87" Yak on it's, the radio's, first flight. He started yelling "I haven't got it , I haven't got it" and four of us looked up and watched the plane wing rock from about 70 degrees right to 70 degrees left back and forth as it decsended at about a 20 degree angle into the ground. When we got it back to the bench everything seemed to work and the phone interferance was discovered later than day. This was the test bed before he put it in his 35% Yak. While the plane was on the bench and he was trying to figure out what could be going on his phone rang and as soon as he answered his radio went nuts. He called me to check my 2.4 Fasst ( I'm the 9C with the TM7 & 607 rx) to see if this was normal, mine is un-effected by my cell phone and it was the next day he actually set his phone on my receiver which incidently has the receiver mounted on a EQ-10 power expander. No problems were caused by his phone on my radio, it just interferes with his radio. We're both Futaba lovers and he's just looking for answers and if somethinng is wrong with his equipment, not Futaba's system. The question was has anyone else noticed cell phone interference with there 2.4 Fasst system
Crashes can do funny things to rxs - at least I've had some 72mhz rxs exhibit susceptability to interference after a crash. Sent them in, and they always had a filter replaced. Don't know about the 2.4 rxs, 'cuz I haven't crashed one - yet!
#361
My Feedback: (24)
Join Date: Jan 2004
Location: Peachtree City,
GA
Posts: 1,351
Likes: 0
Received 0 Likes
on
0 Posts
RE: Major Glitch in a Futaba SS system!!
I don't know if what I just did can be considered a valid test, I went to my garage and turned on my 9C with the 2.4 module and an aiprplane with a Fasst rx in it. I placed my Nextel cell phone next to the plane and had my son call it. While the cell phone was ringing I was able to continue to move the controls but the rx made a chattering sound.
#362
My Feedback: (14)
Join Date: Apr 2003
Location: Bowling Green,
KY
Posts: 1,326
Likes: 0
Received 0 Likes
on
0 Posts
RE: Major Glitch in a Futaba SS system!!
I found the entire thread to be ridculous. You can interfere with anything if you put foreign emission right on top of it. Common sense is required.
My bet is his equipment will be returned with a finding of "no problems".
My bet is his equipment will be returned with a finding of "no problems".
#363
Senior Member
My Feedback: (133)
Join Date: Dec 2001
Location: Bakersfield,
CA
Posts: 1,243
Likes: 0
Received 0 Likes
on
0 Posts
RE: Major Glitch in a Futaba SS system!!
ORIGINAL: Flying Geezer
I found the entire thread to be ridculous. You can interfere with anything if you put foreign emission right on top of it. Common sense is required.
My bet is his equipment will be returned with a finding of "no problems".
I found the entire thread to be ridculous. You can interfere with anything if you put foreign emission right on top of it. Common sense is required.
My bet is his equipment will be returned with a finding of "no problems".
#365
RE: Major Glitch in a Futaba SS system!!
Ok, I'm confused. What is a 14mhz 2.4? Is it operating at 14mhz, or 2.4ghz, or both? Or is it a radio that was originally 14mhz, but with a replacement 2.4ghz module? Or does the 14mhz refer to something other than transmission frequency?
Scott
Scott
#367
Senior Member
My Feedback: (42)
Join Date: Nov 2004
Location: Singapore, SINGAPORE
Posts: 548
Likes: 0
Received 0 Likes
on
0 Posts
RE: Major Glitch in a Futaba SS system!!
Oh I'm having a blast! ordered the 7C 1week before the debacle surfaced. Now its over here and I don't have a clue when it'll reset itself! Fun times ahead.
There will a lot of people who don't go to the LHS or surf the net that'll be unaware of the problem and one day when the tx resets to zeroes it'll be goodbye plane if you have another tx with zeroes.
It'll be good if Futaba can come out with a permanent fix to the switching problem, its like russian roulette now, always a worry when you switch on.
There will a lot of people who don't go to the LHS or surf the net that'll be unaware of the problem and one day when the tx resets to zeroes it'll be goodbye plane if you have another tx with zeroes.
It'll be good if Futaba can come out with a permanent fix to the switching problem, its like russian roulette now, always a worry when you switch on.
#368
My Feedback: (7)
RE: Major Glitch in a Futaba SS system!!
14MZ is the model number of a particular Futaba transmitter , it has nothing to do with transmission of signals. The radio has plug in RF modules allowing the owners to install the module of their choice for the frequency they want to transmit on. to the RX.
#369
Member
Join Date: Dec 2002
Location: CO
Posts: 55
Likes: 0
Received 0 Likes
on
0 Posts
RE: Major Glitch in a Futaba SS system!!
I am as concerned about this as anyone - I sold off all my 72mhz stuff and bought a total of 10 new Futaba 2.4 rxs. Futaba has announced what the issue is, and how to avoid it. They have also made it clear that if your Tx STOPS working the rxs you already have linked to it - THERE IS A PROBLEM.
What if there's already a ZGUID Tx in operation, with a plane in the air, when you discover this?
What if you'd already checked with the other guy earlier and found no interference, but
your Tx has reset itself to ZGUID since then?
Think about it.
Checking with everyone else is not a solution because the problem could occur between the time you check with
them and when you later turn off and back on again. Noticing that your Rx is no longer responding is *not* a viable
solution, because by the time you realize this, your Tx is already reset to ZGUID and it's *ON*, which means
it will shoot down anyone else who is also using a ZGUID Tx (who had no idea previously). Whether we know
the root cause of the problem or not, we do know that this does happen and it basically could happen
at any time, so you need a method of checking that works every time.
As I've said several times over on RCG, the only viable workaround is to get a known ZGUID bound Rx (it's been
reported that all brand new unpaired Rx's come ZGUID bound), and test your Tx against it (see if you can make it respond to your Tx)
before you turn on. Every time. Get one for yourself if you're really paranoid, or at least get one
for the whole club, and the only rule is
"Check with the ZGUID Rx before you turn on and again after you turn on. If it ever moves, then find the ZGUID Tx that's controlling it, and turn it off."
That's it.
ian
#370
RE: Major Glitch in a Futaba SS system!!
ORIGINAL: Daemon
As I've said several times over on RCG, the only viable workaround is to get a known ZGUID bound Rx (it's been
reported that all brand new unpaired Rx's come ZGUID bound), and test your Tx against it (see if you can make it respond to your Tx)
before you turn on. Every time. Get one for yourself if you're really paranoid, or at least get one
for the whole club, and the only rule is
"Check with the ZGUID Rx before you turn on and again after you turn on. If it ever moves, then find the ZGUID Tx that's controlling it, and turn it off."
That's it.
ian
As I've said several times over on RCG, the only viable workaround is to get a known ZGUID bound Rx (it's been
reported that all brand new unpaired Rx's come ZGUID bound), and test your Tx against it (see if you can make it respond to your Tx)
before you turn on. Every time. Get one for yourself if you're really paranoid, or at least get one
for the whole club, and the only rule is
"Check with the ZGUID Rx before you turn on and again after you turn on. If it ever moves, then find the ZGUID Tx that's controlling it, and turn it off."
That's it.
ian
#371
Senior Member
My Feedback: (133)
Join Date: Dec 2001
Location: Bakersfield,
CA
Posts: 1,243
Likes: 0
Received 0 Likes
on
0 Posts
RE: Major Glitch in a Futaba SS system!!
ORIGINAL: Daemon
And hypothetically speaking, what if you discover this at the field, when you turn on your Tx?
What if there's already a ZGUID Tx in operation, with a plane in the air, when you discover this?
What if you'd already checked with the other guy earlier and found no interference, but
your Tx has reset itself to ZGUID since then?
Think about it.
Checking with everyone else is not a solution because the problem could occur between the time you check with
them and when you later turn off and back on again. Noticing that your Rx is no longer responding is *not* a viable
solution, because by the time you realize this, your Tx is already reset to ZGUID and it's *ON*, which means
it will shoot down anyone else who is also using a ZGUID Tx (who had no idea previously). Whether we know
the root cause of the problem or not, we do know that this does happen and it basically could happen
at any time, so you need a method of checking that works every time.
As I've said several times over on RCG, the only viable workaround is to get a known ZGUID bound Rx (it's been
reported that all brand new unpaired Rx's come ZGUID bound), and test your Tx against it (see if you can make it respond to your Tx)
before you turn on. Every time. Get one for yourself if you're really paranoid, or at least get one
for the whole club, and the only rule is
"Check with the ZGUID Rx before you turn on and again after you turn on. If it ever moves, then find the ZGUID Tx that's controlling it, and turn it off."
That's it.
ian
I am as concerned about this as anyone - I sold off all my 72mhz stuff and bought a total of 10 new Futaba 2.4 rxs. Futaba has announced what the issue is, and how to avoid it. They have also made it clear that if your Tx STOPS working the rxs you already have linked to it - THERE IS A PROBLEM.
What if there's already a ZGUID Tx in operation, with a plane in the air, when you discover this?
What if you'd already checked with the other guy earlier and found no interference, but
your Tx has reset itself to ZGUID since then?
Think about it.
Checking with everyone else is not a solution because the problem could occur between the time you check with
them and when you later turn off and back on again. Noticing that your Rx is no longer responding is *not* a viable
solution, because by the time you realize this, your Tx is already reset to ZGUID and it's *ON*, which means
it will shoot down anyone else who is also using a ZGUID Tx (who had no idea previously). Whether we know
the root cause of the problem or not, we do know that this does happen and it basically could happen
at any time, so you need a method of checking that works every time.
As I've said several times over on RCG, the only viable workaround is to get a known ZGUID bound Rx (it's been
reported that all brand new unpaired Rx's come ZGUID bound), and test your Tx against it (see if you can make it respond to your Tx)
before you turn on. Every time. Get one for yourself if you're really paranoid, or at least get one
for the whole club, and the only rule is
"Check with the ZGUID Rx before you turn on and again after you turn on. If it ever moves, then find the ZGUID Tx that's controlling it, and turn it off."
That's it.
ian
Once everyone has checked against a ZGUID rx with Txs that are already linked to their flight packs, they are safe. A defective ZGUID Tx will only shoot down another flier if his system is linked to ZGUID. NOBODY should be on ZGUID - so a failure should show up when anyone's Tx no longer operates their linked rx. If someone gets shot down, they either 1) never bothered to check to see if their system was ZGUID or 2) ignored the failure designator (Tx no longer works rx) and relinked their system after a failure to ZGUID. Since nobody should be on ZGUID, I think it's the guy who is FLYING a ZGUID system who assumes all the risk.
There IS a MUCH simpler way to be safe- TURN THE PLANE ON FIRST, give it a few seconds, and if the servos start moving DON'T TURN ON THE TX! YOU ARE A ZGUID SYSTEM and there is another one ALREADY FLYING!!!!! This actually works for ANY GUID conflict - like if the factory accidentally duplicated a non-zero GUID. Just have to make sure your motor isn't armed on an electric.
#372
Senior Member
Join Date: Aug 2003
Location: Great Falls,
MT
Posts: 151
Likes: 0
Received 0 Likes
on
0 Posts
RE: Major Glitch in a Futaba SS system!!
ORIGINAL: jonkoppisch
I lost a plane with xps when the radio went out and they didn't even give me a new receiver!!!!
I lost a plane with xps when the radio went out and they didn't even give me a new receiver!!!!
#373
Senior Member
Join Date: Jan 2007
Location: , GERMANY
Posts: 184
Likes: 0
Received 0 Likes
on
0 Posts
RE: Major Glitch in a Futaba SS system!!
ORIGINAL: Teachu2
OK - and then it didn't work your rx, correct? Did you rebind your rx, or just send it in?
OK - and then it didn't work your rx, correct? Did you rebind your rx, or just send it in?
After talking to the robbe tech support, I sent my TX in.
ORIGINAL: XJet
Having spent *many* hours designing and building microcontroller-based systems I'd be willing to bet that your system didn't lose its memory on power-up but during the previous power-down.
Having spent *many* hours designing and building microcontroller-based systems I'd be willing to bet that your system didn't lose its memory on power-up but during the previous power-down.
What do you think about the following idea, XJet: Using a transistor for the power supply of the module. First, you switch on the TX. Then, you press a button which gives the voltage to the signal pin of the transistor. It switches on the module without any switch bounce. The voltage at the module is now used to hold the transistor in the on-position. This kind of circuit is called "self-holding", maybe "self-sustanining", in Germany, Im sorry I dont know the exact english term.
A different button is used to open the connection between the module voltage and the transistor signal pin, thus switching off the module without any switch bounce.
Does this sound like a good option until a permanent fix is found by Futaba?
Thanks,
Julez
#374
My Feedback: (162)
RE: Major Glitch in a Futaba SS system!!
He finally said that he'd like to look at it to prove that it wasn't his systems fault, & told me that there was no way I could prove it was his systems fault... Why send it? He's already told me that he would not even consider it being it's fault? + it would cost me more to send it and at this point I'm not going to give him any more of my $. I've already given him enough!! If he would have offered to help me at all, my attitude would have been totally different!
If futaba backed their product as stated earlier, They have my total support!!! If they only replaced his plane, they have my total support!!! If they helped at all, that's a huge step above what i got!!!
I was told, pay your money and send it in and when I receive it I'll tell you it wasn't our fault.. At that time they didn't have the 'unconditional'[sm=lol.gif] warranty
If futaba backed their product as stated earlier, They have my total support!!! If they only replaced his plane, they have my total support!!! If they helped at all, that's a huge step above what i got!!!
I was told, pay your money and send it in and when I receive it I'll tell you it wasn't our fault.. At that time they didn't have the 'unconditional'[sm=lol.gif] warranty
#375
My Feedback: (90)
RE: Major Glitch in a Futaba SS system!!
ORIGINAL: Teachu2
Once everyone has checked against a ZGUID rx with Txs that are already linked to their flight packs, they are safe. A defective ZGUID Tx will only shoot down another flier if his system is linked to ZGUID. NOBODY should be on ZGUID - so a failure should show up when anyone's Tx no longer operates their linked rx. If someone gets shot down, they either 1) never bothered to check to see if their system was ZGUID or 2) ignored the failure designator (Tx no longer works rx) and relinked their system after a failure to ZGUID. Since nobody should be on ZGUID, I think it's the guy who is FLYING a ZGUID system who assumes all the risk.
There IS a MUCH simpler way to be safe- TURN THE PLANE ON FIRST, give it a few seconds, and if the servos start moving DON'T TURN ON THE TX! YOU ARE A ZGUID SYSTEM and there is another one ALREADY FLYING!!!!! This actually works for ANY GUID conflict - like if the factory accidentally duplicated a non-zero GUID. Just have to make sure your motor isn't armed on an electric.
Once everyone has checked against a ZGUID rx with Txs that are already linked to their flight packs, they are safe. A defective ZGUID Tx will only shoot down another flier if his system is linked to ZGUID. NOBODY should be on ZGUID - so a failure should show up when anyone's Tx no longer operates their linked rx. If someone gets shot down, they either 1) never bothered to check to see if their system was ZGUID or 2) ignored the failure designator (Tx no longer works rx) and relinked their system after a failure to ZGUID. Since nobody should be on ZGUID, I think it's the guy who is FLYING a ZGUID system who assumes all the risk.
There IS a MUCH simpler way to be safe- TURN THE PLANE ON FIRST, give it a few seconds, and if the servos start moving DON'T TURN ON THE TX! YOU ARE A ZGUID SYSTEM and there is another one ALREADY FLYING!!!!! This actually works for ANY GUID conflict - like if the factory accidentally duplicated a non-zero GUID. Just have to make sure your motor isn't armed on an electric.
If someone forgot the check and shot down a plane, whose fault it is?
Do we want each local club to adopt such a procedure?