If you switch on debug in blheli suite what does the output look like?
I’ll try that now. I just tried an older version of suite to see if it would help as I had that issue in the past, but now it throws a different error.
Here’s what I get from the log. To be clear there is good communication between the cube and esc as I can run the motor tests without any issue in Mission Planner.
You could also try turning on SERVO_BLH_DEBUG and setting SERVO_BLH_TEST to 1 and see if it passes (look in the messages tab)
Can you expand the ‘+’'s it’ll show how far it got?
I built an arduino interface for my BLHeli ESCs because I can NOT get pass through working on my cube, so I gave up.
Stupid question, but you are using DSHOT right? Passthrough won’t work unless you are using DSHOT (which means you need to use outputs not on the IOMCU)
Yup I’m using DSHOT. I’ve done this setup with black cubes many times and haven’t ever had a problem like this.
Absolutely. I have a couple of copters with cubes and I can’t get any working. I am using the CUAV V5+ cube. Some use the pwm outs and some the aux outs.
At this point it doesn’t matter for me as I have a method to do what I need
I use a old Naze32 FC as a BLHeli programmer for occasions when passthrough doesn’t work. They are ~$13 for the Acro version.
1 Like
I have a black cube that I use for testing that I could use to program the ESC on this bird. That said we plan on making quite a few of this aircraft and I was hoping to streamline the manufacturing process as much as possible.
I’ve added this to the Copter-4.0 issues list so it won’t be forgotten.
It’s very clear that the BLHeli/DShot setup is too difficult. I personally think we’ve got multiple issues going on and we need to identify and then knock them on the head one after another. We’ve got a small change coming which helps users figure out what the board thinks it’s outputting so this will hopefully allow users to identify more quickly when there’s an error in the config.
I’m going to take a random shot in the dark that the issue with using BLHeli on the OrangeCube has something to do with the new high performance boards (CubeOrange, Durandal) presenting two COM ports. I suspect either the BLHeli suite or our passthrough is going to the wrong one. Anyway, we will investigate!
1 Like
Just an FYI…
When you enable CAN On the CUAV V5+ cube flight controllers (assume others as well) you are also presented with two serial ports. One is for normal mavlink and the other is SLCAN that is used for directly accessing the CAN devices, similar to the UAVCAN software
…Dont you need to set SERVO_BLH_OTYPE to 4/5/6/7? Even if _AUTO works, I dont think it sets the output type.
set SERVO_BLH_OTYPE to 4 (= DShot150).
https://ardupilot.org/copter/docs/common-dshot.html#configuring-dshot-esc-protocol-output
…and the_AUTO didnt work for me, I had to set it manually with _MASK:
Use SERVO_BLH_MASK to enable BLHeli_32 pass-through and telemetry support on non-multirotor motors and / or exactly specify which servo outputs you want to enable BLHeli_32 pass-through and telemetry on.
*Edit: Disclaimer: I dont have an orange cube
There does seem to be a issue with BLH passthrough not working on the CubeOrange, the Dev - Team is working on it, hopefully we will have a fix soon.
3 Likes
I can verify that passthrough works with 4.0.2 on my Omnibus nano v6.
I can verify that passthrough works with 4.0.1 Pixhawk 3 Pro and doesn’t work on the Cube Orange
1 Like
Copter-4.0.3-rc1 has a fix for BLHeli passthrough on CubeOrange. I think you’ve tested that PR and found it works. Can you re-test with Copter-4.0.3-rc1? If it doesn’t work, could you re-test with master?
I was wondering if you could post log files? I’d like to see the parameters and also the “RCOut:” message which will tell us what outputs the autopilot thinks it’s using.
ok, what exactly do I do to record a log file?