Can't use multi-phase with stackmat + spacebar

[sourproton]

When using a stackmat with inspection, I can conveniently start inspection with the space bar, then start solving with the stackmat.

When using multi-phase, though, the space bar doesn't trigger the phase system. This would be particularly interesting for blind solvers who want to practice starting the solve with their hands in the stackmat position, but that would still be interested in timing their memo with the space bar.

Would it be possible to make the space bar trigger the multi-phase just as it does for inspection when using a stackmat?

[afedotov]

The biggest obstacle here is clock synchronization problem between timer device and host device. If timer device itself can provide to host device intermediate events like phase/lap with elapsed time, then it is easy to do. Otherwise it is hard to properly implement since timer and host device has own clocks which hard to properly synchronize due to timer protocol one-way and asynchrony. And clocks may skew relative to each other due to different precision.

For now seems like only original StackMat G4/G5 timers can provide such intermediate events like Left/Right pad touches while timer is in running state. But I'm not sure about this, have no such device on hand for now to check.

Combining hardware timer with keyboard timer is worst case scenario in either way for general multiphase. If you need multiphase, just use keyboard timer only, since not much hardware timers designed and capable for multiphase.

For such specific case, like only 2-phase BLD memo/solve, we can make something similar to WCA inspection. Just start memo in same way like inspection with hardware timer, then start solve as usual with hardware timer, then csTimer should handle recorded inspection and solve times accordingly to such BLD mode.

[sourproton]

clock synchronization problem between timer device and host device

I didn't think of that. On the other hand, millisencond precision wouldn't be absolutely necessary in this case, as memo timing is just to get the blder an idea of their time splits. Even with space bar-only multi-phase solves, the very fact that one needs to reach to the space bar to register the end of memo makes it imprecise by nature.

I thought that, since cstimer displays a number on screen, it would be able to read that number during the solve. Though I'm not familiar with cstimer's code at all, so I trust the developer's opinion if they say it's a challenge not worth getting into.

we can make something similar to WCA inspection

I think this would be interesting, but it defeats the purpose of training the hands on stackmat + cover removal movement. I think it would also be too niche. So given that it doesn't solve the original problem and that very few people would use it, I don't think it's worth it unless it's minutes away from implementation.

[afedotov]

I thought that, since cstimer displays a number on screen, it would be able to read that number during the solve. Though I'm not familiar with cstimer's code at all, so I trust the developer's opinion if they say it's a challenge not worth getting into.

This is a bit more complicated. Some hardware timers send only basic intermediate events when they occur, like "timer is started" and "timer is stopped with XX time". These are timers with Bluetooth protocol. Other timers like StackMat-compatible with UART interface constantly update their status over wire with fixed ODR which is only around 6Hz.

So to implement displaying of counting numbers during solve, software timers just use own host device monotonic clock. That is, they start host monotonic clock when hardware timer says it is started and then just display numbers measured by host clock. When hardware timer is stopped, host clock also stops, but no matter what host clock counted just display numbers taken from hardware timer stop event.

Host device clocks can skew to the hardware timer clock by deciseconds even they one-way "synchronized". This is because of status events are send asynchronously by hardware timers and delivered with delay. In case of StackMat because they sent with constant and low ODR. Also some additional delay exists due to audio signal processing - someone come up with idea to plug StackMat UART interface into microphone input for simplicity.

Keyboard/touch events are handled by host device, and obviously such event timestamps tied to host device monotonic clock timeline, there is no any other suitable timeline available there. So you can't use timestamps from host monotonic clock directly, you need to fit them to the hardware timer timeline.