[ggrif]

Having trouble with RTB consistent performance.  Usually when I select RTB/land it works flawlessly. Sometimes though, my frame hares off to the east or south when I select the RTB flight mode.  After a manual return and land and a change of pants all is good again. 
In an effort to find out whats going on I put the BG Revo and OP V9 GPS on a bare frame.  On a plastic barrel on the street in front of my driveway. Mags a re calibrated, everything green.
For 20 minutes or so I observed normal oscillations seen when GPS is close to ground in urban area.  Then it hared off to the east several hundred yards, while sitting on the barrel, stationary. I have a screen cap of the trail. no UAV file though.  Turned on logging and did catch the south west jaunt. 
Curious if someone can give some insight.

Edit: I guess the log file is too big?

[Mateusz]

Spikes are often caused by multipath reflection from buildings. So GPS gets signal with two different timings and computes location incorrectly. Afaik this can be improved by using helical antenna it detects fewer SATs but is more robust against multipath reflections. Wiki has how to on making such antenna and results. Patch antenna has this problem so you don't fly it close to buildings.

[ggrif]

Thanks for your reply.
I'm in the process of building the antenna described in the wiki and am aware of the multipath issue.  Just didn't think any spikes would be so long as I saw today.  Going to go to the field, no buildings nearby, and do the same test.  Field is where I experienced the almost-flyaways.

[Mateusz]

One more thing. This red route show by GPS is the cooked state, not RAW GPS I think. You need to right click on the map and select "show diagnostics".
It will show you green route which is RAW GPS. If you were using EKF (INS13) then having it long stationary can cause EKF to diverge and give really bad results, that is known and normal.
I suggest observing RAW GPS behaviour instead.

[ggrif]

Thank you again Mateusz.  I was not aware of the RAW GPS option, I will check it out.

[ggrif]

Interesting  (to me anyway), just ran a 40 min trace on a Naza/Sparky combo, no radical jumps at all. Also, area of drift is smaller. Green RAW trace is exactly where frame is sitting 

Same conditions as previous test.

EDIT: ran yet another 40 minute trace, this time on a V9/OP Revo test quad.  No radical jumps at all, traces stayed within a reasonable area.

Guess maybe I won't fly the V9 in the first post anymore.

[TheOtherCliff]

Before the first flight of the day, you should plug the battery in, put it in the flight area, and wait for the GPS to download the almanac which takes 12 minutes (after first fix) so figure 15 minutes to be safe.  For GPS's with a battery/supercap the flights soon after the first one (not 6 hours), you can just wait maybe 2 minutes? because it already knows which sats are visible.  Tiny / cheap GPS units don't have memory and may need 15 minutes before each flight???

If you don't wait that long, then as you fly and it finds another satellite and adds it and can jump (usually only a few meters) when a sat is added or removed.

All GPS's have a smoothing algorithm in them.  By default we set the UBX GPS to use "airborne 1g" smoothing.  The Naza GPS uses a setting that is smoother than that.  The Naza is not designed to accelerate or move very quickly.  I use both the V9 and the Naza and have very good opinions of both of them.

Are you aware that there is a long standing glitch in the V9 firmware that has been fixed since 15.09?  It causes some GPS packets to be dropped.  Not too serious, but you should upgrade.  I am running the new firmware in my V9's.  You can get it from a current next or rel-16.09 build.  Flash it with OpUploadTool which you also build.

Flying around buildings and large paved areas and lots of metal are sources of multipathing too.

I live in a typical subdivision.  If I set my quad on the back porch for a long test and logging, that I get GPS multipath jumps of even 100m or so maybe every hour or so.  A jump is where it suddenly (usually 1 or 2 updates at 5 updates per second) jumps 50m-100m and slowly comes back over the next 10s-30s.

[ggrif]

Thanks TheOtherCliff for your reply.

I must admit I've read your advice re time required to download the almanac in other posts as well as your reply above.  I haven't always followed it thinking that if I had a 3D lock with 7 sats all was good. I did not know about jumps caused by sats being added/removed.  I will follow this best practice from this point on.

The motivation for the first post above was, as stated, inconsistent RTB performance.  What I failed to mention was that the particular V9 in question has been involved in several crashes one of which resulted in the unit being ejected from the quad.  Although it looks fine other then a few superficial scratches I've had enough trouble with it that I thought I'd do some testing.  Now, after several static test sessions over the past week comparing results from 3 V9's and a Naza I'm convinced the suspect V9 is damaged.  It consistently zigs/zags 10 meters or so NorthWest to SouthEast with occassional 100-300 meter jumps in the same directions.  I'm sure glad there are now viable replacements available at reasonable cost!

One last question, when observing the system health gadget with a V9 in service, LP16.09, the GPS widget turns black with a red X frequently.  I do not see this behavior with the Naza.  Seems like a pretty serious fault, indicates the GPS is completely off-line, right?

Thanks again!  Learned a lot from your posts!




I am aware of the V9 firmware glitch.  I am flying 16.09 RC1 on all my frames.

[Mateusz]

One last question, when observing the system health gadget with a V9 in service, LP16.09, the GPS widget turns black with a red X frequently.  I do not see this behavior with the Naza.  Seems like a pretty serious fault, indicates the GPS is completely off-line, right?

I can reply to this. Yes when you get red cross on black-square that means that FC is configured for GPS, but GPS is not sending anything. This is ok for a few seconds after powering everything up, but definitely should not happen in flight. Red square is working serial communication but not enough sats. Yellow square is when serial is working and enough sats for low quality fix, this will give very bad/slopy estimated of position and you shouldn't not fly this. Green is what should be used, when there is enough sats and position fix is good/stable.

[ggrif]

Thanks. This black square/red X behavior has to be, I'm thinking, an electrical fault where the GPS loses all power. I've seen it enough times over the past few years when I've forgotten to plug the GPS in!
So, if it is a complete lose of power for a very short period of time, I'm surprised when it comes back online (within a second or less) that it still has a 3D fix with the same number of sats.  Think I'll dig deeper into the diagnostics and scopes and see if I can figure out what's going on.