Jump to content
Terry

Odd problem

Recommended Posts

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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

Terry

Share this post


Link to post
Share on other sites

Well by luck I found the problem and it was something really unexpected !!!

I took the plane out for another test flight but the ESCs failed to arm. I tryed adjusting the stick and even the trims but no luck. The other controls were all ok, even the autopilot was working.

I took the plane back home and changed the Y cable and the problem was gone. I have tested the RTH failsafe 3 times now and it has flown back solid as a rock :)

The Y cable was not home made and I have no idea where I got it but I know where it is now!

Terry

Share this post


Link to post
Share on other sites

Indeed , I cant believe how many hours I have spent because of a servo lead!

All this high tech stuff and I didnt even consider that a piece of wire could be at fault. I wonder how many times when guys say that some bit of r/c tech isnt working correctly the answer is this simple?

I expect most of us have servo extensions that we have moved from model to model over the years.

Terry

Share this post


Link to post
Share on other sites
I wonder how many times when guys say that some bit of r/c tech isnt working correctly the answer is this simple?

I can certainly appreciate that; I have tech support duty and customers will often hear me say to Suspect Everything, even the things they don't think is the problem. Those that act on this simple advice are usually more successful in solving the odd problems.

It is always a relief to find that a horrible problem is caused by something that is simple to correct. Let's hope yours stays fixed! :)

Share this post


Link to post
Share on other sites

Terry, what is it with these FY21AP's !

I maidened my Skywalker over this weekend (with all brand new gear) and the FY21AP seems to 'glitch' with it randomly switching modes during flight.

I've watched the recorded video and it flits between RC & ACM quite often and occasionally between RC & ABM (that's 2 different switches on the RC Tx).

I haven't enough stick time on it yet, but it doesn't seem to do it close in (might be a red herring though).

RTH does work as I tested it at 500 metres out and turned off my RC Tx - it promptly turned tail and came home.

I'm scratching my head as to what it can be but will certainly look into the supplied interconnecting leads.

I'm running with Futaba T9 Super to Corona RPD81 on 35MHz and the FY21AP II & AP117 OSD.

If anyone has any suggestions, I'm all ears !

Nigel.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×