Loiter Mode is not working while everything else works great

Look at that, you have…0 rxerrors. I start getting 20 before even taking off.

I switched receivers. Was using a receiver for “Devo 10” and then tried a DSM2 receiver which always gave a rock solid signal for me for years. No difference, about same # of rxerrors which is not possible.

Something must be wrong with all my boards and/or them accepting a clean code…they are all from goodluckbuy.

Nice selection for the graph. I am going to check out my RSSI and Noise Floor levels.

I am not familiar with noise floor, what kind of noise it is and what are normal acceptable readings…I going to do a little research on that.

Thanks for sharing.

Well, at this point I only have one solution and it is going to cost me. I am going to order a new APM 2.6 and the LEA-6H GPS directly from 3DRobotics. (I already have 2 power/current modules I bought directly from them)

What version do you have? Where did you get yours?

It has to work then…if it doesn’t it is something else like my ESC’s, motors, wiring…which I doubt.

Once I get everything working 100% and consistently, I will work backwards by method of substitution to find out how can 3 APM 2.6 boards be bad.

I will get to the bottom of this!!! and when I do, I will be able to help folks with what I learned!!!

But for right now, I just want to fly, film, do multiple waypoint missions, do “auto” circles, test and play with geofence.

I just did a test to validate the context of the rxerrors metric by connecting mission planner to the copter via the 3DR Radios and watching the graph of the rxerrors, remote rssi, remote noise, local rssi and local noise. When all was connected I was producing the same graph observed in my the previous post. When I disconnected the power from the copter, the remote rssi dropped and the errors went up. When reconnected the power to the copter everything was restored. I didn’t turn on the R/C transmitter bound to the R/C receiver in any portion of this test.

This tells me the context for 5 metrics rssi, remrssi, noise, remnoise and rxerrors is the 3DR Radio telemetry communication opposed to the R/C transmitter / receiver. I don’t think changing your R/C receiver from the “Devo 10” to the DSM2 is going to influence the rxerrors metric.

I’m using a very old JR 10X with a Spektrum DM9 DSM2 module and an AR9000 Spektrum receiver with one satellite receiver and the PPM Encoder between the receiver and the Pixhawk.

The noise floor is the static noise you hear on your AM radio when it is not tuned to any broadcast station. It’s a term commonly used in the amateur radio community to specify the minimum receiver signal level necessary to hear another station. If you’re below the noise floor, it’s very difficult to interpret what is being communicated.

I was going to suggest putting the FC in a different copter or just assembling the components on the bench for troubleshooting if it isn’t too much trouble. This would tell you if it’s the installation or one of the components. Identification of the issue is 50% of the solution :slight_smile:

Dave (W4DJW)

So the “rxerrors” is for analyzing the the telemetry radios signal/code, not the tx/rx signal?
That is odd, I need to research that, not that I don’t believe your data analysis. The developers know RX has always stood for receiver in the rc hobby industry. The telemetry radios are never really called receivers. The are actually not receivers, the are trans-receivers that both transmit and receive, both air and ground units. They called everything but receivers; telemetry radios, modems, uplink radio, 3DR radios.
Anyway, anything is possible, I’ll do some research on that.

