And the 8k cap makes sense because the signal delay on the gyro is 2 to 4ms. That is where we need to keep the focus (reducing filter delay). 1ms = 1,000us. So filter phase delay is literally 1,000x more important to minimize vs. worrying about increasing loop rate speeds.
2ms/27us(DShot600) is a 74th of the 2ms filterdelay. So after knowing/calc which speed the ESC SHOULD be, the communication adds a delay till then ESC knows the value. So why not try to reduce it? But your right, the filterdelays still are the huge factor. Moreover this was the reasons to increase the PID loopspeed, not to calc MORE values, but to speedup the lag to get the new state/value to the esc.... maybe its time for a dynamic PID/Esc refreshtime? So read/calc gyro at 32k+ and send only if the valuechanges are more then a certain amount/and limit is to maximal Dshot repeattime? PS: love your work!
@@uavtech I still don't think there is any point running anything over Dshot600 and that's if your Pidloop is at 32Khz, which not many FCs / firmwares support anymore. Is this true about dithering?
I LOVE this type of videos, they let me understand what's happening with my gear, how it works and how I can optimize it's usage. Please, do make more of this type of content.
Interesting comparison, but you're missing the point of latency vs rate. The advantage of DSHOT 600 over 300 is that the time from the start of sending the data to the ESC, to it having received it, and being able to act on it, is halved. So the desired speed change gets to the motor ~25us earlier. When you consider that at 8kHz the cycle time is 125us, reducing the latency by 20% of the cycle time is quite significant. PID control loops work much better if your "plant" responds faster. Reducing the response time of the "plant" allows you to raise the PID values without causing instability. Thus using DSHOT-600 will allow a more aggressive tune than DSHOT-300.
Its not completely useless because signal intervals might be same but it also metter how long deos it take to complete the transmission. For example dshot 600 end its transmission 26us earlier than dshot 300 so motors react 26 us to signal twice faster. Remember there are 2 parameters "how often its sending" and "how fast its sending" that you miss in this vid. In other words - you need to go to the job once a day and it might take 2 hours or 1 hour so 1 hour is definitely better for me than 2 hours. Human reaction is a way higher than 26us but motors need to update as fast as possible to prevent oscilations etc.
I’d be curious to see how the new Fettec “OneWire” protocol looks on an oscilloscope! I think it is supposed to be D-Shot2400 somehow wrapping 4 motor commands into on signal output. Should be super interesting to see live 👍
Also, it would be really interesting to see the actual phase output from the Fettec ESC to see if it really is a more sinusoidal wave form. Or at least how it compares to a traditional ESC.
It is still very helpful to get dshot out of the way as fast as possible from a code development standpoint. When dma is cranking out a a dshot packet to gpio, you have to block dma adc reads and any dma traffic to spi1 on the stm32f4 series of chips or things get corrupted.
I was literally just talking about this a couple days ago 😂. I never really thought about it until I setup a quad with bf 4.1 and enabled rpm filters. You can really notice how it's overkill when you do this. Kind of makes me rethink quite a bit on what makes a quad fly better. So thanks for the post! You really did an awesome job of explaining what I was already thinking but in a much more quantitative manner lol.
At some point noise becomes an exponentially bigger problem with higher sample rates (in the D-Term I guess). I think that's the reason the devs dropped DSHOT1200.
Excellent video DM...Now it would be interesting to see how many ms it takes for a motor/prop combo to respond to a given throttle change from the PID loop.
@@FredSena the black box log will only show you the output signal to the escs. I guess there may be a way to do a black box of the rpms with bidirectional Dshot.
Spot on! At the end, all the electronics need to move a physical entity, and it's very very interesting to see where the inertia of the motor/prop becomes big enough to render any advancement in the protocol speed useless (or PID loop speed, etc).
@@JoshuaBardwell thanks for the info JB the Gwadddd...I figure you or UAVTECH would watch this video. Yeah so the goal is to make this your only delay if possible/practical.
Thanks for this vidéo. Could you check in Bidir-DSHOT, because frame from ESC -> FC will also take time. I think that is why we use DSHOT600 at 4K with RPM filter
can the power electronics follow these frequencies? how would you test that every packet is taken into account by the ESC voltage sent to the motor ? even better, how can you test if the motor with a prop is taking into consideration every packet sent ?
Thanks . So do you think pro-shot is better for a noisy quad with beat up motors? Like a basher quad ? Or just stick with the d shot 600 I'm running beta flight 4.0.6 with a old mamba f4 stack on DYS 2206 2700kv motors that are very noisy and a little beat up lol ?
I just put a mamba F722 f60 pro esc first build. It’s got jitters at top of throttle my be 3/4 throttle. I watched couple videos an an was runing D600 8k 4K now it’s running 8k 8k with gyro filter on I am learning lol. Great work
Is this DSHOT or bi-directional DSHOT (for RPM filtering)? 8K/8K RPM filtering recommends DSHOT 600 if the FC can cope with the speed. Interesting that only 1 motor command is sent to each ESC per PID loop cycle.
There is no point sending more than one motor command because they would all be identical. The PID loop calculates the motor output right? So there is no new output until there is a new PID loop. Maybe an argument could be made that transmitting more than once would compensate for noise?
More than one transmit of the same value within a PID cycle would be beneficial as any misread due to noise does not require the system to wait till the next cycle for the correction. DSHOT ESC's will discard any corrupted packet in the case of signal noise. The cost of sending multiple per PID loop is that the FC must spend processor power to construct and transmit the signal (may be able to save on construction costs for DSHOT as packet is the same). The benefit of faster transmission in a single iteration per loop PID cycle is that the ESC's ACT on the signal that little bit faster. (Also the ESC's are controlling a physical system that takes time to change - physical motors have momentum and resistance to cope with). Maybe the BF dev's thought the cost of more than one signal per PID cycle (when feasible) is more expensive than the benefit. Also with multiple signals per PID cycle, this could seriously mess up bi-directional DSHOT for RPM filtering as each DSHOT packet reports the poles seen since last received packet. Multiple chances for mis-read per cycle.
I agree 600 and 1200 can be considered useless and can't be told apart in betaflight but in the flight controllers like FL1 that run 32khz you can definitely tell the difference between 600 and 1200 when you switch between the two your tune will be completely off and kiss you can tell the difference also but your right it's useless because you can't update higher than 8k anymore on betaflight
@@uavtech I don't know I'm not as smart as you are or any of the devs y'all are the brains I just know if I fly my other qwads that aren't betaflight I can tell a difference in switching dshot protocols not knocking on y'all just my observations
@@biggfpv2721 , the problem is 100% of the time, folks comps are not A-B when it comes to comparing things. It usually starts out like: "On my F1 quad vs. my BF quad..." And I say: "STOP! Your test was with two different quads (invalid)?!???" When components that cause 10s of milliseconds if delay are set differently, you cannot use that result to judge 0.09375ms differences (8k vs. 32k loop rate). I think sometimes folks just need to do the simple math between 8k and 32k loop rates. 1/32 - 1/8 = 0.09375ms Human reaction time = 250ms Prop rmap speed = 2 to 20ms Filter gyro signal delay = 4 to 6ms
You know that the human reflex action in all this just makes about all this moot. WE can only react to a certain degree with our big Meat wrap bones and limited optical sheep eyes till all this stuff just dont matter.....Lol
Yes, for example when you dive into your own propwash - gyro senses unwanted turns, FC corrects and esc sends those data to the motors. Oscillations can be reduced if you correct after 3 degree turning instead of 9 degree turning. Everything helps because latency adds up but it is more effective to reduce 2000us filter delay than 27us esc command delay.
If I gave you two quads, one with dshot 1200 32khz update loop and the other with dshot 300 8khz. Could you tell the difference just by flying them? Your reactions and signal transmission are way laggier than those update timings. It's like a dozen microseconds difference in a dozen mili seconds. It's like getting a 500 hz refresh monitor when even trained eyes can't see the difference above 200hz
@@mindprobe3587 no I agree if you do what you are saying you can't tell the difference I'm saying if you took two qwads and had them both at 32k and one at 1200 and one at 600 you most definitely can tell, the qwad will fly like shit on 600 and not on 1200 it's not just my reaction and so forth because in that sense if you did what you described you can't tell the difference ,it's the fact that the qwad will fly like crap again that you can tell, if you do what I say
![Best Budget FPV Drone Buying Guide 2021 [Part 2]](http://i.ytimg.com/vi/7ML3ZC_CCQk/mqdefault.jpg)
![Best Budget FPV Drone Buying Guide 2021 [Part 2]](/img/tr.png)
And the 8k cap makes sense because the signal delay on the gyro is 2 to 4ms. That is where we need to keep the focus (reducing filter delay).
1ms = 1,000us. So filter phase delay is literally 1,000x more important to minimize vs. worrying about increasing loop rate speeds.
2ms/27us(DShot600) is a 74th of the 2ms filterdelay. So after knowing/calc which speed the ESC SHOULD be, the communication adds a delay till then ESC knows the value. So why not try to reduce it? But your right, the filterdelays still are the huge factor. Moreover this was the reasons to increase the PID loopspeed, not to calc MORE values, but to speedup the lag to get the new state/value to the esc.... maybe its time for a dynamic PID/Esc refreshtime? So read/calc gyro at 32k+ and send only if the valuechanges are more then a certain amount/and limit is to maximal Dshot repeattime? PS: love your work!
@@bernhardtrzil6315 , cause reducing it come at a cost of reduced features, adding loop jitter, etc...
It is not worth it.
@@uavtech I still don't think there is any point running anything over Dshot600 and that's if your Pidloop is at 32Khz, which not many FCs / firmwares support anymore. Is this true about dithering?
I LOVE this type of videos, they let me understand what's happening with my gear, how it works and how I can optimize it's usage. Please, do make more of this type of content.
Interesting comparison, but you're missing the point of latency vs rate. The advantage of DSHOT 600 over 300 is that the time from the start of sending the data to the ESC, to it having received it, and being able to act on it, is halved. So the desired speed change gets to the motor ~25us earlier. When you consider that at 8kHz the cycle time is 125us, reducing the latency by 20% of the cycle time is quite significant. PID control loops work much better if your "plant" responds faster. Reducing the response time of the "plant" allows you to raise the PID values without causing instability. Thus using DSHOT-600 will allow a more aggressive tune than DSHOT-300.
I'm like number 400 buddy. I'd love it if you made videos again. By far you're my favorite FPV technical channel.
Its not completely useless because signal intervals might be same but it also metter how long deos it take to complete the transmission. For example dshot 600 end its transmission 26us earlier than dshot 300 so motors react 26 us to signal twice faster. Remember there are 2 parameters "how often its sending" and "how fast its sending" that you miss in this vid. In other words - you need to go to the job once a day and it might take 2 hours or 1 hour so 1 hour is definitely better for me than 2 hours. Human reaction is a way higher than 26us but motors need to update as fast as possible to prevent oscilations etc.
Filter delay on the gyro signal is 4,000us, so focus there.
I’d be curious to see how the new Fettec “OneWire” protocol looks on an oscilloscope! I think it is supposed to be D-Shot2400 somehow wrapping 4 motor commands into on signal output. Should be super interesting to see live 👍
Also, it would be really interesting to see the actual phase output from the Fettec ESC to see if it really is a more sinusoidal wave form. Or at least how it compares to a traditional ESC.
It is still very helpful to get dshot out of the way as fast as possible from a code development standpoint. When dma is cranking out a a dshot packet to gpio, you have to block dma adc reads and any dma traffic to spi1 on the stm32f4 series of chips or things get corrupted.
I want to see the flightone esc outputs as they run on 32khz. They also have dshot 1600 2400 3200 and 6400 which is neat
I was literally just talking about this a couple days ago 😂. I never really thought about it until I setup a quad with bf 4.1 and enabled rpm filters. You can really notice how it's overkill when you do this. Kind of makes me rethink quite a bit on what makes a quad fly better. So thanks for the post! You really did an awesome job of explaining what I was already thinking but in a much more quantitative manner lol.
At some point noise becomes an exponentially bigger problem with higher sample rates (in the D-Term I guess). I think that's the reason the devs dropped DSHOT1200.
@@TimeFadesMemoryLasts DSHOT 1200 noise was one reason. Also they could not do bit banged bidirectional DSHOT at 1200 speed.
Are dshot 600 and 1200 better for bidirectional dshot or will it stay useless in that scenario as well?
Not better for RPM. 600 us ok if all completes well (H7 chip). But i would stay away from 1200.
With dshot1200 removed from betaflight is poroshot 1000 now king?
Excellent video DM...Now it would be interesting to see how many ms it takes for a motor/prop combo to respond to a given throttle change from the PID loop.
@@FredSena the black box log will only show you the output signal to the escs. I guess there may be a way to do a black box of the rpms with bidirectional Dshot.
Spot on! At the end, all the electronics need to move a physical entity, and it's very very interesting to see where the inertia of the motor/prop becomes big enough to render any advancement in the protocol speed useless (or PID loop speed, etc).
@@IanF-FPV uav tech has measured this response time. If memory serves its around 10 ms.
@@pomerus actually on the contrary you want the only delay in the system to be the physical motor/prop combo.
@@JoshuaBardwell thanks for the info JB the Gwadddd...I figure you or UAVTECH would watch this video. Yeah so the goal is to make this your only delay if possible/practical.
Osc videos are awesome! Please show what bidirectional dshot looks like in an oscilloscope! 👍
Hey maybe that empty space is used to get RPM data in bidirectional mode. Have you tested with a motor connected and bidirectional enabled?
Thanks for this vidéo.
Could you check in Bidir-DSHOT, because frame from ESC -> FC will also take time.
I think that is why we use DSHOT600 at 4K with RPM filter
that means at 4k pidloop dshot150 is preferable to dshot300 at 4k pidloop?
shot300 needs to be at 8k to be better than dshot150 at 4k
So what do u suggest our setting be set at?
So on a mamba f405 stack it's best on dshot 300?
can the power electronics follow these frequencies? how would you test that every packet is taken into account by the ESC voltage sent to the motor ?
even better, how can you test if the motor with a prop is taking into consideration every packet sent ?
So should we run dshot 600 on 8k???? Wish you would have told us which is better to run and what pid loop buddy?!
dshot 300 on 8k pid - pointless going beyond that, it is just empty space and more subceptible to noise
Can you do a follow up video? I know my shit but this is were it gets a little sketchy for me.
Excellent work bro. I just changed mine to Dshot 300. Really interesting stuff.
What if you use unsynced pwm @ 32000 w/ gyro set to 8k & Dshot 1200?
Pretty interesting tests, Sam!!! 😃
Thanks . So do you think pro-shot is better for a noisy quad with beat up motors? Like a basher quad ? Or just stick with the d shot 600 I'm running beta flight 4.0.6 with a old mamba f4 stack on DYS 2206 2700kv motors that are very noisy and a little beat up lol ?
BF 4.1 with rpm filters bro....add $5 jesc for blheli 's
HEY BROTHER R U STILL DOING THIS
Which is the best budget 5 inch freestyle frame for you? Do you think the Frog Lite is still worth it?
Can you please try this on emuflight 16/16k or if you have a f7 32/32?
I just put a mamba F722 f60 pro esc first build. It’s got jitters at top of throttle my be 3/4 throttle. I watched couple videos an an was runing D600 8k 4K now it’s running 8k 8k with gyro filter on I am learning lol. Great work
Is this DSHOT or bi-directional DSHOT (for RPM filtering)? 8K/8K RPM filtering recommends DSHOT 600 if the FC can cope with the speed.
Interesting that only 1 motor command is sent to each ESC per PID loop cycle.
There is no point sending more than one motor command because they would all be identical. The PID loop calculates the motor output right? So there is no new output until there is a new PID loop.
Maybe an argument could be made that transmitting more than once would compensate for noise?
More than one transmit of the same value within a PID cycle would be beneficial as any misread due to noise does not require the system to wait till the next cycle for the correction. DSHOT ESC's will discard any corrupted packet in the case of signal noise.
The cost of sending multiple per PID loop is that the FC must spend processor power to construct and transmit the signal (may be able to save on construction costs for DSHOT as packet is the same).
The benefit of faster transmission in a single iteration per loop PID cycle is that the ESC's ACT on the signal that little bit faster. (Also the ESC's are controlling a physical system that takes time to change - physical motors have momentum and resistance to cope with).
Maybe the BF dev's thought the cost of more than one signal per PID cycle (when feasible) is more expensive than the benefit.
Also with multiple signals per PID cycle, this could seriously mess up bi-directional DSHOT for RPM filtering as each DSHOT packet reports the poles seen since last received packet. Multiple chances for mis-read per cycle.
So basically run Dshot 1200 and TBS tracer. With an H7 board
Thanks so much. I always wondered about this and you are the first to explain and call this out.
Excellent video,this stuff makes sense and is great to know
Very interesting stuff, thanks!
Ohh wow thank you!!
I still run multishot on a few of my rigs and they fly a bit better than my dshot600 rigs. 👍
did u run multishot 4k/4k on f4 board n blheli_s esc ?
I agree 600 and 1200 can be considered useless and can't be told apart in betaflight but in the flight controllers like FL1 that run 32khz you can definitely tell the difference between 600 and 1200 when you switch between the two your tune will be completely off and kiss you can tell the difference also but your right it's useless because you can't update higher than 8k anymore on betaflight
Yes in 32khz you need 1200 to run that and you need 600 for 16khz.. but for now in BF it's useless.
@@DroneMesh yes I agree
Since filter delay on the gyro signal is 4,000us and higher, how is faster loop rates critical?
@@uavtech I don't know I'm not as smart as you are or any of the devs y'all are the brains I just know if I fly my other qwads that aren't betaflight I can tell a difference in switching dshot protocols not knocking on y'all just my observations
@@biggfpv2721 , the problem is 100% of the time, folks comps are not A-B when it comes to comparing things.
It usually starts out like:
"On my F1 quad vs. my BF quad..."
And I say:
"STOP! Your test was with two different quads (invalid)?!???"
When components that cause 10s of milliseconds if delay are set differently, you cannot use that result to judge 0.09375ms differences (8k vs. 32k loop rate).
I think sometimes folks just need to do the simple math between 8k and 32k loop rates.
1/32 - 1/8 = 0.09375ms
Human reaction time = 250ms
Prop rmap speed = 2 to 20ms
Filter gyro signal delay = 4 to 6ms
Wow super!! Thanks
Hell yea man.
You know that the human reflex action in all this just makes about all this moot. WE can only react to a certain degree with our big Meat wrap bones and limited optical sheep eyes till all this stuff just dont matter.....Lol
It's not for human to react to, more like for the PID loop to correct the quad's movement.
Yes, for example when you dive into your own propwash - gyro senses unwanted turns, FC corrects and esc sends those data to the motors. Oscillations can be reduced if you correct after 3 degree turning instead of 9 degree turning. Everything helps because latency adds up but it is more effective to reduce 2000us filter delay than 27us esc command delay.
Really interesting and usefull
I run dshot 2400! Whoop whoop!
I learned something today 👍
Abernathy Unions
Perez Charles Clark Joseph Harris Betty
You mean that dshot 600 and 1200 are just gimmicks ?
No but in 8khz yes.. Dhsot 600 is for 16khz and dshot 1200 is for 32khz update frequency.
No there not gimmicks they are useless ONLY because you can't go higher than 8k anymore
If I gave you two quads, one with dshot 1200 32khz update loop and the other with dshot 300 8khz. Could you tell the difference just by flying them?
Your reactions and signal transmission are way laggier than those update timings. It's like a dozen microseconds difference in a dozen mili seconds.
It's like getting a 500 hz refresh monitor when even trained eyes can't see the difference above 200hz
@@mindprobe3587 no I agree if you do what you are saying you can't tell the difference I'm saying if you took two qwads and had them both at 32k and one at 1200 and one at 600 you most definitely can tell, the qwad will fly like shit on 600 and not on 1200 it's not just my reaction and so forth because in that sense if you did what you described you can't tell the difference ,it's the fact that the qwad will fly like crap again that you can tell, if you do what I say
@@mindprobe3587 pretty sure you could detect the difference if running higher pid loop / dshot would mean less propwash