FYI, I guess you are connecting the analog output of the sensor to the Arduino analog input pin. In that case, the lm393 is not being used at all. The lm393 compares the analog signal to the level set by the pot, to provide the digital output which you are not using.
So you don't need to waste your money on those sensor modules. You only need the photodiode and a resistor, I suspect.
I also suspect that those modules are in fact using phototransistors, not photodiodes. Photodiodes give only a very small signal which would require amplification to make the output readable by an Arduino analog input, and there is no amplification circuit on those modules.
Well, it was described as photodiode, but I have seen that there is a lot of confusion about the terminology, unless you go to professional sellers. I’d like to use the photo IC listed in the project I have reported, but they seems unavailable in Italy.
I'm building the #1 sensor with 3 photodiodes in diagonal. The autor of the project uses the Kodenshi Corp SIC553-04 or the PIC0903SL.
There are three sensors because, in a focal plane shutter, you have to perform different tests: first you have to check the curtains speed, you use the first and the last sensor to measure the time the single curtain take to cove the photogram; you have to adjust the springs that retract the curtains to match the factory time. Second you have to check the evenness of the exposure times on the entire photogram, so you check the exposure time on the center and on the edges, they must be equal.
Little update on the project: I have switched on a photo IC with a digital output; I have connected the three sensors on three digital input and now I read them with the direct port regiter access.
With this code I have speed up the cycle to 6us; I want to read 1 millisecond of interval, so in the interval the program is able to cycle 167 times, I'm very satisfied with that.
That’s the big problem: calibration and verification of results.
At the moment I don’t have a way to accurately test the shutter tester, I use an electronic analog camera non serviced for a while (I think being electronic the shutter could be quite accurate even if it is not serviced).
The speed of 1/250 and slower are accurate, at 1/500 depends, at 1/1000 it measures 1/800 - 1/900.
I think that this values could be plausible for that kind of camera.
Now I’m searching for a way to test the tester.
You could use a second Arduino to pulse a white LED for a programmable set time, and use the light from that LED to illuminate your sensors.
Check whether the measured results agree with the flash pulse width.
I thought about this way, but I have some doubts about the real duration of the light pulse, I think that the current will have a ramped start and stop so the light rises and falls not instantly; what would be the error? This error could be significant for 1 millisecond duration.
Other problem: I have to use a desk lamp connected to 220V to trigger the photo IC, I don’t know how to command it
Well, I could use a standalone single sensor, without the housing it is more sensitive to the light. Then maybe I could use a single led to trigger it
You could replace the interrupt that generates millis() with one that, first, occurs at exactly 1ms intervals, and second, turns on an LED on one interrupt, and then turns it off on the next interrupt. That combination should produce a pulse of exactly 1ms (1/1000 second) subject only to the accuracy of the Arduino's crystal. I think I have code that sets up that interrupt if you have any interest.
It seems any ramping times would occur in both directions, so the duration of the pulse would still be accurate. But I don't know if LEDs turn on faster than they turn off, or vice versa.
If driven by a FET circuit with low parasitic capacitance, I'd be willing to bet that LED Turn On/Off times are at least an order of magnitude faster than the timescale you're interested in.
Yes, I’m interested in that code.
Another problem is the correlation of the sensor with the camera: you have a finite dimensione of the sensor (theoretically you would have an infinitesimal) so I think I have to keep it into account; second the curtains are at a certain distance from the sensor so, if you use a diffused light source, you have a slight longer exposure time.
The ISO-516 standard reports some of this situations.
I think you can divide up the accuracy testing and calibration into two parts. One would test your software's response to a straight digital trigger (no light involved) of exactly 1ms - what the IR sensor would put out if working perfectly for 1/1000 second shutter speed. Then if that works correctly, you could use @JohnLincoln's LED setup to see if it still works perfectly or whether optical effects degrade its performance in some way.
Here's the code I found for the alternate interrupt for millis(). It's just the blink sketch with a different ISR driving millis(). It should work with any Arduino using the 328P - Uno, Nano, Pro Mini. It's basically the 16MHz clock with a prescaler of 64 to drive the counter, and an interrupt at a count of 249, which actually is 250 because it's zero-based. 16,000,000 / 64 / 250 = 1000.
/*
This features a replacement for the ISR(TIMER0_OVF_vect)
interrupt that drives millis(). It disables the OVF
interrupt, enables the COMPA interrupt, sets OCR0A to 249,
and changes Timer0 to CTC mode. This results in an
interrupt every 250 timer clock cycles, which is exactly 1ms
for a 16MHz crystal. For 8MHz, OCR0A is set to 124. The new
ISR increments millis, but since the interrupt rate is exactly
correct, no periodic double increment of millis is needed.
Using this code probably means you can't do any analog
writes that use Timer0, which would include pins 5 and 6.
Millis() should work as normal at 16MHz or 8MHz.
The effect on micros() is unknown.
*/
extern volatile unsigned long timer0_millis; //these defined in wiring.c
extern volatile unsigned long timer0_overflow_count;
byte MILLIS_INCB = (64 * 250) / (F_CPU / 1000); // ms to 250 ticks
const int cycleTime = 500; // flash LED every second
unsigned long oldMillis = millis();
unsigned long newMillis = 0;
void setup() { //Set up alternate interrupt
// at 249 on timer0
cli(); // disable interrupts while doing this
TCCR0A = 0; // set entire TCCR0A register to 0
TCCR0B = 0; // same for TCCR0B
TCNT0 = 0; // initialize timer0 count to 0
OCR0A = (250/MILLIS_INCB) - 1; // set top of counter (249 for 16MHz, 124 for 8MHz)
TIMSK0 &= ~bit(TOIE0); // disable overflow interrupt
TCCR0A |= bit(WGM01); // turn on CTC mode
TCCR0B |= (bit(CS01)+bit(CS00)); // Set CS00&CS01 bits for prescaler = 64
TIMSK0 |= bit(OCIE0A); // enable timer compare interrupt
sei(); // enable interrupts
pinMode(13,OUTPUT);
digitalWrite(13,HIGH);
}
void loop() { // flashes LED for 1/2 second
// every second
newMillis = millis();
if ((newMillis - oldMillis) == cycleTime) {
oldMillis = newMillis;
digitalWrite(13,!digitalRead(13)); // invert pin 13 state
}
}
ISR(TIMER0_COMPA_vect) { // this is the new ISR - much
// simpler than original
timer0_millis++;
timer0_overflow_count++; // probably not needed
}
You would add code to the ISR to make it turn on an LED on one interrupt, and turn it off on the next interrupt, and leave it off until you push a button in loop(), or something like that.
Are you actually able to calibrate/adjust the speed of the curtains? My understanding is that both curtains move at the same speed regardless of the shutter speed. The shutter speed is basically a function of when the second curtain starts to close.
You are correct, first you calibrate the curtains travel time (the second slightly faster), then you calibrate the fast speed (on the Pentax MX) moving the follower closer or farther from the cam that spins with the first curtain; with this calibration you release the second curtain sooner or later (in percentage of first curtain travel). Then you calibrate the slow speed acting on the governor.
On LearnCameraRepair you can find a manual of the Spotmatic with calibration hint, and a beautiful manual from NatCam on the K1000.
I have done the first test with the light source controlled by another Arduino and the results are quite satisfying. At 1/1000 of second the value measured is 1/998.
