So i was flying my quad for the third time and everything was great. Suddenly the motors stop and it fell out of the sky. Can anybody tell me what happened?
 
Here's what i can give you:
 
Flight Controller:
F4 V5PRO (https://www.banggood.com/F4-V5PRO-Flight...mds=search)
 
Logfile:
https://drive.google.com/open?id=0B-0OCp...DVCamdDbmM
 
Firmware:
Betaflight 3.1.7 (Here’s a backup of my configuration: https://drive.google.com/open?id=0B-0OCp...TEybldpcGs)
 
I’ve assigned one switch to arm my copter and another 3-pos switch for the following flight modes:
-Angle
-Horizon
-Airmode
See picture attached.
 
The function “Disarm the motors regardless of throttle value” is activated
 
I’m confident that I did not touch any of the switches before the quad fell out of the sky.
As you can see at the end of log, for some reason the flight modes changed and ARM was disabled. I guess afterwards it dropped. But I don’t see what triggered this behavior.
 
Failsafe setup:
See picture attached
 
Please let me know if there’s anything else I can provide. I appreciate every help I can get.

Welcome to the forum!

I have questions:

How far away from you was the quad when this happened?

What radio and receiver are you using?

Why have you set the failsafe system the way you have?

Air mode is not a flight mode, it is a feature that is added to the current flight mode. So, with your current mode settings, selecting air mode will also set the flight mode to acro as neither horizon or angle mode will be selected.

The backup of your configuration does not tell us everything about how you have the quad set up. What you need to do is to go to the CLI, type "diff" and then copy the text that appears when you press enter. You can also type "dump", which shows the entire configuration, "diff" only shows what is different from the default values. When posting a dump or diff, please surround the text with [ code ] [ /code ] tags (without the spaces). This will make sure that a long text does not make a really huge post. For example:

Looking at your black box log, you have a huge peak of noise centred at 143Hz on your pitch axis. Because your D-term notch filter has the cut-off at 160Hz, all that noise is being played back on the D-term and making your motor speed change up and down all the time.

It wouldn't surprise me if your motors were very hot when you landed after your 7.5 minute flight. That's not why you 'fell from the sky', but you need to find out what is causing that vibration. Something loose? Damaged or out of balance propellers? Out of balance motors?

That was quick!


1. I’ using a Futaba FF9 with a FrSky DFT 2.4Ghz TX module and a FrSky V8FR-II RX receiver.

2. The distance when I lost control was about 100m, far from the known transmitter range.

3. My idea behind my failsafe setup:
A) If I should ever travel outside TX range, the RX will send ~930 on the throttle channel to the FC. That’s my RX failsafe procedure in case of signal loss. FC failsafe stage 1 should be triggered now.
B) In such a situation, I don’t want my quad to hold the current angle, I want it to become level before stage 2 (landing) kicks in. That’s why i configured 1100 on AUX2, this should activate the angle mode. I understand that “auto” setting on channel 1-4 will bring the stick levels to neutral (except throttle), supporting my leveling theory.
C) Stage two should set motors to 1320, this means 4A overall current (Tested) while I now that the current at hovering is 6A -> I expect the quad to descend instead of free fall
-> Guard time 8=0.8sec. + Auto fallback procedure of throttle channel in stage one -> Does that mean that my motors will be set to zero power for 0.8s until my landing procedure value of 1320 kicks in? This would be concerning but I don’t understand these relations entirely.
-> Delay for turning of the motors during failsafe =40=4seconds -> I understand that once the quad is in stage two with the preset landing power of 1320, after 4 seconds the motors will be off no matter how far the ground still is (?)
Looking forward to your feedback :-)
 
4.Unfortunately I don’t get that [ bracket ] forum-feature to work regarding the requested “Dump” and I couldn’t find any info on the forum so I attached the “Dump” and “diff” file as pdf… I’m sorry.
 
I’m surprised that you found this noise on my pitch axis as all components are (were) tight and new but I did not test the props on my balancer so far. Can you recommend a tutorial so that I can find/analyze/improve this noise by myself? Why is this noise limited to the pitch axis? (I’d expect vibration to affect every axis)

Thanks a lot for your time & support.

Hmmm....

