I have a Matek H743 wing v2 running 4.1.7 and a BLHeli_32 ESC. With the regular load, or with the “-bdshot” load with SERVO_BLH_BDMASK=0 the ESC telemetry works as expected.
If I set SERVO_BLH_BDMASK=1, write it out, and reboot the flight controller, then there is no ESC telemetry.
I verified that Arduplane 4.1.0 (which first introduced the -bdshot capability) shows the same behaviour.
Also, the “-bdshot” load seems to be missing the NTF_BUZZ_ON_LVL option, and my buzzer just clicks instead of actually beeping. It seems like this is currently expected based on some other discussion board comments, but it’s not actually documented in the “Bi-directional DShot” section of the docs.
Could we instead steal timer15 from outputs 11/12 (which are in a weird location anyways) and put the beeper back the way it was? The click is essentially useless, you can’t hear it from any distance.
In 4.2 you can assign a motor output to the buzzer - you will need a buzzer that works with arbitrary GPIO, e.g. a 3-pin buzzer but it works. You can’t assign a random timer to the buzzer pins themselves - there are only so many options.
Be careful only setting single outputs for bdshot - you need to set the whole group, so on that board I think it is outputs 1 and 2.
I was thinking instead to rebuild Arduplane with different definitions to give up the last two motor/servo outputs (they’re a single group, it looks like), use their timer for bdshot, and keep the original buzzer.
Thanks for that chart, I haven’t read up on the lowlevel details.
First, is the broken BLHeli_32 telemetry related to these settings? Or is that a separate issue? My ESC telemetry was plugged into Rx8.
As to your earlier comment about setting the whole group to bdshot, you’re right that it’s outputs 1 and 2. But output 2 is unused, and when I set just output 1 to plain old dshot, the OS automatically set both outputs 1 and 2 to dshot rather than PWM. Would the bdshot setting behave differently? (I’m fine setting both, just curious.)
Isn’t DMA mux input 105 in that chart for timer 15 channel 1? But I see there’s no mux input for timer 15 channel 2.
Could we give up motor outputs 7-10 and use timer4 for bdshot? Or give up timer1 from the LED (PWM13) and use that for bdshot?
Could you explain the part in the bdshot hwdef.dat where it says “Disable DMA on PWM9-12 so that the LEDs get a channel”? Why are we modifying motors on two different timers?
The comment in the MatekH743-bdshot/hwdef.dat file says “so buzzer becomes single tone”, but it doesn’t become a single tone, it literally just clicks.
First, is the broken BLHeli_32 telemetry related to these settings? Or is that a separate issue? My ESC telemetry was plugged into Rx8.
No, likely you have not got dshot at all - telemetry requires dshot
Would the bdshot setting behave differently? (I’m fine setting both, just curious.)
It’s a bug in 4.1, fixed in 4.2 IIRC
Could we give up motor outputs 7-10 and use timer4 for bdshot? Or give up timer1 from the LED (PWM13) and use that for bdshot?
You can organize it however you want. LEDs require a timer and DMA
Could you explain the part in the bdshot hwdef.dat where it says “Disable DMA on PWM9-12 so that the LEDs get a channel”? Why are we modifying motors on two different timers?
There are only so many DMA channels and some require exclusivity
The comment in the MatekH743-bdshot/hwdef.dat file says “so buzzer becomes single tone”, but it doesn’t become a single tone, it literally just clicks.
If I run the regular load this works fine and reports current/voltage/RPM/temp as seen by the ESC. If I run the -bdshot load then the normal BLHeli_32 telemetry doesn’t work, even if I don’t actually try to enable bdshot.
This is the built-in buzzer on the H743-wing V2. It appears to only have two pins which I guess makes it a passive buzzer. Maybe there should be a comment indicating that for the wing boards a separate active buzzer will be needed?
If I run the regular load this works fine and reports current/voltage/RPM/temp as seen by the ESC. If I run the -bdshot load then the normal BLHeli_32 telemetry doesn’t work, even if I don’t actually try to enable bdshot.
Should work - sounds like bug. Can you try 4.2?
This is the built-in buzzer on the H743-wing V2. It appears to only have two pins which I guess makes it a passive buzzer. Maybe there should be a comment indicating that for the wing boards a separate active buzzer will be needed?
Active are also two pins, but I guess the one they supplied isn’t
With v4.2.0 beta 5, with SERVO_BLH_BDMASK=0, the blheli telemetry seems to work okay. Motors 1 and 2 are configured for dshot. If I set SERVO_BLH_TEST the test passes, but after that the telemetry is frozen and even power-cycling the ESC doesn’t help. I have to reset the flight controller to clear it.
If I set SERVO_BLH_BDMASK=3 and then reboot the FC, there is no longer any ESC telemetry that gets reported. It still passes the SERVO_BLH_TEST.
If I set SERVO_BLH_BDMASK=0 and then reboot the FC, the ESC telemetry is back.
Just curious, when using bdshot, is there a way to see what RPM is being returned by the ESC via bdshot? One of the status entries or something?
One other thing…if the ESC loses power the last values of the ESC telemetry stay latched in the “esc1_*” entries in the “status” window in mission planner. This seems wrong, they should be reset to zero so as to not mislead anyone.
I used the latest 4.3.0-dev bdshot code. I turned off blheli debug (if it can cause problems maybe there should be a warning in the help text for the option?), and set SERVO_BLH_TRATE to 0 and set the bdshot mask to cover outputs 1 and 2 and I was able to see the motor rpm under the “esc1” telemetry outputs, but none of the other telemetry. So that part seems okay.
I did discover something odd though. After booting the flight controller if I run the BLHeli self-test (SERVO_BLH_TEST) before spinning up my motor then it passes. If I spin up my motor first and then run the self-test it fails. I tested this three times each way and it’s consistent.
Also, after running the self-test the motor no longer responds to the throttle. I have to reboot the flight controller.
Yeah there are some oddities with the MSP part of the BLHeli implementation - you see the same thing if you connect BLHeliSuite. I would always advise rebooting after either using self test or passthrough. I have had a couple of small attempts at resolving this, but its a complicated piece of code and a long standing issue (predates my involvement).
I’m still seeing the issue where if the ESC loses power the last values of the ESC telemetry stay latched in the “esc1_*” entries in the “status” window in mission planner. This seems like something that could potentially cause problems.
Would this be considered a bug? Should I open an issue for tracking?
This is because if the ESC is not powered then no data is sent. Any function that cares about the validity of this information will be checking the return value of get_rpm() which will be false for any data more than 1s old. So this is simply down to how mavlink is reporting the status.
I want to get the voltage/current telemetry via bdshot, without a dedicates ESC telemetry wire.
But now I’m getting the ESC telemetry only if ALL of these conditions are met:
ESC wire soldered to UART RX
SERIAL_X PROTOCOL = 16 (ESC Telemetry)
Using the -bdshot firmware
SERVO_BLH_TRATE > 0
This is odd because I believe with bdshot I dont need to solder a dedicated wire, and I don’t need for a SERIAL_X and SERVO_BLH_TRATE params.
The possible reason could be the motor groups assigments, it is not very clear what is the restrictions for motor channels/groups etc. I have two usual servos connected to M1 and M2 channels. And blheli32 ESC on the M3 channel.
RC Out log in MP: RCOut: PWM:1-2 DS150:3-4 PWM:5-13
SERVO_BLH_TEST gives the error: ESC: bad channel 3
You can’t do this. This is a change to the bdshot protocol which is not yet merged in either BLHeli32 or Betaflight. When support is finalised I will eventually do the necessary changes to support this.
