I'd like some feedback - Page 2

| There is a new problem now, and I have personally experienced it with 2
| students under my instruction
|
| The rx goes into into failsafe mode while flying, and the engine either
| idles or deadstick.  Apparently, if the 4.8 nicad pack in the aircraft goes
| below the failsafe level while under load, the rx thinks it has lost battery
| power and closes the throttle,  There is a gadget for sale on ebay to
| overcome this, it seems to be, basically, a big capacitor (condensor)

I'm not sure I'd call this a fault of the RX -- I'd call it proper
design.

When the RX finds that the voltage has dropped too low, it doesn't
know if the voltage is going to come back or if it's going to get
worse -- so the safe thing to do is to go into failsafe immediately,
as it may never get another chance.  If the voltage then comes back,
fine, but the RX can't wait, because if the voltage drops further it
may not be able to move the servos anymore.

Now, I don't know what voltage this all happens at, and perhaps
whatever it is isn't ideal, but I'd argue that this is the proper
behavior.

| Another method, of course, is use 6v rx batt.

Or use larger 4 cell packs with appropriately large wires, and make
sure your servos don't bind, so that the voltage never drops too low,
even if all the servos are moving at the same time.  A lot of people
trust their plane to packs that are fine during normal flight, but the
voltages sag too much when all the servos move at once.

(Using 5 cell packs is OK too -- then the voltage sags _even more_
during high current draw, but it's got a lot more headroom before the
voltage gets *too* low.)

As for your gadget, Horizon sells them too for Spektrum RXs --

   http://www.spektrumrc.com/Products/Default.aspx?ProdID=SPM1600

The problem has been even worse for the Spektrum RXs, as at least some
of them don't go into failsafe when the voltage dips -- they reboot,
taking several seconds to come back to life once the voltage comes
back.  Newer versions of the RXs have sped up the reboot process to
around a second or less, but even so -- I'd say the real problem is
the battery and wiring rather than the RX, though it's nice if the RX
can handle the problem better than going to sleep for a while.

--
Doug McLaren, dougmc@frenzied.us
Never take a laxative and a sleeping pill at the same time!

If it's as you and he says I think it's a poor design. Then again I don't
use fail safe on pcm either.
mk

Yes, Marty, I agree with what you say.
I have never experienced the luxury of PCM or 2.4G, but I have seen many
fine planes reduced to matchwood when the PCM failsafe kicked in on a
landing approach and the engine speed was cut and all controls neutralised.

AFAIK, the failsafe setting of throttle cut is not able to be inhibited on
some/many? 2.4G TX's

I have not personally studied the TX handbook on this and am open to
correction

Trefor

On Tue, 15 Apr 2008 21:57:32 +0100, "Trefor"



Then by all means RTFM before you blather out more nonsense.

All the Futaba receiver manuals are available online except the TM-8
module, which they forgot to include; it can be had for the asking,
and will be added to the download section when the web site is
updated.

The Futaba failsafe in the TM-8 module is at least an order of
magnitude more user-friendly than any previous failsafe in terms of
setting the failsafe throttle position.

I suggest respondents herein ignore your wrong-headed opinion, and
lend credence to those of us who actually HAVE Futaba SS systems and
the manuals for those systems.

The Futaba FASST failsafe function doesn't have a design flaw.

The flaw lies in the heads of morons who use such systems without
bothering to learn how they work, and letting the onboard flight pack
degrade to the point of failsafe activation is without doubt, moronic,
particularly for >an instructor<.

Perhaps you should stick to 1990 level technology, because the
present-days systems will indeed allow you to shoot yourself in the
foot if you so desire, which seems your intent.

So Friendly Fred, can you disable the fail safe.......................never
mind. I just bought a Fut 9C super and plan to use it until they pry it out
of my cold dead hands.
Or at least until they work the bugs out of the FASST thing.(there were
bugs)
mk
Futaba flier

On Fri, 18 Apr 2008 20:41:55 -0500, "MJKolodziej"


