the SENS values in hb_tiny_razor.xml airframe file (4096 = 12 Bit) are only set to reverse the BFP
formating what ist done for rates in RATES_FLOAT_OF_BFP(gyro_float, imu.gyro); in ahrs_propagate();
Why?
/* convert bfp imu data to floating point */
RATES_FLOAT_OF_BFP(gyro_float, imu.gyro); // olri div by (1<<12)
/* unbias rate measurement */
RATES_DIFF(ahrs_float.imu_rate, gyro_float, ahrs_impl.gyro_bias);
The trick to get it work is to scale the values from deg/s to RAD/s,
see the lines below from my ahrs_propagate();.
// scale gyro adc raw to [rad/s] FIXME // olri
ahrs_float.imu_rate.p /= 61.35f;
ahrs_float.imu_rate.q /= 57.96f;
ahrs_float.imu_rate.r /= 60.10f;
Putting scale factors in the source files is a really bad solution in my opinion. That is what the SENS parameters are for.
The result of the that *must* give closest-by 0.0... rate on silence!
It's at the moment *impossible* to combine these 2 factors,
becourse the bias is substracted between these to steps.
Why should this be impossible? That is how it is done for all other IMUs...
The aligner runs on the already scaled sensor values, then the averaged gyro values are converted to float in ahrs_align and used to unbias the (scaled) gyro measurements that were just converted to float as well.
The neutrals are basically the raw values (imu.gyro_unscaled) you read when not moving, the sense parameters do the proper scaling to imu.gyro. The BFP values imu.gyro then get converted to float with RATES_FLOAT_OF_BFP.
I worked hard for finding out that ;-), but i didn't see the
jumping point to solve it better, i am not fimiliar with BFP.