Re: garris2's post above, I agree that it would be nice to have a way to maintain Option A menu control while also having a way to control the guardian gain in flight, as I prefer navigating the menus using Option A.

However, if it comes down to a choice I'd pick the guardian control with Aux2. The way I have my guardian control set up is no stabilization on switch pos 0 and mid-stabilization on switch pos 1. I want this in the event the guardian ever comes loose or malfunctions in flight, then I have a way to override it (i.e. turning it off). I don't like to mess around with the menu in flight, as I have crashed before while doing this - so for me it's OK to have a slightly more clumsy menu navigation system if it means I can have active control over the guardian gain.

Also - if I'm understanding the system correctly, the "Stabilizer Overall Gain" menu setting takes over during RTH, and in non-RTH mode, the Aux2 active setting takes precedence - is this correct? And if so, is the "Stabilizer Overall Gain" setting used during the RTH Carlyle method test?

Hello billpa,

Just checking - have you been able to recreate this lockout situation?

RHash, here is an update. I'm still having issues, even with a brand new OSD (firmware 10.12 and 2.55) Since I installed the Guardian, I started getting 1A0000 and 1D0000 errors at bootup on both OSDs. I was getting Stabilizer disconnected errors before I installed version 10.12 / 2.55 but they are somewhat random. The errors at bootup only occur about 50% of the time, other times it boots up with no errors and RTH works fine. I'm a little nervous about letting my Skwalker go for a ride at this time.

Thanks for the update. I still haven't started rebuilding my FPV plane yet - hopefully by the time I finish it someone will have found the source/solution to this.

Until then I'd be reluctant to take something up with the current firmware.

RHash

RHash, we were not able to get a repro of this issue (after many hours of trying), and haven't had any other reports of something similar that I'm aware of, with any firmware version.

I don't know if it was a frayed cable, an issue with your specific hardware, or something else. I don't think the issue was firmware related, since you were running version 10.04 when it happened, which has been out there most of the summer/fall I believe, with nothing similar. I'm more than happy to replace your hardware if you are concerned with it - at least we can be sure it's not a lurking issue with your hw, if we do that. Just open a ticket at http://ticket.eagletreesystems.com and we'll start that process.

thekubiaks, sorry to hear that you got the 1A/1D messages again. Those pertain to the graphics display (and are innocuous), and would not be related to the issue RHash saw. I'll be answering your PM about those later - I'll be sending you a version that disables those completely.

But, I want to confirm that the "stabilizer disconnected" error you saw only happened:
a) when you first set up the Guardian, but did not have the guardian installed.
b) briefly, during USB configuration, power cycling, or similar? It's normal for that message to appear during updates.

In other words, did you see a case where the "stabilizer disconnected" message stayed on the screen, with the guardian connected?

Originally Posted by billpa

thekubiaks, sorry to hear that you got the 1A/1D messages again. Those pertain to the graphics display (and are innocuous), and would not be related to the issue RHash saw. I'll be answering your PM about those later - I'll be sending you a version that disables those completely.

But, I want to confirm that the "stabilizer disconnected" error you saw only happened:
a) when you first set up the Guardian, but did not have the guardian installed.
b) briefly, during USB configuration, power cycling, or similar? It's normal for that message to appear during updates.

In other words, did you see a case where the "stabilizer disconnected" message stayed on the screen, with the guardian connected?

The Stabilizer Disconnected message appeared with the Guardian installed and Guardian activated in firmware. I wasn't doing any updates. The Stabilizer Disconnected message was intermittent when I got the 1A0000 and 1D0000 messages only and for a brief moment. I would see the Stabilizer Disconnected message for less than a second and then it would go away. It has to be something in the Guardian hardware/firmware, I never had a single issue until I installed the Guardian.

OK billpa I think I will open a ticket. My electronics have been through a few crashes already, so maybe the problem is an intermittent hardware issue. Maybe a cracked board/trace or something?

Thanks for your help!

I have trouble perhaps failsafe problems. I have a dragon link LRS and put the failsafe has this done to no movement, when I get to 1.5 km far , the osd tells me "to far of home" and activates the RTH as if I lost the radio connection, if you can help me would be very good for me, I broke a skywalker, I lost a camera among other things maybe I cant change something on the guardian configuration, its like the RHT don´t recognice the servos when the RX radio don´t output signal and don´t return to home alone. Only when I switch manually
Im new on this…
I hope somebody can help me.Im very worried
regards NAcho from Argentina

Hello to everybody. I wanted to ask you guys to take a look at what happened to me as it looks similar to what other have posted. Basically I suffered a crash after experiencing a couple of glitches when I lost total control of my Skywalker after manually enabling RTH. My Gear is as follows:

