Hi all,

Just to get this out of the way first. I don't get paid to do these tests in my spare time. There is not much to gain other than helping other people and me to investigate issues with their mini, particularly with the uncommanded descent incidents. I have a theory about pressure deviation like many others have mentioned. I knew I need to make some tests and data available to back other the theory otherwise it would be prone to scrutiny. I believe theories with evidence in the form of flight data analysis is critical to finding out what is going on with the mini and to help other people to become more aware of their mini in certain risky situations (e.g. low above water). Evidence > some guy claimes to be experienced. So here is my test. It is open to all to discuss and learn. Please be polite and critical. Again, I do not get paid to do this and some individuals on this forum are just too blunt to notice.

Aims

• Confirm altitude deviation with abrupt stops in S and P mode, establish a connection to barometer pressure reading and visual positioning system (VPS).
• Confirm manual descent speed protection is related to VPS.
• Find out if the extended flight in S mode (>12min) causes uncommanded descent.
  

Methods

Have the IMU, RC and gimbal calibrated at home. Have the compass calibrated on the field. Firmware V01.00.0400.

Aim 1
I get up on this nice Sunday morning and headed to the flat grassy park filled with fresh air. The temperature is about 20 Celsius and no wind.



I takeoff, line the mini up at eye level to get a good visual confirmation of any altitude deviation. Get in S mode. And perform the 1-2-1-2-3-4-3-4 path described in the map below. Full stick on start and full release before the stop. The drone faces the top of the map at all times. So 1 is forward, 2 is backward, 3 is right, 4 is left. Each direction is duplicated with the designed path.



