-
Notifications
You must be signed in to change notification settings - Fork 0
Reconnection tests
When the Shield disconnects from the device, the Switch Event Provider will periodically attempt to reconnect to the Shield. However, reconnection times can be very inconsistent and, in some devices, unacceptably long (See [issue #11] (https://github.com/jorgesilva/TeclaAccess/issues/11)). This page is an attempt to diagnose the issue.
The following reconnection times were measured on the Samsung Galaxy S2 X. Note that there seems to be no consistency with respect to any of the events recorded.
| Trial | SEP Reconnection period (s) | Screen state when Shield unplugged | Actual reconnection time (s) |
|---|---|---|---|
| 1 | 4 | on | 17 |
| 2 | 4 | off | 44 |
| 3 | 4 | off | Waited 6 mins. Worked after waking screen |
| 4 | 4 | off | Waited 4 mins. Worked after unlocking screen |
| 5 | 4 | on | 29 |
| 6 | 4 | on | 11 |
| 7 | 4 | on | Waited 3.5 mins. Worked 8 secs after resetting bluetooth |
| 8 | 4 | on | 11 |
| 9 | 4 | on | 12 |
| 10 | 4 | off | 110 |
| 11 | 4 | off | 16 |
After the test above, the down time of the Shield was recorded as it seemed to be more relevant to the actual reconnection time:
| Trial | SEP Reconnection period (s) | Screen state when Shield unplugged | Shield down time (s) | Screen state when Shield plugged | Actual reconnection time (s) |
|---|---|---|---|---|---|
| 1 | 4 | on | ~10 | on | 11 |
| 2 | 4 | on | ~12 | off | 110 |
| 3 | 4 | on | ~8 | on | 13 |
| 4 | 4 | on | ~7 | on | 23 |
| 5 | 4 | on | ~1 | on | 16 |
| 6 | 4 | on | < 1 | on | 12.5 |
| 7 | 4 | off | < 1 | off | 126 |
| 8 | 4 | off | ~7 | off | 230 |
Seems that having the screen on while the app is trying to reconnect the Shield, dramatically decreases the reconnection time.
Then noticed that the socket was being forced to null after every disconnection. Thought this may be preventing the device from closing the socket cleanly (see #10) but may also be forcing the device to create a socket on top of one that is already open (if that makes any sense). After removing the line forcing the socket to null, the following was recorded:
| Trial | SEP Reconnection period (s) | Screen state when Shield unplugged | Shield down time (s) | Screen state when Shield plugged | Actual reconnection time (s) |
|---|---|---|---|---|---|
| 1 | 4 | on | ~6 | on | 120 |
| 2 | 4 | on | ~6 | on | 25 |
| 3 | 4 | on | ~7 | on | 8 |
| 4 | 4 | on | ~8 | on | 7 |
| 5 | 4 | off | ~8 | off | 197 |
| 6 | 4 | on | ~30 | off | 15.5 |
| 7 | 4 | on | ~35 | off | 15 |
| 8 | 4 | off | ~48 | off | Very long (missed measurement) |
Of all possible reasons why the Tecla Shield reconnection time may extend beyond just a few seconds, the most consistent one was having the screen off. It seems that Samsung may have implemented some kind of battery saving scheme that puts the Bluetooth chip on stand-by when the screen turns off. Problem is, there is no warning, nor a way to revert this behavior. Thus, the best approach to solving [issue #11] (https://github.com/jorgesilva/TeclaAccess/issues/11) may be simply to turn the screen on for a few seconds when the Shield is trying to reconnect.
After adding code for turning the screen on, both when the Shield is disconnected and after about 100 seconds, the results are as follows:
| Trial | SEP Reconnection period (s) | Screen state when Shield unplugged | Shield down time (s) | Screen state when Shield plugged | Actual reconnection time (s) |
|---|---|---|---|---|---|
| 1 | 5 | on | ~13 | on | 21 |
| 2 | 5 | on | ~6 | on | 20 |
| 3 | 5 | on | ~8 | on | 30 |
| 4 | 5 | on | ~46 | off | 5 |
| 5 | 5 | on | ~80 | off | 32 |
| 6 | 5 | on | ~50 | off | 10 |
| 7 | 5 | off | ~58 | off | 10 |
| 8 | 5 | off | ~410 | off | 9 |
| 9 | 5 | off | ~58 | off | 8 |
| 10 | 5 | off | ~10 | on | 4 |