URGENT: Tighten your props with wrench
- Thread starter yorlik
- Start date
+1 to that question! If so, PLEASE attach your log for us to see!
I can't believe I am the ONLY one that gets logs of their flights, but it sure appears that way! Even if you never looked at the log, why not attach one or two to a reply here for a look see? It is free, it won't cost you any money. Just post it.
I can't believe I am the ONLY one that gets logs of their flights, but it sure appears that way! Even if you never looked at the log, why not attach one or two to a reply here for a look see? It is free, it won't cost you any money. Just post it.
N017RW
Premium Pilot
I reviewed the data yorlik posted on Tuesday to dropbox.
It seems many of the parameters are only logged every two seconds (i.e. pairs).
If you examine JUST the currentCurrent, [batt.]voltage, altitude, and velocityZ parameters it looks like a perfectly normal flight profile except for the one [pair] 'currentCurrent' data point @251 & 252 sec. This specific 'currentCurrent' data point is just ONE of 270+ data points appears to just be an outlier as it is inconsistent with the other 3 parameters at that time.
But is this the proof of a 'glitch'?
I can't see it.
Maybe I missed it.
It seems many of the parameters are only logged every two seconds (i.e. pairs).
If you examine JUST the currentCurrent, [batt.]voltage, altitude, and velocityZ parameters it looks like a perfectly normal flight profile except for the one [pair] 'currentCurrent' data point @251 & 252 sec. This specific 'currentCurrent' data point is just ONE of 270+ data points appears to just be an outlier as it is inconsistent with the other 3 parameters at that time.
But is this the proof of a 'glitch'?
I can't see it.
Maybe I missed it.
Last edited:
I agree it is hard to see, and may be nonsense. And if it happened more often than 1,2 times per flight, then the props would be flying off a lot more often. That's the point, it only happens rarely.
But the reason I think there is something to this is that all that data is reported - from basically autonomous computers, not just one. the smart battery processor is reporting its info, the MCU is reporting its info, the compass input is another section, etc. Each of these basically independent sources are reporting a glitch that seems to point to a single cause. If it was just one computer generating all the data then ok, it is more likely that all the data is corrupt at that one time.... at least that is my thought. Interesting when you pointed out the line again and mentioned altitude, I never looked at it... it appears my big current reversal may have happened at a time when I changed my thrust from full up to full down; this potential glitch was not in the middle of a full throttle rise.....interesting...
But the reason I think there is something to this is that all that data is reported - from basically autonomous computers, not just one. the smart battery processor is reporting its info, the MCU is reporting its info, the compass input is another section, etc. Each of these basically independent sources are reporting a glitch that seems to point to a single cause. If it was just one computer generating all the data then ok, it is more likely that all the data is corrupt at that one time.... at least that is my thought. Interesting when you pointed out the line again and mentioned altitude, I never looked at it... it appears my big current reversal may have happened at a time when I changed my thrust from full up to full down; this potential glitch was not in the middle of a full throttle rise.....interesting...
N017RW
Premium Pilot
This statement is not very satisfying: "Each of these basically independent sources are reporting a glitch that seems to point to a single cause."
I'm sorry but you'll have to be more specific here.
I only found one outlier in the data you posted.
I'm sorry but you'll have to be more specific here.
I only found one outlier in the data you posted.
Last edited:
my point was not multiple potential glitches at different times during that particular flight, it is more than 1 computer gave matching independent glitch type data:
1) smart battery processor (current & voltage),
2) MCU (vertical rate)
3) barametric pressure sensor (altitude)
Why did all 3 autonomous sources show wrong data at that point?
1) smart battery processor (current & voltage),
2) MCU (vertical rate)
3) barametric pressure sensor (altitude)
Why did all 3 autonomous sources show wrong data at that point?
N017RW
Premium Pilot
I don't see that in my graph which makes this difficult.
Can you be specific using your dropbox spreadsheet data posted Tue.?
Can you be specific using your dropbox spreadsheet data posted Tue.?
N017RW
Premium Pilot
currentCurrent- Red
batt. Voltage- Purple
velocityZ- Light Green
altitude- Blue
- velocityZ downward spikes align with altitude gain and currentCurrent increases accordingly.
- batt. Voltage fairly steady decline though the graph is not ideally scaled for this param.
- There is a 0.5v dip at the point the current spikes beyond Zero (outlier). You'd expect a batt. V dip as you moved to gain altitude and the altimiter and accelerometer confirms it happened. The currentCurrent data is corrupted at that point.
My $0.02.
Last edited:
I would like to know how the data is reported. Specifically what api is reporting the flight information?
More specifically is it one api that pulls all the data from the flight controller, or is it multiple apis that pull the information from the separate hardware?
If all the data comes from one aggregate source then a calculation error could theoretically effect all of the data. I would like to see black box data from confirmed prop loss crashes to compare. The sample set is not large enough to bring significant results without.
If the data is gathered through apis directly from each separate chip that reports data than this data becomes less likely a software glitch than a hardware glitch. If all sources independently report a spike at the same time value that becomes more interesting. Again the sample set isn't large enough to become significant. O think the Sigma value would rise quicker in this case with more data than case 1.
Its also irrelevant but interesting to know the inspire has breaking escs. Most software no matter where it is written, I. E. firmware, plc control software, Android apps, will share a common code base across hardware devices. For example if I implement a Samsung only feature for the note on my app, that code will still exist on an HTC phone but if implemented correctly will never be called. If it isn't done right and the method gets called it will throw an exception that could just cause a log entry or up to a system crash. You see where I am going here. If the glitch does occur during a high gain to low gain maneuver, could it be the firmware if asking for the breaking that is not supported in the current escs? Maybe, probably not, I don't know. If it is then that is a completely software based fix.
More specifically is it one api that pulls all the data from the flight controller, or is it multiple apis that pull the information from the separate hardware?
If all the data comes from one aggregate source then a calculation error could theoretically effect all of the data. I would like to see black box data from confirmed prop loss crashes to compare. The sample set is not large enough to bring significant results without.
If the data is gathered through apis directly from each separate chip that reports data than this data becomes less likely a software glitch than a hardware glitch. If all sources independently report a spike at the same time value that becomes more interesting. Again the sample set isn't large enough to become significant. O think the Sigma value would rise quicker in this case with more data than case 1.
Its also irrelevant but interesting to know the inspire has breaking escs. Most software no matter where it is written, I. E. firmware, plc control software, Android apps, will share a common code base across hardware devices. For example if I implement a Samsung only feature for the note on my app, that code will still exist on an HTC phone but if implemented correctly will never be called. If it isn't done right and the method gets called it will throw an exception that could just cause a log entry or up to a system crash. You see where I am going here. If the glitch does occur during a high gain to low gain maneuver, could it be the firmware if asking for the breaking that is not supported in the current escs? Maybe, probably not, I don't know. If it is then that is a completely software based fix.
Data comes from dji SDK.
N017RW you are correct on my last example; I did not see it was up then change of direction back down; unlike my other examples where the glitch presented itself in the middle of a vertical climb, I missed this one going back down, so it indeed passed thru 0 ok. Good catch man!
I just updated my bug report to dji with:
We have changed update rate on our log file to 250msec. You only send currentCurrent and voltage and some other parameters every 2 seconds, so I am at a loss to try to go any further with my testing. If you are interested in further tests by me, if you send a small app that will record these two variables every 3 or so msec, I would be happy to do further tests to see if the ESC U1 chip firmware is perhaps sometimes unstable as I guess. Otherwise, I am at the limit of my data and will stop, other than suggesting you change your manual to state "use supplied wrench to softly tighten each prop when installed. This change in your manual will eliminate the multitude of "props flying off in flight" issues you have to contend with. Just a final thought for you.
I WOULD still like to hear your thoughts on this whole topic. Thank you.
N017RW you are correct on my last example; I did not see it was up then change of direction back down; unlike my other examples where the glitch presented itself in the middle of a vertical climb, I missed this one going back down, so it indeed passed thru 0 ok. Good catch man!
I just updated my bug report to dji with:
We have changed update rate on our log file to 250msec. You only send currentCurrent and voltage and some other parameters every 2 seconds, so I am at a loss to try to go any further with my testing. If you are interested in further tests by me, if you send a small app that will record these two variables every 3 or so msec, I would be happy to do further tests to see if the ESC U1 chip firmware is perhaps sometimes unstable as I guess. Otherwise, I am at the limit of my data and will stop, other than suggesting you change your manual to state "use supplied wrench to softly tighten each prop when installed. This change in your manual will eliminate the multitude of "props flying off in flight" issues you have to contend with. Just a final thought for you.
I WOULD still like to hear your thoughts on this whole topic. Thank you.
I will finish my input to this thread with summary of empirical data I measured on prop tightness, and calculated on motor torque available, to unscrew same:
1) Each motor can produce CW AND CCW in excess of 2.4#-in torque
2) Best hand tightening I could do required only 1.2#-in torque to unscrew (double what I could tighten with holding motor as hard as I could!) (ie., spin on & hand tightening as tight as you can by holding motor are equal - both result in motor spinning it up to 1.2#-in tightness. So if you spin or hold motor makes NO DIFFERENCE - both unscrew @ 1.2#-in, only half of motor capability in rated flight - let a glitch come and it can go even higher)
3) Wrench tightening required 13.5#-in to unscrew. There will NEVER be an unscrewed prop failure by someone who uses their wrench.
I will not fly without wrench tightened props ever again; you may do whatever you wish. Sorry to those I offended with all my minutiae in this thread.
1) Each motor can produce CW AND CCW in excess of 2.4#-in torque
2) Best hand tightening I could do required only 1.2#-in torque to unscrew (double what I could tighten with holding motor as hard as I could!) (ie., spin on & hand tightening as tight as you can by holding motor are equal - both result in motor spinning it up to 1.2#-in tightness. So if you spin or hold motor makes NO DIFFERENCE - both unscrew @ 1.2#-in, only half of motor capability in rated flight - let a glitch come and it can go even higher)
3) Wrench tightening required 13.5#-in to unscrew. There will NEVER be an unscrewed prop failure by someone who uses their wrench.
I will not fly without wrench tightened props ever again; you may do whatever you wish. Sorry to those I offended with all my minutiae in this thread.
Thank you for all your hard work on this subject.
And thank you again.
May I quote you on my website? The link is in my signature.
N017RW
Premium Pilot
It's been fun yorlik. I applaud your desire to look into this issue.
It seems that in the right conditions there is sufficient deceleration to spin off the props otherwise we would not be talking about it. Is the cause a defect, oversight, a type of flight maneuver??? IDK.
I have previously stated I never added any torque when installing the props but I will now. What can it hurt?
Keep collecting data to see if you can create the zero crossing current line again and/or repeatedly.
It seems that in the right conditions there is sufficient deceleration to spin off the props otherwise we would not be talking about it. Is the cause a defect, oversight, a type of flight maneuver??? IDK.
I have previously stated I never added any torque when installing the props but I will now. What can it hurt?
Keep collecting data to see if you can create the zero crossing current line again and/or repeatedly.
- Joined
- Mar 3, 2015
- Messages
- 735
- Reaction score
- 295
What data?
I fly a P2NV with Flytrex 3G, and I don't get that much detail from the data.
Steve you won't get the granularity of detail that a data logging app with internal api access will.
Can anyone summarise if there is any 100% evidence ?
If the motor stopping is so powerful, would using the wrench to tighten it really make a diff to it flying off ?
I've got a non v3.. but with ESC 2.1 and 2312's...Each flight I basically just do 360's, go back, forward, randomly change directions at full speed... and just make it do all crazy manuveores for entire length of the battery.... for the last 40-50 flights (since I got new esc/2312s). My batteries have done like 120 charges each. I only get battery issues or any issue if I lift up at full power for to long, which I believe is due to the amp/volts in battery.
Anyways how many people has this happened to ??
I'm not trying to be negative and bad mouth every bodies data/investigations... I'm just looking for actual evidence of this happening to a group of people ??? Apologies If I have missed that.
the wrench for 2212's doesn't fit the 2312's does it.. ? kind of annoying hehe.. :/
*edit* I suppose it would not hurt to tighten... so yeah can't make it any worse
Yorlik - Thanks for your work investigating and lists the points you made.
***
If the motor stopping is so powerful, would using the wrench to tighten it really make a diff to it flying off ?
I've got a non v3.. but with ESC 2.1 and 2312's...Each flight I basically just do 360's, go back, forward, randomly change directions at full speed... and just make it do all crazy manuveores for entire length of the battery.... for the last 40-50 flights (since I got new esc/2312s). My batteries have done like 120 charges each. I only get battery issues or any issue if I lift up at full power for to long, which I believe is due to the amp/volts in battery.
Anyways how many people has this happened to ??
I'm not trying to be negative and bad mouth every bodies data/investigations... I'm just looking for actual evidence of this happening to a group of people ??? Apologies If I have missed that.
the wrench for 2212's doesn't fit the 2312's does it.. ? kind of annoying hehe.. :/
*edit* I suppose it would not hurt to tighten... so yeah can't make it any worse
Yorlik - Thanks for your work investigating and lists the points you made.
***
Last edited:
Read this thread again...grrrr annoying when people change there posts after a week!!!!!!!!!
I see its now also about the 100% throttle up issue..
Some guys on the rcgroups forum have done heaps of investigation into that... let me try find the thread.. and yeah.. the battery does crazy things... to get around it I do less than 100% throttle when ascending or short bursts.. like 3-5 seconds stop.. repeat...
The interesting thing is... i had the same error when I had 2312 motors and older ESC (NOT 2.1)
and now I have 2.1 and the error is still there.... so leads me to believe perhaps the issue is with the motor ??
Just to confirm... my post above was in relation to the props coming off.. I read this thread on/off for last couple of weeks... but it looks like now it includes the 100% ascend throttle issue... old news lol
So yeah I was just asking how many people have had the props coming off issue ??
I see its now also about the 100% throttle up issue..
Some guys on the rcgroups forum have done heaps of investigation into that... let me try find the thread.. and yeah.. the battery does crazy things... to get around it I do less than 100% throttle when ascending or short bursts.. like 3-5 seconds stop.. repeat...
The interesting thing is... i had the same error when I had 2312 motors and older ESC (NOT 2.1)
and now I have 2.1 and the error is still there.... so leads me to believe perhaps the issue is with the motor ??
Just to confirm... my post above was in relation to the props coming off.. I read this thread on/off for last couple of weeks... but it looks like now it includes the 100% ascend throttle issue... old news lol
So yeah I was just asking how many people have had the props coming off issue ??
Hey justin00,
Where can I read the "old news"? I didn't realize there was a known issue with 100% assents.
Thanks
Just about to run off to work and normally i'd have 8 hours to spend on the PC hehe (but am in a training thingo at work today)
So just quickly found the thread I made when I had the issue/didn't know the cause.
Inside it a few people explain the issue in technical detail, there is also links to another thread on rcgroups.com which has the investigation in even more detail
http://www.phantompilots.com/thread...-current-discharge-warning.36211/#post-334861
When I get home I'll look on rcgroups.com and djiforums as there were more threads on those forums than on here..
was only being sarcastic about 'old news'.
All though feels like everything on the forum is old news when compared to rcgroups anyways.
Luckily we have that one guy who steals rcgroup threads, posts them up here then asks for donations lol :] :/
So just quickly found the thread I made when I had the issue/didn't know the cause.
Inside it a few people explain the issue in technical detail, there is also links to another thread on rcgroups.com which has the investigation in even more detail
http://www.phantompilots.com/thread...-current-discharge-warning.36211/#post-334861
When I get home I'll look on rcgroups.com and djiforums as there were more threads on those forums than on here..
was only being sarcastic about 'old news'.
All though feels like everything on the forum is old news when compared to rcgroups anyways.
Luckily we have that one guy who steals rcgroup threads, posts them up here then asks for donations lol
:] :/
Last edited:
