Breaking the Wall

Day of rest. Went to church. It was Benjamin's 14th birthday, so I ordained him to the office of a teacher in the Aaronic Priesthood. The full-time missionaries spoke in the Sacrament meeting. Interestingly enough, both of them are from Northern California and both grew up on a farm. One comes from a family of 11 children. The other was a convert to the Church, his family joined when he was 12 years old. He told about how his father was an alcoholic and his parents were in the process of divorce when they started meeting with the missionaries. His father was quite stubborn but eventually decided he wanted to know for himself if the Book of Mormon was true. He prayed and received a strong positive answer. They joined the Church, he overcame his addition, and he and his wife are still together.

Then we had a great lesson in Sunday school on revelation, and a continuation of that of sorts in the Elder's Quorum - the topic was the Holy Ghost. The lesson manual mentions how President Lorenzo Snow and other missionaries were thrown off a boat during a storm in Hawaii in 1864 and when they found President Snow he was not breathing. They did what they knew how to do, and he was still not breathing. Then they had a prompting to do what we know as mouth-to-mouth resuscitation, which was successful. It was interesting to read their account of it - they did not know the word for the procedure and they just described it.

A.M. Total of 12 miles. We are feeling better although not 100%. Benjamin did 7, Jenny 3, Julia 0.5, William 0.5, Joseph 2, Jacob 1. Tested the Fast Running Friend again with perfect results both on the distance and immediate pace.

I am going to announce a "special offer". If you bring a MotoACTV or any Android-based GPS-capable device that you are willing to run with to my house I will install Fast Running Friend on it. If you bring your laptop, I will configure it so that it has the tools for me to do remote maintenance on your device. If Fast Running Friend bugs out on your device I will investigate and fix the problem. As insurance, if I brick your device and cannot repair it in time, I will buy it from you for a price you consider fair. All services are free of charge. The offer lasts until I am tired of people coming to my house. If you are interested, send me a private message to make the arrangements.

A.M. Total of 12. Benjamin did 7, Jenny 3, Julia 1, Joseph 2, Jacob 1, William 0.5. We are slowly recovering. I did a little workout to test my health and see how much fitness I've lost. Did a mile up the canyon in 6:08, and after a little rest another mile back down in 5:34. It felt hard, both up and down. Fast Running Friend was perfect with one small exception. Coming out of the canyon it reported pace 5:53, and then 5:57 when the actual pace was around 5:45. Then immediately after it reported 5:18 when the actual pace was around 5:28. However that spot is set up very well for signal distortion with the trail squeezing through a narrow opening between two tall rocks. I have not yet analyzed the data, but I've seen a similar pattern in another test sample and I am suspecting the problem is that we pick up the signal with virtual delay - that is the signal keeps us on the trail, at least the points the Fast Running Friend considers legitimate are on the route, but they are shifted back. So the GPS driver in other words tells the Fast Running Friend that we are now where we were in reality one second ago. If that indeed is the problem, there is absolutely nothing we can do to correct for that short of making the sampling distance too long because in the absence of some other feedback we cannot tell if the runner legitimately slowed down by 10 seconds per mile and then sped back up or if he ran evenly. Such a change of pace is completely legitimate and the erroneous point lies on the course.

I am still working on refining the GPS part of the Fast Running Friend, mostly the usability stuff - configuration file reading and writing, then UI to edit it on the device and via web browser if the device can connect to WiFi, support for splits of various kind, ability to upload workouts to the Fast Running Blog, etc, but I already ordered Garmin Footpod and will start research once it gets here. I have high hopes for the footpod  - I think it will have more accuracy than GPS, and also less power utilization.

A.M. Total of 12. Benjamin did 7, Jenny 3, Julia 1, Joseph 2, Jacob 1, William 0.5. I did a pickup down the canyon for 1.25 in 6:46. Felt stronger than the day before. More sleep helped, I think.

A.M. Total of 12. Benjamin did 7, Jenny 3, Julia 1, Jacob 1, Joseph 2, William 0.5. Worked on adding wireless connectivity to the Fast Running Friend. So far it has been giving me good results distance/pace wise - has not bugged out yet.

A.M. Total of 12. Benjamin did 8, Jenny 3, Joseph 2, Julia 1, Jacob 1, William 0.5. Discovered a bug in the Fast Running Friend. If you pause, walk over to the new location, and then restart, it adds the displacement to the distance. Will fix it. Finished the configuration file reading/writing code, and worked on the wireless connectivity. The idea is that to configure it the user can just start wireless configuration daemon on the device using a menu function, and then connect to the device through a browser. The only issue is how to get the device to figure out the wireless authentication credentials initially - my plan at this time is that he just presses the "enable mass storage mode" on the device menu, then connects the devices to the desktop/laptop via USB, then puts his SSID and password in the config file, disconnects the device, and Fast Running Friend figures out the rest. One problem, of course, is that some users are too illiterate to open and edit a plain text file :-) If it is Microsoft Word, or PDF, they do not have a problem, but I've had accounting departments return my invoices that I sent as a plain text attachment with .txt extension complaining that they could not figure out how to open the file. Indeed Microsoft does not "delight in plainness", and definitely does not help its users in that cause. So maybe I should make that config file in Microsoft Word format :-)

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.