Build a shutter tester for Focal Plane shutters - Cheap, Easy & it Works

[Flighter]

It depends on the receivers themselves and which wavelengths they are sensitive to.
You could wrap the sides with a bit of electrical tape to make a tube to see if it improves any.

Some of the Ebay listings seem to suggest that the sensors can be affected by bright lights and that they respong to a wide wavelength.

 

[Xylo]

With these things, better put every chance on your side.

 

[Niglyn]

I don't think so, I've been getting results that I don't really understand but haven't had time to investigate, camera was an OM1 set at 1/500 second.

The first set of results on your screenshot shows that laser 1 was stopped (blocked by the shutter on closing) before it was opened. This cannot be.

The other issue seen is laser 2 giving a start time of 0. You will get this once, every 70 minutes (time it takes for microsecond clock to wrap-around), so you have something going wrong here.

Waving a bit of paper in front of the sensors will give totally outrageous curtain speeds (as both lasers are going on and off about the same time) however a proper shutter, or piece of card with slot cut in it, moved across the sensors (should) work fine.

 

[Flighter]

After fiddling with the virtual model, I believe the results Flighter are seeing in the travel time are related to the sensors being reversed #1 for #2.

This could be due to how Flighter has the camera oriented in the device. Try flipping the camera around.

I was able to duplicate Flighter's display by reversing them.
So this is what I get when pin 3 is triggered first and pin 2 second. See below:

View attachment 333841

Thanks, I shall have a try tomorrow if I get the time.

 

[ic-racer]

I added some code to identify reversed shutter if you have the camera the wrong way in the device or the shutter goes the other way, but I suspect Niglyn can do somethng more clever:

 

[Flighter]

The first set of results on your screenshot shows that laser 1 was stopped (blocked by the shutter on closing) before it was opened. This cannot be.

The other issue seen is laser 2 giving a start time of 0. You will get this once, every 70 minutes (time it takes for microsecond clock to wrap-around), so you have something going wrong here.

Waving a bit of paper in front of the sensors will give totally outrageous curtain speeds (as both lasers are going on and off about the same time) however a proper shutter, or piece of card with slot cut in it, moved across the sensors (should) work fine.

Thanks, more to check tomorrow or when I get the time.

 

[Niglyn]

Hi,
Attached is a quick sketch to check functionality of the lasers. No output to LCD, just to serial monitor in Arduino IDE.
Change the .txt extension to .ino

Blocking the laser light to the rx sensor 1 will result in the screen saying 'Laser 1 blocked'
Allowing the laser to shine onto the rx sensor 1, will say 'Shutter seen'

Same for second laser/sensor.

This will allow you to check the lasers are functioning and wired correctly.
I know there was some chatter on another forum about the newer photo-transistors having their output reversed, so this could be an issue, so the attached code should prove.



From Flight's photo, it is taken from the operators viewpoint, so the camera must be facing forward, as if you were taking a photo. The lasers shine into the back of the camera, not into the lens.
Laser 2 is on the left. Laser 1 is on the right.

There will be overflow & maths errors if the lasers are not seen/blocked in the correct order, i.e by blocking with ones hand or a piece of paper, or using a camera with a vertical shutter (unless you rotate the camera of course).

The sensor is not very visible light sensitive, so should work ok in the average room, but strong light could mess with it.

 

[Flighter]

Thanks Niglyn, I'll hopefully have time tomorrow evening to give it a go.

 

[snusmumriken]

Brilliant of @ic-racer to divine and demonstrate the reversed sensor/reversed camera issue so quickly! Is there a particular reason for the camera to be positioned with its back to the lasers? Is it simply so you can see (on the shutter curtains) when the camera is correctly positioned, or is there some other reason?

I've used Arduinos successfully in my work, but am certainly no expert. As mentioned in post #125, @Flighter's problem brought to mind a hazard I was aware of, timer overflow (=wraparound=rollover). Basically, when the timer in the chip - which is counting the number of time intervals elapsed since start-up - reaches a very large number, it goes back to zero and starts again. So the program could find itself subtracting a very large number (the start time) from a very small number (the stop time). As @Niglyn says, overflow happens every 70 min or so, and since the shutter speeds are very brief compared with 70 min, you'd have to be very unlucky to be affected by it, and the false reading would be obvious straight away.