Hold the F/S button  on the Tx module in while turning the Tx power
on.  Continue holding the F/S button until the green LED glows solid
and the red LED starts blinking.

Re-arming F/S is done the same way, and no, you can't re-arm F/S
without turning the Tx off and back on.

I'm sure that will be deemed a design flaw as well . . .

\

Does the failsafe need to be disabled every time the Rx/Tx is turned on, or does
it stay disarmed until you go through the rearming procedure?
--
Jim in NC

On Sun, 20 Apr 2008 22:15:17 -0400, "Morgans"


does

Stays where you left it.

Switching F/S between armed and disarmed states requires holding the
Tx module's F/S button while powering up the Tx.

--------------


I have to agree with Doug. It is now the end user's responsibility to work
around the quirkiness of the system with the methods that Doug recommended.

R/C'ers have been working around system quirks for decades, but just don't
realize or remember it any longer. Such as turning the transmitter on first
and off last. Been doing that for a long-long time. The good news is that as
the manufacturers gain experience with their digitial-digital systems, they
can tinker with the software to eliminate many of the quirks.


Ed Cregger

I'm not arguing the toss here Doug, just making people aware of the problem.
I, and others in my club, have spent countless hours trying to retune our
students' engine, checking fuel tank plumbing, etc etc.,  to prevent
deadsticks, to no avail.

Now we, and others, are aware of this problem, we can make the necessary
adjustments, whether it be 6v batteries, gruntier 4.8v's or anti-glitching
devices, I don't care


OK?

Trefor

That's really a very good description of the problem that Spektrum has had
to deal with, Doug. thanks for the explanation.

It appears that one of the conclusions that can be drawn at this time is
that Futaba and Spektrum both have some issues, and they are trying to deal
with them. So far, I haven't heard about any issues with Airtronics/Sanwa. I
also haven't kept up with the XtremeLink system in recent months, so I'm not
sure if they are still having issues or not. The point is, I think I will
wait another generation or two before committing to any 2.4 GHz system

Harlan

The "failsafe on low battery" situation with Futaba was also inherent
to their PCM receivers and is a "feature" of the system so that you
get a good warning if things are going awry.

As for XtremeLink (XPS), check out the latest article over at
RCModelReviews.  Independent testing have once again proven that
despite the manufacturers claims, XPS doe not hop when it encounters
interference and is therefore more vulnerable than some other brands.

When subjected to reasonable levels of interference Futaba and JR/
Spektrum continued to operate unaffected but under identical
conditions, XPS and Assan both failed, locking up and/or dropping to
failsafe.

It's now becoming clearer as to what's fact and what's fiction in the
world of 2.4GHz.

----------

But one must keep in mind that the quirks mentioned really have nothing to
do with the unit being on the 2.4 GHz band as far as the RF link aspect is
concerned. It would be premature to shun the 2.4 GHz band simply because the
accessory software was flawed. I see the current problems as having to do
with folks developing software with a new impetus toward utilizing some of
the extra bandwidth that is afforded by rules that are regulating the new
band. Sometimes, one can go too far creating in software gizmos that truly
aren't necessary, nor desirable, just because you can, but couldn't before.

Perhaps in the future, programmers will provide a soft toggle that will
permit the end user to toggle off the "fail safe" to low throttle when the
battery voltage is temporarily lower than some arbitrary figure. Or, perhaps
they will allow the end user to choose such a voltage level. We're just
getting started on the possibilities that abound with the increase in
bandwidth that is provided by using the 2.4 GHz band. Surely there will be
some mistakes. That is why my 2.4 GHz systems are being utilized in smaller,
less expensive, aircraft. Once I feel that the bugs have been worked out,
I'll move up in size and expense.

Ed Cregger

On Wed, 16 Apr 2008 03:11:34 -0400, "Ed Cregger"


Move on up, Ed, 'cuz the bugs are fictional.

Except for the scant few Futaba FASST receivers which had the
manufacturing defect, Futaba's FASST systems are quite mature.

