Implementing some DShot special commands

[FieserKiller]

Implementing dshot commands, especially the beep command would be great as we could get rid of clunky piezo buzzers on fcs.

See corresponding betaflight feature request: https://github.com/betaflight/betaflight/issues/3061

[sskaug]

This is on the list for BLHeli, probably first off for BLHeli_32. I've been looking around in Betaflight, but not (yet) been able to find good info on what dshot commands are implemented. Is there a good overview somewhere?

[brycedjohnson]

I was recently looking at adding the ESC beep... just trying to brush up on my old asm knowledge. But I'm sure you could add it in 1/10 the time. 👍

Here is what kiss implemented: https://www.rcgroups.com/forums/showthread.php?2756129-Dshot-testing-a-new-digital-parallel-ESC-throttle-signal

request area is 1-47 the kiss24A uses 1-13 from it 1-5: beep (1= low freq. 5 = high freq.) 6: ESC info request (FW Version and SN sent over the tlm wire) 7: rotate in one direction 8: rotate in the other direction 9: 3d mode off 10: 3d mode on (3d mode dont workes with Dshot ATM) 11: ESC settings request (saved settings over the TLM wire) (planed but not there yet) 12: save Settings

According to @mikeller this CLI command can send the special commands right now:

dshotprog <esc number> <command> ... <command>

with ("255" is "all escs")

[mikeller]

@sskaug: https://github.com/betaflight/betaflight/blob/master/src/main/flight/mixer.h#L29-L43

I've implemented CLI support for these commands (except for the part of receiving and displaying feedback to 6 and 11, but this probably won't be possible with blheli based ESCs, since they lack the telemetry serial feedback support).

Happy to help with the implementation, let me know.

[sskaug]

Thanks a lot for the info! Implementing this and telemetry is next on the list for BLHeli_32. However, at the moment I have my hands full getting _32 rolling. So, please let me come back to this in a little while :).

[mikeller]

No hurry. We've got the KISS implementation that we can use to test the flight controller code against.

[FieserKiller]

Looks fixed! https://redpinelabs.com/dshot_commands/ at least for beep and direction switch commands. Strangely I can't find a pull request o_O

[sskaug]

@mikeller Now telemetry is implemented in BLheli_32, and will hopefully roll out soon. So I started looking at dshotprog. Is there anything special I should consider? I just looked briefly at it, and it seems you only send one frame with the command? No redundancy/error protection from using multiple frames? And you only allow the commands to be sent when disarmed?

[mikeller]

@sskaug: That is good news indeed. The telemetry is compatible with how it is done for KISS?

The 'spec' for Dshot lives here: https://github.com/betaflight/betaflight/blob/master/src/main/drivers/pwm_output.h#L36-L61

As for safety, you get the CRC check that is done on every frame. Then, for a command, the telemetry bit needs to be set. Plus, for all config change / save commands, they have to be sent 10 times consecutively for the ESC to accept them. (All documented in the above link).