• Plane: 1900mm Skywalker
• R/C: Futaba 9CAP PCM with synthesized TX and RX
• Eagletree: OSD, elogger v4, GPS, guardian expander, Air speed expander, Temp sensor, brushless RPM sensor
• Batteries: 4s 5800mA for motor, 3s 3600mA for video cam and tx and radio rx (stepped down with turnigy bec).
• Video system: 2.4 GHz 500mw
• On the ground I have Eagle eyes on a Readymade RC tracker with an 8Bbi Antenna
• Fat shark goggles

The story can be seen here:

FPV Over Clouds at Dawn Ending in a Crash in San Pedro Sula, Honduras (14 min 49 sec)

Unfortunately (yeah I learned my lesson) I was not recording the video feed from the plane and osd, but I was able to recover the video from the Gopro. The annotations on the video point out what was going on.

In line to what others have stated on this thread, I recall that just before taking off, the GPS struggled to get a position, but afterwards it had 13 sats on screen. I then reset the home position and took off without resetting the OSD. I have the RTH to be activated with the throttle fail safe, but instead of using trim, I programmed a throttle cut switch which work perfectly on the bench test. I also had the guardian gain on aux 2 and set about 50%.

I am attaching the FDR file and my config file so billpa can take a look at them. Now the plane was lost for more than 2 hrs with the system still running, so I figured the data recorder was not going to show much, but I can’t even get the file to run properly on the software. It’s like the file is corrupt.
I was very lucky to recover all my gear nearly intact, but I want to solve this issue as I know I will not be as lucky a second time.

So what do you think happened?

Hi, and sorry to hear about your crash. Glad things were recovered intact, though.

You are right - it's very difficult to do much analysis without seeing the OSD overlay. Also, the .FDR file you posted is empty, which is very odd. When you download data from the logger via USB, does it instantly complete, or does it take some time to download?

What appears to be happening is that the OSD is attempting RTH, and is initally able to return the plane in the direction of home. Later, I hear the throttle alternating between high and off, which could indicate that GPS fix is periodically being lost. RTH will go into failsafe without a valid GPS fix.

There does not appear to be any sort of OSD lockup, based on what I am seeing/hearing?

Also, I noticed that the last several seconds of the recording did not have audio? Was this just a glitch with the GoPro?

So, I think the big questions are:

a) (most important) Why you are seeing glitches with your Rx. It would be very interesting to see the servo deflection display when this is happening, and it would be interesting also to see the RSSI level (if it can be extracted with this RX). I assume you are at 72 MHz, rather than 2.4Ghz?

b) Why GPS is losing fix, if it is. Do you have our GPS V4 with the torroid ring? And, is it mounted as far away from your VTx as possible?

c) Why there is no data in your logger. Seeing the logged data would let us know whether the GPS was losing fix, among other things. Let me know whether downloading takes a non-trivial amount of time. If it does not, can you check under "Hardware, Choose what to log in recorder" and make sure that GPS and other parameters are logged?

Thanks for the quick reply.

1. A) I have 72Mhz PCM, and I have only had glitches with this plane setup. I don’t know if it may be that the uBEC (with toroid ring) is causing interference. I have heard that some people have had trouble with some of these. I read how to do the RSSI but I really don’t want to mess with the Rx as I intend to move to a long range UHF system shortly. On another note, isn’t the RTH supposed to activate when there is interference? In all of the cases where I have had glitches, the RTH did not come on, which is why I turned it on to test it. However I could not recover from it; I fought with it for the last minute of fight.
   
   
2. B) I do have the GPS V4 with toroid ring. It was mounted on the front part of the plane (behind the Go Pro). The Video Tx is mounted right behind the engine (3/4 of the fuselage). About 25-26 inches apart. See attached pic. Maybe it works better if it is on top of the wing? I had noticed in previous flight that the speed and altitude would freeze up for a couple of seconds, almost sure due to a lost GPS fix. The entire system is new this was only like the 4th flight so I really don’t have more experience from the system with this setup.
   
   
3. C) It did take some time… more than 1 minute. I had all the parameters turned on to be logged. I actually downloaded the file 3 times with the same result. I then reseted the memory and did a bench test, downloaded the new file and that one was ok. Something funny with the software though, is that very frequently it tells me I have to update the firmware. I click the update buttons, apparently everything updates, but the update buttons don’t disappear. It is my understanding that once you are up to date with the firmware the buttons go away? They never have.

The last few seconds without sound was actually due to the Go pro getting wet on impact into a puddle, which damaged the file. I had to do some magic to recover it.

Just realized that the link to the video does not have the full description of what happened. please go to the youtube site to read the full description.
Any thoughts?

