Hi guys,
is already anybody working on DSHOT support for PX4?
Best regards
Timo
I doubt it, as no oneshot42, multishot support seen yet.
Will u be interested implementing DSHot on PX4?
i will be doing some research into dshot and , oneshot42 soon maybe as soon as early next week ,px4 might already have the ability to support in ,if i remember right the comunication protocol between the Fc and ESCs is 48mhz “for dshot”, which you would need to change the pwm_rate to 48000000hz “or something like that” to test , don’t quote me on this cuz i have a bad short term memory and have not tested this or spent enough time researching it
watch this video https://youtu.be/X-1YMl6aO1g
its about motor protocols it will point you in the right direction to test dshot , multishot and oneshot42
i bought a set of 4 FVT littlebee 40a blheli-s dshot ESCs ,i will have them in a few days maybe with some luck i will manage to figure out if i can get dshot enabled or atleast some fails under my belt lol
don’t go with BLheli-S …
to late now there bought , may i ask why?
It’s really cool that a few people are interested into this topic.
The Dshot protocol seems to be a very simple protocol. I think the most challenging part is to implement it with low CPU usage. The betaflight implementation is a good point to start. Betaflight uses DMA with PWM waveforms for DShot.
Does anybody now how it exactly works?
For the implementation I would go for 3 DMA channels and two PWM waveforms are neccessary. Just like the OctoWS211 implementation: https://www.pjrc.com/teensy/td_libs_OctoWS2811.html#tech
Hi,
I am interested in doing that, but probably, heavy DMA resource is required.
I’ve implemented it on Betaflight, but here less people seems interested.
If I get any result, I will let all know here 
but no guarantees.
that is a great start thank you for that , i wish people in the forum would be more responsive the new ideas , or even bad ideas , only one thing that truly is discouraging to me is the lack of feed back fo or bad for the last few weeks it has felt like i was writing and reading on a dead project
@dpsoul @greybush what do you need from the dev team to get started? I’m not the expert on the DMA topic so not much help from me here… Will try to organize someone who can give input 
- ada
About 50 or more years ago people invented something called the serial bus a.k.a UART. Modern MCUs have hardware blocks to accelerate the handling of it and include error-filtering (over-sampling) on the signal.
It’s interesting to see that DSHOT (a serial bus) is now marketed as a brand new innovation. Its essentially hacking a serial port onto non-UART hardware by emulating a serial bus in software. Doing this is valid - it means that you can use legacy hardware to software-emulate an UART. But its not really scalable (and consumer drones outside of the hobby space use UART for the ESC bus for many years now).
The correct solution to the problem is to use a high-speed UART in hardware. I’m waiting for DBDSHOT (differential DBSHOT) to be invented. That would then re-invent CAN.
I don’t think that implementing it is a good use of our time. It would make a lot more sense to create an ESC with LIN support or similar. We do already have a serial ESC bus (with feedback and software upgrade support) on Intel Aero - its in src/modules/tap_esc.
1 Like
I don’t think it would be fun to live in an ideal world ;). And unfortunately none of the ideal solutions are available for users to buy (standalone). Nor is the better technology naturally going to be the market winner.
If these DSHOT ESCs are going to spread (looks like they will considering where they are coming from) we will have users wanting to use them.
As I said I’m not criticising the approach - it makes sense to support legacy hardware. I would be happily merge a PR adding it. However, its still not something that I will actively pursue. For this to make sense we need more active contributors from the racing domain. @anton-matosov is already doing a fantastic job on integration and UI and I would love to see someone picking up DMA PWM outputs.
You can not disable dampen light in BLHeli-S, so most probably you can not get rid of that twitchy then…
But since you already order it, i would be interest to see what it does on your side…
i see , yes this will be interesting , i have a funny feeling i might have a bad esc in the video i posted the back right motor stopped spinning first , i have always had this issue with this and after replacing the motors, and eliminating the possibility of incompatibility between the esc and the cobra motors " which are known for having sycn issues with some ESCs " still very awsome motors tho ,i still think i may have a failing esc in the mix of some default PIDs lol
good luck with the new ESCs, would love to see videos of your playing around with these BL-S!
i see the point you are making about spending time on already or soon to be outdated software , so with that being said how you suggest reaching this need for better and faster cutting edge tech ?
what about support for say oneshot42, and multishot, do this stay with in the anolog protocols that are in place now ?
@greybush It depends on your objectives - if you want to maximise general hardware support then someone should work on PWM DMA and DSHOT. As I said I would enthusiastically support that, its just not something I can put development bandwidth myself towards.
If you talk about a more long-term approach then I think looking into one of the higher-end ST or NXP motor control ESCs and building a reference design like Pixhawk with a really good interface protocol would make a lot of sense - because that will be fast, allow serial boot loading and motor feedback. And it will allow bringing in more accurate control through FOC.
What you need to realise is that the faster interface protocol is not making the ESC significantly faster. The main factor for response time is how the motor state is estimated and how the phases are controlled. The communication delay difference from OneShot to DSHOT is small compared to the overall delays from other parts of the system.
Keep in mind that a racer propeller takes 5000 us for a complete revolution. So if you have 100-200 us communication delay its already pretty small compared to the physical dynamics of the motor.
Or in other words: Protocols better than OneShot have diminishing returns.