Although you were only 100m away, I really can't see any way that the flight controller would disarm unless some kind of failsafe event happened. Depending on how you have mounted the receiver antennas and how your radio's antenna was orientated, it's not impossible to get a failsafe at 100m

When you set up your receiver, how did you set failsafe on it? As you may know, you can either set the desired control positions on your radio and briefly press the failsafe button on the receiver, or you can turn off the radio and briefly press the failsafe button. The second way causes the receiver to stop sending any PPM signal to the flight controller if it loses contact with the radio.

For Betaflight/Cleanflight, the 'no pulses' failsafe is what you need. If you use the first method, the flight controller cannot detect that the radio has entered failsafe mode as there is still a valid PPM signal with valid channel values.

The important thing here is that you configure your receiver for 'no pulses' and that you check that failsafe works by removing your propellers, arming the craft and then turning off your radio. Personally, I set my failsafe to "hold" for one second and then drop if the signal does not come back. While "land" sounds tempting, you can't predict what altitude or attitude your quad might have when it loses signal and having the flight controller still spinning the motors when the quad has already hit the ground or flown into a tree can mean that the propellers could be prevented from turning and will give you cooked motors and burned up ESCs.

The vibration isn't severe, it's more the PID controller's reaction to it that seems to be exaggerated. How vibration affects a frame is unique to the frame and the propellers and motors being used and how the filters and PID controller are set up. In your case, there is a small vibration being picked up by the pitch gyro:



This noise is then expressed in the P-term:



And picked up by the D-term:



Which leads to a lot of noise being output to the motors:



Seeing as how your D-term notch filter is centred at 260Hz and has the cutoff at 160Hz, I'd be tempted to move the centre down to 220Hz and the cutoff down to 120Hz. This should filter out the noise that is centred at 143Hz.

If that's not enough, then move to 200Hz with cutoff at 100Hz.

Here's my TX:


My RX:


With this setup, i used to fly my hexacopter >1km LOS.

I have preset my RX failsafe throttle value to ~920 because i thought that together with the Betaflight "Valid Pulse Range Settings" in the failsafe tab (=990) -> my 920 will be considered as invalid by the FC -> And this would trigger failsafe stage 1. 

At this point i'd like to mention that my RX does not have any serial output and the FC only accepts serial input. So i added a converter between RX and FC which is set to PPM output:

 
I have tried to change the RX failsafe to no-pulse. However, the receiver tab still shows the same values like before. It even does this when i unplug the serial cable from the FC. Is there any better place to check the incoming PPM values?


Do you recommend to change the channel map or switch to SBUS?

I was hoping that the logfile would indicate the exact reason why failsafe was triggered which lead to the crash. Since this seems to be impossible, i guess it comes down now to trial and error. This is what i have in mind:
1. Exchange the RX with another unit (same type)
2. Switch the serial converter to SBUS
3. Uncheck "Disarm the motors regardless of throttle value"
4. Change my FC failsafe configuration according to your advise "Hold for 1sec -> drop"
5. Change the filter configuration according to your advise
-> If it crashes again, i may swith to Cleanflight. not because i know it any better but because i've seen other Betaflight quads with the exact same malfunction and no explanation to it.

Still appreciating your advise...

If you're using a converter, then I doubt that the converter will correctly transfer 'no pulse' failsafe. Sorry, I didn't realise that the V8FR-II didn't have PPM output.

The log doesn't show that the flight controller entered failsafe mode. If you look at the log in the Black box Explorer, you can press 'T' to show the detailed status:



Just after the quad disarms, you can see that rxSignalReceived and rxFlightChannelsValid are still 1 and that failsafePhase is still 0. So, the flight controller itself isn't seeing a failsafe condition.

The Betaflight firmware itself won't suddenly disarm without being told to. Although the black box log does not include the exact values of all the AUX channels, it is recording that the AUX channel values changed and the only way the craft could have disarmed is if AUX1 went below 1350.

Looking at the image you posted of your channel values with the connection from the converter to the flight controller unplugged, it shows AUX1 at 1135 and AUX2 at 1100. These values correspond with the mode selections recorded in your log at the time the quad disarmed and crashed.

