Can anyone provide guidance on the best PWM frequency when using DSHOT with BLheli32? I know from my racing quads that it’s ideal to match it to your PID loop frequency. Any advice is appreciated 
I’m guessing it’s the lowest available, 16k. I’m open to other opinions though.
I had a poke around in the parameters on the wiki page but I couldn’t find an answer I’m afraid. Hopefully someone else has some ideas.
I can give you one data point. On my F4 Nano board running a loop rate of 800Hz and Dshot600 configured the default PWM Frequency of 24kHz is working fine.
1 Like
From my research in the racing community, where ESC performance really counts, it sounds like 16k is the best considering the PID loop runs at 1k on AP.
It runs at 400Hz default.
Wow, so the PID loop runs even slower than I thought.
Depending the FC it can run faster. 800Hz seems to work OK for me on an Omnibus F4 Nano V6.
Yes, the SCHED_LOOP_RATE parameter can be used to increase the main loop rate. I’m not sure what the current maximum rate is but I think it’s between 1000hz and 1600zh (Copter-3.7 will likely offer high rates).
1 Like
Is there a way to check CPU usage to make sure you aren’t going overboard? Any advantages to running a higher loop speed? I know on my racing quads that higher loop speed are beneficial, but it’s a totally different use case.
@vosair, yes, the PM message will show the number of long loops (i.e. main loops that took too long) in the “NLon” column. Numbers below 50 are probably OK but if it’s in the hundreds then that’s not really good.
I think the higher loop rate is only useful for small racing quads. For more medium sized vehicles they physically can’t react fast enough to take advantage of the higher loop rates.
I checked with Tridge about loop rates and he says the practical limit is about 700 at the moment although rates as high as 1000 work. The issue at higher rates is that telemetry messages may not be sent to the ground station. It’ll likely be increased for Copter-3.7 but for 3.6 it seems like keeping the SCHED_LOOP_RATE at 800 or lower is best.
1 Like
Thanks for the advice, much appreciated!
Hello Randy,
A couple of weeks ago, I tried raising the SCHED_LOOP_RATE parameter to 800 in a Mini Quad and got the permanent error in my Pixracer R15 with ChibiOS, which said “Bad Gyro Health”, the solution, return to the default value of 400.
I did that to test D-Shot 600, I’m using D-Shot 300 for the moment until the SCHED_LOOP_RATE is updated.
2 Likes
I was running my 13" 2300g quads on 48k, now I’m down to 16k. The only thing I’ve noticed is 16k seems a bit more quiet in comparison. I didn’t have any problems running at 48k with timing set to auto.
something changed recently in the master - i had couple of odd refusal to arm and then i saw - as soon as radio connects to the model and it passes all checks in the startup - load level was going to 99% on the 800Hz loop. i had to drop it back to 400Hz. @tridge suggested it was an effect from suboptimal mavlink loop. if you run code from master - make sure to check what your cpu load level is when armed.
it was working fine before at 800 - so something quite recent changed that.
there is a common belief that a higher rate leads to smoother motor control and should be reducing vibrations. i tried it and did not find any factual evidence - so keep it running on 32.4 code with default values. it works and so far i did not see any benefit from changing it.
1 Like
Thanks Paul I do have Master loaded but haven’t flown it yet. How are you determining load level?
simplest one is to look at MP page - right under sonarrange there is ‘load’. as soon as failsafes complete - in my case it works if i connect power and radio - it would go there from 19% to 99% on the 800 loop.
it may be misaligned dma, may be mavlink, may be who knows what, all i know i did not change a thing but since less than a month ago it behaves like that now. on a positive side, i did not see much of a critical difference between 800 and 400 loops. 800 loops were a bit more responsive, but not by a ton.
PS. i do not think it is DMA - just tested it, returned back 800 and still got 99.6% cpu load. i recently freed up DMA channels from serial ports to fix dshot hiccups - so it for sure should have now enough DMA for SD card and other channels - but - issue is still there.
OK, thanks. With my F4 nano V6 @ 400Hz load is ~22% and it doubles to ~45% at 800Hz. Running master from yesterday. No SD card of course!
Similar for me… about 38% running at 800hz on the omnibus nano f4.
I have all logging disabled in the configuration, due to not having an SD card. (Not sure if that makes a difference)