In the first part of this post series we went over the most common ESC protocols that have been in use up until today. These protocols for the most part still dominate the market. In the second part we are looking at more recent protocols that attempt to tackle issues such as latency, refresh rate and interference.
Oneshot ESC Protocols
The Oneshot family of protocols is an attempt to tackle synchronization and latency issues in one go. Compared to classical PWM, Oneshot offers the following technical advancements:
- Syncing of PWM pulse to the flight controller control loop (like in SyncPWM)
- Reduction of pulse length (duration), leading to less latency between flight controller and ESC
- Significant reduction in pulse period, leading to more frequent throttle value updates (much faster than FastPWM)
The advancements listed above combine to significantly improve motor control responsiveness. This is relevant as modern flight controllers have much higher control loop update frequencies (up to 32kHz for some newer microcontrollers). This allows the aircraft to react to disturbances in a shorter time and thus allows it to better maintain stability.
On the other hand, the impact of increasing the control loop frequency to such high figures is still a topic of debate, with adversaries pointing out that increase offers little value due to diminishing returns.
Oneshot comes in three flavors: Oneshot125, Oneshot42 and Multishot. Each of the three have a different PWM pulse length range as follows: Oneshot125: 125-250μs, Oneshot42: 42-84μs and Multishot: 5-25μs.
All protocols discussed so far are considered analog in nature. This is because they convey throttle information encoded as the length of the PWM pulse, which is a continuous quantity. One major issue with such encoding is electrical interference. Electrical interference can come from many different sources, including ESCs and motors. It also affects signals of shorter pulse lengths to a greater degree than longer ones. Newer protocols such as Multishot are more prone to interference compared with classic RC-PWM.
To reduce the effect of interference a trick is commonly at use. Simply, the signal from the flight controller is sent multiple times to the ESC, even within a single control loop. Take for example a flight controller with a 8kHz control loop frequency. the control loop period is 125μs. Multishot offers a PWM period of 25μs. Within a single control loop, the signal to the ESC can be repeated five times. In theory repeating the same signal should not make any difference. In practice though, it helps reduce the effects fo interference by “averaging out” variation in the throttle values caused by interference and within a single control loop.
Digital ESC Protocols
Recently a new family of ESC protocols, termed DShot, have been introduced that are fundamentally different to existing ones. All ESC protocols discussed so far encode the throttle value in the length of a pulse. DShot instead uses a train of pulses in each cycle, which encode binary values. This way it achieves true digital communication. Instead of encoding throttle in the length of a pulse, it encodes it in binary form in a train of pulses that represent either one or zero. What’s more, each value is complemented by error-detecting code, so that it’s validity can be verified at the ESC side.
The message carried each cycle can be broken in three parts: Throttle value, telemetry request and checksum. This makes up for 11bits + 1bit + 4bits = 16bits total. The telemetry request serves to request data back from the ESC on models that support it. Transmission of telemetry data is done in a different line.
There are currently four variants of DShot the difference between them being the speed of connection:
- DShot150 – 150,000 bits per second or 9375 Hz update frequency
- DShot300 – 300,000 bits per second or 18750 Hz update frequency
- DShot600 – 600,000 bits per second or 37500 Hz update frequency
- DShot1200 – 1,200,000 bits per second or 75000 Hz update frequency
All this bring a clear advantage to the game: The throttle value from the flight controller to the ESC is precise and valid. There is no advantage anymore in averaging over multiple values as in Oneshot, since there is no possibility of the flight controller transmitting the wrong value. On the other hand, DShot has increased hardware requirements from the ESC as well as flight controller. This renders many of the ESCs and flight controllers at use today (especially low-end ones) unable to benefit from DShot. The Betaflight wiki maintains a list of DShot-compatible flight controllers. With respect to ESCs, any model that comes with BLHeli_S should support DShot.
Another drawback is that the pulses used by DShot have such short length that they end up being filtered by LC filters that are commonly installed in FPV aircraft to eliminate noise in the video signal.
The way ahead
ESC protocols described so far either are or are close to becoming mainstream with the hobby and FPV communities. In this section I want to discuss a few interesting ideas that are mostly experimental for now, but may lead the way for future innovations.
UAVCAN has been made available quite some time ago, in order to bring the CAN bus to drones. The CAN bus is renowned for it’s extreme reliability and is thus attractive for application in drones. It is really an advanced protocol stack that is in use in advanced commercial and research applications. While most of the protocols outlined here support simple 2-point, one-way data transmission, UAVCAN supports such features as multiple nodes, decentralized communication, publish/subscribe based data transmission and many others. UAVCAN supports advanced data structures with nesting and namespaces. The protocol is suitable for realtime applications and supports low-latency communication.
For all the benefits that UAVCAN may bring to the game, it does need new hardware to become available, both on the ESC side as well as the flight controller. There are already ESCs and flight controllers that support UAVCAN, and projects such as UAVCAN for Hobbyists help bring the tech to hobbyists sooner. IT remains to be seen whether this very capable technology will catch up to the drone/FPV enthusiasts.
Proshot is a hybridization between digital (DShot) and analog (Oneshot) protocols that aims to achieve the robustness of digital with the flexibility in hardware of analog protocols. Instead of using a base-2 digital signal, that is pulses that encode a single bit, Proshot proposes using a base-16 (hexadecimal) encoding, that is, pulses that have 16 possible “length states” (from 1μS to 2.6μS), and as such encode four bits. The total length of a Proshot “message” is four pulses, so 4×4 = 16 bits. The content of the message is the same as in DShot, so 11bits throttle value + 1bit telem. request + 4bits CRC = 16bits total.
There are a number of advantages of Proshot over DShot. The first is related to hardware support. Due to having only four pulses instead of 16, Proshot is less heavy on the ESC MCU. In addition, it does not interfere with LC filters or filtering capacitors. All this while maintaining the precision and error-checking capabilities of DShot.
SPIShot has been discussed on blck.mn as an alternative to existing digital protocols such as DShot. The premise is to use the SPI bus of each microcontroller to communicate digital information to the ESCs. The advantage is that since almost all microcontrollers have dedicated hardware-backed SPI communication, Proshot should be much easier to implement on existing flight controller and ESC hardware, unlike DShot that has increased DMA requirements. SPIShot requires a total of four wires including Vcc and Ground. The flight controller transmits all ESC throttle values in a common message and the ESC selects the relevant value through address identification. Each ESC is assigned an address through a pairing process between ESC and flight controller.
This is the second part of a two-part post series on ESC protocols. In this post we went through the latest trends in ESC protocols that attempt to tackle issues such as latency, refresh rate and interference. In the last part of the post we briefly outlined some cutting-edge ideas on ESC protocols that may very well be the future!
What kind of ESC protocol does your setup use? Share your experience in the comments below!