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:
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)
My 2 cents on this:
https://github.com/jerabaul29/OpenMetBuoy-v2021a/blob/754e84098409607f0cd39af3f9588810210aaf35/legacy_firmware/firmware/standard_gps_waves_drifter/wave_analyzer.h#L44-L52
https://github.com/jerabaul29/OpenMetBuoy-v2021a/blob/754e84098409607f0cd39af3f9588810210aaf35/legacy_firmware/firmware/standard_gps_waves_drifter/wave_analyzer.cpp#L247-L252
and the decoder:
https://github.com/jerabaul29/OpenMetBuoy-v2021a/blob/754e84098409607f0cd39af3f9588810210aaf35/legacy_firmware/decoder/decoder.py#L139-L153
https://github.com/jerabaul29/OpenMetBuoy-v2021a/blob/754e84098409607f0cd39af3f9588810210aaf35/legacy_firmware/decoder/decoder.py#L291-L418
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):
https://github.com/jerabaul29/OpenMetBuoy-v2021a/blob/754e84098409607f0cd39af3f9588810210aaf35/legacy_firmware/firmware/standard_gps_waves_drifter/imu_manager.h#L58-L76
https://github.com/jerabaul29/OpenMetBuoy-v2021a/blob/754e84098409607f0cd39af3f9588810210aaf35/legacy_firmware/firmware/standard_gps_waves_drifter/data_manager.h#L11-L13
https://github.com/jerabaul29/OpenMetBuoy-v2021a/blob/754e84098409607f0cd39af3f9588810210aaf35/legacy_firmware/firmware/standard_gps_waves_drifter/data_manager.h#L26-L27