Filmwasters
Which Board? => Main Forum => Topic started by: 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.
-
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.
-
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.
-
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.
-
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:
(https://i.imgur.com/5tF9lLU.jpg)
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).
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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
-
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 ;) ).
-
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...
-
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 €.
-
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...
-
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.
-
The audio method of measuring shutter speed is rather popular, it doesn’t work with leaf shutters and some curtain shutters like Speed Graphics.
-
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? :)
-
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.
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.
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.
-
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.
-
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.
-
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.
-
I'll try to implement 1602 LCD output to support your venture. I hope to get around to implement it until next weekend.
-
You don't have to. I'll get around to do it when I get the parts :)
-
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.
-
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.
-
OK, I managed to switch from the badly designed 4Bit library to the better built-in LiquidCrystal Library.
-
Well done! I've merged the latest revision of the software. If you need any assistance, please feel free to let me know.
-
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...
-
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.
-
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.
-
Your idea with cycling the display after each test is good. It optimises the way you can display things on a smaller LCD.
-
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 ;D
-
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?
-
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.
-
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!
-
Wow, great job! It looks fantastic. The wooden case gives it a lot of class. :)
-
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... :-\
-
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.
-
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 (https://www.ebay.ca/itm/LM393-Optical-Photosensitive-light-sensor-module-for-Arduino-Shield-DC-3-5V-GM/262136733649?hash=item3d08911fd1:g:VVcAAOSwSeVaQHv7)
-
PM'ed you.
-
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.
-
I thought it would never get here!
I finally got the light sensor for this thing!
-
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.
-
You guys are on another level. My hat's off.
:-)
-
And with this new sensor, it should be much more sensitive.
-
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. :)
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.
-
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.
-
I guess that you could improve results by measuring through a focused lens. But I haven't tried that yet. And in my case (I'm using IR diodes) I would need to adjust focus for IR. When I get around to putting the whole contraption into a case, I'll have a closer look at these options.
BTW: Have you seen the photoplug: http://www.photoplug.de/ (http://www.photoplug.de/) ? It works together with the "Shutter Speed" app. The app is originally based on checking the shutter speed by sound (which probably isn't that precise) but it also works with the photoplug (an optical sensor which is attached to a smartphone's microphone jack) which should improve the precision. In any case, it looks like an interesting option,
-
Yeah, the old sound card trick... I heard that it has quite a variable level of precision...
-
Yes, but the Photoplug, though it's plugged into the mic input, actually is a photo sensor that simply uses the mic input as an interface to get the data into the smartphone. So you actually use a strong light on one side of the shutter and the Photoplug on the other end, plugged into the smartphone which uses the Shutter Speed app. This way they basically do the same as we do with our Arduinos.
-
I know...
Using a phototransistor to capture the voltage variation using an audio program is the base of a lot of the older ways of getting shutter speeds.
But even older than that was capturing the image from an old CRT television and counting the number of lines recorded on the film. And for the slower speeds, it was actually photographing a rotating vinyl record on which you put a white mark. Measure the angle of the mark on the film and you can find the speed...
-
I use a photo tachometer to test the shutter on my movie cameras. I put a test roll in the camera, take the lens off and point the tachometer at the shutter. That gives me an RPM that I convert to Frames per second. It works great, I mostly shoot at 18 FPS so I just adjust the speed and leave it there. I also use it to check the speed of my turntables. I put a few pieces of foil on the platter and get a direct reading from it.
Francois, I'm going to try that turntable method you mentioned, it sounds so simple. First I'll make sure the table is accurate with my photo tachometer. I would think setting the turntable to 78 rpm would give me more accurate results. I'll just put a note card next to the turntable with the shutter speed I'm using.
-
That's about it. The only thing is I don't remember the formula that is used to convert to shutter speed.
All I know is that it works up to about 1/30.
-
Yesterday I spent a few hours rewiring the tester and fixing the old sensor so that it works again with the new setup.
Now I have to wire the new sensor and make a dark housing for it, I don't want light to hit the sensor from behind...
-
You got digital light sensors now, right (the three pin version with a variable resistor on the little circuit board)? If so, then you don't need to worry about the housing or scattered light. You can simply adjust the threshold of the sensor so high using the variable resistor so that it will only detect a direct light source. I've never had a problem with incident light even with a sensor for visible light.
-
Mine's a 4 pin sensor with the potentiometer. It's got Analog/Digital/GND/+5VDC.
I'll just use the Digital output....
-
I'll just use the Digital output....
That's a good idea. This way you can use the potentiometer to adjust the sensor's threshold and you can use interrupt based detection on the Arduino.
-
On your sensor, do you block light that comes from behind?
I was thinking about this last night and it might be part of the high shutter speed test failures.
Thing is that at speeds over 1/500 there isn't much light hitting the sensor. You might be hitting the lower threshold of the component. And having even the slightest bit of light entering the back might be a problem.
-
I use an IR diode and sensor and can lower the threshold quite considerably but I still have the same issues at speeds faster than 1/500s. I guess that incident light or too little light isn't the issue. Also, in my understanding dialing in a higher threshold shouldn't influence the speed of the detection, just the amount of energy that is needed to trigger the detection. But that's just a guess. I lack the skills to pinpoint the exact reason for the imprecise measurements at higher speeds, so this is all guessing, to be honest.
-
Don't forget that ambient light does contain IR rays... that's why we have High Speed Infrared film :)
On those sensor chips, I believe they have an amplifier and a comparator. So the potentiometer should be the gain of the amp part of the circuit.
When the gain gets to be too high, you just increase the noise on the system making reading unreliable.
I was looking at the sensor on mine and it looks a lot like an LED used in reverse. When not powered, LEDs produce a very weak amount of electricity when light is shining on them. It's a trick used in many toys that have a motion detector. I believe it may be the same thing here.
-
I made a new cable for the new sensor and tried it like that just to see if it works. And boy is the new sensor sensitive!
I'll have to make a good holder for it, it's way too sensitive to use handheld!
-
Worked all afternoon on a housing for the sensor. Didn't turn out as I had expected but it should be fine.
I'll have to test it out tonight...
-
I ran some tests last night and I think I have figured out why I keep getting strange values from the sensor.
It turns out that the whole circuit seems to have a lot of lag once it's been triggered. Even with an adjustment of the trim pot it still outputs strangeness. I'm hoping it's related to the small led on the board. If that's the case just adding some baffling will fix it. If not, it's going to be back to the original sensor.
-
OK, I just found the problem!
The issue was that while the phototransistor I was using sets the detection pin to HIGH when it detects light, the new sensor board actually sets it to LOW in the same conditions. The strange values I was getting were the actual time between shutter activations.
Now, I'm at the point where I need to improve the high speed detections...
-
Yes, you're completely right. That's the way most sensors with digital outputs work. Sorry for not mentioning it, it simply didn't occur to me that this was causing your problem because my code on Github is already designed for digital sensors and I completely forgot that your first design used a diode.
-
I've begun modifying the code a bit to make it more universal. So far I haven't tested it but it should work.
I made a boolean called sensorboard. In the setup phase, I check if the pin is high or low. I know that if it's high, it's a sensor board and if it's low it's a phototransistor. Then in the interrupt section, I use a more complex logic statement
if (sensorboard == true && digitalRead(interruptPin) == LOW || sensorboard == false && digitalRead(interruptPin) == HIGH)
That should make it work no matter what is plugged-in at system start.
Also, last night I was playing with some tape and figured out how to make the sensor detect faster speeds!
It all depends on the type of shutter that is measured as they all require a different technique.
For central shutters, the best deal is just to use the sensor as-is.
For focal plane shutters, you need a slit aperture that is 90° to the direction of travel.
I tried using a pinhole but then I run into the problem of not having enough light entering the sensor...
So I'm thinking of adding a set of removable sensor masks that would be held possibly with magnets on the front of the sensor... but I'll have to put the magnets on the top to avoid creating eddy currents in the shutter, something that could definitely slow it down.
-
That sounds very cool. Especially the explanation how to up the precision. Would you be willing to submit a patch to my original code on Github to include the enhancement that you made? Or would you mind if I worked your modification into the code?
-
Also, last night I was playing with some tape and figured out how to make the sensor detect faster speeds!
It all depends on the type of shutter that is measured as they all require a different technique.
For central shutters, the best deal is just to use the sensor as-is.
For focal plane shutters, you need a slit aperture that is 90° to the direction of travel.
I tried using a pinhole but then I run into the problem of not having enough light entering the sensor...
We sort of had this conversation a few years back here http://www.filmwasters.com/forum/index.php?topic=8323.msg111096#msg111096 (http://www.filmwasters.com/forum/index.php?topic=8323.msg111096#msg111096)
I use a pinhole and a laser which gives plenty of light.
-
A laser would be ideal, but then I'd need to make a special rig to endure everything is perfectly aligned...
Then again, it's probably easier in a sense. But it does take more space than my current setup...
-
Hey Peter,
I was wondering if you use the laser to test cameras with fixed lenses?
And when you test SLR's, do you leave the lens attached?
-
Hey Peter,
I was wondering if you use the laser to test cameras with fixed lenses?
And when you test SLR's, do you leave the lens attached?
That'll be no to both questions.
Long time since I did anything with fixed lens cameras and no reason to leave the lens on with an SLR.
-
Good to know.
That means that when I get to a future iteration of the project, I'll have to take a few things into consideration.
When I get enough space in my cupboards, I'll have to make some sort of mounting jig to keep everything aligned...
I also have to future proof this thing... I know that white light works wonders with a central shutter. If I ever have to test something old just to get the proper shutter time, I want it to be easy.
-
If I ever have to test something old just to get the proper shutter time, I want it to be easy.
I'm not so sure it can be easy, especially the faster speeds.
Between lens (or leaf) shutters open like an iris, starting in the middle of the lens then opening out to the edge of the lens. Once fully open and after a delay, the blades start to close with the centre of the lens being the last part to be covered. The time taken for the blades to travel from fully closed to fully open and from fully open to fully closed is finite and, at fast shutter speeds, can represent a significant part of the exposure time. So the question is, at what point do we measure the shutter speed from and to?
What we need is a measurement that would give us the same degree of exposure if the shutter was perfect with instantaneous opening and closing. So, ignoring things like acceleration and assuming a constant rate of opening and closing of the shutter, we would need to measure the time between when the shutter is 50% open and 50% closed.
(https://i.imgur.com/BooBEvj.jpg)
In the diagram, the solid line is a theoretical representation of the light measured at the film plane as the shutter opens and closes. The light ramps up as the shutter opens, stays at 100% for a set time, then ramps back down to 0% as the shutter closes. The total exposure is the integration of the area under this line. The green dotted line represents the time measured between the 50% open and 50% closed points. If a perfect shutter were to open for this amount of time (red dotted line) the total exposure would be the same as that of the real shutter.
Now this is all hunky-dory, assuming we can find a way of measuring the shutter speed at the 50% open points, until we introduce apertures. If we assume the above refers to a shutter with the aperture set to maximum, then when the aperture is closed down the light reaching the film plane stops ramping up at the point the shutter opening equals the aperture opening. To measure a meaningful shutter speed now, we need to lower the points at which we start and stop the measurement to 50% of the new maximum.
(https://i.imgur.com/xdGqq1g.jpg)
So this means our point of measurement needs to be variable and linked to the size of the aperture used. Not quite so simple. I think the only way would be to record, or store, the output from the sensor then retrospectively measure the minimum and maximum values, calculate the 50% points then measure between them.
There is another factor to consider and that is the effective shutter speed varies with aperture - in the diagrams above, the green line is longer in the second example than the first but the shutter speed selected is the same. So what aperture should we be measuring the shutter speed at? There probably isn't an answer to that but what we perhaps should be doing is measuring at several apertures to see what the variation is. A shutter which opens very quickly will have less variation than one that opens more slowly. This can also be expressed as the shutter efficiency (a measure of the total light passed by a shutter during an exposure, compared with the light that could be passed by a perfect, infinitely fast, shutter fully open for the same extreme time). A worst case would be a shutter at its top speed with the aperture set to maximum where the efficiency could be as low as 50% equating to 1 stop under exposure. Something the user probably needs to know about.
An alternative view...
It's arguable that shutter speed is mostly unimportant, unless you are doing something scientific where a precise shutter speed is required. For general photography, if a shutter is 50% out, it probably won't make much difference to the end result except in exposure and so maybe it's exposure, not shutter speed, we should be measuring.
It would need a method of integrating the output from a light sensor placed at the film plane and a method of calibrating the system to the light source, which could, I guess, be done by gating the output from the sensor for a fixed period while holding the shutter open. Once calibrated it would be possible to measure the amount of under or over exposure for each shutter speed setting which, ultimately, is what matters (who really needs to know their 1/125th shutter speed is actually 1/135th?). It would also work with all types of shutter.
As it happens, for a long time now, I've been expressing shutter speed test results in terms of under and over exposure. It seems more useful to me and people seem to understand it.
Discuss...
-
I do get where you're going with that. The best way to get a very precise shutter speed measurement with a central shutter would be to make multiple samples at different apertures, average those by aperture and then average the apertures together.
When you look at the shutter's motion, it tends to produce a type of half bell shaped exposure. There is a period of acceleration at the start of each motion, followed by a fairly constant speed and a sudden stop. Then it's back the other way. I know the acceleration is not linear since there is some friction in the system. The only way I know of making very precise measurements would be using a high speed video camera to record the motion. But somehow I think this would be overkill.
And exposure wise, I believe in the close enough principle. If I were to try and calculate the real exposure in a super precise way, I would first need to start with a T/stop measurement of the lens. F/stops are just a mathematical representation, not tested in the real world. Then I'd need to factor in the focus distance since it makes the lens to film distance change. It might not be big but I read that on some lenses it can be surprisingly significative. And then there is the shutter speed...
And once you factor all this and input it in a sort of calculator, the decisive moment is definitely gone, has taken a plane and landed in Timbuktu. ;)
But on the up side, since the shutter is located at the same place as the aperture, it just changes the way the light comes in in a similar fashion.
The good thing for us is that film has a lot of sensitivity latitude. So those minute variations are not much of a problem.
The other good thing is that central shutters don't go to very high speeds. I know Kodak made one that went to a supposed 1/1000... but the fastest one I have climbs maybe to 1/500. And that's if I'm lucky. So finding the speed at which I need to set my exposure meter isn't much of a problem.
And leaf shutters are even slower... I now know that my Diana F+ has an average shutter speed of 1/84th :) doesn't change much when compared to the suggested 1/60 but in a way it makes me feel geekier 8)
I was just thinking... if you use your laser checker, do you get the same values close to the edge of the barrel and through the sensor when measuring a central shutter with the aperture wide open? I'll have to see with mine...
-
And exposure wise, I believe in the close enough principle. If I were to try and calculate the real exposure in a super precise way, I would first need to start with a T/stop measurement ......
......the decisive moment is definitely gone, has taken a plane and landed in Timbuktu.
I think you miss the point. I'm suggesting measuring the actual exposure given by the shutter in lab conditions as an alternate way of checking shutter speed accuracy. If the shutter is slow you get over exposure. If it's fast you get under exposure. If it's correct you get the expected exposure. And you don't have to worry about the problems of accurately measuring the the time the shutter is open for or the variations due to the way leaf shutters open and close.
I was just thinking... if you use your laser checker, do you get the same values close to the edge of the barrel and through the sensor when measuring a central shutter with the aperture wide open? I'll have to see with mine...
You mean do I get a different values if I measure at the centre and the edge? Yes, absolutely. That's one of the main problems of measuring a leaf shutter. That's like (referring back to my diagrams) measuring the duration at the top and bottom of the curves. Clearly it will be different. If you're using a non-focused light then the position isn't likely to have much effect but it then comes down to at what light level the sensor triggers. At a low level it's the same as measuring at the bottom of the curve and at a high level it's the same as measuring at the top of the curve. So adjusting the sensitivity of the sensor will give you different results.
-
You're right, it would be possible to measure shutter speed by using the amount of light that is transmitted.
Once the real lens transmission on B is calculated, it should be fairly easy to calculate....
I need to think of a way to make a measuring device that would work........
It could actually be more precise than using a regular tester that relies on what is basically a laser trap..... but by how much, I really have no idea.
-
I'm wondering how to hack this plus of precision into an affordable Arduino shutter tester. I'm wondering if using two different sensors connected to interrupt lines would work. For example you could place one where the diagonals of the image plane's edges (36x24mm) intersect and one right at one of the corners. You could then look at the times that the sensors registers a change in light exposure and use the time differences for calculations. On the other hand it could well be that I completely miss the point of this discussion. ;)
Anyhow, one thing that I need to patch into the shutter tester's software is what Peter mentions about the times on the speed dial not being the *exact* times but just an approximation. I think it'd be helpful to tell the user that 1/30s on the dial is actually 1/31.25s.
-
Anyhow, one thing that I need to patch into the shutter tester's software is what Peter mentions about the times on the speed dial not being the *exact* times but just an approximation. I think it'd be helpful to tell the user that 1/30s on the dial is actually 1/31.25s.
Sorry, I'm obviously not good at explaining myself. I was actually suggesting the complete opposite. A user really isn't interested (usually) in the precise speed of their shutter. All they are really interested in is the accuracy. So giving the result as a + or - exposure error is more practical and useful. Here's an example of how I present shutter speed test results.
(https://i.imgur.com/4D6Xflx.jpg)
The upper and lower limits are taken from the camera service manual and are there so the camera owner can immediately see whether the shutter is within specification or not. The numbers are errors as fractions of a stop exposure (EVs).
What I'm suggesting is, given that the results are probably more meaningful if presented as exposure errors, then maybe measuring exposure directly, rather than converting speed errors into exposure errors as I do now, would make sense. It also eliminates all the issues of accurately trying to capture the shutter movement.
-
What I think Peter is thinking about is using the analog output part of the sensor instead of the digital one.
You have a constant light source in front of the camera. The first test would be done on bulb to get the amount of light that goes through the lens without any blocking. This is the baseline. Then on each actuation of the shutter, you record the sensor output to measure not the shutter speed itself but the total amount of light that it lets through in one cycle.
This can then be translated into a value that represents the whole cycle.
It's a bit like on uv exposure units where they use a sensor to calculate exposure as units instead of time...
-
I'm wondering how precise this can be done. The Arduino has 16 MHz. The success of this would heavily depend on optimising the code so that it won't use too many CPU cycles. Other than that, the EV boundaries in Peter's last post could easily be implemented with a digital sensor. You could hint at too slow, too fast or optimal shutter speeds with "+", "-" and "=". I'm wondering how hard it would be to make an interface to allow to adjust EV boundaries. You could basically use the Contax tolerances in the chart and make those adjustable.
-
What I think Peter is thinking about is using the analog output part of the sensor instead of the digital one.
You have a constant light source in front of the camera. The first test would be done on bulb to get the amount of light that goes through the lens without any blocking. This is the baseline. Then on each actuation of the shutter, you record the sensor output to measure not the shutter speed itself but the total amount of light that it lets through in one cycle.
This can then be translated into a value that represents the whole cycle.
It's a bit like on uv exposure units where they use a sensor to calculate exposure as units instead of time...
That's basically it, yes.
If only I could speak Ardweeno I'm sure I could have explained it better ;)
-
No need to stick a babblefish in your ear, we can translate. :)
Now what I'm wondering about is how to convert an amount of light for a period without using seconds in the system...
I could count photons, but that would be a tad too much...
-
No need to stick a babblefish in your ear, we can translate. :)
Now what I'm wondering about is how to convert an amount of light for a period without using seconds in the system...
I could count photons, but that would be a tad too much...
What's the problem with seconds?
I was thinking the sensor would be the input to a A to D converter and the output would be sampled at some rate fast enough to give the required resolution. The output values would be summed to give a value representing the overall exposure. As long as you know the sample rate and the A to D output value that represents a fully open shutter you can convert the result to an equivalent shutter speed.
Shutter speed = the measured values summed together / ( the value that represents a fully open shutter * the number of samples per second)
-
The Arduino currently has both digital and analog inputs and can work with both of them without any need for conversion. The analog pins record resistance while the digital pins are used for switch inputs. Currently the switch inputs are much faster than the analog pins, especially on two pins which can be assigned directly to an interrupt call. This is what we're using right now.
-
I see several problems with sampling continuously from an analogue pin. The main problem that I see is the accuracy of the analogue inputs. The input can read anything from 0 to 5V. Within this span, it can detect 1024 different voltages (which basically gives you an integer value of 0 to 1023 when reading a voltage). While this sounds accurate enough, this is only theoretical in my eyes because you'd have to calibrate a light sensor so meticulously that it would output 0 V for "shutter closed" and 5 V for "shutter fully open". It's very unlikely that this is easy to do (especially since you'd need circuitry to actually do this sort of calibration). But even if you did, the biggest remaining accuracy problem has to do with CPU cycles and detection cycles. The Arduino needs 1 microsecond to read from the analogue input. Neglecting the amount of CPU cycles that you'd need to read and to actually store the read value this means that you get about 5 samples for 1/2000s and 10 samples for 1/1000s under more than ideal circumstances. Factoring in CPU cycles for storing stuff etc. in I'm sure it's even worse. I doubt that this is accurate enough (and -- as François already pointed out -- this is the reason why reading from a digital input which can send an interrupt within a single CPU cycle (1/16,000,000 s) would be a better solution if you could rig it in a way that it'd work with all shutter types). You could use up to two sensors with an Arduino Uno which you could place at strategically chosen positions on the film plane to e. g. measure the travel times of curtains. But I don't know how useful that would be.
Sorry for all the techno babble.
-
Sorry for all the techno babble.
Strangely, as I don't speak Ardweeno, I understood every word. Seems it's probably not the correct device to do what I was thinking. Maybe, if I ever get the time, I'll look into an implementation.
-
I'm glad that what I wrote made sense to you. :)
I'm pretty sure that you could use a Raspberry Pi to do exactly the same and you could produce sophisticated output since you could attach it via HDMI to real screens. I think that you could easily use the pins on the RasPi to build a very similar setup as with the Arduino. Furthermore, you could code all of the program in Python which is a lovely language to do useful stuff with. The RasPi should have sufficient power and memory to do sampling. However, I currently have the same problem as you do: a lack of time. :)
-
The RasPi is definitely a better option when high speeds and processing is involved. Lets not forget that the Arduino's heart beats at a whopping 20MHz at best...
We're talking 1 million instructions per second at the processor level. To put that in perspective, that's twice the speed of the original 128K Mac that came out in 1984!
-
Been thinking about your exposure curve thing Peter... and I'm beginning to think that for most shutters it would simply be unnecessary.
On both sides of the curve is the shutter's acceleration/deceleration slope. While it does let light through, on a healthy sounding shutter it might be a negligible part of the exposure which most people would never see. A snappy shutter means that the slope is very steep.
On the other hand when a shutter sounds like a slouch, the acceleration is not there and the exposure will be affected by the flatter curve. It also means that the shutter definitely needs a good CLA...
-
Been thinking about your exposure curve thing Peter... and I'm beginning to think that for most shutters it would simply be unnecessary.
On both sides of the curve is the shutter's acceleration/deceleration slope. While it does let light through, on a healthy sounding shutter it might be a negligible part of the exposure which most people would never see. A snappy shutter means that the slope is very steep.
On the other hand when a shutter sounds like a slouch, the acceleration is not there and the exposure will be affected by the flatter curve. It also means that the shutter definitely needs a good CLA...
By "most" I assume you mean most leaf shutters as it was only leaf shutters I was referring to. But this is applicable to ALL leaf shutters. And I did say "ignoring things like acceleration" as that's not what I was talking about. It's the time it takes for a leaf shutter to go from fully closed to fully open then again back to fully closed. At fast shutter speeds this takes up a significant part of the exposure and, in fact, at the top speed the whole exposure is likely to be taken up with the shutter opening and closing. Which is why leaf shutters don't have such high top speeds as other types. If the problem only applied to a few shutters which are a bit sluggish and need of a CLA then I'm sure the shutter manufacturers would have built leaf shutters with much higher top speeds - but they didn't.
Tell me this, how are you planning on measuring the shutter speed of leaf shutters using the Arduino?
-
You're right about the top speeds. They are really hard to do on focal plane shutters. I might be mistaken but I think only Kodak made some which used rotating blades to avoid this problem.
So far, I've been just sticking the sensor on the back of the lens, pointing it at my desk lamp and pressing the button. I figure that leaving the lens on will reduce the need for a very precise sensor location... But I'm also running into the problem that the sensor is not precise at anything above about 1/100. I just tested it with a lens that goes up to 1/400 and uses a massive spring to reach that speed. But it tells me it's at 1/125... very improbable.
I know the sensor is also very sensitive to ambient light. Just testing in the wrong conditions can ruin the entire test, especially at high speeds.
When I use it to test a focal plane shutter, I top-off at a very low speed too...
I'm starting to think that I'll need two sensors for different tests, or something like that...
Right now, I'm really puzzled by this problem... it's going to definitely need some very good engineering to overcome this.
-
With an IR sensor and emitter I have consistent measurements down to 1/250s. Have you considered trying IR? Apart from that, even when using a visible light sensor, I can trim it so that it's only triggered by a really bright head torch. Have you tried using a brighter light source and no lens on the camera and trimming the sensor to a higher threshold? Still, I share your frustration with speeds quicker than 1/250s. I have no idea what's going on.
I've got a RasPi here which I can use for testing the sensor. Maybe I can quickly write some code in Python this weekend so that I can compare my mileage on the Pi with the Arduino. It's really hard to understand why the accuracy is so bad beyond ~1/250s. When using an interrupt driven program with a digital sensor on the Arduino the precision should be completely sufficient. It's a mystery.
-
So far, I've been just sticking the sensor on the back of the lens, pointing it at my desk lamp and pressing the button. I figure that leaving the lens on will reduce the need for a very precise sensor location... But I'm also running into the problem that the sensor is not precise at anything above about 1/100. I just tested it with a lens that goes up to 1/400 and uses a massive spring to reach that speed. But it tells me it's at 1/125... very improbable.
So the light hitting the sensor (ignoring any positional variations) increases from zero to some maximum then decreases back to zero. At what point does the measurement start and finish? If it's starting almost immediately and stops just before the shutter closes then I can understand it giving you 1/125th. If you decreased the sensitivity so that it didn't start until the light reaches near maximum then it would probably give you a speed much faster than 1/400th. That's the issue. Defining and then controlling the point at which timing starts can make such a big difference to the result.
I know the sensor is also very sensitive to ambient light. Just testing in the wrong conditions can ruin the entire test, especially at high speeds.
Ambient light will add to the light transmitted through the shutter so effectively it increases the sensitivity which will alter the point at which the measurement starts.
Right now, I'm really puzzled by this problem... it's going to definitely need some very good engineering to overcome this.
For FP shutters, I think (I know) the problems are surmountable but I came to the conclusion there isn't a practical one for leaf shutters which is why I started thinking about alternative methods.