Copter problem - descends or climbs -

Have you seen mine? and can you tell me why this was never issue with previous version? and if you read GPS altitude, it is quite the same with barometric. It was a calm day, and drone wasnt moving to sides

Hi @Vaclav_Demeter
i cant understand your problem, by looking at the log everything was ok and FC reacted well to throttle change

Look at time 10:55. the drone started to ascend way before the throttle changed and later, the drone continued descending with throttle at middle level. and again and again.
Am i missing something obvious?

tanks
According to the log, is there a vibration problem?
and
Should the barometer be in an air-flowing environment?
Because in my quad, the flight is in the center of the quad and the flight control is closed all around

vibration level is good

no actually

tanks
how to disable barometer ?

If in your case barometer is indeed the problem, than just set the EK2_alt_source to 2 (GPS). Right now you have it set to 0 propably. I havent seen your logs, so i dont know.
But its not problem in my case.

as @Vaclav_Demeter said you can set EK2_ALT_SOURCE = 2 to use GPS altitude
but be careful in case of GPS glitch your copter will be crazy badly so always fly in aria with good GPS signal

@Vaclav_Demeter in your case i checked your log many times and im out of idea whats happening but let try with EK2_ALT_SOURCE = 2 too in your case and see what will happen

Well. I could but it wouldnt solve my problem. Because if you look at the logs, the batometric altitude and gps altitude are very similar.
So it measures altitude precisely with both barometer and gps (alt_source is set to barometer)
and yet it decides to ascend/descent.
Very strange issue.

Yes but we need to change something, to get a point to work on it

I understand,but there is a little-big problem.
I had this firmware uploaded one more day before these logs. and that day this wasnt an issue.
Than the day from the logs it happened more than once.
So i thought about what parameters did i change in the morning and there were only two.
I changed LGR_OPTION from 0 to 3 (because as i wrote in different post in 4.0.5 lgr deploy/retract based on altitude dont work in loiter. it worked with 4.0.3)
and changed PLND_EST_TYPE from 0 to 1
Both should have no effect on this.
But still i changed them back.
Since then, i flew for maybe 10 hours and this error didnt occur again.
That is the problem. Because i cannot really replicate the error.
But i know its there, and its possibly dangerous.
I have a big expensive drone on which i cannot really test parameters i am not sure wont endanger my drone.
And when this drone goes to client, and this error occurs, it could be dangerous.

And that is really a problem, because since arducopter 4 was released, i havent found any really stable version.
I have 2 GPS CAN connected. on early releases of arducopter 4 there were some compass issues. than arducopter 4.0.3 seemed good, but once in a while “internal error 0x400 (or something similar)” occured, which did not allow me to arm (even after reset) (and i read in other post that someone had the same issue with 2 CAN GPS connected). Than there was 4.0.4 which is no longer flaged as stable in mission planner.
And now there is 4.0.5 which i know has this mysterious error.
And as i wrote, somehow the same settings for landing gear as in 4.0.3 dont work.

So officially you can now only buy Here3 CAN GPS (if you want larger quantities and not buy on amazon/ebay) and yet i have found no stable firmware that would allow me to use them.

Hello. So yesterday and today it happened again.
Meanwhile between 20.11.2020 and 08.01.2021 we flew for maybe 200hours and it hasnt occured once. So today morning we switched EK2_alt_source to 2 (GPS) I hope it will solve the problem magically.
BTW if you want to reply, please do it in the following thread, because its been currently discussed there.
Copter-4.0.5 released! - ArduCopter / Copter 4.0 - ArduPilot Discourse

There is a PR to support multiple CAN CPS consistently that might help here.
I advise you to keep EKF_ALT_SOURCE at 0 and use at least AuduCopter 4.0.5

I am sorry, but i dont really understand what you are saying. That the issue is with two CAN GPS and i have it set incorrectly? despite the fact alt source was = 0?
Or are you just saying that you know there is a problem and you are working on it?
Please explain it to me, because i seriously dont understand (i am not trying to be mean).

Read the PR that I posted to understand a potential problem with 2 CAN GPSs.
Basically right now GPS1 might become GPS2 after reboot and vice-versa. That can be tricky if you set a OFFSET_POS location for each GPS.

Did you try increasing the RC3_DZ parameter?

Oh. I understand now.
Thank you.
Do you suggest to use only one can GPS since (if i am not mistaken) these parameters that are described in PR are not present in current AC 4.0.5 release? (If i am not blind)
And dont you mean in my case RC1_DZ? (since its my throttle channel)? (that one was changed to 80) , RC3_DZ was changed to 50
But i dont really get how could it help. Cube is receiving 1700pwm according to logs, which is much higher then mid position ±DZ

If you have not set any GPS_OFFSET_POS you should be fine with 2 CAN GPSs.
The parameters are not yet present in any released FW (beta or otherwise).
Yes I mean your throttle channel. And I assumed RC3 because that is the most common one. By not using the most common one you might be tapping into a bug that only you see!!!

i am not using GPS_OFFSET_POS.
But can it also be, that when i am using both external GPS compassess, that they also switch ID and thats why once while they work worse? Or is it just related to GPS ?

I understand what you mean by not using common channel. I will switch it to common on monday.
But do you see in my logs that it is a strange behaviour.Right? Just to rule out, that i am not looking incorrectly.