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

[VirtualFeature]

Hi Virtual,
Thanks for adding your comments & thoughts to the thread. All are most welcome.
Taking A, B & C as Right, Middle & Left sensors,

Point A would always be 0ms, as that is when the tester sees the first change and starts measuring.
Time between A and B is shown as first curtain travel first half.
Time between B and C is shown as first curtain second half.

This is then repeated for second curtain.
The total travel time A to C is shown as curtain travel speed.

Exposure at A, B and C is shown, as well as deviation from centre (as a 'professional' tester would)
and also the tester guess what speed the camera has been set at and shows deviation from this nominal speed.
Currently it guesses separately at A B and C, so could guess different exposures, but I may change this, so it only guesses for B.

I don't know if people find all of the data shown on the tft, useful or if they just look at the larger summery at the bottom?
The details could be removed and replaced with something different.

So all the data is there, if you have an idea for displaying it differently, draw a sketch & I can implement it
Something like the below?


A-----12mS------B--------8mS-------C

1/30 1/26 1/38

A-----18mS-----B---------14mS------C

I see, very interesting. I'm rather new to this, and it's all somewhat theory to me rather than practical at this point. I've thought more about it and once I finally get my tester working, I might experiment with the code myself.

The data for point-to-point transit time is all there as you said, but I think there could be specifically some use in interpreting the data.

If I am not mistaken, shutter curtains should always travel with the same acceleration, regardless of shutter speed selection, correct? For instance, the first curtain will always take the same time to travel from A-B, B-C at 1 second vs 1/500th - the difference is in the width of the spacing between the curtains, which is how you determine shutter speed.

I think the information that is interesting to me is how "correct" the shutter curtain movement itself is, not how close to the correct setting spacing it is. For instance, you can tension the first curtain too much, and the second too little, and some shutter speeds will be accurate! With "linear interpretation" you'd never know, but being able to interpret the data in terms of acceleration instead would be very useful. You may be left scratching your head as to why the slow shutter speeds are ok, but the fast ones are running 1-2 stops out of spec. This information would tell you the movement of the curtain is the culprit.

If we know the exact distance between sensors (which we should/do), and the time it takes for the curtain to travel between points, we can determine acceleration and therefore a new, useful metric.

Displaying the data would make sense in this sort of format, I think:

Ctn1
A-----12mS------B--------8mS-------C
Accel: 3m/s^2 Result: FAST
Expected: 2.4m/s^2

Ctn2
A-----18mS-----B---------14mS------C
Accel: 2.4m/s^2 Result: NORMAL
Expected: 2.4m/s^2

Clearly these are fudged values and not actual calculations, but i think it gets my point across.

Obviously this is starting to get a bit hairy if people haven't got their sensors exactly positioned right - because the math falls apart, but the rest of the shutter speed testing will be inaccurate anyway if it's not correctly spaced, so...

 

[Niglyn]

