Hi guys

I've just built my first quad (my first aircraft) and now looking for a little help.
The drone is a Q380 quad as follows;

• Q380 frame
  
• 3S Lipo
  
• 2212 980kv Brushless Motors
  
• DYS BLHeli ESC 30Amp ESC
  
• Matek power board
  
• Naze32 Rev 6 controller
  
• Radiolink AT9 transceiver
  
• Radiolink R6D receiver
  

In Cleanflight I can set up min and max speeds, control the motors with the sliders and see control signals coming in from the AT9 txr.
I cannot however, control the drone with the transmitter.

The Arm Mode is controlled from AUX 1, but I don't fully understand this. I've set switch C on the AT9 as the arm switch.
I suspect I simply have to arm the system, but don't know how to do this. 
As you can see, I'm a rank beginner.

What do I need to do next?

Many thanks

Could you post a picture of your modes tab in cleanflight?

---

When you are in the transmitter tab, flip the c switch on your transmitter and see which aux channel that responds. This will be the aux channel you will set as the arm switch in the modes tab. Drag the slider to the command area where you want your switch to arm, and push save. If done correctly, you should see that the arm box will turn yellow whenever you flip the switch and it should work.

If not, see if the cpu usage is not too high, write status in the cli command window, and look for cpu usage. If it says 100 or 1, then it is too high, and will not arm. If you have chosen a looptime that is too high, you might need to lower it to get the cpu usage down. It could be something else, but this is my first thoughts

(27-Sep-2016, 06:20 AM)oyvinla Wrote: Could you post a picture of your modes tab in cleanflight?

---

When you are in the transmitter tab, flip the c switch on your transmitter and see which aux channel that responds. This will be the aux channel you will set as the arm switch in the modes tab. Drag the slider to the command area where you want your switch to arm, and push save. If done correctly, you should see that the arm box will turn yellow whenever you flip the switch and it should work.

If not, see if the cpu usage is not too high, write status in the cli command window, and look for cpu usage. If it says 100 or 1, then it is too high, and will not arm. If you have chosen a looptime that is too high, you might need to lower it to get the cpu usage down. It could be something else, but this is my first thoughts

Thank you oyvinia

Here's a couple of screen grabs.



I appreciate the information.

Is the switch a two or three way switch? I normally use a two way switch where I arm at the high value, so I drag the slider all the way up, so it covers from around 1500 to 2000. If you have a three way switch, the way you have set it up, you will now have the quad armed in the middle position

(27-Sep-2016, 07:14 AM)oyvinla Wrote: Is the switch a two or three way switch? I normally use a two way switch where I arm at the high value, so I drag the slider all the way up, so it covers from around 1500 to 2000. If you have a three way switch, the way you have set it up, you will now have the quad armed in the middle position

Yes, it's a three-way. I can set it to arm in the third position but it still won't arm (Arm doesn't change to yellow in the Mode tab).
I'm not familiar enough with the AT9 to assign ch5 (AUX1) to a two-way switch.

I'm beginning to wonder if the Naze32 is faulty, but it doesn't make sense.

This forum post is because I've run out of ideas.

Cheers

If you go back to the transmitter tab, you can see that aux1 is responding when you flip on switch c on your transmitter?

(27-Sep-2016, 07:29 AM)oyvinla Wrote: If you go back to the transmitter tab, you can see that aux1 is responding when you flip on switch c on your transmitter?

Yes, everything responds to transmitter signals, including the aux1.
In my case, it's switch C.

I had some similar issues like you when I first started and the way I fixed it was reflash the board with full chip erase and set up everything all over again. I don't know why, but it could be something with your settings. You could post screenshots of your different settings tab and a CLI dump and we can have a look at it to see if there is anything that is not like it should be.

(27-Sep-2016, 08:01 AM)oyvinla Wrote: I had some similar issues like you when I first started and the way I fixed it was reflash the board with full chip erase and set up everything all over again. I don't know why, but it could be something with your settings. You could post screenshots of your different settings tab and a CLI dump and we can have a look at it to see if there is anything that is not like it should be.

Thanks very much for your persistence oyvinia.

Screenshots as requested and CLI dump attached.

Try to disable the aux1 under the adjustments tab. I'm not sure as I never use the adjustments, but it could be that it affects it.

(27-Sep-2016, 09:39 AM)oyvinla Wrote: Try to disable the aux1 under the adjustments tab. I'm not sure as I never use the adjustments, but it could be that it affects it.

Thanks my friend.

No joy there either . . .

To arm via switch or throttle stick, your throttle input MUST be below min_check.  From cleanflight docs:

min_check - With switch arming mode is in use, lowering your throttle below min_check will result in motors spinning at min_throttle. When using the default stick arming, lowering your throttle below min_check will result in motors spinning at min_throttle and yaw being disabled so that you may arm/disarm. With motor stop enabled, lowering your throttle below min_check will also result in motors off and the esc's being sent min_command. Min_check must be set to a level that is 100% reliably met by the throttle throw. A setting too low may result in a dangerous condition where the copter can’t be disarmed. It is ok to set this below min_throttle because the FC will automaticly scale the output to the esc's

Use the cli to find value of min_check (code: get min_check).  Then go to receiver tab and see what cleanflight interprets you minimum throttle input.  Set endpoints in your transmitter so that the minimum throttle value is less than min_check.  (Or you could change the value of min_check - better to lower endpoints, though.)

Edit: I always make sure my low throttle input is below 1000 as a matter of course. This puts it below min_command and min_check even with cf/bf defaults.