Do you need floats for the force curve?

[JaapvanEkris]

Hi @Abasz ,

I was looking at your project, and you have quite some details about how to transport floats to the BLE-client. But why use the (cumbersome sized) floats, where peak forces often are in the 350N to 800N range. Wouldn't a bunch of integers be as good, but a lot easier to transport?

Jaap

[Abasz]

Thanks for this, I always appreciate a second pair of eyes.

Transporting the floats are no more cumbersome than to transport integers. They both 4 bytes on the 32bit system. I don't transport peak forces separately, I only send the full force curve and peak is calculated by the client. This is actually the reason I dont round them to integers. Because in that case potentially there would be multiple max values (which is theoretically possible even in case of floats but significantly less likely).

The complexity here comes from the fact that BLE notify packet size is set to the MTU (maximum transfer size per notification) that is variable between devices (on the receiving end). Android has 256 bytes, my Garmin watch has 20 bytes (though there this is not relevant), IPhone has some random value of course (because why not)... So the packet size is variable and these 4 byte floats (or integers) needed to be fitted within the MTU.

There was a design decisions that I only use whole 4 bytes (so there is no splitting of the bytes that may leave full MTU capacity unused) that serve the purpose of avoiding escalation of data loss (e.g. when one chunk gets undelivered if it had split of the 4 bytes there are scenarios where the client would not be able to use the received chucks at all as it has no way of know how to chain the chunks together). This allows every chunk to be self contained basically and loss is limited to the values within the lost chunk and no escalation.

[JaapvanEkris]

Thanks, that clarifies that for me.