Hi Virtual,
People think making a shutter tester is easy. The interweb is full of ideas (that don't work). As I found, the theory is simple, until the penny drops that one is trying to measure a point light source of photon width, with a sensor which is wider than a photon.

We add to this, the understanding of how a focal plane shutter mech actually works and the ingenuity of engineers and how they design the mech to overcome inherent issues.

If we take a cloth horizontal shutter and a flash sync of 1/30 second.......

At 1/30s the first curtain fully opens then the mech, which is indexed to first curtain travel, will trip second curtain release.

Notice on the shutter speed dial, how the legend spacing between each shutter speed halves? (cue sound of another penny dropping )

At 1/60s, the first curtain opens half way, then the mech, which is indexed to first curtain travel, will trip second curtain release.

This of course happens all the way to max shutter speed. As first curtain travel is indexed to second curtain release, this ratio always halves each time the shutter speed is increased. Nothing can change this. (some cameras have separate escapement for slow speeds)

So as you correctly understand, it is the width of the slit & the speed it is moving, which determines exposure

The speed of the two curtains are not indexed, so they can travel, accelerate, decelerate or get stuck.

The point above is very important. Many DIYers will blindly start increasing tensions on the curtain springs as the camera is under-exposing or blinds not fully traversing the gate. All this does is over-stress the shutter mech, leading to catastrophic failure. A teeny tweak maybe ok, but any more, means that the shutter mech requires a full disassembly to remove all the old grease, which becomes hard & sticky, as well as the old oil & contaminants, dust, grit etc, that gets caught in the mech and blind travel tracks. Just adding new oil is also a very bad idea.

Camera service manuals will normally specify curtain travel speed in mS. This is the first figure to set the curtain speeds to. Assuming the mech is all clean and lubed correctly as per the service manual, this should give the best overall accuracy.

Tbh, as this is the measurement used to set a blind speed, I cannot see any use for calculating acceleration
If the service manual says 18mS travel time and yours is 11mS, it is accelerating too fast.

The blind will accelerate from zero, up to whatever speed the spring allows. The curtain could keep accelerating until the drum reaches end of travel and stops it dead (better cameras have a brake) or the spring run outs of puff and starts slowing down before reaching end of travel.

As the blinds have to start from zero when entering the film gate, they speed up, thus exposure will always be greater at start of travel. (Assuming both blinds running the same speed)

If the blinds slow down towards end of travel, this will give a shorter exposure in the middle.

As the blinds (or ribbon) is wound onto the rollers, the diameter increases, meaning more and more curtain is pulled across with each increasing revolution, thus increasing blind speed.

What does all of this mean? Well firstly, there is no such thing as 'shutter speed' and secondly exposure is really very inaccurate )
Look further up the thread and you will see the ISO standards for exposure and how wide the tolerance is.

Trying to get an old vertical plane shutter to be spot-on accurate will drive you crazy & will never happen. Some cameras are easier to play with than others. Zenit, for example are a right pig, you need a special tool (not available, had to make my own) to hold the blind tension whilst one release the locknut, to then adjust the tension. Then there is a grub screw to lock the locknut!

Others have a cam, which makes things easier when learning how to adjust 'shutter speed'.

Even when getting a camera very close. Wait to the weather changes & the grease changes viscosity )

 

[VirtualFeature]

wow, thanks for the detailed reply! I learned a lot and thank you for taking the time to make this great tool.

 

[Niglyn]

I happened upon this today.
Clever idea to use bellows to hold lasers & sensors in alignment.

GitHub - stuart-brown/ArduinoShutterSpeedTester: Platform IO Arduino project for a film camera shutter speed tester

Platform IO Arduino project for a film camera shutter speed tester - stuart-brown/ArduinoShutterSpeedTester

github.com

 

[ic-racer]

His shutter speed tester, calibrator looks interesting too:

GitHub - stuart-brown/ShutterSpeedTesterCalibrator: Simple code that flashes Laser LED for 100ms, once a second, for calibrating and testing Shutter Speed Tester

Simple code that flashes Laser LED for 100ms, once a second, for calibrating and testing Shutter Speed Tester - stuart-brown/ShutterSpeedTesterCalibrator

github.com

 

[ic-racer]

I just saw post #468 asking about using a diffuse light source, instead of the lasers.

As with all of the mechanical aspects of any tester, testing is important. I found that the distance of the sensors from the light source affected the results.

Of course a big advantage of the lasers is that they should not show this effect.

So, in my case, the camera body is always set about 250mm from the light source to get the correct reading. I could only discover this by empric testing (though Srozum does mention this in the instructions for his tester).

Anyway, canaq, if you built it that way, please share you results !

 

[ic-racer]

Since we are sharing ideas for the mechanical aspects of the testers, I'll present the little laser gantry I made. I used a simple box and a marking device form Home Depot.

Of course the wiring will be dependent on which shutter tester software it will mate with.

 

[Niglyn]

I just saw post #468 asking about using a diffuse light source, instead of the lasers.

As with all of the mechanical aspects of any tester, testing is important. I found that the distance of the sensors from the light source affected the results.

Of course a big advantage of the lasers is that they should not show this effect.

So, in my case, the camera body is always set about 250mm from the light source to get the correct reading. I could only discover this by empric testing (though Srozum does mention this in the instructions for his tester).

Anyway, canaq, if you built it that way, please share you results !

View attachment 377885 View attachment 377886

The further away, the faster the shutter,
or the further away, more time required for the light to travel (which would make it slower, but as it is the speed of light, I cannot see that a fe cm would make any difference)'
My guess would be diffraction at closer distance, so sensors are seeing light for longer.

 

