2.3 version acc_1G and MSP_RAW_IMU

[Plüschi]

2.3 version

acc_1G definition is nice BUT it should also be used in MSP_RAW_IMU message output (protocol.c).

I have an ACC_1G of 4096 and it totally messes up the GUI display. Those values should be shifted according to ACC_1G to give a nice graph. 4096 -> >>3, 2048 -> >>2, etc. Can this be automated with some defines?

Same goes for gyro values, some scale factor for deg/sec should be used in output to GUI. I do use >>2 on gyro since i run it full res.

[Alexinparis]

2.3 version

acc_1G definition is nice BUT it should also be used in MSP_RAW_IMU message output (protocol.c).

I have an ACC_1G of 4096 and it totally messes up the GUI display. Those values should be shifted according to ACC_1G to give a nice graph. 4096 -> >>3, 2048 -> >>2, etc. Can this be automated with some defines?

Same goes for gyro values, some scale factor for deg/sec should be used in output to GUI. I do use >>2 on gyro since i run it full res.

Hi,

acc_1G definition is nice BUT it should also be used in MSP_RAW_IMU message output

A real time message to transmit 2 static bytes
It is really not reasonable to burn 2 bytes in this message for this.
Currently, the range of ACC_1G is something like 200-> 512 for all sensors.
For your own need, I suggest a GUI adaptation

[Plüschi]

You misunderstand.

Im not suggesting to send acc_1g along, im suggesting to make sure the acc data in in the 200 to 512 range.
im suggesting If (acc_1g >= 4000) divide acc / 8 before sending.

[Sebbi]

Wouldn't it be better if the GUI could just display values over 512 properly? Just divide by 8 in the GUI code