transmit data as uint16's + min/max f32s

My 2 cents on this:

float16 is far too coarse for anything useful since the mantissa is very few bits; should not be used neither for signal processing nor for data transmission
float32 is fine for data processing, but unnecessary heavy for data transmission
I have been transmitting data using: either a pre-determined range (+-2g for example), or a dynamic range (transmitting MaxAbsValue as a float32 at the start of the transmitted struct for spectra), and then the data themselves as uint16_t, scaled between -rangeAbs and +rangeAbs; see:

and the decoder:

in theory, when accumulating the accelerations in RAM (either to feed in the Kalman filter if doing the nsigma filtering by hand rather than using the accelerometer built in filter, or to store in RAM the acceleration before taking the Welch spectrum at the end), it would be possible to use scaled uint16_t; for simplicity, I have been using float (ie float32_t), but of course this uses twice as much RAM, so that may be a RAM optimization that can be done (at the cost of needing a couple of multiplications / divisions extra for each entry, but with an FPU this is cheap):
- accumulators to average by hand the imu: (float but really could be uint16_t, though this is quite small)

accumulator for the 20 mins of vertical acceleration data (float but really could be uint16_t, and this is big):

gauteh / sfy