This flight path is then carried out in P mode at eye level. Then at 15m (just outside VPS' infrared sensor range) above ground, in S mode and P mode. Then at eye level with VPS taped to simulate flying above the water in S mode only. I verified that the mini is indeed blind with the black tape applied with my hand, it did not react to my hand under its belly like it normally does.



Aim 2
Full stick punch up in P mode from 0.5m to 40m. Release fully to stop. Full stick descent back to 0.5m. Repeat twice.
Get into S mode and repeat the same procedure twice.
Tape the VPS then repeat twice in S mode.

Aim 3
This test was the least systematic of the three. It was tested because someone whose name (I think Christian U) I forgot here claimed to have isolated his descent issue to over 12min of sport mode action. I performed and a number of full-speed forward flights in sport mode before the 12 min mark, then did a couple more after 12 min. VPS was covered the whole time.


Results

Aim 1


Fig.1 Eye-level, S mode.


Fig.2 Eye-level, P mode.


Fig.3 15m, S mode.


Fig.4 15m, P mode.


Fig.5 Eye-level, S mode, VPS taped.



Aim 2


Fig.6 P mode and S mode punch up 0.5m to 40m and back.


Fig.7 S mode punch up 0.5m to 40m and back, VPS taped.



Aim 3


Fig.8 S mode forward thrusts before 12 min. ~4m high. VPS taped.


Fig.9 S mode forward thrusts after 12 min. ~4m high. VPS taped.


Discussions and conclusions


Aim 1

I can visually confirm the forward and left flights in Fig. 1,2,5 all show noticeable but small climb as the drone is flying to the end. Additionally, a more pronounced climb was observed immediately upon the full release of the stick (what JJB saw in his quick stoptest). Eventually, the mini corrects itself to the start height by lowering altitude gradually if left to hover in place.

In backward and right flights, the mini drops a bit as it flies long, the change is very small. Barely visible by eye and very subtle on the graph.

S mode forward and back flights made a "~" like feature (tilde) in the blue barometer altitude trace. The right and left flights made the "∽" shape (reversed tilde) in the barometer altitude trace. The inversed tildes are way less pronounced and sometimes hard to identify in the graph. The same trend exists in the 15m tests in Fig 3 and 4 albeit I could not visually confirm any altitude change. (Not tall enough sorry) The two types of features exist throughout all test altitudes and VPS state, the barometer reading features appear to be determined by the directions of wind created by the mini's movement. S mode does make the features more pronounced but the shaped are not changed.

I conclude, the fact that this is directional and faster speed does it make it more obvious makes the issue pressure related. The barometer's pressure calculated height gives one type of response in forward and aft and another type in lateral flights. This could be due to the positioning of vents on the fuselage of the body. On the front, we have this big inlet behind the gimbal.



This lets air in fast in during fast forward flights. The air goes into the battery bay where the barometer is located.



For lateral flights, the big inlet does not work effectively. The mini has two lateral mesh vents and vent gaps around the heatsink/mainboard. Those might be responsible for airflow in the fuselage during lateral flights. Why are the pressure features opposite of each other?  ~ and∽? I actually do not know, I am not an aerodynamics expert. There might be some complicated flow patterns inside the body dictating what I see. It is very difficult to model even for DJI I wager.


What I did notice for the VPS deactivated flight is the altitude fluctuates quite wildly compared to VPS assist mode. That is normal. However, on occasions the altitude correction (lowering) of the mini after an abrupt stop from high speed can coincide with a downward altitude fluctuation. The combined result is the mini appears to be dropping out of control. You should be quick on the stick to save it because deactivated VPS means mini will keep dropping til it hits something, unless the altitude correction + fluctuation halts before the impact. It would be totally another issue if your mini is irresponsive to stick command in such a situation, and I am not covering that here.


Aim 2

Fig.6 clearly shows there is no speed limit when ascending past the VPS range in P mode. But when the mini comes back down, landing speed protection kicks in (after the vertical orange lines) making vertical speed (blue trace in the bottom panel) drastically reduce to zero. In S mode, the vertical speed reduction kicks in faster than P mode, as soon as VPS sensor picks up the signal it starts braking.

Fig.7 shows VPS was indeed at work for the descent braking. With VPS taped, I manually braked at about 3m above the ground or my mini would have slammed into the grass. Fig.6 shows the mini started automatically braking at about 5m above the ground. Again, be real careful when VPS is not working.

Aim 3

I did not observe any noticeable flight behavior changes before and after 12min of operation (overheating) in S mode, both when visually observing the flights and the data in Fig.8 and 9. But Christian U did say he would not expect that from every mini as he did not get that from all of his 3 minis. Welcome to comment if anyone sees anything I did not.


My final words: Thank you for looking through this rather lengthy report. I hope this helps people out there. Please be critical to this report and let me know about anything you find suspicious. I spent my Sunday afternoon doing this out of the goodness of my heart and interest in the hobby and the truth for all users. I do my best to be logically sound. Special thanks to JJB for making such a useful analysis program!


TLDR: Flying low without VPS can be really risky especially when going fast! Keep your eyes peeled and go easy on the brake.

Logs: Dat file for eye-level S & P mode abrupt stop tests         

         DAT File for 15m S & P mode abrupt stop tests and descent speed test has been lost on my phone due to unknown reasons.
         Dat file for VPS taped tests on S mode vertical descent and eye-level abrupt stop tests and 12 min tests
      

Man, thanks a lot for the tests and detailed analysis/explanations.

I have to admit I wanted to see a different result since I have reported my very obvious climbs and drops, however my tests were perform in hills, changing terrain with trees below, I guess I could spend my Sunday afternoon too replicating the same or almost the same test in a flat calm area, then move to my backyard were most of my drops occurred.

Crazy when one thinks about the 24h difference , we are literally as far as possible within this planet.

Not sure if I will cover the VPS since is proven in your tests.

But the other day I was also thinking about how my latest IMU calibration was done in colder weather leaving the mini outside for 30 min, as some users suggested, and now that is slightly  warmer if this may have any effect in the mini's behavior...

Looking forward to see if this is all normal or I have a faulty component on mine.
Thanks again!

Thanks a lot for the tests!

Thank's Guorium, great testing thanks a lot for your report.

Please could you upload the DAT file and share the link.

grahamjohnson10 Posted at 2-16 04:09
Thank's Guorium, great testing thanks a lot for your report.

Please could you upload the DAT file and share the link.

I made 2 out of the 3 available at the bottom of my post. The second flight's DAT was lost. I had auto-sync off the whole time. So I doubt auto-sync is the one taking out DAT files.

Hi Guoriom,

Much better weather down-under (seen from where i live) to do lots of tests.

Your conclusion that airflow through the inside along the baro sensor does have effect on the measures values are correct, seen this in my simple quickstop test.

Just follow the blue line, airflow along sensor changes from rapidly nose down to nose up!So no question about that.  Think i will fly with some, not all or full coverd, covered inlet air vents to see the difference.

VPS height has some influence in height keeping flying within range, is my test you see low values on vertical speed up/down. In cases where a MM drops height quickstoppend above water you see large values on down vertical speed. I think that when the VPS height signal back to the drone is weak or gone that the systems thinks that the MM is suddenly flying "higher" ; thus the correction made by sw is larger than it should be.

BWT, soon an FRAP update, more MM messages in the program.


cheers
JJB

JJB* Posted at 2-16 04:48
Hi Guoriom,

Much better weather down-under (seen from where i live) to do lots of tests.

Not too good weather here really. Got fire, flood, and almost constant strong wind. The storm just cleared yesterday and the field was actually very wet. But the wind is the calmest during the early morning and evening so I had to test in the morning, and turned out lucky with no wind.

What more MM messages are not currently displayed in FRAP?

That would be pretty stupid of DJI if the loss of VPS height means suddenly "flying" higher. What if there is just water below? Could test this out by shooting past a cliff edge more than 10m deep.

I still find the vertical speed data strange. In my uncommanded drop post my vertical speed was negative while the altitude was increasing...

Guorium Posted at 2-16 05:06
Not too good weather here really. Got fire, flood, and almost constant strong wind. The storm just cleared yesterday and the field was actually very wet. But the wind is the calmest during the early morning and evening so I had to test in the morning.

What more MM messages are not currently displayed in FRAP?

Have to look better into the vertical speed values, some values are written with some delay into the file but not too much delay not to compare one set of data wich the other.

In the latest converter file all messages (i hope) are now de-crypted. You will see this in the next update.

cheers
JJB

JJB* Posted at 2-16 05:24
Have to look better into the vertical speed values, some values are written with some delay into the file but not too much delay not to compare one set of data wich the other.

In the latest converter file all messages (i hope) are now de-crypted. You will see this in the next update.

Needs a better look indeed. This is just not right. Negative v speed about -2m/s but altitude is more or less flat? I have a video of the flight validating the altitude curve. The time from 1300 to 1360 is about 6 seconds. Can the delay be that much?

Guorium Posted at 2-16 05:39
Needs a better look indeed. This is just not right. Negative v speed about -2m/s but altitude is more or less flat? I have a video of the flight validating the altitude curve. The time from 1300 to 1360 is about 6 seconds. Can the delay be that much?

[view_image]

uhh, if you look at the lower 2 blue lines, down stick and minus vertical speed = oke. (except maby for the last up vert speed)

Alt line rises a little, or is this just indicating a rise. Hard to tell without seeing all data and the actual eye-ball mark1 vision  ;-)

