We’re developing an indoor training bike.
I noticed that there are some protobuf decoding errors when receiving commands from the android app. It seems like the protobuf bytestreams are cut off at a maximum length of 18 bytes. Adding 1 byte of opcode and 3 bytes of BLE, the maximum received data seems to be 22 bytes, very close to the minimum MTU size of 23 (maybe I’m missing a byte somewhere?). In any case, that lead me to believe that the MTU might not have been set by the client (and the MTU update procedure it’s indeed not set from server side in our implementation, which I have added now).
I just wanted to remark this for 2 reasons:
- With the windows zwift application, I don’t have this issue (the client seems to triggers an MTU update procedure)
- The “Zwift Protocol v2.1” documentation clearly mentions some requirements about MTU, but it does not mention which side (client or server) should initiate the MTU update procedure at startup.
For consistency reasons, I think it would help to update the documentation and the android application, or I’d like to know if I have an incorrect understanding.