Confirming bug with shutter speed encoder in-between positions

[orcinus]

Advertisement (gone after registration)

A while back, a youtuber (forgot who) reported an issue where setting the shutter speed dial between steps (by accident) makes the actual shutter speed fall back to some other, seemingly random value. It was discounted as not-reproducible by most people in the thread.

I've managed to reproduce it on my sample just fine and can report it happens only between *some* speeds, not all of them.
Likely a matter of specific tolerances and/or switch noise, and likely variable from camera to camera.

Here's a video:

 

TL;DW summary - Yes, the problem exists, yes, it might not be present or equally present in all samples, yes, like the debounce issue fixed by latest firmware, it should be fixable in software and is a very rookie hardware UI design mistake. And no, it's not a problem in real life / use, but should be fixed nevertheless considering the status and price of the camera.

[jaapv]

Ummm... I have had many cameras over the years that were incorrect when the shutterspeed was set "between the clicks" I would call this user error, not a bug.

[elmars]

I can confirm this. Dial very carefully in LV mode between two steps and then You can see the change of shutter speed. Always 1/3000 sec. If I release the shutter the photo is taken with 1/3000 sec.

[SrMi]

I can confirm this as well, though I need to be in LV to find the exact location where the shutter speed jumps up.

[mrmalo]

1 hour ago, SrMi said:

I can confirm this as well, though I need to be in LV to find the exact location where the shutter speed jumps up.

Same here.

[orcinus]

4 hours ago, jaapv said:

Ummm... I have had many cameras over the years that were incorrect when the shutterspeed was set "between the clicks" I would call this user error, not a bug.

So is leaving the door on a car open while the car is not in park - yet cars will prevent you from doing this.
This does not justify leaving a gaping hole in the UI for the user to exploit and make an error.

It's simple defensive programming.

Same issue could occur due to, e.g., oxidised contacts or crud in the optical path (if the encoder is optical).
It's good engineering practice to avoid potential sources of spurious input.

And i disagree, i had about every brand of camera under the sun - none of them did this, including Leica's own M240.

Edited February 28, 2022 by orcinus

[orcinus]

Advertisement (gone after registration)

3 hours ago, SrMi said:

I can confirm this as well, though I need to be in LV to find the exact location where the shutter speed jumps up.

Yeah, the readout in the viewfinder lags a bit, making it much harder to find it.

[jaapv]

1 hour ago, orcinus said:

So is leaving the door on a car open while the car is not in park - yet cars will prevent you from doing this.

Huh?? None of my cars have grabbed me and yanked me back to close the door...

[orcinus]

16 hours ago, jaapv said:

Huh?? None of my cars have grabbed me and yanked me back to close the door...

Mine will complain, loudly, and put the car in park.

Another lesson in engineering: don't try to control what you can't control (the user).
Control what you can - the equipment  

[digitalfx]

23 hours ago, orcinus said:

Mine will complain, loudly, and put the car in park.

Another lesson in engineering: don't try to control what you can't control (the user).
Control what you can - the equipment  

That is strictly due to safety laws and/or lawsuit protection by the manufactures though.  

[orcinus]

8 hours ago, digitalfx said:

That is strictly due to safety laws and/or lawsuit protection by the manufactures though.  

Not terribly relevant.

Encoder output filtering is an established practice, just like button debounce.
No amount of gaslighting changes that.