Delay for most of the values 0.2 or 0.3 of a second, some values are written each second.
cheers
JJB

Wow, awesome job!  I'm sure this was quite time consuming so many thanks for running such a thorough test.  Took me a while to read and understand all the data and your 3 Aim conclusions.  The one thing that seemed to stick out was the vertical speed data appeared a bit strange.  Again, thanks for sharing this test data.

Personally I don't think the barometer is the problem, or the GPS height readings.

I think there is something wrong with the firmware code that is causing these uncommanded height issues.   

Looking at the chart below both the barometer and GPS readings seem to match.

Your commitment is very appreciated Guorium but I think the conditions didn't really help exacerbate the altitude drop problem.

I've had my Mini repeatedly dropping about 2-3 meters from a 10 m height and UP Control Stick input caused only a lethargic reaction. I tend to agree with the air pressure build-up inside the drone body as the main cause, in fact the most prominent outcome was happening after a sudden stop in S from a full DOWN and FORWARD motion.

By the way I was thinking about fixing this problem with a gimbal protector, partially enclosing the gimbal assembly to offer protection against frost bites.

grahamjohnson10 Posted at 2-16 05:56
Personally I don't think the barometer is the problem, or the GPS height readings.

I think there is something wrong with the firmware code that is causing these uncommanded height issues.   

I also think so.

