I'd like some feedback

| 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, snipped-for-privacy@frenzied.us
Never take a laxative and a sleeping pill at the same time!
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
wrote:

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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
wrote:

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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Fri, 18 Apr 2008 20:41:55 -0500, "MJKolodziej"

<SNIP>
Yes, easily.
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 . . .
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
\

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


Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Sun, 20 Apr 2008 22:15:17 -0400, "Morgans"

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.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

--------------
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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

----------
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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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'
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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.
<SNIP>

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.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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?ty800
-- vintage ----------------------------------------------------------------------- vintage1's Profile: http://www.rcgroups.com/forums/member.php?u 02 View this thread: http://www.rcgroups.com/forums/showthread.php?t 586
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.