Is Bidirectional DSHOT required for RPM Filter?

There is a group of people who think that the RPM Filter is the best thing to happen to flight controllers and quadcopters since the sliced bread. Perhaps. I’m more inclined to believe that RPM Filter is just an example of good functionality. But it will not be about that, so let’s go back to the topic.

motor RPM telemetry data

Joshua Bardwell asked me a question if INAV uses ESC telemetry for the RPM filter. The answer was, of course: yes, INAV has no Bidir-DSHOT support, and 4th wire is required for RPM filter in INAV.

But the latency and jitter makes it unusable. Isn’t that the whole reason for bidirectional dshot development


Is it true that the RPM filter is unusable without Bidirectional DSHOT, and a flight controller really has to know the RPM after each motor update? How much jitter RPM data has and how fast motor can accelerate and decelerate? If you have no idea what’s I’m talking about, here is an express course to RPM filtering:

  • Bidirectional DSHOT allows ESC to report motor RPM after each DSHOT packet. If the main looptime is processed at 4kHz, RPM is also obtained at 4kHz
  • ESC telemetry gets RPM data one ESC at a time. On a quadcopter (4 motors) and 4kHz control loop, each motor RPM is then updated at 1kHz
  • RPM filter sets a series of narrow notch filters on gyro data, one for each motor on every axis. Four motors, three axes, 12 notch filters in total.
  • By default, notches are placed with a Q factor 5, so for example at notch center of 233Hz (14k RPM equivalent) attenuation band starts at around 211Hz, reaches max attenuation at 233Hz and then fades at 255Hz
  • Notches are updated to match current motor RPM

The real questions now are:

  • How much jitter RPM data have?
  • How quickly motor with a propeller accelerates and decelerates?
  • Is the 1kHz update rate via ESC telemetry enough?

I did an experiment, recorded a Blackbox log, and now I will share my findings with you.

Test setup:

In general, this quadcopter is slightly overpowered. 2208 stator size is just too much for 5-inch propellers. Most probably, on smaller motors (2205, 2206, 2207 and 2306) propeller acceleration profiles would be lower.

All the acceleration units are in Hz/ms (Hertz per millisecond). Why? Notches work with Hertz and in our example each motor RPM is updated every 1ms. It’s a very nice measure of how much motor frequency can change between measurements.

motor RPM analysis

After looking at the available data turned out that:

  • Average jitter was 0.5Hz/ms
  • Highest jitter was 3,5Hz/ms
  • In general, jitter was greater during deceleration than during acceleration or stable rotation speed. This suggests that at least some of the jitter was caused by induction load and flyback causing ESC missing single commutation cycles. Not full desync, just problems with measurements
  • The highest recorded motor acceleration (at least 50ms in length and correlated with the throttle or other stick movement) was 1,7Hz/ms. This translates to 104k RPM/s. Yes, 104000 rotations per minute per second. It’s less than a quarter of a second to reach 25k RPM!
  • The highest recorded motor deceleration was 2,3Hz/ms. 138k RPM/s.

The conclusion is that… well… remember 32k mode? It turns out that 1ms update rate on a motor RPM via ESC Telemetry is just enough. Yes, it is possible that not all the notches from RPM filter hit precisely noise frequencies introduced by motors. The error can reach even up 15% from the filter center frequency, but mostly during decelerations (jitter or micro desync), and even then, it’s well inside the filter band to be effective. During better scenarios, the error will be closer to 10% and way inside attenuation band.

I also checked the FFT graph of the reported motor rotation speed. It turns out that most updates have a frequency of around 50Hz or even less. Yes, there are some outliers but no visible spikes above 100Hz.

motor RPM FFT graph

Bottom line: ESC Telemetry is good enough for the RPM filter, and the main advantage of Bidirectional DSHOT is wiring simplicity, not an increased update rate! Not perfect, but good enough. And we have no idea how precise ESC measurements really are. I have a feeling that not that precise as people like to think.

But we all love big numbers, don’t we?

