Rummys Blog An world of endless Monday

Wednesday, 31 August, 2016

More testing

Filed under: WearRoutes — Andrew.Rowbottom @ 7:18 am

I have tried to fix a couple of the issues.

Duplicate Locations

The duplicate locations was due to very very poor management of the “android lifecycle” of my application meaning that the second time it was started there was a LOT of old code still running from the last time, in effect I ended up with 2 location listeners and so on.

This has been partially fixed, though there is still a fair bit more to do to get it perfect

Deep Sleep

Apparently deep sleep doesn’t just affect “running” code, it also affects code that wants to wake up at a certain time.
Resolved by learning yet another android API!
The code now seems to reliably wake up every 30 seconds to take a sample.


The “Fused Location API” ass recommended by google is not nice, it doesn’t tell me the “true source” of the data, so I have to deduce it through other means. What I’ve seen so far is..

  • Locations with really large accuracy errors seem to be cell tower locations, and don’t come with elevation
  • There are quite a lot of locations with an accuracy from 24m upwards .. these *seem* to be WiFi locations, when plotted on a map they are often off track and near houses. Potentially they have some value (I could for example snap the location to the nearest track), but would require coding to get usable.
  • In order of “goodness” for points with moderate accuracy (>24m) it seems to be no elevation = poor, “velocity” look to be good, as do points with “bearings”

The sequence of locations seems to be ..
wakeup, ask for location updates, get a rough location in about 5 seconds, get a better (32m) location within about 10 seconds, get a pretty good (10m) location about 15 seconds after wakeup.

So .. my options appear to be:
I can wait for better accuracy this would be a simple code change
I can force the GPS to be running full time on the phone so that it doesn’t have to wait ~15sec to get a good fix (though this might be reduced if I got a good fix in the previous request)
I can get the phone to wakeup before the watch, and start to pre-emptively get a good fix so that a good fix is already there for the watch when it wakes up — I could probably even insist on a GPS fix .. in effect transferring the battery drain from the watch to the phone.

I’ll work on this albeit at my usual slow pace.

Monday, 22 August, 2016

wearRoutes more testing

Filed under: World of Warcraft — Andrew.Rowbottom @ 3:25 pm

I’ve been occasionally testing wearRoutes “recording” during my drive in.
I’ve found a number of problems, so far all seem to be related to the watch going into “Deep Sleep” which means that the normal way of asking for code to run in e.g. 30 seconds often means it *doesn’t*.
Even when it does run the damn watch will go back to sleep while it’s waiting for some location data and so not get the data it wants.

I’ve worked around the second problem by acquiring a partial_wake_lock – aka forcing the watch to stay awake while it’s waiting for a decent GPS reading. Fortunately it looks like this won’t kill the battery (too much) because a usable location usually arrives within 10 seconds, meaning the watch can sleep for 20 seconds out of every 30. Not perfect, but not bad either.

The first problem manifests like so…
a) I schedule in some code to run in 30 seconds (this code asks for the Location)
b) The code actually runs anything upto 5 minutes later (varying considerably though usually about 1.5 minutes)

I’m going to have to delve even further into android and use the Alarm Manager — nothing seems to be trivial, or perhaps I’ve covered all the trivial stuff 🙂

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.

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