Problem with bridge mode with remote desktop about walt HOT 5 OPEN

The bridge script assumes that it runs on the same device as the app and therefore has access to the same clock (this is the case we have with ChromeOS where the bridge is needed because the app has no access to USB).

It's possible to get rid of this assumption by using the WaltDevice.simpleSyncClock()
Call it in WaltDevice.syncClock() instead of the connection.syncClock() here
https://github.com/google/walt/blob/master/android/WALT/app/src/main/java/org/chromium/latency/walt/WaltDevice.java#L220

I think with the simpleSyncClock() your setup should work ok, but the clock synchronization accuracy will be lower, probably in the order of 2-4 ms.

Thanks for the detailed description of your setup, it sounds interesting.

from walt.

This does help indeed thanks.
Now, at the end of the test pass (like after 20 taps on tap latency), when doing calling updateLag, the python bridge kills itself because it isn't properly initalized

Here is the stack trace

w>: '6724782\n'
w<: 'bridge update'
bridge command: bridge update, pausing ser2net thread...
Paused ser2net thread
Traceback (most recent call last):
  File "walt.py", line 707, in <module>
    run_tcp_bridge(args)
  File "walt.py", line 691, in run_tcp_bridge
    srv.serve()
  File "walt.py", line 640, in serve
    self.connections_loop()
  File "walt.py", line 602, in connections_loop
    self.net2ser_loop()
  File "walt.py", line 617, in net2ser_loop
    data = self.net2ser(data)
  File "walt.py", line 570, in net2ser
    self.walt.estimate_lag()
  File "walt.py", line 231, in estimate_lag
    times_local_received[i] = time.time() - self.base_time
TypeError: unsupported operand type(s) for -: 'float' and 'NoneType'

from walt.

There is no implementation for "simple" updateLag. The workaround is to comment out the call to either updateLag() on Java side or estimate_lag() on Python side. It doesn't provide useful data anyway.

What sync accuracy are you getting?
When syncing it displays Remote clock: .... lagBounds = (0, x)
It means that the WALT clock is behind the Android clock by at most x us.

from walt.

Thanks this works.

Loss of clock accuracy seems to be around 3ms when averaged.
Latency is quite random between 4ms and 11ms

from walt.

For reference, here is my current diff:
http://pastebin.com/mndUN7P4

from walt.