Slashdot Mirror
Bizarre Droid Auto-Focus Bug Revealed
itwbennett writes "Pity the poor engineer who had to find this one. One of the more interesting of the handful of bugs that have appeared since the launch of Verizon's Droid smartphone has to do with the on-board camera's auto-focus. Apparently it just didn't work. And then suddenly it did. Naturally, this off-again, on-again made the theories fly. But the real reason for the bug was revealed in a comment on an Engadget post by someone claiming to be Google engineer Dan Morrill: 'There's a rounding-error bug in the camera driver's autofocus routine (which uses a timestamp) that causes autofocus to behave poorly on a 24.5-day cycle,' said Morrill. 'That is, it'll work for 24.5 days, then have poor performance for 24.5 days, then work again. The 17th is the start of a new 'works correctly' cycle, so the devices will be fine for a while. A permanent fix is in the works.'"
15+ years ago I had to debug some code in a report printing app for OS/2 (remember that OS?). The bug would cause the app to crash when a report was printed out. But the bug would only happen on certain days. Certain days in September. Only on Wednesdays in September. Only when it was a Wednesday in September after the 9th.
The bug? The original programmer had tried to optimize memory usage as much as possible and was off by a count of one. With "September" being the longest month spelled out, "Wednesday" the longest day spelled out, and a 2 digit date, the header that the program put together to send to the printer would overflow its buffer by one character.
Probably not measuring the times per sampling, but measuring the time the focus mechanism is moving. To keep costs down, I suspect the mechanism has no feedback mechanism, so to focus you move one way for a set amount of time (guaranteed to hit a mechanical stop). Then the software might keep track of focus position by how long it's driven the lens in one direction or the other starting at that known position (oops, I moved "out" 100 ms, but overshoot, so now I'll move "in" 50 ms). Or it might be that the bug makes it so the lens never gets properly reset to it's starting position.
"National Security is the chief cause of national insecurity." - Celine's First Law
Since we're talking about phone bugs, here's one I had to fight with for a while...
Lots of users are having problems with the GPS functionality on the iPhone 3G/3GS (see e.g. here). No apparent pattern there, but in Brazil, lots of users from one specific carrier were having GPS problems, and the beginning of these problems coincided with the start of Daylight Savings Time in Brazil. My iPhone, as well as my girlfriend's, are with this carrier and were experiencing the problem. Those with unlocked phones report trying other carriers' SIM cards and had GPS working again, but once you popped back the problematic carrier's SIM card, the GPS was dead again.
This nearly drove me nuts as I paid an obscene amount of money for the TomTom app and couldn't get it to work, so keeping up with the engineer spirit, I tried to debug the problem myself. I observed an interesting fact: there's a Clock app on the iPhone with a World Clock pane, and if I added a clock from any time zone, including my own, it was off by one hour. However the iPhone's main clock, shown on the top of the screen, was showing the right time. Eventually I discovered that if I restored my phone as a brand new phone (not restoring from backup) the GPS would work fine and world clocks would be fine... until you reboot the phone. After rebooting, the GPS is gone again and the world clock is off by one hour again.
Now you might ask what the time has to do with GPS. A lot, it turns out. GPS works by triangulating your distance from the satellites in the GPS constellation, which depends on knowing the exact position of the satellites. Since their orbits are corrected every so often, you must rely on so-called ephemeris data from each satellite, which is the required information to compute fairly exact orbits, and is updated fairly often (Wikipedia says GPS receivers should update ephemeris data every 4 hours). Originally this data is broadcast by the satellites themselves in their navigation message, at an awfully slow rate of 50 bits/s. You read it right, bits, not bytes or KB or MB, that's bits. As the navigation message is 1500 bits long, it takes at least 30 seconds to download it, which is about the time most standalone GPS receivers take to get a fix from a cold start (i.e. with stale ephemeris data). To work around this delay, most phones with GPS use the assisted-GPS variety, which downloads ephemeris data from a faster channel such as the cellular network. My theory is that some WTF-worthy excuse for an engineer at the carrier decided that, rather than doing time zone updates the right way, by updating configuration files to point to the new time zone, he'd just rather adjust the clock forward by one hour. The GPS chipset probably works with time zone neutral clocks so it asks for (say) UTC time and gets it off by one hour, and then computes the satellite orbits as though it were one hour later than it actually is. Obviously this means the triangulation computations go horribly wrong and rather than reporting something absurd, the chipset just pretends it couldn't get a fix.
It took a lot of complaining from a lot of people (to the carrier and to the government agencies responsible for telecommunications), but the carrier finally fixed the problem. However, it was a nightmare trying to deal with clueless customer support representatives who didn't try in the least to help (and probably were thinking all along `what does this wacko think GPS has to do with DST?'), just blindly suggesting that we restore the phone, or even try to uninstall the built-in Maps app, or blaming it on Apple and saying they weren't responsible -- and never mind that unlocked phones with SIM cards from other carriers worked fine, and that the iPhone support situation is unique in Brazil as Apple outsourced support to the carriers themselves. In the end, the customer support WTFs would be worth another post of its own, at least twice the size of this one.
But
Join the NFSNET. Our prime goal is making little numbers out of big ones. http://www.nfsnet.org/
Honestly, autofocus on the just-so-so camera is the last of my worries:
Really, fix the camera sometime down the line. But make the phone dial hands-free. Make email work. Make the navigation something other than worthless. Make "lock the screen" really lock the screen.
Someone at Google should use one of their own phones for a while and see how (s)he likes it.
It's a wonderfully powerful platform, but clearly not as well-thought-out or fluid to work as iPhone/iPod Touch
You kid, and I can appreciate the humor, but it was stated that way as a matter of journalistic integrity. Rather than claiming the the true Dan Morrill posted this (which they have no proof of) they stated what they did know: the person that posted this says he's Dan Morrill. That way if it turns out that Dan Morrill didn't actually post it, they've not put word into someone's mouth, as it were, and only need to release an update along the lines of "Bug discoverer really someone else".
It's sad that we've become so used to the modern media's 'report what you think happened and maybe correct yourself later if you're called on it' style that phrases like this are actually worthy of comment, humorous or otherwise....
I realize the post was made by a Google engineer, but, wouldn't a bug in "the camera driver's autofocus routine" be on Motorola's end, not Google's? I'm sure they were working together on it, but aren't drivers usually written by the hardware vendor?
Don't you wish your girlfriend was a geek like me?
Open Source had everything to do with finding the bug. Either you mistakenly believe that Android is a Google platform, or that paid employees don't work on Open Source software. If a Red Hat employee finds a bug in the Linux kernel, does it mean "Open Source had 0 (sic) to do with finding the bug"? Paid Google employees aren't finding bugs in Apples code, now are they?
It won't be available until December 11th! OMFG! (feigns disgust)
You mean they already have a roll-out plan in place, and they already informed you with details of that plan ???? You either don't know how software is developed (closed and/or FOSS), or you didn't eat your Wheaties this morning. If this was closed source you would neither know about the bug, or any roll-out plan, most likely because the bug would remain hidden or there would be no desire to share that information with you.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
(2^31) seconds = 68.0511039 years of uptime before the bug manifests? So this wasn't much of a problem for BSD?