The logs will show what looks like PWM if Dshot is being used.
If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck. 
You can’t log PWM values if FC doesn’t generate PWM signals.
Why not? Dshot has to be scaled in some fashion. But whatever. Attached are 3 logs from the same FC configured as PWM, Oneshot125 and Dshot150. I think all we need here is confirmation of how Dshot output is being scaled in the log.
Dhot150.bin (364 KB) Oneshot125.bin (440 KB) PWM.bin (396 KB)
Note: Just for kicks I set the BLH Mask and O-type to Chan’s 9-12 and Dshot150 and tested it again. Same output in the log.
1 Like
@rmackay9, Yes, please. I know you guys are already spread far too thin, but I think if this is a persistent issue and source of confusion that documentation must help.
As for OneShot, it likely is the best option possible for any older/early Atmel/SiLabs 8-bit ESCs (of which plenty are still running around), so having good/clear documentation on how to take advantage of it seems like a great thing.
Thank you for the logs.
Oneshot125 works, and is logged as such. Dshot doesn’t.
I mean, it’s a digital 2048-step value. Why would one log it as “halve the value and add 1000” ?
And believe me, the ESCs that don’t know PWM blink “no communication” at me on Pixhawk1, Black Cube, Orange Cube and Pixhawk 4 Mini.
I wonder if you can force a BlHeli_32 to forgo signal detection and stay on a single protocol
Yes, I admit I’m not sure what’s going on. I don’t have a ESC connected to the FC and even if I did it may not be clear if it’s being supplied with Dshot. Unless it has an indicator as you have that is. There is something else going on here too because the Pixhawk 2.4.8 outputs Oneshot125 range values as shown but the PixRacer does not with the same level of firmware. As Randy states above it seems we need a definitive way to know what protocol is actually being sent.
1 Like
What exactly are you looking for in the logs?
Here is my Hex running Dshot
That’s your Hex running PWM 
Dshot digital Values:
0 = disarmed.
1 to 47 = Reserved for special commands.
48 to 2047 = Active throttle control.
If AC would’ve outputted DShot, values logged should’ve been 0 instead of 1000 in disarmed state, and probably 50 instead of 1100 when armed and throttle down.
I have never calibrated the ESCs and everything is working perfect and all motors are in sync. So my belief is I am running dshot
That’s how homeopathy medicine works. 
Tbh, since the advent of BlHeli_32, I even tick out the possibility of throttle calibration in BlHeliSuite. I forgot when I’ve last calibrated ESCs… probably back in 2017.
Btw, if everything is working perfect, why didn’t you save the AutoTune parameters ?
I did… on another run. I was doing a bunch of testing
I have a quad that is allegedly running Dshot… Let me grab those logs and take a look
Guys, the log will not tell you if you are running Dshot. I think we need to get passed this. Attached is the output from the same Pixhawk 2.4.8 on Copter 4.0.0 configured for Dshot300 (because that’s what Cornel wants to use). It’s producing Dshot! One view is at low throttle and one is at high. I zoomed a bit so you can only see 15 of the 16 pulses but clearly Dshot is being produced. In the log it will be shown in typical PWM range.
2 Likes
Thanks for that. I will say that the startup tones of my ESCs are different on Dshot vs PWM/Oneshot. So this is why I am confident that I am actually using dshot
1 Like
If it goes between 1000 and 2000, guess what kind of signal is it !?
Do you really believe there’s a DShot to PWM translator running loops inside the Pixhawk for logging purposes ?
@dkemxr
DShot is digital. It’s octets of data on a serial line. I only have a matchbox-sized $20 scope at home so I don’t think I can look at the signal, but I’ll try.
Yes, something like that. It’s simply being scaled to produce a useable metric. I don’t know why your ESC’s are not accepting it.
It’s 16 bit, 11 for throttle, 4 CRC and one Tel request. with pulse width for binary values.
How about making a DShot tester on a STM32F1 board? Should it be possible to parse the protocol? (probably yes) Is there any code which could be adapted to this task? Then, it would display the received values on an OLED display or even report the correct protocol with a LED diode.
EDIT: maybe even Arduino?
Mission Planner could possibly add a value in the Status screen by decoding the output.
Maybe someone with a Saleae stumbles upon the thread and gives us a helping hand.
DShot values would be a usable metric, just as OneShot125 values are. With finer resolution, even.
The simple ideea that instead of logging DShot output values, there’s a snippet of code that does some math, and uses MPU cycles and RAM to do a translation to familiar-ish PWM values, for me is unfathomable.