Passionate about technology, people, new places and especially the possibilities of the future – here you will find the musings and antics of Jason Blackman (blckmn).

DSHOT – The new kid on the block

What is DSHOT?

DSHOT is the name coined for a new digital ESC protocol by Felix (KISS) who is working in collaboration with Boris and the rest of the betaflight team, and Steffen (BLHeli) is also playing his part and introducing this protocol to BLHeli_S.

Make no mistake (despite what some have said) although this protocol uses the PWM (Pulse Width Modulation) features of the micro-controllers it is in fact digital. Each pulse represents a single bit. The timing of that pulse, as in the duration, in relation to the overall period between pulses dictates whether the bit is ON or OFF i.e. a bit value of a ZERO or a ONE. The micro-controllers are simply using the direct memory access, and timer capability within micro-controllers to generate the necessary signals on a motor pin so as to minimise the CPU utilisation.

What is the difference to current protocols?

Non-digital PWM protocols, such as Multishot, Oneshot42, Oneshot125 etc., simply rely on the width of the pulse to indicate throttle position. This has a number of significant drawbacks. In those analogue protocols subtle timing variations are a phenomenon we all know as jitter. This is where the signal jumps around the desired point. The shorter the pulse width the higher the likelihood and impact of this jitter. We have all seen an example of jitter in the receiver tab of the respective xFlight configurators. Variations in the pulse width also result in an unknown zero throttle, and an unknown maximum throttle. It is this reason that calibration of ESCs is required when using PWM.

Pretty much all digital communications use timing and voltage levels against some form of reference (usually a ground) to indicate bit values. Serial (e.g. RS232, RS485 etc) uses the high (voltage > reference) to indicate a bit value of 1, and a low (voltage closely approximating reference or < reference) to represent a bit value of 0. In the case of serial each end of the communication needs to know the timing to utilise as consecutive bits in a 1 state are merely continuously highs (no pulses). The baud rate is therefore critical.
In the case of DSHOT the timing is less critical. The reason for this is that the pulse width (duration) as a proportion of the total period denotes the bit value. This is very similar to the way in which WS2811/2 LED Strips work. In fact aside from the different timings, it would be pretty much identical.

What is in a name?

For DSHOT600 the 600 signifies the bit-rate (in kilo-bits), so it can send 600 kilo-bits per second). For DSHOT300, and DSHOT150 it is essentially the same, but the bit-rate is slowed, for 300 (300 kilo-bits per second) it is 2x slower, for 150 (150 kilo-bits per second) it is 4 times slower. This means the timing above is simply x2 for 300, and x4 for 150. DSHOT300 and DSHOT150 were introduced to ensure that support for older less capable ESCs exists so flyers can get the benefit of digital accuracy.

DSHOT bucks the trend, the higher number is faster than the lower numbers. The oneshot protocols (including Multishot) have used increasingly lower numbers to signify faster speeds.

What are the technical details?

For a bit to be 0, the pulse width is 625 nanoseconds (T0H – time the pulse is high for a bit value of ZERO)

For a bit to be 1, the pulse width is 1250 nanoseconds (T1H – time the pulse is high for a bit value of ONE)

The reason for the difference in pulse length for bit 0 and bit 1 values is that it allows for considerable tolerance in determining the value. So these timings can be off slightly and the result will still be the same.

As with any protocol there needs to be a communication stream of bits, that will be interpreted for some outcome to occur. For the case of DSHOT the signal for a motor update consists of 16 bits (a frame). The first 11 bits are the actual throttle value. The next bit is to signal the ESC to provide a telemetry update (using a separate return channel), and the remaining 4 bits are a checksum.

The throttle value with 11 bits gives a resolution of 2048. It has been suggested the first values be reserved (possibly for startup tones or commands), so 0 means disarmed. So if 1 to 47 are reserved, and then 48-2047 is the throttle position – giving 2000 steps of resolution.

In the throttle value portion of the frame the most significant bits are first, so the first bit having a value of 1 means the throttle is at least half way, i.e. 1024, the second bit represents 512, the third 256 and so on until bit 11 represents the value of 1. So the bit sequence 11111111111 represents full throttle, and 10000000000 represents half throttle. The following image is a capture of DSHOT600 in action on a BluejayF4:

There is normally a pause between frames of at least 2 microseconds to indicate a frame reset. A reset simply indicates the end of one frame and thus any future bits are the start of a new frame. With DSHOT occurring at the end of a PID loop this pause is actually considerably longer. If DSHOT were to be made to continuously output a signal then this delay would be required.

Is it the most efficient?

It should of course be noted that DSHOT is not the absolute most efficient protocol for representing bit values in a serial stream, but the reason for the approach taken rather than other options is to ensure accuracy in the very noisy environment found on a multi-rotor. That said it is certainly no slouch. It takes it to the current crop, with DSHOT600 being a mere 1 microsecond slower than Multishot at full throttle. Even DSHOT150 is on a par with Oneshot42. The following graph represents the full throttle timing of the current protocols:

DSHOT has no real concept of minimum and maximum durations for timing, it is a digital protocol afterall. A disarmed throttle value of 0 takes the same amount of time to communicate as a full throttle value.

Will my ESCs or flight controller be supported?

Work is being done in KISS firmware and in Betaflight to support this new protocol, and so far testing is looking very promising. It is unlikely that F1 processors (Naze, CC3D etc) will be able to support it, due to the direct memory access requirements of the hardware. Those processors just don’t have enough DMA channels available. F3, F4 and F7 all have more than enough. However inside those processors certain mappings exist – between timers, DMA and the actual pins – and so it is possible we will find a target where you won’t be able to simply use motor outputs 1 to 4, but may have to move to motors 1, 2, 4 and 5 (as an example). Resource remapping in Betaflight 3.1 when released will make this task nice and easy (aside from any soldering if needed).

For ESCs the hardware requirements will mean BLHeli_s or better. There are also ARM based ESCs, such as KISS 24A RACE, that will support DSHOT or are able to be upgraded to support it. Unfortunately the old ATMEL and slower SILABs based ESCs are unlikely to ever have the power nor timing hardware needed to support DSHOT. Either way it will mean a firmware upgrade, and in some cases this will mean soldering if the ESC does not have a boot loader that allows simplified firmware updates.

Ok – so what are the benefits?

The key benefit to digital is there is absolutely no increase in value through repeating the same information, more than once. Digital is simply accurate. There is no jitter (variations in throttle value created due to timing). If the signal is corrupted the ESC can detect it through the checksum. Many will have found motor updates of 32khz appear smoother. This is most likely to do with the repeating signal being “averaged” out effectively and thus effectively filtering (smoothing) the jitter. DSHOT eliminates this PWM jitter, and therefore motor updates need not occur anymore frequently than a motor can actually physically adjust – and make no mistake there is a physical limit as to how quick a motor can change its speed.

Another benefit is of course, no calibration required. In the digital world a zero is just that, a zero.

So really now it is just a case of rest in peace PWM, for we have a new friend, and that friend goes by the name of DSHOT!

“Many will have found motor updates of 32khz appear smoother. This is most likely to do with the repeating signal being “averaged” out effectively and thus effectively filtering (smoothing) the jitter. DSHOT eliminates this PWM jitter,”

I think the 32KHz update rate is smoother because it eliminate the looptime jitter (not signal value jitter), and dshot still has FC output looptime jitter. Its not nearly as bad now a days with F4 FC as opposed to F1 FC running on the ragged edge.

Question, how much more delay is there in processing dshot signal value in the esc than MS? tia

If ESCs are going digital, why developers take the route of “reinventing the bicycle” – there is a lot of serial protocols that are being supported by the HW of almost all modern MCUs without the need for DMs and such. Considering that there are just two wires to control ESC, ground and signal, the obvious choice would be the 1-wire serial protocol (UART). The relatively low speed of 115200 baud would be comparable to Dshot 150, but serial protocol can easily go to 1 MHz rate, which would beat Dshot 600. My (custom) FC talks to my (custom) data logger at 1 MHz with no problems at all in a noisy quad environment.

This was an excellent read and made it easy to understand DSHOT when looking at it on my oscilloscope, thank you!

A small correction: As 0 indicates disarm and 1-47 are reserved for commands, half throttle is not 1024 (10000000000), but 1047 (10000010111), and values starting with a 1 don’t indicate at least half throttle as the article states.