Oneshot125/42 blhelis

Yea, that would be a good way to present it.

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.

Pix 2_4_8 4_0_0.param (17.4 KB)

OK at 4.0.1 (Pixhawk1 as shown below) Dshot150 is working fine as shown on the scope.

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

Maybe someone can check my conversion here.

1 Like

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.

1 Like

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.

2 Likes

Which FC did you test Sergey?

MatekF765-WING on Copter 4.0.1

That’s what I see in Dave’s OneShot125 log.:

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!

1 Like

So what exactly does this mean?? Just that the scaling is diff between the main vs aux ports when an I/O processor is present?

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.

Looks pertinent.

Now why would a variable not be logged in its intrinsic value, but rather translated ? And where’s the equation behind the translation ?

I’m OK with maths, I just don’t know where to look in the code…

I asked in the Mission Planner thread thinking it’s really a log download and status screen thing but no answer yet.

Further down the rabbit hole! Note the chan scaling from the same Motor 1 output on Chan 1 and 9…

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

Yes. This has been my supposition all along. I don’t know how the RC outputs are produced/scaled in logs but in every case and FC I have tested the actual outputs match the protocol selected. It’s simply the fact that you cannot determine the protocol from log data as it’s presently presented.

As I mentioned before, my ESC’s startup tone is different with Dshot. That’s how I knew it was in fact using Dshot

My somewhat informed guess is that the logging is scaled because we didn’t create a new mavlink message for DShot