In the logs where the drone dropped, you were able to see this in hight readings. So the barometer was not interfered by some airflow or so because it used the right data.

Kind of curious what the problem is...

JJB* Posted at 2-16 05:46
uhh, if you look at the lower 2 blue lines, down stick and minus vertical speed = oke. (except maby for the last up vert speed)

Alt line rises a little, or is this just indicating a rise. Hard to tell without seeing all data and the actual eye-ball mark1 vision  ;-)

Yeah down stick and minus v speed is ok but the altitude should be decreasing when v speed is minus. It is holding flat and even going up a bit. I did not eyeball the drone. It was far to eyeball. The footage of that flight does match the ALT trace in the graph. See this video that covers the flight from 1290 to 1340. It is not a delayed data issue then.

grahamjohnson10 Posted at 2-16 05:56
Personally I don't think the barometer is the problem, or the GPS height readings.

I think there is something wrong with the firmware code that is causing these uncommanded height issues.   

Thanks for working on the dat files. I did not point towards the barometer being faulty. The barometer reads what is around it and it appeared to work fine. There might be a bug in the fw causing it to overcorrect for a pressure deviation after abrupt braking.

@m80116 By lethargic you mean your up stick worked but very slowly?

Yes, you push the stick full up and it doesn't respond anywhere nearly as promptly as it should normally (weird logic at play there).

m80116 Posted at 2-17 17:02
Yes, you push the stick full up and it doesn't respond anywhere nearly as promptly as it should normally (weird logic at play there).

In my observation, the up acceleration was pretty prompt with the time of the stick. I am not sure what part of my report make you think the opposite.

First off, thank you for all time and effort you went too.  

Assuming I am reading spikes on charts correctly...

Think you have shown what I was pondering about early on.  Drone flying fast into the wind is ramming air in, faster than air can flow out.  When there is no wind, the sudden stop still cause drone's nose to pitch up, and more air is suddenly being pushed in.  Possibly as result of increased (brief) front Prop speed?  


Either way, leading to very slight air pressure (brief) rise inside drone.  Knowing drone's barometer is sensitive enough to detect several feet in altitude change, slight rise (briefly) in air pressure inside would lead drone to think it is flying lower (briefly) than it really is.


Why few peole have seen opposite?    Possibly different boards inside their drones or a "off" batch run with problems.

Be helpful if we could monitor the Drone's CPU's utilization information.  Percent CPU busy, memory used, I/O transfers, etc.

Again, great job!

Spark_Pilot_XxXx Posted at 2-16 10:33
I also think so.

In the logs where the drone dropped, you were able to see this in hight readings. So the barometer was not interfered by some airflow or so because it used the right data.

There is possibility we are looking at combination of problems.  Resulting in:
1) Compounding of problem
2) Reverse of problem (drop then rise)
3) Near canceling out of problem.

Worst trouble shooting nightmares for Computer System Engineers is two nearly simultaneous problems, resulting in similar symptoms.  Intermittent, pseudo-random memory addressing problems for part of memory word being Twilight Zone of Outer Limits repair nightmares.

HedgeTrimmer Posted at 2-17 19:25
First off, thank you for all time and effort you went too.  

Assuming I am reading spikes on charts correctly...

Drone flying fast into the wind is ramming air in, faster than air can flow out.  When there is no wind, the sudden stop still cause drone's nose to pitch up, and more air is suddenly being pushed in.

What has escaped some people is that the wind has nothing to do with any of this.
If you fly your Mini in perfectly still air, in Sport Mode its ground speed and airspeed will be 29mph.
Or to express it another way, it will have a 29mph wind hitting it in the face.

If the Mini is pushing directly into a 10 mph wind, its ground speed will be 29-10 = 19mph.
But its airspeed (the wind hitting it in the face) is still 29mph.
ie.  No difference.
Flying this way or that relative to the wind makes no difference to the drone and its altitude sensing system as anyone that's flown these things for a while should be aware.

Labroides Posted at 2-17 19:37
Drone flying fast into the wind is ramming air in, faster than air can flow out.  When there is no wind, the sudden stop still cause drone's nose to pitch up, and more air is suddenly being pushed in.

What has escaped some people is that the wind has nothing to do with any of this.

