A.M. Total of 15.5. Ran with Chad and the kids. Benjamin did 8.5, Jenny 3, Julia 0.5, Joseph 2, Jacob 1, William 0.5. Fast Running Friend had a chance to prove itself against Chad's Garmin 210. The course was of known length with marks. In the first 5.04 miles Fast Running Friend said 5.03, Garmin said 4.99. Garmin got off track on the distance over about a half mile stretch, then maintained the difference. Fast Running Friend was within 0.01 on all intermediate splits. Then over the next 2.04 miles Fast Running Friend added 2.02, while the Garmin added 2.05, so now the Garmin was closer to the truth that it was before. Then Chad accidentally disabled the GPS, so we were testing just the Fast Running Friend. Over the next 4.00 it reported 4.03, then after that it stayed on track until it ran out of battery with the total running time of around 1:53, but we started at 80% battery charge. Fast Running Friend was without question more accurate on the immediate pace. This one is difficult to verify exactly, but both Chad and I agreed whenever we sampled it that Fast Running Friend was reasonable every single time, while Garmin made sense only 60% of the time or so. Fast Running Friend also showed some resilience in a situation that I did not explicitly think through in my code. At around 1.4 mark I made a VPB stop and did not press the Stop button. When I was done and started running, the Fast Running Friend extrapolated my distance to be about where Chad was at the time. Then once it noticed that I've gone 0.15 from the last trusted point it corrected the distance moving me backwards, and eliminating the detour because the turn angles in the path were too high and disruptive. By the time I caught up to Chad the Fast Running Friend was showing the correct distance. It is a good sign when your code does the right thing when used in a way that you did not explicitly program for. I do need to do something about the battery life. From the tests I've done so far, things look ugly. If I tell Android to give me GPS updates at a higher interval, it does give them to me at a higher interval so the accuracy is lost, but the GPS driver (/system/bin/SiRFDrv) is still reading the GPS device (/dev/ttyS0) once a second no matter what and the battery drains just as fast. So I might need to bypass the Android GPS notification system, and read the GPS device myself. This is going to be an adventure, but it has some payback potential - first, improvement in the battery life. Second, quicker acquisition of the GPS signal - I suspect somewhere in the convoluted communication process that takes the signal for the device to the application there is a bug that withholds the legitimate signal. There are times when the app is not getting the signal, the GPS driver logs says it is waiting for signal, yet I catch SiRFDrv red-handed reading the correct GPS coordinate in plain text from /dev/ttyS0. Third, this can give me the flexibility of varying the read interval quickly which could allow better battery life without sacrificing accuracy. I just need to learn more about how the GPS works on a lower level.
| 