[ic-racer]

The further away, the faster the shutter,
or the further away, more time required for the light to travel (which would make it slower, but as it is the speed of light, I cannot see that a fe cm would make any difference)'
My guess would be diffraction at closer distance, so sensors are seeing light for longer.

Depending on how deeply set in to little holes the sensors reside, they are a distance behind the shutter (ds in diagram) and this affects the reading. As the whole assembly (sensor and shutter) moves farther back from the diffuse screen, it receives rays that are straighter (more like laser light). With changed response. In my case the reading gets closer to how the creator programmed the firmware. Otherwise, one could adjust calibration in the software for an optimum response at a given distance from the screen (or to function with, say a 50mm lens in place).

Image from ISO 516 Shutter Speed Testing:

 

[ic-racer]

Of note, a GitHub member contributed a re-design of the original 3-way sensor, with his/her own STL files, to allow for a more precise alignment of the sensor's lens and the little holes in the face of the module. Those files could be of value for anyone not wanting to use lasers. https://github.com/srozum/film_camera_tester/discussions/47

Using a laser as a light source, I believe, minimizes the need for such detailed construction of the sensor.

Image from User-462 on GitHub:

 

[Niglyn]

@ic-racer

Hi, is there any way to contact User-462 directly?

Would like to see if I can use a slightly modified version of his stl files and add them to my github,

but I don't want to get embroiled in a thread for a different tester.

Thanks.

Image from User-462 on GitHub:


View attachment 378050

 

[ic-racer]

The modified sensor STL files were posted as attachments in the thread on GitHub as Zip files. You can just download them.

See the link below to the post "STL files here..."

Universal Sensor Case and Other Modifications · srozum film_camera_tester · Discussion #47

As I worked on the sensor assembly, I realized that the sensor construction is fairly critical for good testing results. One way to ensure reliable construction is to reduce the amount of hand craf...

github.com

 

[ic-racer]

Just to point out that sorzum's film camer tester is offered up to be downloaded and built by people like you, Nyglin, that can actually write code for it. Us C+ illiterates have to use his firmware.

 

[Niglyn]

The modified sensor STL files were posted as attachments in the thread on GitHub as Zip files. You can just download them.

See the link below to the post "STL files here..."

Universal Sensor Case and Other Modifications · srozum film_camera_tester · Discussion #47

As I worked on the sensor assembly, I realized that the sensor construction is fairly critical for good testing results. One way to ensure reliable construction is to reduce the amount of hand craf...

github.com

Hi, yes I know the stl files are available for download, but it is only polite to ask if I can take them to add to my project. I also would like a minor change, which user-462 maybe happy to do.

For reasons I do not wish to go into, I do not want to hijack or get involved with this other tester project.

 

[Niglyn]

Just to point out that sorzum's film camera tester is offered up to be downloaded and built by people like you, Nyglin, that can actually write code for it. Us C+ illiterates have to use his firmware.



View attachment 378144

Hi, yes this project is open source and one could easily take the enclosure design and add my electronics/firmware instead.

Whilst I have C++ knowledge & also CAD/CAM, I have no access to a 3d printer, so what would be really great would be a co-lab with someone who could make the printed parts.

I love the enclosure design I posted in #479 however the firmware is limited. So to make something like this for my tester would be great.
Would be simple to build two versions, one for lasers and using a sensor-back for the camera and LED light source.

 

[ic-racer]

Ok, I see.

I was really happy with my 3d pieces from JLC3DP. In fact I have another project I'm planning on having them do the printing.
I do have multiples of the PC boards, happy to send you some.

 

[VirtualFeature]

Not sure if this is intended or not, but I have just finished the most basic of builds for the shutter speed tester - with a standalone small-version film plane tester, with the battery operated video light source recommended in the parts list.

On the ESP32 3.0.9.0 firmware, it seems to operate as intended when checking to see if the sensors notice the light source (Sensor 1 Seen, Sensor 1 Blocked, etc).

However on 3.1.0.2, checking this setup mode functionality spits out continuous errors about flickering light source, unless I position it just right. I don't have another PWM style light source to test with, only DC LED or regular AC light sources. My LED lamp on my desk doesn't seem to cause the log to send out hundreds of warnings.

