Author Topic: Arduino shutter tester (Read 16921 times)

cs1 · « **on:** March 18, 2018, 04:59:30 PM »

Thread for the shutter tester I built using an Arduino, IR module and LCD (https://github.com/c-s-1/shutter-tester).

François, you wrote in another thread about different types of modules and their reaction times. Unfortunately, the module I used came without any specs. However, I think that the IR emitter of the module should start emitting IR as soon as the module is powered. Since I still have a few of those modules left I could try to write a test routine to find out how much delay one has to expect from the IR detecting diode by using a second module that I let the Arduino power on and off and by using its IR emitter.

Francois · « **Reply #1 on:** March 18, 2018, 07:34:18 PM »

If you have the sensor's number, you can always check it out on the newark.com website.

For some reason, I still think the slit would be a good idea. I remember years ago I took apart an old 8" floppy drive and there was such a gizmo in it. It was used to calculating the registration hole position for timing the rotation speed of the disk.

Francois · « **Reply #2 on:** March 20, 2018, 01:10:03 PM »

Don't you just love it when an idea wakes you up at 2:20 in the morning?
Well, here is a snippet from my nightly notes.
You don't really need to test the speeds higher than flash sync.
Flash sync is the fastest curtain displacement speed the camera can produce. After that, higher speeds are obtained by reducing the width that's open between the first and second curtain. So if you know by how much the shutter lags at the flash sync and calculate the difference in percentage, you should be able to apply this factor to all the upper speeds and get an accurate prediction of their real value.

cs1 · « **Reply #3 on:** March 20, 2018, 04:12:52 PM »

Incredibly inspiring stuff that you come up with when other people sleep.

I've created a new branch for the software release v0.2. Do you think that it'd be useful to have a way to select a reference speed (e. g. "1/30s") for a test and have the tester display the factor of how much the actual speed diverts from the reference speed? I was also thinking about displaying the median and the standard deviation which would give a good idea about how reproducible shutter speeds are.

Pete_R · « **Reply #4 on:** March 20, 2018, 04:33:36 PM »

Quote from: Francois on March 20, 2018, 01:10:03 PM

Don't you just love it when an idea wakes you up at 2:20 in the morning?
Well, here is a snippet from my nightly notes.
You don't really need to test the speeds higher than flash sync.
Flash sync is the fastest curtain displacement speed the camera can produce. After that, higher speeds are obtained by reducing the width that's open between the first and second curtain. So if you know by how much the shutter lags at the flash sync and calculate the difference in percentage, you should be able to apply this factor to all the upper speeds and get an accurate prediction of their real value.

But, especially in mechanical shutters, different mechanisms come into play at different speeds and there may be no correlation at all between what happens at flash sync speed and at higher speeds. Here's an example:

The flash sync speed is 1/250 which is designed to run a bit slow to ensure proper sync. I don't see how you could predict that some of the higher speeds are running fast and some slow (too slow).

Pete_R · « **Reply #5 on:** March 20, 2018, 04:39:14 PM »

Quote from: cs1 on March 20, 2018, 04:12:52 PM

I was also thinking about displaying the median and the standard deviation which would give a good idea about how reproducible shutter speeds are.

True, except most people don't understand median and standard deviation. I think showing maximum and minimum, like in my example above, is probably better.

A feature I would find useful is being able to export the values, either in real time or later, to a PC for processing.

cs1 · « **Reply #6 on:** March 20, 2018, 07:10:57 PM »

Good point. The Arduino is rather dumb in terms of output but I could let it print the current, minimum and maximum speed as CSV values on the serial line so that you can easily import them to a spreadsheet.

Francois · « **Reply #7 on:** March 20, 2018, 08:25:59 PM »

The flash sync speed is the fastest shutter speed that leaves the entire frame open. When you take a picture at higher than that speed with a flash, it still works but you're missing a part of the frame.

When we reach the higher speeds, the variation comes more from the second curtain's adjustment than the sliding speed.
Unless some camera has a specific second spring to increase the maximum speed, it should be pretty much the same.

One of the best cameras I find to understand this is strangely the Fed 5B. With it, you really can feel what's going on.

cs1 · « **Reply #8 on:** March 20, 2018, 09:11:05 PM »

I just pushed a new release of the software. It now shows the average exposure, cleans up the LCD output a little and prints CSV lines to the serial line so that you can basically cut'n'paste them somewhere for further evaluation.

Pete_R · « **Reply #9 on:** March 20, 2018, 09:27:18 PM »

Quote from: Francois on March 20, 2018, 08:25:59 PM

When we reach the higher speeds, the variation comes more from the second curtain's adjustment than the sliding speed.
Unless some camera has a specific second spring to increase the maximum speed, it should be pretty much the same.

Still not sure where you are coming from with this Francois but I'm all ears.

Some shutters do have an extra spring for the highest speed but that wasn't what I was getting at, and anyway, I'm only aware of leaf shutters that work like that. All the speeds are timed somehow - the time between the release of the first and second curtains. But this timing can be done by different mechanisms for different groups of speeds. So I'm not sure how you can calculate the highest speeds based on a measured lower one. I'm obviously missing the point here.

Francois · « **Reply #10 on:** March 20, 2018, 10:13:34 PM »

For the lower ones, there is an escapement mechanism that does the timing between the release of the first and second.
But on the more primitive cameras like on the fed (and Leicas), the higher speeds are set by a pin that locks in a spool. Depending on the position of the pin, there is a different gap between the first and second curtain. But in all cases the speed of the cloth remains the same from start of the frame to its end.

On other cameras, they can use a different mechanism but at its base, it does the same thing. That's also why motor drives have a top speed slower than what we expect. I for a long time couldn't figure out why my camera at 1/1000th could still take only 3 frames/s... it all boils down to travel speed.

Vertical shutters while having a higher "full open" speed still have this limitation. The curtain can only travel so fast.

Pete_R · « **Reply #11 on:** March 21, 2018, 06:51:29 AM »

OK, think I understand. But that's not the case for all shutters. If the shutter has a mechanically set width to the gap between the curtains I can see your idea works. But none of the shutters I'm familiar with work like that. The gap is produced by a timed delay between the release of the first and second curtains and that delay may be created by a number of unrelated mechanisms.

Francois · « **Reply #12 on:** March 21, 2018, 02:13:19 PM »

When I woke up last night at midnight, I figured out how to check it out for sure.
The best way would be to record the sounds the camera makes using a contact microphone and check the waveform using an audio program.
Since the mirror always takes a set amount of time to go up and down for a specific camera, the stuff in between those moments should be the shutter itself.
By using, let's say a piezo disk attached to the camera, it should be possible to record the vibrations that travel through the metal in a very accurate way using a sound card cranked up to its fastest speed. That should clearly indicate if there is any variation in the travel speed.

And if we want to push this even further, putting a piece of photo paper in the silk compartment and pointing a flash directly at it should record the slit width. From that it should be possible to calculate the shutter speed.... It's just a harder way to do it

cs1 · « **Reply #13 on:** March 21, 2018, 06:32:51 PM »

I might be mistaken but my understanding is that no matter how the shutter works, it should always expose punctual at the speed that it's set to. Since the IR emitter of the tester is the only IR source that triggers the IR sensor above the threshold and since both work punctual, the measured times should be reasonably accurate for most purposes.

I'll try to further stabilise the code and I'll also try to add a calibration routine to compensate for possible delays in the sensor module's circuitry. If you're looking for a project to kill time until spring, maybe you can build a tester and let me know how it works for the shutters that you have at hand.

Feel free to open issues on github if you find bugs (which you very likely will

).

Francois · « **Reply #14 on:** March 21, 2018, 08:09:06 PM »

Not much of a programmer but I'll give it a try as soon as I get a bit of spare money to build one.
I'll see if I can't improve on the whole thing...

cs1 · « **Reply #15 on:** March 22, 2018, 06:54:42 PM »

For everyone who's interested, here's a quick list of components and prices: Arduino Uno R3 ~8 €, LCD (2004, I2C) ~4 €, IR module ~1 €, push buttons + wires ~2 €. If you add a case and some additional parts you can build it for under 25 €.

Francois · « **Reply #16 on:** March 22, 2018, 08:26:05 PM »

And even cheaper if you scavenge parts.
I read on Make that a plastic soap box works marvels for arduino projects.
So does using a hollowed-out piece of 2x4 lumber...

Francois · « **Reply #17 on:** April 02, 2018, 10:57:20 PM »

I just ordered some cheap components from China, so it might take a while before I get to start building one.
If the Arduino clone I got works, I should be able to get the cost down to less than 10$.

In the meantime, I'm waiting for some very small phototransistors that are coming from Toronto. I'm thinking about embedding one at the bottom of a tunnel to filter out any angular light that might hit the sensor. This should give me increased precision.

So now all I can do is wait...

Here's a list of components I'm getting:
-UNO R3 ATmega328P CH340 Mini USB Board for Compatible-Arduino IB (5.53$CAD)
-LCD 1602 Keypad Shield For Arduino Due Duemilanove UNO R3 PANTALLA AZUL BUTTONS (3.64$CAD)
-40Pcs Dupont Wire Jumper Cables 10cm Male To Female 1P-1P For Arduino (1.05$CAD)
-1 Vishay BPW17N - Phototransistor, 825 nm, 12 °, 100 mW, 2 Pins, T-3/4 (1.8mm) (0.285$CAD)

I know I will have to rewrite some of the code to deal with the two line display but it should be quite easy. The screen comes as s shield with buttons so it should be just plug & play as I suck at soldering.

JoeV · « **Reply #18 on:** April 03, 2018, 03:54:00 AM »

The audio method of measuring shutter speed is rather popular, it doesn’t work with leaf shutters and some curtain shutters like Speed Graphics.

Francois · « **Reply #19 on:** April 03, 2018, 02:22:33 PM »

You mean the one where the sensor is plugged in the sound card or the Indofunk certified method of listening to the shutter to hear if it's on the beat?

cs1 · « **Reply #20 on:** April 03, 2018, 06:56:31 PM »

Quote from: Francois on April 02, 2018, 10:57:20 PM

I just ordered some cheap components from China, so it might take a while before I get to start building one.
If the Arduino clone I got works, I should be able to get the cost down to less than 10$.

I'm pretty sure it'll work. Sometimes you need to install an additional serial driver because the Chinese Arduino Unos sometimes use different chipsets but that's no show stopper.

Quote from: Francois on April 02, 2018, 10:57:20 PM

In the meantime, I'm waiting for some very small phototransistors that are coming from Toronto. I'm thinking about embedding one at the bottom of a tunnel to filter out any angular light that might hit the sensor. This should give me increased precision.

I'm curious whether it'll really make a difference.

Quote from: Francois on April 02, 2018, 10:57:20 PM

I know I will have to rewrite some of the code to deal with the two line display but it should be quite easy. The screen comes as s shield with buttons so it should be just plug & play as I suck at soldering.

I'm currently cooking up a new release (you can look at the dev branch on github, it already has a few changes to accommodate for difference I2C chipseds). I have a 1602 display so I could try to make the code work on it as well. However, all my LCDs come with an in situ I2C module and the 1602 doesn't have a I2C module so I need to figure out how to work around it. Or I'll simply try to implement a 1602 display without testing it and you let me know if it works.

It shouldn't be that different, I just need to figure out a layout that'll display all the needed info on a smaller display.

Francois · « **Reply #21 on:** April 03, 2018, 09:13:46 PM »

For the driver problem, I can also hook it up to my venerable Linux box. That should fix all the problems. I just hope I won't get one that's missing the bootstrap... That would mean I'd need to get a real Arduino and use it to copy the bootloader to the cheap one.

My theory behind my choice of sensors is that by putting at the end of a tube, I reduce the angle of sight of the sensor, a bit like looking through the end of a roll of paper towels. I know my sensor has a 12° angle of view. That's pretty wide unless I use a laser as my light source (I think that's what Peter did with the tester he bought from Russia). But by making it see maybe ½°, that should increase the precision... there's no reason I can think of that would not make it so. But contrary to using a slit aperture, it doesn't reduce the amount of light that hits the transistor.