Hello hermanacosta5,

Very sorry to hear about your crash (I know the feeling of helplessly watching your plane go down during loss of control during RTH ).

Before you tried to regain control just before the crash, it appears as if the system did a slow right turn toward home base. After you tried to take manual control, the system looked like it initiated a slow left turn to home base. What I think may have happened here (ignoring for a moment the altitude problem) is that you may have briefly got control and "nudged" the heading enough to where the system determined a left turn was the appropriate home base direction.

Regarding the altitude, I notice from the config file that the "UseBaroForRTHAlt=0" - I think this means that the system is to ignore the pitot tube altimeter and instead use the GPS-derived altitude. This may be where much of the problem is. I don't use GPS altitude as a reference because it is not referenced to your home base, but to some unknown "absolute" reference (sea level?) Also, I think that GPS altitude is not as accurate in reporting altitude data as it is for position data (especially when you have satellites dropping out). I have flown from the beach before - I have seen my GPS read my initial altitude at 100 feet or so (???) even when I have like 9 satellites locked in. I strongly recommend you use the ET altimeter as the RTH altitude.

Your RTH altitude is set for 545, but the system may have thought the plane was flying higher than that if the GPS lock was not solid, thus descending ultimately into the ground. Also, if your home base altitude is about 500 ft or more above sea level, this is a setup for disaster if you're using GPS altitude. If you had totally lost GPS lock while in flight, I'm not sure what the system would do. With a baro altimeter, the system should at least hold the programmed altitude, referenced to your home base (though wandering around aimlessly for awhile).

It's curious that your throttle sounded like it went to climb setting (3301) while descending. It should not have done that.

BTW, that is some spectacular scenery you fly at! Great video. I really need to get myself a go pro.

Hi,

Re RTH activating with Rx interference, based on your OSD configuration, RTH should activate when either:
a) the Rx stops sending pulses at all, or sends illegal pulses
b) the Rx goes into failsafe, and the throttle failsafe pulses are the same as the ones detected when you turned off your radio during the wizard.

"a" should never happen with PCM, so my assumption is that the Rx (or at least the throttle channel) is not being driven to the failsafe position. I've heard rare reports that some Rx's (likely not Futaba) actually drive a different failsafe position in some circumstances. Or, if you reprogrammed your failsafes after the wizard was run, this could happen. When you turn off your Tx now, does RTH engage?

I would recommend turning on "servo deflections" display, which will let us see exactly what your Rx is outputting for throttle. Alternatively (or additionally) you could turn on throttle logging in the eLogger, and connect the Rx throttle output to the eLogger's throttle input via the Y cable, but seeing the info on the video real time makes things easier to track down.

Re GPS mounting, it's ideal to mount the GPS by itself, but I would be surprised if it would help here (it's usually proximity to the VTx that causes problems, and those are really rare with the toroid GPS).

Re data in the logger, it sounds like data were there, but there may have been some corruption of the data during the crash. We have a way of retrieving the raw data remotely, so if you see the download issue again, please don't clear the logger. Sorry, I know that's not too helpful now. :S

Thanks RHash for the comments on the video! Let me tell you that I was more concerned in recovering the video than the equipment itself (I mean obviously I was thrilled to get everything back intact), but recovering the video has its story.

Here is when Murphy’s Law kicked in:
I was so excited to see my first “above the clouds video” even though it was less than 1000 ft (or so said the GPS altitude). I decided to land, but quickly realized new clouds were rising… so I decided to do 1 more lap (where it all happened). After the crash, could not find the plane, did not have GPS tracking in Google earth, and did not have recording… Once the plane was found (a search party was summoned, several people that live nearby helped us), they brought it back without the Gopro… I just thought “forget the plane, get me my cam!!!”. A few mins later they came back with it (yay!!)… it was wet… fell in a puddle… and just that morning I had changed the back cover to the non-water proof back cover… after all, I was not flying over water was I? After drying the sim card I found out that the video was there, but could be played because the gopro did not write the index to the file. I used 3rd party software to recover the video file, but only was able to without audio. Once the Gopro revived, it fixed the file with audio, but clipped the video a few seconds before impact (this is why the video ends without audio). Sigh.. in other words I am proud of my vid!

Now on the altimeter… yes I agree that barometric altimeter would be best.. I am only about 100 ft above sea level, but I have seen the GPS altitude jump a bit. It has even been -100 some times. Could this be an indication that the GPS is bad? Any ways I did have planned to get the barometric altimeter.
It does look that the guardian was in control of the plane all the way down (very elegant turns and extremely close near misses with trees). However every time it glitch before, it went to full throttle and slow left turn… fail safe maybe? The difference this time is that it never gave me back control.