"If you fly your Mini in perfectly still air, in Sport Mode its ground speed adn [sic - and] airspeed will be 20mph.
Or to express it another way, it will have a 29mph wind hitting it in the face."

Want to try that again?  


"Perfectly still air" to me says 0-mph wind.

If MM can fly at a max ground speed of 20-mph, and there is 0-mph wind, then airspeed is 20-mph.
(Resulting or effective) Wind hitting drone in it's face is still 20-mph, not 29-mph.


Whereas, if drone does not have a max ground speed, instead it has a max airspeed, different outcome all together.
Let's say MM has max airspeed of 29-mph.  Drone at full power flying into a 29-mph wind would for most part hold it's position.  Resulting in 0-mph ground speed.

Labroides Posted at 2-17 19:37
Drone flying fast into the wind is ramming air in, faster than air can flow out.  When there is no wind, the sudden stop still cause drone's nose to pitch up, and more air is suddenly being pushed in.

What has escaped some people is that the wind has nothing to do with any of this.

"Flying this way or that relative to the wind makes no difference to the drone and its altitude sensing system as anyone that's flown these things for a while should be aware."

Which ignores known air intake opening (resulting air flow path) of MM, as pointed out in OP's pics.

HedgeTrimmer Posted at 2-17 19:50
"If you fly your Mini in perfectly still air, in Sport Mode its ground speed adn [sic - and] airspeed will be 20mph.
Or to express it another way, it will have a 29mph wind hitting it in the face."

I'm sorry .. I made a typo the first time I mentioned the speed of the Mini.
0 and 9 are very close on my keyboard.

I've corrected the typo so you can try reading it again.

Labroides Posted at 2-17 19:59
I'm sorry .. I made a typo the first time I mentioned a speed.
0 and 9 are very close on my keyboard.

Thank you for clarification.  Will re-read.

HedgeTrimmer Posted at 2-17 19:58
"Flying this way or that relative to the wind makes no difference to the drone and its altitude sensing system as anyone that's flown these things for a while should be aware."

Which ignores known air intake opening (resulting air flow path) of MM, as pointed out in OP's pics.

Which ignores known air intake opening (resulting air flow path) of MM, as pointed out in OP's pics.
And if you read my post above, it shoots a big hole in that idea.

Labroides Posted at 2-17 19:37
Drone flying fast into the wind is ramming air in, faster than air can flow out.  When there is no wind, the sudden stop still cause drone's nose to pitch up, and more air is suddenly being pushed in.

What has escaped some people is that the wind has nothing to do with any of this.

What needs to be clarified...

Is Mavic Mini Maximum speed limited by:
1) MM's ability to overcome air flow (air speed), MM is allowed to use max prop thrust and best pitch regardless of ground or air speed?
2) MM having an internal Maximum flight speed based on Ground speed / GPS?

3) MM's ability to overcome air flow (air speed), is limited to XX% of max prop thrust?

Labroides Posted at 2-17 20:02
Which ignores known air intake opening (resulting air flow path) of MM, as pointed out in OP's pics.
And if you read my post above, it shoots a big hole in that idea.

Sorry, I disagree.  The testing done by OP shows direction of flight (forward, backward, sideways) does effect results.  Which fits with primary air intake being located at front, not sides or rear.

HedgeTrimmer Posted at 2-17 20:07
What needs to be clarified...

Is Mavic Mini Maximum speed limited by:

What needs to be clarified...
These are all basic concepts that should be understood by anyone trying to argue one way or the other about drone flight.

Is Mavic Mini Maximum speed limited by:
1) MM's ability to overcome air flow (air speed), MM is allowed to use max prop thrust and best pitch regardless of ground or air speed?
Increasing the prop speed will just make the drone climb higher.
Forward flight speed is governed bt the angle the drone tilts forward with prop speed being automatically adjusted to provide the required lift to maintain altitude.
There is no "best pitch" as the props have a fixed pitch.

2) MM having an internal Maximum flight speed based on Ground speed / GPS?
It's based on airspeed.
That's why the groundspeed decreases if you push into a strong headwind.

3) MM's ability to overcome air flow (air speed), is limited to XX% of max prop thrust?
Is limited by the tilt angles programmed for each Flight Mode.

