What would a logic analyzer tell you that a O-scope won’t for this purpose? The purpose being to show that Dshot is actually being produced when the parameter is selected to do so. It’s clear Dhsot is being produced, I can watch the bit pulse widths change (11 of them) with throttle position. I have tested all Dshot protocols that Arducopter supports and they all behave as they should.
Perhaps the scaling is done when the log is downloaded? What would you use for Dshot values in the log? 0-2048 steps? I don’t really see the problem with scaling to 1000-2000us but I suppose it could be done differently.
I’m still check on this (this area of the code is not my expertise) but I think AP’s RCOU onboard log messages and the values sent to the GCS (i.e. chXout on MP’s status screen) will be scaled to the 1000 to 2000 range when non PWM outputs are used. So besides DShot we have various versions of CAN and so I think for consistency we should always log and send values in the same range (1000 to 2000).
Users need to be able to check that DShot is working though so hopefully we can think of a way to do this. My first thought is a text message sent soon after startup similar to what AP sends for the input decoding.
Beside logging and reporting of protocol used,
In case of DShot, does it use full 2048 steps resolution or the same 1000 steps range, just in digital representation?
Cześć.Dave.
Could you write what firmware version for pixhawk 2.4.8 (pixhawk 1 or fmuv3, etc) you have installed when you have proven that you have oneshot125? I would also like to ask for a param file or although you have mapped engines. I can’t repeat the oneshot on my pixhawk 2.4.8. Thanks
Hi. One more question I ask. Did you connect the oscilloscope to see the oneshot and you had esc connected to the controller. If so, were they blheli32 or blhelis? It is already stupid to think that maybe after initialization pixhawk sends something via dshot commands to check if it is dealing with esc blheli32 and if it does not turn on regular PWM. I need to check if there is any rcout traffic after initialization …Thanks
Hi Marcin-Sure, anything to get to the bottom of this issue! Attached is the parameter file and screen shot of the messages screen on boot. There is not an ESC connected but I don’t think would matter as there is no signal back to the FC indicating what protocol was accepted by the ESC. Even ESC telemetry doesn’t supply this as far as I know. fmuv3 at 4.0.0. I believe I just let Mission Planner select this but some weeks ago I had updated the bootloader so it was recognized as fmuv3. I’m about to update to 4.0.1 Stable by choosing the Pixhawk1 target to see if this is persistent.
Good question Sergey. When I look at the output on the O-scope and convert the pulse widths of the throttle signal bits (1st 11 pulses) to binary I see a range of 1040.
Low throttle: 00011110111
High throttle: 10100000111
This is where a Saleae is helpful. Once you nail the protocol, you sit and watch the values like on a debugger.
I don’t have access to one, but come Monday I’ll be able to scope the outputs on the Orange Cube, with ESCs connected.
Made a quick patch to the AP_HAL_Chibios to see on the OSD the actual protocol mode used within RCOutput class.
Tested on MatekF765 and it looks like both Oneshot and Dshot does work, and also both modes logs RCOUT in 1000-2000 range. At least this is true for this FC and Copter 4.
I was scratching my head over this until I mapped the motor outputs to both the IOMCU (main outs) and the FMU (Aux outs) on the Pixhawk 2.4.8 on 4.0.1 because I had a hunch. Well, take at look at the status screen outputs for a Oneshot125 configuration. The scaling to 1000-2000us only occurs on the Aux outputs. Ch1-4 122us vs. ch9-12 at 982us. This is why I was so puzzled about the PixRacer. It was clearly producing Oneshot125 but why the hell was it scaling the output differently than the Pixhawk 2.4.8 all else being equal. Because it doesn’t have a IOMCU!
Yes, apparently. I don’t see any problem with what the actual output is when scoping them. Regardless of the output source FMU or IOMCU it produces the protocol configured. It’s just how it’s logged and displayed on the status screen causing some confusion.
So the values are the ‘same’ they are just on diff scales. Very odd. And if the only diff is the io processor vs fmu then it might be how the data is interpreted and outputted in the log file