As for failsafe, the days of having to go into a programming mode in
the Tx are gone as well.

Failsafe in the FASST system, that is, in the 8 channel version I
have, is "programmed" by putting the throttle stick where you want it
to go when failsafe kicks in, and then pushing a button on the Tx
module - hardly a complicated process and a whole bunch simpler than
anything seen heretofore.

Again, ignore the bone-headed pundits who admit they don't have a
FASST system and don't know what the FASST system manual says about
failsafe activation and programming (and any other subject these
nitwits expound upon, for that matter).

Futaba's FASST systems are the systems we've all been waiting for
decades, ever since proportional radio control systems became
available.

Fred McClellan wrote:

No, it was the transmitters with a DESIGN defect.



Once they redesign the two transmitters that will reprogram themselves
onto a common logical 'channel'

wrote:



Failing to encode a parameter when loading firmware is NOT a design
defect, it is a simple manufacturing error.  If it were a design
defect correction would not be possible without a re-design.

As is your penchant, you got it wrong again.




It is not a "common logical 'channel' by any stretch of your fertile
imagination.  It is a missing identification code, pure and simple.

You guys have fun with your Futaba-bashing session; the fertilizer
being spread here by know-nothings is as usual, nothing short of
astounding.

Geez, Fred, ease up, big fella. A bunch of us own, use and like Futaba stuff
..... usually.
But lets call a spade a spade when they screw up and send out radios  that
should have never  left the production point.
Whether you call it a production or design error, it was an error that
should never have gotten through QA. Their customers had to tell them about
it. Then they were slow to react. Period.

I, for one, am betting that Futaba comes  through this as the better system,
but right now they ought to be reviewing their process control.

Harlan

The point was, it was not a production issue:sets can be 'reprogrammed

to GUID zero by switching on, checking long enough to see the battery i
OK, and switching off.

Its is arguable as to whether any did indeed leave the factor
unprogrammed, as it is common practice when selling sets to perfor
exactly this check in the shop.

You may read the discussion here and make up your own minds

http://www.rcgroups.com/forums/showthread.php?t=79800

--
vintage
-----------------------------------------------------------------------
vintage1's Profile: http://www.rcgroups.com/forums/member.php?u=1202
View this thread: http://www.rcgroups.com/forums/showthread.php?t=84586

The situation with Futaba 2.4GHz is that the affected TXs and TX modules did
indeed suffer from a design defect.  The defact was such that a rapid power
cycle could set the TX "unique" ID (UID) to a common value of zero, thus
ensuring that two TXs suffering from the symptoms will interfere.

AIUI Futaba have performed a redesign (of the software) which ensures the
problem should not recur.  The fix can be applied to existing TXs which requires
they be sent back to the local distributor/importer.


It *is* a common logical channel as the channel selection mechanism for fhss is
code division medium access control.  Ie the channels used at any time are
determined by the TX UID.


I don't think anyone here was Futaba-bashing.  However there was a problem and
the Futaba importers' responce differed in different countries.


--
Boo

Boo wrote:

Thank you for saying what I didn't have the patience to say.

EVERY 2.4Ghz setup has SOME basic design issues. Futaba is probably
(once they have this issue sorted properly), the best, BUT that isn't
going to stop me or anyone else pointing out that this particular issue
was a fundamental design flaw: And in the USA it has NOT been well
handled, unlike Europe where the sets are being swapped out FOC.

Futaba tried to cover the problem up by claiming it was a few sets that
went out unprogrammed, but within days several users had managed to
reset their IDs by switching the sets on and off quickly (long enough to
check the battery, not long enough to fully boot the system) the
transmitters all reset their GUIDS to zero, thus placing them on a
common logical channel.

There is some evidence that leaving the sets on and the batteries
running flat would also cause this, but its not been fully proven.

This effect is fully implied in European distributors documentation on
the problem, but strangely absent from US distributors documentation.

One assumes this is because of the overly litigious nature of US
consumer law.