As for coding for the LCD, I'll have to see what I get in the end. I know the part looks good but the question is always "will it work?"
I don't know which pins they are using to drive it. All I know is that they were nice enough to offer a passthrough connection for the pins it doesn't use.

cs1 · « **Reply #22 on:** April 04, 2018, 05:20:44 AM »

I think that I'm slowly but surely getting your idea with the view angle of the sensor. I'm going to try it myself and let you know if it helps.

Regarding getting the code to run: I'd be happy to give you a hand if you like. We could do a Teamviewer session if code needs to be changed. Please feel free to let me know if you need help.

Francois · « **Reply #23 on:** April 12, 2018, 03:20:15 PM »

Quote from: PeterR on March 21, 2018, 06:51:29 AM

OK, think I understand. But that's not the case for all shutters. If the shutter has a mechanically set width to the gap between the curtains I can see your idea works. But none of the shutters I'm familiar with work like that. The gap is produced by a timed delay between the release of the first and second curtains and that delay may be created by a number of unrelated mechanisms.

Yesterday while I was having a s%*! Day with Windows (had to restore a backup because it decided it didn't want to start) , so I went through my camera shelf looking and listening to various cameras.

Now I must humbly say you were right. So I'm sorry for arguing and doubting.

I've summer it up in roughly four categories.
Horizontal shutter with mechanical timing: both curtains most likely linked together.
Horizontal shutter with electronic timing: independent curtains with magnetic releases.
Vertical shutter with mechanical timing: could be both linked or not, but most likely not linked.
Vertical shutter with electronic timing: not linked and controlled by electromagnets.

So there it is.... We do need high speed measurements.

cs1 · « **Reply #24 on:** April 12, 2018, 03:23:30 PM »

I'll try to implement 1602 LCD output to support your venture. I hope to get around to implement it until next weekend.

Francois · « **Reply #25 on:** April 12, 2018, 08:20:47 PM »

You don't have to. I'll get around to do it when I get the parts

Francois · « **Reply #26 on:** June 18, 2018, 06:39:04 PM »

I'm feeling a bit like Marvin Martian right now!
"Ohh! Finally! At last! Here is my PU-35 Explosive Space Modulator!"... but in my case it's my LCD-1602 keypad shield.

This looks like it's going to turn this project into somewhat of a re-write since this screen doesn't use the regular LCD library from Arduino. Instead it uses the more exotic LCD4Bit_mod library...

Now I guess I'll have to learn to actually program this thing..... at least I got the test script working.

cs1 · « **Reply #27 on:** June 18, 2018, 07:20:31 PM »

This reminds me that I need to merge the changes I made to support other I2C addresses into the current master branch on github. I haven't had time to work on the project for quite some time now.

Francois · « **Reply #28 on:** June 20, 2018, 06:28:15 PM »

OK, I managed to switch from the badly designed 4Bit library to the better built-in LiquidCrystal Library.

cs1 · « **Reply #29 on:** June 20, 2018, 07:02:06 PM »

Well done! I've merged the latest revision of the software. If you need any assistance, please feel free to let me know.

Francois · « **Reply #30 on:** June 20, 2018, 11:01:59 PM »

Any big changes apart from what's on the changelog?

I'm going to take a look at it. I know I have to remove everything that has to do with turning off the screen since mine can't be turned off.
Also, I remove all the parts related to the IR Illuminator since my sensor is for visible light.

I also optimize things as I go. Like when you send the lcd.clear(); command, the cursor automatically goes to the 0,0 position, so no need to use the lcd.setCursor(0,0); command.

I have a few things to deal with since I'm using a 16x2 screen. I think I might print the minimum and maximum shutter speeds only for a few seconds after the reset command is sent.

I also am wondering about the weird routine you put in where you move the cursor to specific regions to write the information after the labels instead of re-writing the whole screen... why? It would be easier to just send a few lcd.print(); commands and re-write everything...

Anyways, right now I'm at the point where I need to figure out the case and solder some wires to the LCD shield. For the box, I'm using a 50¢ travel soap box from the dollar store (they're the cheapest thing to put electronics in... and the arduino fits in width-wise just like a glove. I'm using a 1/8" audio jack for the sensor. I took the stereo version in case I want to put two sensors to see if there is a big change between the start and the end of the shutter travel (though I'm going to get things working with just one for now). Everything will be powered by a USB phone charger. That way I don't need to worry about this.

Anyways...

cs1 · « **Reply #31 on:** June 21, 2018, 05:27:29 AM »

No, the changelog is pretty much complete.

There's no code that's specific to IR. The exact same code works with a visible light sensor. No need to change anything. Code only needs to be changed if you want to use a sensor with an analogue output instead of a digital output (the latter is the one that the code is for; you can set thresholds / sensitivity using a potentiometer on the sensor itself; since this only has to be done once, it's more convenient than using an analogue sensor and it's quicker due to the interrupt code).

Good point regarding lcd.clear(). I'll check if going to (0,0) is default on all screens.

Regarding moving the cursor: it's much quicker if you move the cursor and only overwrite parts and re-use stuff that's already on the screen. If you don't, you get a very noticeable flicker on most LCDs. I don't like the flicker, so I optimised the code to overwrite only variable parts of the displayed text.

Francois · « **Reply #32 on:** June 21, 2018, 02:30:42 PM »

That's a good reason. But I still might change it on mine to make things simpler.
I grew up learning to program on a commodore 64 so I tend to optimize differently depending on whether speed or size is an issue at various points in the program.

I'm going to try the latest version and see what I will need to change.

cs1 · « **Reply #33 on:** June 21, 2018, 04:16:33 PM »

Your idea with cycling the display after each test is good. It optimises the way you can display things on a smaller LCD.

Francois · « **Reply #34 on:** June 21, 2018, 09:13:32 PM »

Yeah. There might be a speed issue on larger LCD's but on a 16x2, it's not that bad.
I can see a speed problem if I ask it to scroll some text, but I wonder if it's not more of a problem with the processor or the serial communication line's baud rate than anything I can fix.
I did look at my screen closely and I can see what annoys you. Mine does a type of fade out-fade in while writing the screen.

Right now, I'm working on a new case (I broke the other one while working on it). This time, I opted for a tried and tested material: wood

Francois · « **Reply #35 on:** June 29, 2018, 01:31:35 PM »

Finally got it working!

I didn't know you can only assign an interrupt to pins 2 & 3...
Is it just me or does the thing need an awful lot of light to work?

cs1 · « **Reply #36 on:** June 29, 2018, 07:06:35 PM »

Good job, François!

Yes, on an Arduino Uno pins 2 & 3 can be assigned an interrupt. Since an interrupt based detection only takes ~1-2 CPU cycles, it's more precise than querying an analogue sensor in the event loop. Regarding your question concerning light sensitivity: most light sensor modules (no matter if IR or visible light) that output a digital signal have a potentiometer which you can adjust using a screwdriver. There's also normally an LED on the module which lights up when the digital signal is triggered. Using that LED you adjust the potentiometer to the threshold which triggers the digital signal. You need to find the best threshold so that it isn't triggered by the ambient light but only needs a certain amount of light (torch etc.) to be triggered.

Francois · « **Reply #37 on:** June 29, 2018, 09:06:03 PM »

I'm just using a standalone phototransistor (a KID7404) and a 10K pullup resistor hooked to ground.
The way mine is made, I had to add a 10K pullup to the reset switch too as it just didn't work any other way. It could be because I'm using all the cheapest Made in China components I could get...

The rat's nest of wires is a testament to my struggles with the project. And I still have wires that I wonder why the heck I kept them!

cs1 · « **Reply #38 on:** June 29, 2018, 09:08:19 PM »

Wow, great job! It looks fantastic. The wooden case gives it a lot of class.

Francois · « **Reply #39 on:** June 29, 2018, 09:30:23 PM »

Thanks... but it's just a case from the Dollar store I adapted and decorated using collage.
The hardest thing was fitting the USB cable through the box. Lets just say that making a square hole for the plug wasn't the easiest thing to do!
But the nice thing is that the sensor fits completely inside the box when I unplug it.

I'm thinking about getting a high powered LED and fitting it on some sort of cap to facilitate the exposure... or something like that.

I must say I really like the code you wrote. It works surprisingly well. I did change things a bit mostly to fit my display (which doesn't work with the I2C library BTW) and change the pins for the button (which when pressed turns the pin high). I also reverted to using microseconds for the calculations. I figured that if I'm going to find a way to trigger it at 1/1000 and up, I'll need that precision...
But right now, anything faster than 1/250 is out of range even when I use a massive LED projector flashlight.

What bugs me the most right now is that I just can't get it to work when the light goes through a lens... $:-\$

cs1 · « **Reply #40 on:** June 29, 2018, 09:43:00 PM »

I think that it might actually be worth investing 1,50 € into a digital light sensor because it really is easier to calibrate and you can use your mobile phone's LED light (if applicable) as a simple light source.

Regarding the precision: same as you I found that it works really well down to 1/250s. I don't actually know why it isn't more precise at faster speeds. 1/500s is already a gamble. I don't think that it's a limitation of the Arduino Uno. It runs @ 16 MHz which means that a CPU cycle is about 62.5 nanoseconds long. If you use interrupt driven measurements, this should give us plenty of precision. I tend to think that the sensors are the weak link but that's just a wild guess. A guy that I know who knows a lot about microcontrollers forked the project and proposed a driver that he has written which runs at a very high precision. I haven't had a chance to discuss his driver with him but I think that I'm going to check it out to see whether this helps with shorter speeds than 1/250s.

Francois · « **Reply #41 on:** June 29, 2018, 10:21:17 PM »

Do you think that would do
https://www.ebay.ca/itm/LM393-Optical-Photosensitive-light-sensor-module-for-Arduino-Shield-DC-3-5V-GM/262136733649?hash=item3d08911fd1:g:VVcAAOSwSeVaQHv7

cs1 · « **Reply #42 on:** June 29, 2018, 10:51:33 PM »

PM'ed you.

Francois · « **Reply #43 on:** June 29, 2018, 11:01:56 PM »

Thanks!
I just ordered one... will be a while before it gets here but I can wait.
It will be better that's for sure. The one I had found was a photo resistor while this one is a photo transistor. And crazier thing is they don't cost much more than a single transistor.

As for the speed, it will surely be faster than my setup. I have about two feet of wire to do the loop around on mine. Voltage must decrease too much to get a decent reading.
This one uses a Texas Instruments LM393 which is a voltage comparator. That means that the decision on whether the sensor is high or low is taken locally before being sent to the Arduino. That means added sensitivity and a more reliable signal... fantastic.

Francois · « **Reply #44 on:** October 10, 2018, 04:32:15 PM »

I thought it would never get here!
I finally got the light sensor for this thing!

cs1 · « **Reply #45 on:** October 10, 2018, 06:09:34 PM »

Cool! Looking forward to seeing the result when you put everything together. I also need to finally assemble my tester. Haven't come around to doing it yet. It still sits here in its breadboard setup.

Jeff Warden · « **Reply #46 on:** October 10, 2018, 06:53:34 PM »

You guys are on another level. My hat's off.

:-)

Francois · « **Reply #47 on:** October 10, 2018, 09:20:27 PM »

And with this new sensor, it should be much more sensitive.

cs1 · « **Reply #48 on:** October 11, 2018, 07:45:08 PM »

Quote from: Jeff Warden on October 10, 2018, 06:53:34 PM

You guys are on another level. My hat's off.

Just in terms of nerdiness.

I can do Arduino stuff but I'm still pretty useless when it comes to more serious camera repairs. That's why I like this forum: experienced people share their knowledge about camera maintenance and if the "nerd level" helps to contribute stuff back (like a shutter tester), I'm glad.

Quote from: Francois on October 10, 2018, 09:20:27 PM

And with this new sensor, it should be much more sensitive.

Please make sure to share your final design (a sketch of the setup would be great). I'm very curious about your mileage. I'm still trying to figure out why everything faster than 1/500s seems to be hard to measure.

Francois · « **Reply #49 on:** October 11, 2018, 08:46:25 PM »

The only reason I can see is that the size of the light sensor comes into play...

Maybe making a rig to shoot a laser directly on the sensor would increase precision?

But right now, I'm concentrating on making a new sensor housing for this one. Thing is it's not exactly compact in size...
Also, it uses 3 pins for the detection instead of only 2, so I'll have to get me some wire for it... and re-wire my entire setup to take advantage of it.