50ButtonsEach / flic2lib-android

Flic2 SDK for Android
Other
17 stars 8 forks source link

Understanding the latency #22

Closed Fussballexperte closed 1 month ago

Fussballexperte commented 2 years ago

I have a use case where I need the button to transmit button events as quickly as possible. Power consumption does not matter in this case.

Like explained in #7 I've set the BT parameters to a 11.25 ms connection interval. (9,9,0,600) Still, interactions take about 80 ms to reach the screen of the smartphone. (I'm using the Super-Slomo with 240 fps of the iPhone for measuring the delay, observing a color change like in the example app. Display runs on 144 Hz and from other input methods like touchscreen or internal hardware buttons I know the display is able to react to such changes at least within 20 ms) Button and device are directly next to each other.

During my experiments, I noted two interesting things:

1) The internal LED of the buttons reacts a lot quicker, i.e. it starts shining within 10-15 ms after pressing the button. Still, the event does not show up on the phone for another 60-65 ms. 2) I built sort-of a ping-functionality into the button. You can query the battery state and I measure the time between sending the request and receiving the response. Using the before-mentioned connection settings, I obtain a ping time of 5-20 ms, as expected.

So I quite don't understand why there is so much delay in delivering the actual button events. From the LED observation I can conclude, that the button itself is aware of the change in its state very quickly. From the ping experiment I know the button is able to transmit information within the expected time interval.

So it should be possible to get notification within 20-25 ms, what would be sufficient for my use case. What can I do to actually achieve this?

Emill commented 2 years ago

Hmm not sure what could cause this. If you see the button shines green, then it will transmit the event at the next possible connection event, which should be within 11.25 ms. Maybe you could try to perform some other action than changing something on the screen, for example turn on an IKEA Trådfri switch, send an http message or whatever.

Fussballexperte commented 2 years ago

Hmm not sure what could cause this. If you see the button shines green, then it will transmit the event at the next possible connection event, which should be within 11.25 ms. Maybe you could try to perform some other action than changing something on the screen, for example turn on an IKEA Trådfri switch, send an http message or whatever.

I tried switching on the flashlight. It is slightly faster, about 15 ms, but still not anywhere near the expected result.

In which order are these events processed? When you say "if you see the button shine green, then it will transmit". Does this mean, the event is transmitted after the LED is activated? Could this cause the delay? Observing this in slow-motion, I see that the LED starts shining small and dark and builds up in the following cycles, until it shines in full brightness. When it shines in full brightness, the change in state is observed on the phone display.

However, I noticed that there is roughly the same delay for the button up and button down events, i.e. the delay seems to be the same when no LED is involved, in the case of the button up event.

Emill commented 2 years ago

The LED pulse is first initiated, then it will transmit the event. The LED runs in parallel so that can't cause any delay.

You could check the hci snoop log in Android what millisecond the event is received, and then compare this with logcat timestamp, if you log when the event is received.