good points herkam. makes me rethink my conclusions. Paul showed only single direction command is given on pwm sig, so like I said, no reversal command can be sent. One down. But we do not have details on the esc velocity loop controller, so we cannot know if it is going unstable and telling the fets to reverse direction or just as bad, command fets in way to effectively try to stop motor with full current. so esc itself can still be doing something not so nice. No control system should allow ANY variable to go to saturation, and we can see currentCurrent does, so there is still some issue.
but more thinking and i have to remember the currentCurrent variable is current draw from/to(?) battery; since it is hi values like -17amp to idle in sky, -24 to rise, -12 to go down, all values that seem to make sense, I assumed when it is reported as large + value it meant the motor or some motor reversed direction suddenly. dumb assumption since the current is still coming from the battery, not going back into it. When a pwm esc like this, capable of reversing direction, suddenly reverses or commands speed to drop much slower than it is going, the motor becomes a generator and does reverse the current flow - that is what I am used to in the industrial world. it could still happen here, but the problem you made me consider is that the associated battery voltage is going down, not up at these reported current reversals - means the motor is not regening into the battery if that data is accurate... so it may mean their math is off and the 32676, only 1 bit away from the 2^15 probably digital word being used to scale the current, is wrong. How would this effect the smart battery? I do not know, but it sounds dangerous. since it is typical to have signed 2^16 bit word give +/-32767 values, it may be a math issue and really mean n o reversal of current but rather they mean -32.675amps. this would make sense, especially since the big reversed number seems to stay 2-3-4 seconds at a time. A large speed change would likely happen in milliseconds instead. but it may give dji pause to consider if this is a math mistake only, how it may affect smart battery response. The instability issue in the esc is still potentially real and can still potentially explain the quick speed drop which obviously is the cause of props flying off. and I have not tried to compile prop off reports, but doesn't it seem they became much more prevelant after going to 2.1 esc? I will add this comment to dji SDK bug report I entered. Without more data, I will continue to wrench tighten my props so no amount of motor sudden speed drop will unscrew them. I bet none of the prop unscrew cases ever happened to anyone who wrench tightened them. why take the chance?