Just thought I'd mention it in case something has been changed in between versions that is making it overly sensitive. Could just be my setup though, but again I have no way to test.

The portable light is of course at 100% power output so in theory it should be not causing flickering. It's just strange the errors only start flooding on 3.1.0.2. Thanks!

 

[Niglyn]

Not sure if this is intended or not, but I have just finished the most basic of builds for the shutter speed tester - with a standalone small-version film plane tester, with the battery operated video light source recommended in the parts list.

On the ESP32 3.0.9.0 firmware, it seems to operate as intended when checking to see if the sensors notice the light source (Sensor 1 Seen, Sensor 1 Blocked, etc).

However on 3.1.0.2, checking this setup mode functionality spits out continuous errors about flickering light source, unless I position it just right. I don't have another PWM style light source to test with, only DC LED or regular AC light sources. My LED lamp on my desk doesn't seem to cause the log to send out hundreds of warnings.

Just thought I'd mention it in case something has been changed in between versions that is making it overly sensitive. Could just be my setup though, but again I have no way to test.

The portable light is of course at 100% power output so in theory it should be not causing flickering. It's just strange the errors only start flooding on 3.1.0.2. Thanks!

Hi, it is great that you have built the tester.
Sorry you are having problems with the LED light. In fact these documents have recently been updated to exclude LED lighting, because as you have found, they are very problematic.

.....................................................

The tester is primarily designed to work with low power lasers. They are ideal as they give a narrow collimated light source and are cheap.

PWM light sources are really bad for things like shutter testers. The rapid on/off of the LEDs causes havoc with the readings.

I purchased the little LED light source and it worked ok for me. Both the colour and brightness wheels have to be turned fully up.

However, I have been communicating privately with another user who was having lots of problems with the same light source, even when turned fully up, is getting flicker warnings.

The alignment screen was not originally intended to detect flicker. The seen/not seen was for laser alignment only and toggles relatively slowly.

Due to the LED problems of another user, the alignment screen in 3.1.0.2 firmware now has very fast LED flicker detection & warning coding, as you
are now seeing.

Moving on.....

Due to the problems with LED lights, I have recently updated the film-gate documents and removed the link to the LED light and given a general description of LED requirements, leaving it up to the builder if they want to experiment with LED lights.

The shutter tester build has always been designed to be simple to build, using off-the-shelf parts and without requiring PCBs or 3d printed parts.
I do not want to move away from this. Builders of course can adapt the hardware as they see fit and add 3d printed parts, like cases, sensor holders etc.

I am experimenting myself with LED light sources. For best results they need a long reflective housing, to even out the light and a good diffuser. Think of a metal Pringles tube. There is significant heat generated, so cooling is required and the components housed in a safe non-combustible enclosure.
But as said above, this is going well above the design concept of the tester.

 

[VirtualFeature]

Finished putting the rest of my tester together, and it's working wonderfully overall, thank you so much for dedicating so much time and effort to this.

With the correct settings on the back of the portable LED unit, I have resolved the flicker complaint, however I am running into an issue similar to ic-racer from a few pages back. My results are offset by factors of a millisecond or less depending on the light-source proximity.

At slower speeds, it's less of an issue but at 1/1000th my results are wavering between 1/700th and 1/1800th on multiple cameras.

The diffused LED box originally recommended seems to be working fine. The only issue i can think of is misaligned rx units or wider than intended bores for the film plane tester face.

Tomorrow I'm going to mess around with something a previous user mentioned of using black tape and making literal pinholes in it as a mask for the rx box, but if you have any insight for any other reasons as to why the readings would get so out of whack at fast speeds I'd love to hear the theories.

I have noticed so that offsetting the light source parallel to the camera by a few centimeters either side will massively affect readings. 1/1000 reading S1 1/2600, SM 1/800, S2 1/970. Leads me to believe my sensor guide holes could be less that perpendicular but who knows. Only testing will tell i guess!

 

[VirtualFeature]

Well, to report back, I did some testing with some new light sources, and checked everything top to bottom.