Re telemetry, Betaflight now also supports reading of the ESC info (see betaflight/betaflight#3474, some more changes to come there), so it'd be great if we could standardise on the format for the info frame.

[tracernz]

Hi @mikeller. If you want to standardise it, any chance we can document it somewhere neutral where everyone can discuss/contribute? That would be much appreciated. :smiley:

[mikeller]

@tracernz: Yes, good suggestion. Do you have a suggestion on what to use as 'neutral ground'? (I am not fazed about keeping it a part of the Betaflight repository, since we're open source, and everybody can submit change proposals by pull request.)

Also, good work on your saleae Dshot analyser, it's very useful!

[sskaug]

The BLHeli_32 telemetry is compatible with the KISS telemetry spec. Why are there special DSHOT_CMD_SPIN_DIRECTION commands for BLHeli_S?

As for the ESC info telemetry frame, how many bytes is it? I guess we would need "BLHeli_32" and the FW rev, and probably also the ESC model label.

[tracernz]

@mikeller I kinda wonder if it's worth a repo for all things that are of interest to BLHeli, KISS, BetaFlight, MWOSD, dRonin etc. e.g. the MSP canvas commands for OSD, BLHeli passthrough. The repo could contain Markdown files, and proposals could be submitted as PRs, where we can all discuss/suggest. Heh, maybe it would just slow things down though? Hard to say what the protocol would be if somebody disagreed.

Glad you enjoy the analyser. I should give it some more love, maybe support for DShot commands. :wink:

[mikeller]

I am not sure if one repo for all these different 'areas of interest' would be a good thing. For people wanting to participate on only one or a few of the topics, getting inundated with GitHub messages for all areas would be a pain. What I could see would be an organisations with a wiki for drafts, and one repo for 'standards' and proposals for each area of interest.

The analyser is sweet as as it is, going from a value < 48 to a command is a no brainer. What would be a great addition though would be support for ProShot. (https://github.com/betaflight/betaflight/blob/master/src/main/drivers/pwm_output.c#L159-L167) ;-)

[mikeller]

@sskaug: The DSHOT_CMD_SPIN_DIRECTION commands were added to allow temporary reversal of the spin direction in the field, to recover a craft that has crashed upside down ('anti-turtle function'), without running the risk of this causing an inconsistent config to be permanently stored (fyi, KISS now implements these commands too: https://github.com/betaflight/betaflight/pull/3267#discussion_r125990478

I am talking through the ESC info format with Felix from KISS right now: https://github.com/betaflight/betaflight/pull/3267#discussion_r126349307 (maybe we should talk 'live' on slack or so?)

[mikeller]

@sskaug: Update: https://github.com/betaflight/betaflight/pull/3267#discussion_r126377236 To me, this sounds good. 128 types is plenty, and there are 2 so far unused bytes that could be used to encode subtypes for the blheli_32 types.

Any recommendation on what hardware to get to test blheli_32 telemetry?

[sskaug]

The Airbot Wraith32 should be a good test vehicle for BLHeli_32

[sskaug]

I just posted some proposals here: https://github.com/betaflight/betaflight/pull/3267#discussion_r126377236

[sskaug]

BLHeli_32 test code for the Wraith32 is published here: https://github.com/bitdump/BLHeli/tree/master/BLHeli_32%20ARM

[sskaug]

Test code for BLHeli_S is published here: https://github.com/bitdump/BLHeli/tree/master/BLHeli_S%20SiLabs/Rev16.61%20Dshotprog%20test%20code

[KnuckleUpFPV]

tested the new blheli_32 dshotcmd hex and tried the anti turtle setup. It changed all the motors to one direction. Once the turtle switch was off all the motors went the other direction and would not default back to regular rotation. After power cycling the same thing. However if I spun the motors up in blheli suite or betaflight motor tab, they spun the correct direction. From the transmitter all one way. I had to flash back to the last telemetry release to fix this issue. This was on the wraith 35a. Just a heads up from my testing.

[sskaug]

Thanks a lot for testing! Due to a compiler peculiarity, the direction reversal was buggy. This should now be fixed, updated code is on github.

[KnuckleUpFPV]

I will snag it after work and go for it again. Im happy to test it. I fly twice a day. Around 20-30 packs. I will definitely be able to get a decent baseline on behavior by tonight. I was going to hook up esc telemetry, but as i understand it, each esc needs a seperate uart. Unless im missing something and they can be chained in series.

[sskaug]

Great! Telemetry needs no more hardware. Just connect all 4 ESC outputs together, and then connect that one wire to a uart on the FC.

[KnuckleUpFPV]

Will do. I will get some dvr recordings of the esc info on the osd. Thank you for getting this all together for us.

[markusgritsch]

@sskaug: I'm implementing the new Dshot motor beep commands for the firmware running on cheap toy flight controllers by silver13 (e.g. https://github.com/silver13/H101-dual).

I think I've discovered two irregularities with the current BLHeli_S motor beep implementation:

• I have configured my ESCs to have "Break On Stop" on. After powering them on (but before running the motors), the motors spin freely when truning them by hand. When issuing a DSHOT_CMD_BEEPx, everything is fine. After giving throttle for the first time to the motors and stopping them again, motor break is active, and they are noticeable harder to turn by hand. When issuing DSHOT_CMD_BEEPx now, the motors and ESCs get warm very quickly. I think it would be a good idea, to deactivate motor breaking, before doing the beeping.

• Currently DSHOT_CMD_BEEPx seems to use "Beep Strength". Wouldn't it be more appropriate to use "Beacon Strength" when beeping is issued by Dshot?

Kind regards, Markus

[sskaug]

Hi Markus

Thank you for very relevant input! Updated code is now on github, as Rev16.62.

As this is only test code, I would not recommend to publish with the Suite or the Configurator. When everything tests fine, we will release a Rev16.7.

Thanks, Steffen

[markusgritsch]

Thanks for the very quick fix! All well now :)

BTW, is it intentional that DSHOT_CMD_BEEP5 also calls beep_f4 like DSHOT_CMD_BEEP4 does?

[sskaug]

Great! Yes, beep 5 and 4 are the same, as there are only 4 tones in the standard _S code.

[KnuckleUpFPV]

The dshotcmd is working superbly. anti turtle mode can now be used.

[mikeller]

@sskaug: I did a test with 16.62 (https://github.com/bitdump/BLHeli/blob/master/BLHeli_S%20SiLabs/Rev16.62%20Dshotprog%20test%20code/Hex/L_H_10_REV16_62.HEX), and I found that there seems to be a problem with DSHOT_CMD_SPIN_DIRECTION_NORMAL / DSHOT_CMD_SPIN_DIRECTION_REVERSED, as used in https://github.com/betaflight/betaflight/blob/master/src/main/fc/fc_core.c#L231-L241: When spinning the motors in the configurator Motors tab (the normal / reverse commands are not sent), they spin like normal. When arming (commands are sent), the motors don't spin (except for motor 1, 1 out of 10 times or so, right after powering up the ESCs). If I go back to the Motors tab after this, without disconnecting the battery, the motors won't spin either.

This makes me suspect that the DSHOT_CMD_SPIN_DIRECTION_NORMAL / DSHOT_CMD_SPIN_DIRECTION_REVERSED commands, potentially in combination with non-idle Dshot commands being sent right after, are causing the ESCs to lock up in 16.62.

(I have submitted https://github.com/betaflight/betaflight/pull/3821 to prevent the firmware from sending the normal / reverse commands on arm if the mode is not configured, and this provides a workaround.)

[sskaug]

@mikeller Great feedback. A non-idle RC pulse did not have priority over dshot commands. This is now corrected in the updated Rev16.63. The BLHeli_32 test code is good with regards to this.

[mikeller]

@sskaug: I can confirm that 16.63 fixes the bug above.

[sskaug]

Great, thank you.

[KnuckleUpFPV]

I tested the esc telemetry. I hooked all 4 tx pads from esc to uart2. At idle its showing just over 500. At max throttle its showing 3970ish. I think its missing some zeros unless im missing something. Esc temp started at 35°c and went up to 40°c

[mikeller]

@KnuckleUpFPV: What ESCs did you use?

[KnuckleUpFPV]

@mikeller the same ones mentioned a few messages back from me. The blheli_32 wraith 35a esc's. Its working just seems like the rpm is off. At first i thought my osd layout had it too far to the right but that wasn't the case.

[mikeller]

Not sure how to properly scale for those ESCs. But like for the KISS ESCs, the RPM is eRPM (electronic RPM), and the conversion to RPM is dependent on the design of the motor.

[KnuckleUpFPV]

Im running the emax rs 2205 2600kv motors. I have no idea how to scale the rpm either. I thought the wraith esc's had current sensors, but not seeing the current at the esc. Only at the fc/pdb. Its a matek f405 aio

[mikeller]

As in 'the current is not reported in the ESC telemetry'? Could it be that one of your ESCs is not reporting back properly? (Current and other additive values are set to 0 if there is no telemetry received from one or more of the configured motors, whereas voltage and other averaged values are reported in this case.) Can you check if you get a current value if you reconfigure to a model with only 1 motor (plane), and see if you get telemetry for that one motor?

[KnuckleUpFPV]

Yeah its not reported in the telemetry. I can give it a try tomorrow. Bed time now. Ill report back

[KnuckleUpFPV]

Ok im an idiot. I forgot to switch the current sensor to esc sensor in the battery tab. Couldn't go to bed without taking a second look. Its working correctly. All 4 are reporting accordingly.

[KnuckleUpFPV]

I saw a multishot command firmware in the blheli gui. Is that correct? I tried it with multi and it was a no go. And the official dshotcmd 16.63 didnt work on dshot. The multi firmware did work on dshot though.

[mikeller]

What is 'multishot command'? No idea how commands would be sent (reliably) with a protocol like MultiShot.

[KnuckleUpFPV]

No idea. That's why im asking. Its what the 16.67 is labled now. Multishot command in the blheli gui

[mikeller]

Ah, I think the naming is misleading, the firmware does MultiShot and Dshot, and Dshot commands.

[brycedjohnson]

I did the initial dev work on blheli fork that was called blheli-multishot just because I had it on my computer at the time. It is so named because that was the repo that originally contained the first multishot stuff. It had pulled in all the other blheli updates and had some different beeps and startup music.

[mikeller]

@sskaug: I finally got around to implementing support for BLHeli32 ESC info: betaflight/betaflight#3987

[sskaug]

Great! This will be included in the next rev of BLHeli_32 (Rev32.2).

[Drewlrox]

So I flashed the 32.13 test code to my Wraith 32's to use anti turtle mode and beeper dshot commands but neither switch seems to be working, I am on betaflight 3.2 rc4, Am I missing something?

[mikeller]

@Drewlrox: For what I can tell 32.13 is a test release for a different feature, and does not include the Dshot command code. Try 32.12 from https://github.com/bitdump/BLHeli/tree/master/BLHeli_32%20ARM, this works fine for me for Dshot commands on Wraith32.