Go back and read my earlier post explaining why flying into a headwind makes no difference to altitude sensing.
You seem to have missed somethuing.

Labroides Posted at 2-17 20:23
What needs to be clarified...
These are all basic concepts that should be understood by anyone trying to argue one way or the other about drone flight.

"These are all basic concepts that should be understood by anyone trying to argue one way or"

How about we try talking about subject of thread without lecturing from on high?

Most everyone here knows pitch was not a reference to blades of MM's props, because MM's props have fixed blades.  Pitch was reference to angle of tilt upward or downward for nose to cause drone to fly backward or forward.

Increasing the prop speed will not just make the drone climb higher when it is coupled to angle of tilt of drone (aka Pitch).  Which is what you do go on to state.  Difference is I used pitch being that is proper term for rotation around Y (Lateral axis).

There is indeed a best pitch angle.  Pitch (tilt drone to much downward) and drone's prop pull/thrust will result in descent (result of less lift), while increasing forward speed.  Factoring in MM's body shape, the more MM tilt's downward, drone presents more air resistance, and likely air pressure on surface tries to push MM downward.

HedgeTrimmer Posted at 2-17 22:05
"These are all basic concepts that should be understood by anyone trying to argue one way or"

How about we try talking about subject of thread without lecturing from on high?

How about we try talking about subject of thread without lecturing from on high?
I was simply answering the questions you asked, but now you are taking me to task for that?

Most everyone here knows pitch was not a reference to blades of MM's props, because MM's props have fixed blades.  Pitch was reference to angle of tilt upward or downward for nose to cause drone to fly backward or forward.
I read your question the wrong way.
You were asking basic questions and I took it that you were asking about propeller issues only when you said:is allowed to use max prop thrust and best pitch.

So ... back to the topic of the thread ...
How about what I have been trying to communicate from post #30 from a few hours back?

Labroides Posted at 2-17 20:23
What needs to be clarified...
These are all basic concepts that should be understood by anyone trying to argue one way or the other about drone flight.

"Go back and read my earlier post explaining why flying into a headwind makes no difference to altitude sensing.
You seem to have missed somethuing."

I have.  Once you corrected typo, and clarified MM's speed with your reply to #3 ("Is limited by the tilt angles programmed for each Flight Mode").  Eliminating MM's speed being internally limited to ground speed (derivied from GPS velocities).

Then we can say, a headwind when flying forward (nose into wind) will make no difference.


Reason I asked for clarificcation, has to do with differences in what has been previously discussed with regards to MM's RTH speeds.  With some insisting MM can not go faster into headwind when returning home - even though MM is below it's Maximum airspeed, further backed by flight records showing MM was not Pitching as much as it can in Sport at 100%.

Labroides Posted at 2-17 22:26
How about we try talking about subject of thread without lecturing from on high?
I was simply answering the questions you asked, but now you are taking me to task for that?

I was simply answering the questions you asked, but now you are taking me to task for that?

Okay, I apologize.   I mistakenly took your first line ("These are all basic concepts...") coupled to blade Pitch as condensing.

HedgeTrimmer Posted at 2-17 22:39
"Go back and read my earlier post explaining why flying into a headwind makes no difference to altitude sensing.
You seem to have missed somethuing."

Then we can say, a headwind when flying forward (nose into wind) will make no difference.
It will make no difference to the speed of the air that the drone is experiencing.
It will have a real effect on groundspeed.

Reason I asked for clarificcation, has to do with differences in what has been previously discussed with regards to MM's RTH speeds.  With some insisting MM can not go faster into headwind when returning home - even though MM is below it's Maximum airspeed, further backed by flight records showing MM was not Pitching as much as it can in Sport at 100%.
The Mini is a special case and some have been showing faults (sometimes) that are not seen in any other DJI drones.
All the others will maintain altitude regardless of wind conditions etc.
All others will always fly at the same tilt angle every time you push the elevator full forward.

Sometimes some Minis just look like they are getting tired and just give up.
In that situation, they don't tilt far enough and show a tendency to sink regardless of what the pilot does with the joysticks.