However, I had been thinking that once I've got this nice gadget up and running, I'd like to accumulate measurements from (say) 10 repeat tests, and calculate the average and range for each shutter speed. Those extra calculations would obviously be wrecked if one measurement was spoiled by an overflow error. Happily, there are several ways to avoid this being a problem.

I'm still waiting for my lasers to get here from China!

 

[Niglyn]

Is it simply so you can see (on the shutter curtains) when the camera is correctly positioned, or is there some other reason?

Yep exactly that. Also the Mk 3 or 4 version, if I can be bothered, will have additional sensors to detect flash sync. It will require another two at the extremes of the film gate & it will also give curtain bounce warnings, without having to reposition the sensors or camera.
It will be far easier to mount these sensors in a project box with holes drilled at 32mm and 36mm centres, which in turn will be placed directly onto the camera gate.

This is a simple shutter tester (that works) so if not used correctly, sensors reversed, or waggling paper in front of the sensors, then yes there will be wraparounds on the maths.

It is quite easy to deal with the microsecond wraparound & there are various ways, but for me, this is not an issue. Providing the maths subtracts & no addition calculation, then there is no error when the microsecond clock wraps around.

Again, easy enough to store a number of samples & display them. The screen could prompt you through the process. 'fire shutter' then 'fire for 2nd time' etc and then display the results as a block, average etc.

It maybe better to do a cumulative average, each firing gets added and mathed (is that a word?) so you can fire 1, 2, 5 or 10 etc and the maths recalculates each time. Add a push-button to start from zero again, when changing shutter speed for example.

However, for my needs, this offers no real advantage, but complication either having to fire 10 shots when I just want one, or pressing buttons to reset.

I have updated the code to detect crossed sensors & paper being waved in front of the sensors. Will add it to a post soon.

For playing about with, get a piece of card and cut a slot in it, 20mm wide, or so. You can then move this back and forth to simulate a shutter. I have one with a second smaller slot cut, which adds shutter bounce simulation.

 

[Niglyn]

Latest code attached. Change the file extension from .txt to .ino

Code has shutter bounce detect (move second laser to the edge of the gate, for best results when testing for this).

It has error checking for reversed sensors and when triggered by waving paper or hand in front of sensors.

Also added flash sync check. It is only valid for the space between the two lasers & I have no way of proving it actually works, other than pieces of card with different width slots cut in them, which seem to indicate that it does.
Would not advocate moving the sensors to 36mm centres to test shutter speed, but this would be needed to fully test flash sync,

There was some chatter on another forum about newer rx sensors having their output reversed.
(Rather than giving 'high' when it sees the laser. it now gives 'low')
The code can now easily be configured for either variant, by commenting or uncommenting two lines of code, that are located at the top.

Any other requests?

 

[Flighter]

Just done a quick pre-dinner test with the laser_text program and I'm guessing my sensors go low when they receive light as I was getting the laser 1 and laser 2 seen messages when my hand was in front of the lasers and the blocked messages when my hand was removed.

This makes sense as it explains why the first set of results on my screenshot was reporting laser 1 apparently stopped by the shutter closing before it was opened given that the program was expecting the sensors to go high on receiving light.

 

[Flighter]

I will have a try with the revised 2.9.6 code if I get the chance after dinner.

 

[Niglyn]

Just done a quick pre-dinner test with the laser_text program and I'm guessing my sensors go low when they receive light as I was getting the laser 1 and laser 2 seen messages when my hand was in front of the lasers and the blocked messages when my hand was removed.

This makes sense as it explains why the first set of results on my screenshot was reporting laser 1 apparently stopped by the shutter closing before it was opened given that the program was expecting the sensors to go high on receiving light.

Code is now easily changed. Will post a screen grab of what needs to be changed

 

[Niglyn]

This is how the code should look for original sensors

If you think the sensors are operating in reverse (some reports suggest the photo-transistor supplied with the rx board now works in reverse) then change the code by putting '//' in front of the first two lines of code above and removing the '//' from the bottom two lines,

