Canon单反遥控器(英文)

Canon单反遥控器(英文) DIY Canon RC-1 infrared remote control clone This article describes how to build a DIY low-budget AVR-based infrared remote control for Canon cameras. The reverse-engineered communication protocol of the RC-1 is described here. The RC-1 lets you trigger the camera instantly or with a delay of 2 seconds from a distance of up to 5 meters (~16 ft). It comes in very handy when taking long exposure pictures or for HDR photography. The presented circuit can be used as part of DIY interval triggers for smaller Canon cameras without the external trigger connector. In bracketing mode the RC-1 lets the camera shoot a whole series of images at once! It is recommended to read the RC-1 communication protocol description first. The Circuit The first circuit I made was based very much on the original Canon (or Mitsumi, see image above) design. After I got it working, I simplified the schematics successively to reduce the part count and make it more easy to build. The schematics of the initial version is here. The simplified version is shown in the picture below. I was able to trigger an Canon EOS 400D from more then 5 meters (~16 ft) with both versions, though the simple version had more failed trigger attempts. The "high-end" version uses a crystal oscillator to provide a precise clock to the microcontroller. The IR-LED is driven by an NMOS transistor allowing higher current then the controller outputs can source. The controller is supplied via a diode to reduce the supply voltage below the recommended maximum of 5.5 V. In the simplified version the crystal oscillator was replaced by the internal 8 MHz oscillator, saving three external parts. The disadvantage of this solution is that the frequency is drifting slightly with the supply voltage and temperature. Details on this behaviour can be found in the "Electrical Characteristics" section of the Attiny25 data sheet. The most radical simplification was the elimination of the transistor. I found out experimentally that driving the IR-LED directly from paralleled microcontroller pins is powerful enough to trigger the camera from about 5 meters (~16 ft). Finally the voltage reducing diode has been dropped increasing the supply voltage to the "absolute maximum" value of 6 V. I don't recommend to leave the mode selector input pin unconnected in the simplified version. I had some sporadic shots in the wrong mode. AVR source code The program was written in C and compiled with the avr-gcc compiler in the AVR-Studio. The _delay_ms function was used to generate the delays. After applying power to the controller, pin PB0 is tested for its level. If the level is high (pin not connected, internal pull-up active), the instant trigger signal is emitted. If the pin is tight to ground, the delayed trigger signal is send. After sending the pulses, the microcontroller is put in power-down mode to reduce the power consumption to the minimum. When the pushbutton is released, no current is drawn from the battery, except the leakage current of the capacitor. A high quality cap should be used to keep this current low. The LED output signal is present on pins PB1 and PB2. The pins should be used in parallel if driving the LED directly as in the simplified circuit version. For some inexplicable reasons I wasn't able to parallel more then two pins. Before compilation, the microcontroller clock frequency must be specified in the c-file header according to the oscillator used. If the internal 8 MHz oscillator is used as clock source, an F_CPU of 7.9 MHz is a good choice. The reason for the difference is the voltage drift of the internal RC-oscillator. The nominal frequency of 8 MHz is specified for a supply voltage of 3 V. It's decreasing slightly for higher supply voltages. The dependence is documented in a diagram it the data sheet of the controller. I was able to trigger an Canon EOS 400D from more then 5 meters (~16 ft) with both versions, though the simple version had more failed trigger attempts. The "high-end" version uses a crystal oscillator to provide a precise clock to the microcontroller. The IR-LED is driven by an NMOS transistor allowing higher current then the controller outputs can source. The controller is supplied via a diode to reduce the supply voltage below the recommended maximum of 5.5 V. In the simplified version the crystal oscillator was replaced by the internal 8 MHz oscillator, saving three external parts. The disadvantage of this solution is that the frequency is drifting slightly with the supply voltage and temperature. Details on this behaviour can be found in the "Electrical Characteristics" section of the Attiny25 data sheet. The most radical simplification was the elimination of the transistor. I found out experimentally that driving the IR-LED directly from paralleled microcontroller pins is powerful enough to trigger the camera from about 5 meters (~16 ft). Finally the voltage reducing diode has been dropped increasing the supply voltage to the "absolute maximum" value of 6 V. I don't recommend to leave the mode selector input pin unconnected in the simplified version. I had some sporadic shots in the wrong mode. AVR source code The program was written in C and compiled with the avr-gcc compiler in the AVR-Studio. The _delay_ms function was used to generate the delays. After applying power to the controller, pin PB0 is tested for its level. If the level is high (pin not connected, internal pull-up active), the instant trigger signal is emitted. If the pin is tight to ground, the delayed trigger signal is send. After sending the pulses, the microcontroller is put in power-down mode to reduce the power consumption to the minimum. When the pushbutton is released, no current is drawn from the battery, except the leakage current of the capacitor. A high quality cap should be used to keep this current low. The LED output signal is present on pins PB1 and PB2. The pins should be used in parallel if driving the LED directly as in the simplified circuit version. For some inexplicable reasons I wasn't able to parallel more then two pins. Before compilation, the microcontroller clock frequency must be specified in the c-file header according to the oscillator used. If the internal 8 MHz oscillator is used as clock source, an F_CPU of 7.9 MHz is a good choice. The reason for the difference is the voltage drift of the internal RC-oscillator. The nominal frequency of 8 MHz is specified for a supply voltage of 3 V. It's decreasing slightly for higher supply voltages. The dependence is documented in a diagram it the data sheet of the controller. Program: #define F_CPU 7900000your_frequency // crystal frequency #include #include #include #include #include #include #define HPERIOD 0.01524 #define RATIO 0.4 #define NPULSES 16 #define LEDOFF 0b00000001 #define LEDON 0b00010111 int main(void) { uint8_t i; DDRB = 0b00010110; // pin PB0 is input, pins PB1-PB4 are output PORTB = 0b00000001; // pull-up for input pin PB0 asm volatile ("nop"); asm volatile ("nop"); if ( PINB & (1<