6 thoughts to “Is Bidirectional DSHOT required for RPM Filter?”

  1. I asked about this topic on the Betaflight FB group since I feel unqualified to answer. Here is the response from Bruce / eTracer

    ESC sensor telemetry is not reliable enough or guaranteed response from the ESC. It’s implementation falls into the “best effort” camp as it’s considered non-critical. The way it works is that when telemetry is desired a bit is set in the dshot command to initiate the telemetry request. Sometime later the ESC should (but might not) send the telemetry packet out through the separate UART connected to the flight controller. So there’s an asynchronous aspect to this rather than the synchronous nature of bidirectional dshot. Also because we don’t have 4 (or more) UARTs to waste on this, all the ESC’s are connected to the same RX of a single UART. So that means we need to do a careful round-robin requesting telemetry for a single ESC, waiting for the response (or timing out if it never comes) and then move on to the next ESC. And since they are electrically sharing the same interface the timing needs to be pretty “loose” to avoid collisions on the line. All this means it’s pretty slow. In Betaflight it takes about 80ms to get through all 4 motors for one telemetry cycle. 80ms is a long time – 640 PID loops at 8K.

    1. Additional information quoted for those who may not be members of the FB group.

      “There is also some misinformation in the article. It’s not actually possible to get a 1KHz telemetry rate (requesting at 4KHz) using ESC Sensor and a shared UART. This is because the telemetry response takes ~900us to be sent from the ESC to the flight controller. Well actually it’s probably more like 750us (115200 baud with 10 bytes + start/stop), but it’s spec’d at 900us from the BLHeli32 docs so there’s probably some overhead. So that means that it would take roughly 1ms (1000us) before you’d send the request to the next ESC (since it has to align with the next DSHOT signal). The way it works in Betaflight (and copied in INAV) is that the request to the next ESC is dependent on receiving the reply from the previous. So the response from the ESC is the controlling factor on max rate. Since there’s 900us built in to the data transfer of the previous ESC data the next request can’t go out until that’s complete otherwise you risk 2 ESCs talking on the line simultaneously and getting garbage. So at best you’d get RPM data at 250hz or data that’s 4ms old. The motor RPM can change a lot in 4ms.”

    2. For the sake of having several opinions on the topic.

      TL;DR: Bi-directional DSHOT is a potentially lower reliability protocol with simpler wiring and only placebo-level benefit to actual noise filtering.

      1. Caring about individual motors only makes sense if you use individual rejection filters to suppress noise from each motor individually. As long as you have only one rejection filter per axis you care about average RPM only.

      2. Regarding the update rate. When I was adding serial ESC telemetry to INAV I was getting a telemetry response within 1-2ms of the request. Longer gaps were only happening in presence of high EMI noise (more on that below). This gives us a max 8ms update cycle for 4 motors which in the worst case translates to ~16Hz shift in average motor noise frequency. Rejection filter band is much much wider, so why should we care about the slight delay in data at all?

      3. Originally, DSHOT and all other motor protocols were using push-pull drivers on the FC MCU side, which means the EMI should be pretty damn strong to disrupt the signal going to the ESC. Yet it still happens and happens the more the longer the wire you have between ESC and FC. Bi-directional lines are usually designed as pull-down only (aka open-drain) to prevent burning out your CPU pins on either end of the line. If Betaflight changed the outputs to open-drain to do this aligned with electrical engineering standards – it’s sacrificing reliability even more. But if the pins are still configured as push-pull (I won’t be surprised if they still are), using bi-directional DSHOT is having a ticking bomb onboard of your quad and it’s only a matter of time until it burns out the ESC or the FC.

      4. Bi-directional DSHOT telemetry reports only RPM (no voltage, no current, no temperature) which makes it pretty useless on any system that wants to know more about the system state rather than just motor RPM.

      5. Bi-directional DSHOT has a benefit though – it’s using less wires (one wire instead of two). In case of a 4-in-1 ESC this is actually also a marginal benefit – it’s 1 extra wire for telemetry and 1 less wire for current sensing.

      1. Would you be able to expand at all on Part 3? Using Bi-Dir recently I encountered the strangest ESC failure. I blew exclusively the signal pin on a BB2 MCU. The MCU was fine otherwise. Commanded the ESC with normal startup chimes, flashed new settings just fine (like louder chimes, brake on stop, etc…). This happened just after coming to a hover. Replaced the MCU on the ESC with a donor BB2 chip and the ESC was back in action like nothing ever happened. Curious to understand if this could’ve been the potential cause.

    3. Hello guys,
      I have read everything and it is quite too complex for my little brain.
      Is it still relevant to enable RPM filter ? At which frequency do we need to set the FC loop, dshot, etc.
      Best regards

Leave a Reply to bg Cancel reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.