Droid camera fixes itself (for 24.5 days) | Hacker News Reader

Droid camera fixes itself (for 24.5 days)

engadget.com

94 pointsdminor17 comments

Open articleView on HN

TechCrunch was reporting that you just needed to "clean the lens" to get focus working...

http://www.techcrunch.com/2009/11/17/droid-autofocus-fix-now...

Yes, and if you bang on a drum the magic cargo planes arrive and drop food to you.

What is this a reference to?

Richard Feynman's 1974 Caltech Commencement speech: http://www.lhup.edu/~DSIMANEK/cargocul.htm

Try also "Cargo Cult" keywords in wikipedia and/or youtube. It should give you more drums ;)

Is there a date workaround yet? I don't have the phone, but it would be interesting to see if manually setting the date to a certain period fixes the autofocus until the update.

Edit: Answered my own question:

"Just changed the date back to 11/11 and got red boxes. Went back to 11/17 and got green boxes again. Could be something to it." - From the article comments.

Does anyone have the actual technical details of why this is?

My guess is that they're measuring time in milliseconds stored in a 32-bit signed integer and its overflowing to negative after 24.5 days (which is approx 2^31 milliseconds http://www.google.com/search?q=2^31+milliseconds+to+days )

Ya I've run into this before where we started an ms counter at 0 and after 24 days it would overflow.

Pain in the ass to catch....

A simple overflow would not matter though, unless you were taking a picture exactly when it overflows.

I bet it's a loss of accuracy when the timestamp gets large, and they start to do math on it.

That means right after the 24.5 day cycle it will be great, and will get worse and worse till the end of the cycle.

Personally I think that's the funniest bug ever.

it is related to 24.5 days = 2^31 milliseconds. however it's not an overflow, it's a bug with sign extension when casting from uint32 -> int32 -> int64 -> uint64, instead of directly uint32 -> uint64.

those operations are equivalent whenever the most significant bit of the uint32 is a 0, but orders of magnitude different when the most significant bit is a 1. so that explains why the bug turns off after 24.5 days and then turns back on after another 24.5 days.

if this doesn't make any sense to you, check out this wikipedia page: http://en.wikipedia.org/wiki/Sign_extension

the lesson is, be very careful when casting between signed and unsigned ints.

Why would an autofocus routine use a timestamp? Boggle me confused.

My guess is that autofocusing is based on input collected over a period of time, not instantaneous input.

Some implementations are (this one appears to be), but not all of them.

For instance, one simplistic way of focusing automatically maximizes the contrast in the area of interest.

Well, there are many options how to do autofocusing, but one of them involves sending out either ultrasonic or infrared wave and calculating the delay it takes to cover the distance to the subject.

Now lets just hope that someone with more knowledge about the implementation of this system can describe the problem more clearly...

I'd like to point out that if we assume that the infrared wave travels at the speed of light in empty space (I know it's somehow slower but good enough for the back of this virtual envelope) to a subject 1.5m from the camera and comes back, the total time would be 10.007 nanoseconds, so the timer should be accurate enough to measure fractions of nanoseconds to perform a correct autofocus.

So, I don't think that's how it works. Now, for the sound wave, maybe?

Mine doesn't seem fixed.

Reply on news.ycombinator.com