Using the sun (nature's LED) i was getting very consistent, reasonable readings until I shifted the film plane tester - having the pilot holes for the rx units even partially obscured by the film gate was giving me bizarre readings (diffraction?) - so the moral of that story is to use bulb mode to ensure a very, very good placement of the sensors and peek all the way through, even if it looks right.

The second was that having the LED light source too far away from the camera, or too close, caused bizarre readings. Minimum of 5cm from the lens plate, and maximum of 15cm provided consistent, replicatable readings when combine with good sensor placement.

The third was that the black-button setup did not always complain about flicker. It would if it was particularly bad, but when hooking up the unit to my PC and using a serial monitor, i could see it logging dozens of flickers per second that the TFT screen wasn't reporting. I think they may have been refreshing too fast for the TFT to catch. If that's the case, maybe a buffer value for the flicker detection would be a good idea.... having the variable that sets the flicker text on the TFT have a sleep before being cleared. If that's what's causing it. This made me think about the LED unit and I found that the end-stops for the dials on the LED diffused light were a bit conservative. Rotating the dials to their max positions didn't fix it, but giving them a bit of an extra-firm turn suddenly resolved all the flickering complaints entirely. I believe that the flicker was causing some of the more extreme readings.

With all these combined, my tester seems correctly calibrated and operating properly! It has also shown me my OM1 as a bit of a funny 1/1000th...it slows down part way through its travel, about a third of a stop. The rest are dead on!

 

[Niglyn]

Well, to report back, I did some testing with some new light sources, and checked everything top to bottom.

Using the sun (nature's LED) i was getting very consistent, reasonable readings until I shifted the film plane tester - having the pilot holes for the rx units even partially obscured by the film gate was giving me bizarre readings (diffraction?) - so the moral of that story is to use bulb mode to ensure a very, very good placement of the sensors and peek all the way through, even if it looks right.

The second was that having the LED light source too far away from the camera, or too close, caused bizarre readings. Minimum of 5cm from the lens plate, and maximum of 15cm provided consistent, replicatable readings when combine with good sensor placement.

The third was that the black-button setup did not always complain about flicker. It would if it was particularly bad, but when hooking up the unit to my PC and using a serial monitor, i could see it logging dozens of flickers per second that the TFT screen wasn't reporting. I think they may have been refreshing too fast for the TFT to catch. If that's the case, maybe a buffer value for the flicker detection would be a good idea.... having the variable that sets the flicker text on the TFT have a sleep before being cleared. If that's what's causing it. This made me think about the LED unit and I found that the end-stops for the dials on the LED diffused light were a bit conservative. Rotating the dials to their max positions didn't fix it, but giving them a bit of an extra-firm turn suddenly resolved all the flickering complaints entirely. I believe that the flicker was causing some of the more extreme readings.

With all these combined, my tester seems correctly calibrated and operating properly! It has also shown me my OM1 as a bit of a funny 1/1000th...it slows down part way through its travel, about a third of a stop. The rest are dead on!

Hi,
The little LED light has multiple LEDs. Turn the brightness down as much as you can and you will see them.

When turned up to the max, the light is too bright for our eyes to see the individual LEDs, but not so for the shutter tester. So if the light is not sufficiently diffused, different sensors will see differing light levels.

It is also noticeable how dimmer the edges of the LED diffuser screen are, so by moving the LED light sideways, there is an imbalance of the luminance level.

The light sensors respond to luminance. The more light, the quicker they will switch on. IC's chart demonstrates quite nicely the inverse square law.

Lasers are really the best light source. They offer a very bright focused collimated beam, that bangs the senor on or off very quickly.
Alignment is the issue with lasers. The best way is having two separate stands, one for horizontal and another for vertical shutters. This way, the lasers can be in a line & not diagonal. only one plane then has to be exact, the other can be off by either 30 or 20mm.

The latest firmware now detects flicker in the alignment screen, before it just checked if the sensor was seen or not seen periodically, far too slow to see flicker. The tester was never really designed for LED lights, so flicker was never a problem.

Adding code to dismiss rapidly flickering lights would be possible, but could adversely affect accuracy, as extra code would be required in the measuring loop.
The measuring engine has been written to be fast. It does not do any computations, but simply records the input register at each change and a microsecond clock timestamp. Only when the sequence is complete, does the code then compute the values. Up to twelve separate readings are taken within the shutter cycle.

Thanks for updating us with your use of the tester & LED lights. & I'm glad it it is all now working for you.

I currently have a big bag of LED lights, lenses & drivers to play with, to see how feasible it is to make a cheap LED light that works, for a shutter tester )

 

[VirtualFeature]

Depending on how deeply set in to little holes the sensors reside, they are a distance behind the shutter (ds in diagram) and this affects the reading. As the whole assembly (sensor and shutter) moves farther back from the diffuse screen, it receives rays that are straighter (more like laser light). With changed response. In my case the reading gets closer to how the creator programmed the firmware. Otherwise, one could adjust calibration in the software for an optimum response at a given distance from the screen (or to function with, say a 50mm lens in place).

Image from ISO 516 Shutter Speed Testing:

View attachment 378048

I'm going to be doing some experimentation with the LED light sources over the coming weeks to see what I can do - and how to keep any adjustments to improve the outcome at low cost.

The first thing I want to try is a mutli-stage bore for the lens of the receiver unit. Having a 0.5mm bore all the way through to the receiving unit's lens, then boring out a small section to be 1mm, so the lens can fit snugly, should (roughly) halve the potential for angled light as the width of the bore will be half as wide. Whilst I don't expect that it will have that dramatic an impact on the final results as per the formula, I would like to see just how much it rectifies the issue.

The second is to find a cheap accessible Fresnel lens, and some way to align/house it near the mounting plate of the camera to focus the incoming light.

I could just give up and make a laser based system, but the flexibility of a focal plane tester is too appealing!

 

[Niglyn]

I'm going to be doing some experimentation with the LED light sources over the coming weeks to see what I can do - and how to keep any adjustments to improve the outcome at low cost.

The first thing I want to try is a mutli-stage bore for the lens of the receiver unit. Having a 0.5mm bore all the way through to the receiving unit's lens, then boring out a small section to be 1mm, so the lens can fit snugly, should (roughly) halve the potential for angled light as the width of the bore will be half as wide. Whilst I don't expect that it will have that dramatic an impact on the final results as per the formula, I would like to see just how much it rectifies the issue.

The second is to find a cheap accessible Fresnel lens, and some way to align/house it near the mounting plate of the camera to focus the incoming light.

I could just give up and make a laser based system, but the flexibility of a focal plane tester is too appealing!

Hi, I have ordered a LED heat sink, with LED COB mounting, and a 120 and 60 degree lens.
Then current drive the LED COB, no PWM, to ensure no flickering. This should do the trick.
The driver I have is constant current out, but is controlled by PWM, so the shutter tester will be able to turn the light on & off and control the brightness.

Unfortunately, rather than sending these three parts, they sent me three strings of LEDS, so I'm having to go through the refunds & then re-order. (

A suitable housing is required, which will be non-combustible and diffuse the light sufficiently. Then cleverly, a longer dark tube which should collimate the light somewhat.

Cheap plastic fresnel lenses are available, however, I'm not sure how well these would work, as they give one focussed beam. Would be good if teenyy frenel lenses could be found, one for each sensor.

Lasers really do work the best & 3d printing a housing for them and the sensors, I think is the best option & have two separate mounts for horizontal & vertical shutters.

 

[OAPOli]

I've wired up the components for the LCD/4 buttons version of the tester.

Unfortunately I can't flash the code onto the board as per instructions.

Tried googling the issue without success.

 

[VirtualFeature]

I've wired up the components for the LCD/4 buttons version of the tester.

Unfortunately I can't flash the code onto the board as per instructions.

View attachment 379376

Tried googling the issue without success.

Most important thing to do is follow this guide (https://github.com/billbill100/Came...rks/blob/main/ESP32/6_ESP32 Firmware load.pdf) to ensure you are using the correct COM port, the driver is installed, etc. If you've followed it and it's still not working, I got tripped up by the USB cable itself. I spent a few hours going in circles (and this was my job once upon a time!). Some USB-C cables are power-only cables, no data pins at all. Obviously if this was the case though, you would not see it in your Device Manager.

What is happening here is that the computer is not communicating properly with the device. The output there is for a "Test Run" rather than any communication to the ESP32, and it's failing to connect to and/or write to the board at all. It's sort of like, "IF i was going to write to the board, would these files fit?" and that's as far as it gets.

Ensure the device is in Device Manager, get the right COM port, ensure the driver is installed, and if that fails try another machine if you can.