Add (e)RPM field to blackbox logs

[tbolin]

Alternative to #12562, logging eRPM instead of eInterval

Adds a separate field for motor RPM from dshot telemetry.
Will only log the existing motors and only if bidirectional dshot is activated, and leaves the debug field free to use for other things.
Can also be disabled just like other black box fields.

The logged value is eRPM and the field names in the log file are "eRPM(/100) [*motor number*]".
However, in black box explorer the field is just called RPM and the displayed values are RPM and Hz.

Corresponding PRs
Blackbox Explorer: betaflight/blackbox-log-viewer#640
Configurator: betaflight/betaflight-configurator#3392

Data

Some example logs with the dshot RPM debug enabled

• Meteor75_erpm_1602Hz.zip
• Meteor75_erpm_3205Hz.zip

[github-actions]

Do you want to test this code? Here you have an automated build:
Assets
WARNING: It may be unstable. Use only for testing! See: https://www.youtube.com/watch?v=I1uN9CN30gw for instructions for unified targets!

[blckmn]

AUTOMERGE: (FAIL)

• github identifies PR as mergeable -> FAIL
• assigned to a milestone -> PASS
• cooling off period lapsed -> PASS
• commit count less or equal to three -> FAIL
• Don't merge label NOT found -> PASS
• at least one RN: label found -> PASS
• Tested label found -> FAIL
• assigned to an approver -> FAIL
• approver count at least three -> FAIL

[tbolin]

Updated first post with some example logs.

For some reason the data from the RPM field is one frame ahead of the data in the debug in the 3205 Hz file (and occasionally just different). In the 1602 Hz file the data is just slightly off with no obvious pattern.
I suspect this have something to do with the rpm field and debug field using different compression for the P frames (difference from previous for RPM field and difference from average of previous two for debug).
The RPM field also uses unsigned values for the I frames where the debug uses signed values.

This issue is also present in the other PR (logging the e intervals) but there I couldn't be sure that the difference was not due to some kind of rounding error.

Not sure if this is a problem with this PR or have something to do with the decoding in bb explorer.

[ledvinap]

@tbolin : Isn't is just race between debug[] write and blackbox sampling?

[tbolin]

@ledvinap

@tbolin : Isn't is just race between debug[] write and blackbox sampling?

Maybe, but as far as I know getDshotTelemetry that is used to get the eRPM data for the RPM field will also call DEBUG_SET(DEBUG_DSHOT_RPM_TELEMETRY, *rest of the parameters*) here https://github.com/tbolin/betaflight/blob/b5151f4b270efc741850943ae1cffe69a55b4d49/src/main/drivers/dshot.c#L170 if there is new data, so I would expect the debug to be ahead then. Haven't looked into it that deeply though.

[tbolin]

I found the reason for the delay. In loadmainState the debug values are pushed into blackboxCurrent before getDshotTelemetry is called. That also explains why the difference doesn't have a pattern when the bb update rate is halved. The debug field will often contain a value that the RPM field haven't even seen.
Everything seems to be working as intended.