Specifically, it appears as though Bluetooth on the PM5 does not have access to the currently active CSAFE State Machine, perhaps instantiating a new State Machine with each separate Bluetooth CSAFE command the PM5 receives. That may not be precisely the cause of the issue, but that explanation matches the symptom: any individual set of CSAFE commands sent in one Bluetooth update are treated as operating on the same State Machine, whereas CSAFE commands sent over distinct Bluetooth updates are treated as operating on a State Machine that always starts in the Ready state regardless of prior Bluetooth-delivered CSAFE commands or even the active status of a workout.
The CSAFE State Machine should be reporting it's current state during Empty Frame (or CSAFE_GETSTATUS_CMD) messages. Instead, it always reports it is in the Ready State, even when a workout is active.
Code: Select all
send Empty Frame:
--> [0xF1, 0x00, 0xF2]
response is "Ready state":
<-- [0xF1, 0x01, 0x01, 0xF2] or [0xF1, 0x81, 0x81, 0xF2]
(start any workout via the PM5 screen, row some)
send Empty Frame:
--> [0xF1, 0x00, 0xF2]
response is "Ready state", which is invalid:
<-- [0xF1, 0x01, 0x01, 0xF2] or [0xF1, 0x81, 0x81, 0xF2]
should have received In Use status:
[0xF1, 0x05, 0x05, 0xF2] or [0xF1, 0x85, 0x85, 0xF2]
Code: Select all
(start any workout, row some)
send CSAFE_GOFINISHED_CMD:
--> [0xF1, 0x86, 0x86, 0xF2]
response is "the last command was ignored as it was not applicable to the current state, which is Ready":
<-- [0xF1, 0x11, 0x11, 0xF2] or [0xF1, 0x91, 0x91, 0xF2]
Code: Select all
(start any workout, row some)
send CSAFE_GOINUSE_CMD + CSAFE_GOFINISHED_CMD:
--> [0xF1, 0x85, 0x86, 0x03, 0xF2]
response "current state is Finished":
<-- [0xF1, 0x07, 0x07, 0xF2] or [0xF1, 0x87, 0x87, 0xF2]
(active workout ends)
Overall, this issue makes app development relying on Bluetooth connections to the PM5 effectively useless for any functionality that attempts to control the rower.