This would suggest to me that your converter either became disconnected or stopped working.

I see your point. When i watch the last 500ms of the logfile, the flight channel signals were alive until the very end. I assume this proves that the PPM signal wire was not disconnected. So it appears that:
-      At 07:30:465 I switched from Acro/Airmode to Horizon with AUX2 (3-position TX flip switch C) and then
-      At 07:30:506 I switched from Horizon to Angle mode with AUX2 (TX flip switch C) and at the precise same moment I disarmed the aircraft with AUX1 (TX flip switch A)



I’m not sure if its even possible to switch both TX switches simultaneously in midflight.

Since the throttle channel remains around 1328 until the finish, I assume that the disarm status and the resulting crash could have been avoided by unchecking the setting "Disarm the motors regardless of throttle value". Correct? Obviously it would be much better find the root cause for the AUX1+2 channel behavior.

Since my FrSky V8FR-II receiver des not support PPM output. I’m considering now to purchase the FrSky 8CH D8R-XP receiver (https://www.banggood.com/FrSky-2_4G-8CH-D8R-XP-D8RXP-Telemetry-Receiver-p-1008354.html?rmmds=search) which would make my PPM converter unemployed since it has PPM and RSSI output. I’m 99% confident that it is compatible with my FrSky DFT TX module  (https://www.banggood.com/Wholesale-FrSky...mywishlist).

Disabling "disarm regardless of throttle" is a good idea. It's also very useful for landing, particularly if you have air mode permanently enabled. As you come in to land, you flip your arm switch to disarm. The flight controller is still armed as you land until you finally drop the throttle to zero. This actually makes it much easier to land, particularly if you are landing with FPV.

I can't fully explain what happened in your log. You're right to note that the throttle and other channels still appear to be active, even after the AUX1 channel changes to disarm the quad. This makes no sense to me and speaks against my theory that the converter became disconnected from the flight controller.

I am using Betaflight on quite a few quads, mostly with S.BUS receivers, but there are some PPM and Spektrum serial receivers in the mix as well and I have never seen Betaflight itself do anything like what happened to you. Although you commented that you had "seen other Betaflight quads with the exact same malfunction", I find it hard to believe that there is such a critical bug in Betaflight. It would have been reported, reproduced and fixed.

I'm sure your DFT module would be compatible with the receiver that you linked to, but the main drawback with that receiver is the ridiculous size compared with other available choices like the D4R-II. If you don't need 1.5Km range, there are also tiny single antenna D8 compatible receivers on BG that work very well.

It's a mystery what went wrong, but I'd still suspect your converter or your receiver before I'd suspect the flight controller.

To be fair, i've seen one other Betaflight quad which fell out of the sky multiple times because the motors suddenly stopped spinning. So it looked exactly like my case but i'm not sure if my friends quad had a blackbox and what type of analysis he did. It's very well possible that there's a different reason and in neither case it's "Betaflight's" fault. It wouldn't be right to blame it on the software considering the positive experience of the other users.

You're right, the D4R-II is a much better choice, i just realized that i don't need 8 physical outputs if i go for CPPM anyway. The order is currently being processed and if i have a bug in my RX or PPM converter, the D4R-II will solve it.

I also look forward to solving the vibration issue, maybe i'll ask for your help again with future logfiles but for now i think we can close this case. Thank you very much for your time and explanations which really did help for my understanding.

My pleasure! I'm glad I could help.

Our quads are quite complex devices these days and there are many different factors that can lead to things going wrong. In most cases, a black box log, photographs of the build and a full listing of the components used can lead to a full diagnosis of the cause.

Your problem is one of the first I've seen where I can't offer a full explanation, so I'll be really interested to hear if switching to the D4R-II makes your problem go away.

Just an update: 

I received the new FrSky D4R-II and i tried to set up its failsafe to "no-pulse" as recomded by unseen. I fallowed the instruction from unseen which are identical as in the user manual. It did not work on the bench and so i ended up watching this video: 
To my surprise, this acctually DID work even though it is much more complicated. Looking at the video feedback, i'm not the only one who struggled seting up the correct failsafe mode on this particular RX. 

Since my quad is still in repair status, i only tested it with the Betaflight interface: