34 replies to this topic

[Terry]

Not sure where to post this and not sure what to post but I have an odd problem and my brain needs a boost. Just hope that by wrighting it down it may spark an idea !

Here goes, I have been flying a twinstar with an FY21AP auto pilot and 100mW 5.8Ghz video with no problems for 6 months. The other day while testing a 500mW 5.8Ghz video TX I found the RTH failed to work. The Futaba FASST dose not have a failsafe so I made one using PICs which again has been working fine. I should point out it uses the LED on the RX to trigger the PIC into failsafe.

When I checked the on board video I could hear the motors failed to run as they should have gone to half throttle. I checked the failsafe on the ground and it worked perfect. I tried moving the 500mW TX about and holding it near different bits to see if it would make it fail but no.

I flew a few more times with both the 100mW and the 500mW TX and it seems that with the 500mW the RTH dose nothing at all and with the 100mW it returns but the motors cut in and out. This may not be correct but its how it seems at the moment.

Has anyone else had odd effects when using 5.8Ghz or the FASST system?


Terry

Edited by Terry, 30 March 2011 - 06:42 AM.

[Mr.RC-Cam]

Tough one. FWIW, it's not unusual for a perfect working FPV installation, with lots of reliable use, to suddenly experience RFI/EMI issues. It is often an indication that it was borderline all along. Sometimes it means something is failing, perhaps from fatigue.

If you are not able to duplicate it on the bench then you will have to experiment with shotgun fixes. If you are sure that the basic failsafe hardware and firmware is robust then some common mode filters on all its cables would be high on the list. If you go to the effort to install the Toroids then keep in mind that they are very inefficient at microwave frequencies. So to compensate you need a significant number of wire wraps on them; Too few wraps just adds a dumb payload and offers no relief.

[Kilrah]

Are the ESCs connected to the receiver directly or to the AP21?

[Terry]

The ESCs are connected to the PIC failsafe that is connected to the RX. When the RX red LED lights it waits 2 seconds then switches the PICs to send all controls surfaces to centre including the motor (half speed) and set the FY21AP to RTH.

It may be nothing to do with RF but it looks the most likely cause at the moment apart from the fact I failed to recreate the fault on the ground.

I plan to take an identical RX and failsafe from my BiTwinstar and test it in this plane first. Just a bit more info, the video system is in the nose with no connection what so ever to the r/c RX which is just behind the wing but at the bottom. Also the video aerial is V while the r/c aerial is H.


Terry

Edited by Terry, 30 March 2011 - 06:41 AM.

[Terry]

Well its nothing to do with the 5.8Ghz video TX as the fault was there when I left it unplugged

Also my other RX and failsafe play up when used on this plane even though they worked fine in the other plane. So that starts to point the finger at the ESCs and the BEC. Im using Turigy 40A controllers which I guess are switching regs? Can anyone point me to a good low noise BEC to try?


Terry

[Mr.RC-Cam]

If you trust that your BEC's are working, but think they have excessive switching ripple, then how about cleaning up the DC with an LC filter?

[Terry]

Yep in the long term I will do that if it proves to be the case but I want a low effort way of testing it. It may not be the ripple it may be dips or spikes I just dont know yet. The PIC failsafe dose continue to run or it would fail to give any pulses and there would be no control of the plane at all. I think it may be the enable/disable signal from the RX is borderline and any noise is tipping it over the edge. Funny how it only ever dose it in the air and not when ground testing though.

Terry

[Mr.RC-Cam]

Got it -- you are wise to do the temporary BEC sub. Perhaps you have an unused brushed or brushless ESC that you can use just for its BEC?

Just curious, which ESC are you using now? How many servos on it and what is the battery voltage?

FWIW, if the PIC based failsafe is using the internal OSC feature then voltage definitely impacts code timing accuracy. So voltage variations could affect the failsafe's detection accuracy. If the PIC is using an external Xtal for the clock then voltage is not as critical. Furthermore, if the brownout feature is enabled then it can create problems with unexpected voltage dips.