If it was due to a problem with altitude sensing, you would still see the Mini climbing when the pilot gives it full throttle but unfortunately there have been many cases where they just sink and nothing corrects this.

The elements that need looking into to solve the mystery are the failure to tilt properly, the loss of lift and why this only happens to some Minis, some of the time.

Labroides Posted at 2-17 22:57
Then we can say, a headwind when flying forward (nose into wind) will make no difference.
It will make no difference to the speed of the air that the drone is experiencing.
It will have a real effect on groundspeed.

"If it was due to a problem with altitude sensing, you would still see the Mini climbing when the pilot gives it full throttle but unfortunately there have been many cases where they just sink and nothing corrects this."

Valid point.  

Baring in mind, graphs are initialling showing deviation between Barometric sensor and VPS (alitude).  Something there is going on with altitude sensing.   But I agree the deviation, is not there long enough to keep MM from responding to full throttle (increase altitude as fast as possible), as has been reported by several Pilots.

Leading to question as to why MM does not respond to full throttle as reported.

A firmware bug as suggested by several Pilots.   A bug that is only hit upon when MM is commanded from full speed forward to backwards.  Not backwards to forwards or side to side.

Following two possibilites do not fit with problem being it is worse  going from full foward to full backwards.
--- Possibility MM's CPU becomes overloaded processing rapidly changing flight sensor information, leading to MM lagging in processing Pilot's commands.
--- Possibility of sudden change from full speed forward to backwards is causing voltage dip, resulting in bad alitude data.  


Testing done by OP and reported near crashes due to sudden dips, (MM's failure to quickly respond to full throttle ascend) are two different problems.

HedgeTrimmer Posted at 2-17 23:42
"If it was due to a problem with altitude sensing, you would still see the Mini climbing when the pilot gives it full throttle but unfortunately there have been many cases where they just sink and nothing corrects this."

Valid point.  

Leading to question as to why MM does not respond to full throttle as reported.

A firmware bug as suggested by several Pilots.   A bug that is only hit upon when MM is commanded from full speed forward to backwards.  Not backwards to forwards or side to side.

Following two possibilites do not fit with problem being it is worse  going from full foward to full backwards.
--- Possibility MM's CPU becomes overloaded processing rapidly changing flight sensor information, leading to MM lagging in processing Pilot's commands.
--- Possibility of sudden change from full speed forward to backwards is causing voltage dip, resulting in bad alitude data.  

Or something else entirely.
Leading to question as to why MM does not respond to full throttle as reported.
You have to look at what might have changed when a Mini that flew normally for weeks, just gets tired mid-flight.
I haven't got my head fully around what's causing the problem but I suspect most of the  discussion on this forum has been following a dead end trail of  irrelevant distractions and perhaps this guy is touching on the real issue:  

Testing done by OP and reported near crashes due to sudden dips, (MM's  failure to quickly respond to full throttle ascend) are two different  problems.
I don't have any confidence that the OP has any idea what he is doing and I can't tell what he thinks he's testing.
It doesn't seem to have anything to do with the real problem that has claimed too many Minis.
He needs to look somewhere different from those flashy graphs and listening to people with actual experience might be helpful too.

Labroides Posted at 2-18 00:42
Leading to question as to why MM does not respond to full throttle as reported.

A firmware bug as suggested by several Pilots.   A bug that is only hit upon when MM is commanded from full speed forward to backwards.  Not backwards to forwards or side to side.

It usually is the simplest things, I wonder how many noticed that warning, I didn’t but it makes perfect sense, good find .
A lot of testing could have been avoided if one just read instructions.

I suggest an urgent change to the firmware: if the user decides, he must be able to bypass the controls and impose his commands on the drone regardless of the altitude measured by the software.

Renato61 Posted at 2-18 02:08
I suggest an urgent change to the firmware: if the user decides, he must be able to bypass the controls and impose his commands on the drone regardless of the altitude measured by the software.

It's starting to look like something that firmware wouldn't fix.
Look at the video I linked above.

Renato61 Posted at 2-18 02:08
I suggest an urgent change to the firmware: if the user decides, he must be able to bypass the controls and impose his commands on the drone regardless of the altitude measured by the software.

It's starting to look like something that firmware wouldn't fix.
Look at the video I linked above.