Blackbox acceleration/vibration fixes

[breadoven]

Prevents overflow in blackbox acceleration and vibration fields.

Also fixes misplaced accVibe calculation.

[github-actions]

Test firmware build ready — commit d287397

Download firmware for PR #11447

227 targets built. Find your board's .hex file by name on that page (e.g. MATEKF405SE.hex). Files are individually downloadable — no GitHub login required.

Development build for testing only. Use Full Chip Erase when flashing.

[breadoven]

Note: if acc.dev.acc_1G = 2048 max G is limited to 16.

An alternative would be to replace acc.dev.acc_1G with 100 so the blackbox saves in "centi" G. This would allow G readings up to 326 but wouldn't be backwards compatible.

[stronnag]

Any reason you can't use int32_t vice int16_t. Don't think that breaks anything.

[breadoven]

Any reason you can't use int32_t vice int16_t. Don't think that breaks anything.

I thought sticking with int16_t would help avoid adding more Blackbox bloat and a 16G limit should be fine in general, with values much higher starting to become a bit meaningless. Although I just realised the bmi160 acc uses 4096 for acc_1G which would limit you to a mere 8G.

[breadoven]

I should have checked what these sensors are good for in the datasheets. Most of them only go up to 16G with the BMI088 the only exception capable of going up to 24G although it seems to be set to a 12G range for INAV. So a 16G limit in Blackbox isn't an issue. Also the BMI160 has been set to an 8G range for INAV for some reason so that's the max possible.

One thing I did notice for the BMI088 when checking the data sheet is:

https://www.bosch-sensortec.com/media/boschsensortec/downloads/datasheets/bst-bmi088-ds001.pdf

INAV uses 2048 for the calibration factor whereas the data sheet shows a calibration factor of 2730 for the 12G range. Is this correct ? @sensei-hacker ?

Edit: Looks like a 0.75 correction factor has been applied in the BMI088 driver to account for the above so all good.