[Terry]

The ESCs are Turnigy 40A with a 3A BEC, I tested the output and its 5.25v.
4 x Tiny S servos and the FY21AP so its not stressed. 2S 5000mAh lipo.

Failsafe detection is not effected as I use the red data loss LED output on the FASST RX to trigger it. I have tested the PIC enable pin and it switches at 1.45v and the RX output as I have removed the LED swings from 0-3v.

As I said before the PIC is still running as it passes the normal control pulse in one pin and out another with no problems. It seems either the PIC is ignoring the data loss signal or the RX is not giving it but I dont know which.


Terry

[Mr.RC-Cam]

Too bad it won't do it on the bench. Hope you find the troublemaker!

[Kilrah]

Hmm. How are you testing failsafe on the ground and in the air? Same or different method? By turning radio off?

[Terry]

Yes turning off the radio, when I watch the onboard video back I can hear that the motors fail to restart after 2 seconds. I have run the motors at different speeds for long periods on the ground to simulate flying and turned the radio off and on many times but it never fails.

Terry

[Mr.RC-Cam]

I have a feeling there is a something important in the details that we are missing.

When you test it on the ground, you turn off the R/C Tx, and failsafe works fine. But is that how you were testing in the air when it did not work? That is, are you turning off the R/C Tx to test it in flight?

[Terry]

Yes I only have a 6 channel TX so I turn it off to force a failsafe.

Update, just to confuse things it worked great just now in the air. It flew back from 3000ft out and 900ft high and just circled overhead without loosing any hight. The only minor change I made was to add a 10k resistor in the enable feed, not sure if it is this that made it work or luck!
I suppose I should remove it and see if the problem returns but I dont have much time at the moment


Terry

[Mr.RC-Cam]

The only minor change I made was to add a 10k resistor in the enable feed, not sure if it is this that made it work or luck!

Hmm, let's dig deeper. What PIC are you using? Which pin is used for failsafe enable? Is the internal weak pull-up resistor enabled on the pin?

[Terry]

There are 3 x 12F675 that enable on pin4 with pull ups off.

The software monitors this pin so that any good packets will turn off the failsafe and needs complete loss of good packets for 2 seconds to enable it. This was done to try and ensure that the failsafe would only enable if the TX was turned off but I guess it also means any negative spike that goes lower than 1.5v will cause the failsafe to kick out.


Terry

[Mr.RC-Cam]

The pin-4 choice is good since it is TTL and not ST. A 2-second delay sounds appropriate too.

Perhaps it would be worth changing the code so that the failsafe input signal used a "fuel gauge" debounce algorithm to control the feature. With this method the input pin controls a software counter; It counts up when the failsafe enable pin is active and it counts down when it is inactive. The actual failsafe feature is on when the counter increments past a threshold value and it remains on until it decrements to zero (or some suitable low threshold value). In between the values is the hysteresis. Your increment and decrement do not need to be symmetrical, so the resulting activate/de-activate delays can be different.

But none of this is necessary if the problem in not related to the code. So hopefully you determine the cause so you can fix it.

[Terry]

I must admit the whole thing was a bit of a rush job as I couldnt believe Futaba didnt add a failsafe to all channels, I thought it was standard these days.

In hindsight I should of added a 0.25 second delay to ensure the data was good before exiting failsafe but my mind was thinking more about getting stuck in failsafe and not having control. It seems we may have got to the bottom of it though


Thanks, Terry

[Mr.RC-Cam]

I couldnt believe Futaba didnt add a failsafe to all channels, I thought it was standard these days.

I agree, it's amazing that programmable failsafe wasn't provided since it is just a "software" feature. But JR has this issue too. I suppose it is their way to get us to buy the more expensive R/C systems.

[Terry]

Just a quick update to say it failed to work again today. Will update again when I have more info!

Terry