Rummys Blog An world of endless Monday

Tuesday, 9 August, 2016

wearRoutes real world test #2

Filed under: World of Warcraft — Andrew.Rowbottom @ 1:12 pm

I’ve done some tweaking to try to reduce the battery usage and ran wearRoutes on my watch for 2 hours in “record” mode, almost entirely on the “stats” screen, so no map burning, though I suspect that the stats screen actually burns more CPU than the map screen, since it has “bigger” updates.

This version differed from the previous version in may ways, but mainly the stats screen updates roughly 4 times a minute – though not actually at 15 second intervals due to this ‘n’ that.

The results were, interesting.

First the battery which drained pretty constantly at about 7..8% per hour – 14% in 2 hours (98% to 84% ), this is about half the rate at which the battery drained in the last test, so I guess I’m probably doing something right, though I was deliberately not “poking” it.
2016-08-09-wearRoutesBattery

A few interesting features showed up in the location handling.

  • The “distance” travelled was at 2km before I even reached the end of the first field, and the logs show that it had briefly locked onto a cell tower with an appalling accuracy of 1.4km. So I need to discard poor accuracy points. A “feature” of these points is an elevation of exactly ZERO which is a nice little indicator.
  • The second feature is that it looks like all of the points are duplicated in the gpx log!I can’t tell if this is my code messing up or if it really truly did receive duplicate points! I’m really not sure where these are coming from, but there’s a fair chance they’re causing extra useless screen updates.
  • The “instantaneous” speed was mostly though not entirely missing from the data collected, it was present on the data with good accuracy

On the plus point I’ve separated the location gathering code from the rest of the system so it should be fairly easy to sort out.

To Do

  • filtering to exclude the “elevation = 0.000” points, a quick test produces a track with no particularly noticeable speed spikes, though there are a few “gaps” in the logs that way.
  • See if I can rework the location gathering to be “persistent” about getting quality data, this should have a side effect of getting more valid “instant-speeds”.

Powered by WordPress