so it looks like this:-

 

[Flighter]

Success, it was the new-fangled reversed sensors! Having amended the code as above it's now working as expected. Thanks for your help Niglyn and everyone.

Camera set to 1/500 so shutter running slow, slower speeds are much better.
More tests at 1/500 below. With the code matched to the sensors I've found that the alignment isn't as critical as I thought and room lights are not a problem.

Next job is to tidy up the wiring and fix the lasers and sensors with something better than blu-tack!

 

[ic-racer]

Nice to see you got it working!!

Just a comment on the spacing. I see you have 6ms which is about what one would expect with 20mm spacing for a vertical shutter.

However, the OM-1 has a horizontal shutter and the specifications for OM-1 are 12ms with 32mm spacing.

 

[Flighter]

Just a comment on the spacing. I see you have 6ms which is about what one would expect with 20mm spacing for a vertical shutter.

However, the OM-1 has a horizontal shutter and the specifications for OM-1 are 12ms with 32mm spacing.

Yes, I'm glad to have got it working.

Thanks for those details, I just measured and my spacing looks about 19mm. I've noted the 32mm spacing for the OM specs and will aim for that when I look to secure the lasers and sensors with a better method than blu-tack.

 

[Niglyn]

Build a (not quite so) simple shutter tester (that works)
Latest code attached. Change the .txt extension to .ino

You will need to add another library file to your Arduino IDE LibPrintf

This allows the output screen data to be better tabulated and laid out.

Any bugs or requests for additional functionality (except average over a number of shutter firings), let me know.

Also any ideas for other photography/Arduino based projects.

 

[Flighter]

Thanks Niglyn, I shall give it a go tomorrow.

 

[snusmumriken]

Getting there. Got my lasers now, still waiting for the LCD display. Currently nursing a smashed leg that I can’t stand on yet, so accessing my boxes of stored electronics stuff has been bloody awkward, and I haven’t figured quite how I’m going to cut pieces of wood. Everything is a challenge right now, but this project is frankly a welcome distraction since I can’t get out and take photos, or even use the darkroom.

 

[Niglyn]

Getting there. Got my lasers now, still waiting for the LCD display. Currently nursing a smashed leg that I can’t stand on yet, so accessing my boxes of stored electronics stuff has been bloody awkward, and I haven’t figured quite how I’m going to cut pieces of wood. Everything is a challenge right now, but this project is frankly a welcome distraction since I can’t get out and take photos, or even use the darkroom.

Sorry to hear about your leg. Hope it is repairable.
Rather than wood, you could use Lego, matchboxes, I even heard of somebody using blu-tack
I only used wood as it was a quick way to build a platform to hold the sensors & then never bothered to do anything else. Putting the into project boxes would probably be a good idea, mine are constantly getting knocked out of alignment.

The LCD is optional, so leg permitting, you could start tinkering.

 

[Flighter]

From bitter experience I would give blu-tack a miss, not one of my better ideas!

Hope you can get your leg sorted, sounds very frustrating.

 

[snusmumriken]

Sorry to hear about your leg. Hope it is repairable.
Rather than wood, you could use Lego, matchboxes, I even heard of somebody using blu-tack
I only used wood as it was a quick way to build a platform to hold the sensors & then never bothered to do anything else. Putting the into project boxes would probably be a good idea, mine are constantly getting knocked out of alignment.

The LCD is optional, so leg permitting, you could start tinkering.

Lego, brilliant solution! (Also very appropriate in the circumstances!) I was planning to box the gadget once I’ve got it working, so that’s perfect.

I’ll comment out the LCD display lines for now.

 

[Niglyn]

Averages are coming....Averages are coming......(sung to the coca cola Christmas ad )

Latest wiring diagram below. Can you spot the changes?

Only change is the addition of two push button switches to pins D11 & D12.
These buttons are optional. One resets the average count to zero.
The other is for future ideas, possibly to toggle the LCD to show current or average readings.

In lieu of a push-button, you can just use a jumper wire between D11 or D12 and 0V, just be careful not to touch it to anything else!