I am using a Matek 405 Wing and a Spedix GS30 BL_32 ESC. I set SERVO_BLH_AUTO =1 and SERVO_BLH_MASK =3 (Ports S1 &S2) ESC and motor are connected to ESC1 and signal with ground wire to S1.
I was not able to bring up MOT_PWM_TYPE or Q_M_PWM_TYPE to set those to 4 (Dshot 150)
When I connect with BL Heli 32 Suite it connects but I when attempting to read the setup I get an error “Found no valid ESC configuration”
Additional Information:
I found a bunch of commands in Arduplane for the Maytek 405 board while looking at the configuration commands list. They are all SERVO_BLH_***** settings which included AUTO, DEBUG, MASK, OTYPE, TEST, TMOUT, TRATE.
DEBUG=1 for enable de-bugging
MASK=1 to match _AUTO
The command OTYPE is the setting for the DSHOT Speed, it was at 0 and I set it to 4 which is for DSHOT150.
PORT is to set the Telemetry port for the ESC so I set that to 1 for S1 Which is where I have the ESC connected
TEST=0 for no test
TMOUT is for setting an “inactivity timer” for the ESC, I let it at 0
TRATE is for setting the Hz Request for telemetry from the ESC and I also left that at 0
It seems like the instructions in the Wiki are a bit out of date as these commands are not addressed bu the some of the settings like setting DShot to 150 using MOT_PWM_TYPE or Q_M_PWM_TYPE which I could not find in the list for the 405 board.
If anyone has information about this I would really appreciate the help. Id love to get this wing in the air
Thank for the reply, I was behind one version at 32.6.1.3 so I updated to 32.6.1.6. Now I get a message that states Connection to flight ctrl at com 15 failed “set com statc function failed system error code 121 the semaphore timeout period has expired” Please check usb/serial port status
I re started the flight controller and re-connected and got the same result. I then checked windows and the FC is still shown as present at com15. I was able to connect, at com 15, to Mission Planner.
Thinking it might be a driver issue I again disconnected and re started the flight board and tried BLHeli again, same response. I used both Zadig and Imersioin RC Driver fixer, re-setting between each, and continue to get the same message.
I am going to start the aircraft up with no props and test to see if everything is working properly and if, now that I have the FC configured to output DSHOT150, the throttle seems smoother than it did before. My concern is that the throttle was so stepped (RPM adjustment was in steps rather than a linear response) that it would not fly well and it would not respond well to autonomous flight modes.
While I realize all this is rather new I’d rather sort out as much as I can on the ground vs just tossing it in the air and hoping it works. Again thanks for your help.
Spent sometime last weekend having exactly the same issue as you:
Setup:
Matek F405-Wing
arduplane 3.9.8
Blheli_32 Hobbywing x-rotor mini (not the 4-in-1)
Set up passthrough and masks in Mission Planner
Tried 3x versions of blheli32 software (32600, 32610 and 32616) but could not connect at all; Mission Planner connects fine. Tried all the driver fixing programs. Tried different COM ports too. Blheli32 error message:
In the end I flashed Betaflight on a spare omnibus F4 board and, on the same computer, with the same drivers and USB cable managed to do a passthrough connection with it and configure the ESC with the blheli32 software.
Not of much help I know, but at least the issue seems repeatable?
i just did some testing and have to say while blh32 features basically work, there’s a couple of things to pay attention to that make blh32 handling on ardupilot a bit less than intuitive.
ardupilot min PWM out defaults to 1100, while at least on my wraith32 esc the min PWM defaults to 1040. unless specified otherwise, the ESC won’t see the expected min PWM on startup and eventually fail to allow passthrough connect.
at least on plane firmware setting SERVO_BLH_AUTO = 1 alone won’t allow reliable detection of connected blh32 ESCs. specifying the outputs using SERVO_BLH_MASK however works reliably no matter what _AUTO is set to.
there were compatibility issues with blh32 suites 32.6.1.2 to 32.6.1.4. see BLHeli32 Dshot not finding ECS with passthrough for reference. suite revisions 32.6.1.5 and latest (as of now) 32.6.1.6 do work, as well as earlier revisions 32.6.1.1 and back.
windows USB port / driver handling has some potential to interfere as well, that might be specific to my PC though. under certain conditions shutting down and restarting MP or blh32 suite was required to regain access to the USB port.
to sum it up, setting the following preconditions allowed reliable passthrough connect:
set the FC’s and / or the ESC’s min PWM to allow the ESC to initialize reliably on startup. setting your motor output’s min PWM to 1000 will allow reliable ESC initialization in most cases. adjust from there if required.
use SERVO_BLH_MASK to distinctively specify the outputs used for blh32 ESCs.
use a compatible blh32 suite revision, preferably 32.6.1.5 and up. don’t use 32.6.1.2 - 32.6.1.4.
it might be worth adding that sometimes on a failed first attempt to connect via BLHeli32 suite, simply hitting the „connect“ button a second time did work…