Someone gave me the idea of removing the “TX” wire off the FC to GPS connection so the APM cannot overwrite the settings in the GPS but that did not work either. Loiter was the same. (I had an actual 3D lock, but no data for Hdop or # of Sat.
Anyway, I had to try it.

I don’t mind taking the copter apart piece by piece to troubleshoot it on the bench if that is what it takes, however, what analytical tools can I use on the bench that can give a conclusive result for working in Loiter Mode? I believe I would need an actual flight for that.

The only thing I can think of is having it “on the bench” to troubleshoot is to remove those nasty red boxed Err: GPS-0 and Err: GPS-2 which I get on each and every one of my data logs and the "rxerrors"
I could put it “on the bench” in a big box where I can bring it outside to get the satellites and simulate the copter armed and running. Separate my high power wires, substitute components, etc and record logs until the those nasty error messages disappears.
I don’t think the copter will ever “loiter” with those gps error messages.

Any other ideas on bench testing? Graghical tools to use?

I was thinking more along the lines of solving one problem at a time. If you can eliminate the GPS errors on the bench or in another copter you should be able to isolate that issue in the current copter. If not, you can start looking for it in the GPS, Compass, FC, RX and wiring on the bench free of the ESCs, motors, PDB, PMU and high current wiring…

Once the GPS errors are eliminated, the next step is to address the Loiter jitters. On that note, is your copter’s CG balanced in the center of the FC on both the X & Y axes and in relation to the motor’s lift location? In other words, are any two motors having to work harder than the others?

My CG is balanced front to back and side to side. I build the copter with the a balanced CG in mind.

I agree, I will try to isolate one problem at a time, starting with the GPS errors.

There is nothing I can do to make it work…so I need a new problem solving tool.

I decided to order the APM 2.6 and GPS module directly from 3drobotics. It arrived yesterday.

All I did was substitute the APM and GPS, everything else was from my original setup…EVERYTHING WORKS BEAUTIFULLY now.

I flew in loiter mode, did RTL command and auto landed, I “fenced it” a few times, and also did some way point navigation; it is flawless. (not getting any GPS error messages on the logs)

So now I know the original problem was not in my setup or the other electronics, it is between my “other” APM boards and GPS or a combination of the two.

I will use this working platform to find out why my other APM boards and/or GPS modules are not working well.

Thanks for everyone’s help…keep it coming.

It is not over yet, I would like to make any healthy APM 2+ and GPS (LEA or NEO) module fly flawlessly whether it’s an original board from 3drobotics or not.

Will report back with all my findings!

Good to hear. Yes, do keep us informed of your progress with finding out the origin of the other boards. Sounds interesting. I learned a bit more about PID tuning and have mine dialed in so smooth you could eat supper off of it while it is hovering :slight_smile:

I think I’m going to order a couple more now!

I had the same problem with v3.1.2: Flaky control in loiter, two flyaway crashes and numerous flyaway saves. The logs showed ECODE 2.

I went back to v3.1.0 and my hex flies with the same amazing rock-steadiness as before the upgrade to v3.1.2. The logs are normal, no ECODE 2, and no errors at all.

I’ve been attentive, of course, to calibrations and distancing GPS/Compass module from all else.

The lesson I’ve relearned is that an upgrade is always a Beta test and an easy retreat to last know stable firmware is essential.

(Running 3DR APM2.6 and 3DR GPS/Compass module)

[quote=“fahoenack”]I had the same problem with v3.1.2: Flaky control in loiter, two flyaway crashes and numerous flyaway saves. The logs showed ECODE 2.

I went back to v3.1.0 and my hex flies with the same amazing rock-steadiness as before the upgrade to v3.1.2. The logs are normal, no ECODE 2, and no errors at all.

I’ve been attentive, of course, to calibrations and distancing GPS/Compass module from all else.

The lesson I’ve relearned is that an upgrade is always a Beta test and an easy retreat to last know stable firmware is essential.

(Running 3DR APM2.6 and 3DR GPS/Compass module)[/quote]

Error messages contain a subsystem and a code. The subsystem needs to be included to evaluate what the code means.
Most likely, you had GPS glitches. They have nothing at all to do with what firmware you’re running on the flight controller. GPS reliability varies day-by-day, and 3.1.2 is a very solid release.

“Error messages contain a subsystem and a code. The subsystem needs to be included to evaluate what the code means”

jschall - can you please, explain what the above means in more detail? It would be very helpful for me and I am sure for a lot of the folks viewing this thread.
What is a subsystem, where is it located (how do we look it up)? How, specifically, do we “include” the subsystem with the code for evaluation?

Also, since you are a developer, you are one of the few which could answer this question:
The “rxerrors” in the tuning graph of the main flight data screen in mission planner are errors from what device?
The telemetry radios, the actual receiver, or the gps receiver?

fahoenack - I can confirm that v3.1.2 works perfectly in all the flight modes and commands, however there must be a logical explanation why your loiter mode did not work in 3.1.2v and when you switched to 3.1.0v it worked.
Let me ask you a question very important to the “loiter” research I am doing, thus this thread.

When you switched back to 3.1.0v did you change anything else? Anything at all? Any parameters?
Did any re-calibrations? Any physical changes to the copter itself?

…or you just did the update (downgrade) and loiter started working?

[quote=“Belteshazzar”]“Error messages contain a subsystem and a code. The subsystem needs to be included to evaluate what the code means”

jschall - can you please, explain what the above means in more detail? It would be very helpful for me and I am sure for a lot of the folks viewing this thread.
What is a subsystem, where is it located (how do we look it up)? How, specifically, do we “include” the subsystem with the code for evaluation?

Also, since you are a developer, you are one of the few which could answer this question:
The “rxerrors” in the tuning graph of the main flight data screen in mission planner are errors from what device?
The telemetry radios, the actual receiver, or the gps receiver?[/quote]

The format of an error message in the dataflash logs looks like:
ERR,Subsys,Code - for example:
ERR,11,2 would be a GPS glitch

rxerrors are errors on the telemetry radios.

[quote=“jschall”]

Error messages contain a subsystem and a code. The subsystem needs to be included to evaluate what the code means.
Most likely, you had GPS glitches. They have nothing at all to do with what firmware you’re running on the flight controller. GPS reliability varies day-by-day, and 3.1.2 is a very solid release.[/quote]

Here is an example of GPS reliability being inconsistent: http://www.pcworld.com/article/2138121/solar-flare-wednesday-could-mean-radio-blackout-for-gps-communications.html

Very interesting, Dave. I guess I will keep my bird close within visual limits if I fly on Wednesday.
So I heard your bird is so stable you can eat supper on it :smiley: What time is dinner? I’d love to visit SC and fly around the beautiful scenery there!

You just missed dinner :blush:

And after watching these webinars I think I know how to tune the PIDs.

Arducopter Tuning Guide: http://diydrones.com/forum/topics/arducopter-tuning-guide
PID Parameters Explained: http://youtu.be/16Clfh5eBzg
Tuning PID: http://youtu.be/SefKQb9y_B4

The last two are not in the context of flying but they teach you what Dave C. is doing in the first one. The best 1.25 hours studying PID tuning I’ve spent yet. I’m extremely happy with the Pixhawk.

Here is a snapshot of what it looks like here. Not too green yet but in about 4 weeks that is all going to change.
[attachment=0]G0010999.png[/attachment]

Belteshazzar
I just changed back to v3.1.0. Since it had been working before, there was nothing to change. However during my efforts to get 3.1.2 to work, I did recalibrate the compass and accel. a few times.

Here’s what I have:
Hexcopter (a knockoff Flameweel)
3DR APM2.6 board
3DR GPS/Compass
3DR Power module
Turnigy 9x and turnigy rx
4S 2600mAh
Martinez board gimbals hanging off the bottom with a GoPro

The only clear difference from what I’ve been reading here is that mine’s a Hex. Also, while using 3.1.0 the first time, I was using Position Mode (mode 8), having no occasion to know that mode 8 was blank in Mission Planner 1.2.98. After the upgrade to 3.1.2 and the first huge flyaway, the log shows “Error Mode 8” in addition to the GPS errors. I haven’t used mode 8 since, but nevertheless had two more major flyaway wrecks and some fortunate saves, even after removing mode 8. Since retreating to 3.1.0, I have not tried mode 8. Many flights in Loiter, RTL and Auto, windy conditions, no errors and rock-solid performance. These programmer geniuses know what there doing!

W4DJW - Beautiful landscape, I trying to imagine everything green. What’s that, about 150ft up?
Great links for PID tunning. I will check in detail later when my loiter dilemma is fixed and is working on all my boards.

fahoenack - I believe I know why your Loiter mode is not working on 3.1.2v
Seems switching between versions using the standard “Initial Setup” screen in MP planner is not enough.
You need to erase and reset the APM. (I found this in one of the forums)
You have to erase the eeprom which could still have “some memory” of the old firmware, afterwards.

AFTER updating the firmware you want click on the Terminal Tab (CLI)
Select correct COM Port, make sure BAUD is set to 115200.
Click on the Connect APM tab
At the command line…
Type “setup” press ENTER
Type “reset” press ENTER,
Type “Y” and press ENTER
You should see the response: Reboot APM
Physically press the reset button on the APM board (just hold it down for a sec) It will display "erasing eeprom"
Done
You can press Enter 3 times to stop the screen from scrolling showing all the present parameters if you want.
This process is the “clean” way to change to a new firmware update…or downgrade, if you wish

By the way, if you are using a older firmware that has Position mode, don’t be afraid to try it if your Loiter mode is working well. It uses the same sensors, calibrations, etc as Loiter mode with the only difference that it doesn’t use the barometer sensor to hold altitude. If “Loiter” works, 'Position" has to work!

I will write a detailed post when I have time to help folks to avoid fly-aways. There is a way in APM to minimize (actually eliminate it, if the APM is setup correctly and you got good GPS signal) fly-aways/crashes by incorporating several failsafes and then TESTING them.
Fly-aways should not happen with such a sophisticated flight controller as the AMP2+ or Pixhauk.
That’s the whole beauty of it!!!

Belteshazzar,

Thanks for the info about clearing and resetting the APM. It seemed a logical thing to do when going to an earlier version but I did not know how at the time. I should read more forums!

How did you solve your problem that began this thread in the first place? I must have missed the post. I’m guessing that will be the subject of your future post about flyaways. The sooner the better!

…clear and reset when going to an earlier version or UPGRADING to a new one, clearing the eeprom process should always be done to eliminate all doubt of a messed up firmware change.

I did not solve the original problem of the Loiter mode not working on a healthy apm 2+ board and gps unit… I only fixed the problem partially by buying the apm 2.6 board and gps module directly from 3drobotics which comes ready all flashed with the latest stable versions both board and gps…and of coarse…it works perfectly.

This not a solution. Trying to get any decent apm board to work from scratch. My APM boards are perfect and yet they do not “Loiter”

I am using the working 3dr boards as platform to trouble shoot the non working boards.

Getting close to the solution, it looks it is not the boards themselves but how they communicate with the GPS unit.

Will report solution, hopefully soon.

And yes, I will be writing the anti-fly-aways solutions soon…it has everything to do with flying in Loiter mode so fits perfect to the thread’s subject.

Not resolved yet but I have some answers I been looking for.

The root of the problem is what I suspected; the communication between the GPS and the APM.

When using the original GPS ordered from 3drobotics (a Ublox LEA-6H) all my other APM 2.6 boards work perfectly in Loiter mode…actually works in every mode.

The moment I try to use a different GPS with the same APM2.6 board, Loiter doesn’t work.
I realize when I switch a GPS unit, I also am changing the compass which needs re-calibration; it is not the compasses, they work perfect and are locked in to accuracy of about 1 degree.

Using Ublox, I am trying to configure the other Ublox GPS units I have, 2 NEO-6M and 2 LEA-6H to mirror the settings in the original 3DR one.

There seems to be a partial block in communication. Cannot configure the gps units via Ublox by uploading a txt file without some error messages and neither by directly using the configuration view.
Starting with the original gps unit from 3DR; cannot view its present settings in the configuration view screen.
Ublox, however is communicating fine with the all the GPS units as far as receiving all location data.
It displays the 3D fix with all the “pretty colorful graphs” working well showing all the satellites it is getting, etc.

I believe this is the root of the problem a lot of people are having with their copter not working in Loiter Mode, for this problem is somewhat concealed because this GPS / APM miss-communication will not show on any log/telemetry graph or on live tuning nor will it produce a gps error message in the logs.
The data that does show is an excellent hdop, for example, close to 1 and tracking 12 satellites…yet…Loiter will not work. This is tricky because it makes you think everything with the gps unit is fine.

First I will try to find if there is a data matrix to where mission planner is reporting this error.
Second, I will have to find out how to “see” the exact settings on the 3DR gps and duplicate them on the other gps units. (It’s almost like the unit has this data blocked, but I am hoping this is just my imagination)
I need to find out why I can not view and change the actual gps settings using Ublox while everything else works and shows up.

Hope to report soon…