Archive for the ‘Canon XSi’ Category

Building a remote interface for Canon ETTL flash interface

April 10, 2009

I haven’t posted for awhile.  I’ve been busy with more demanding tasks.

I think I’ve done enough research into the Canon ETTL interface and I believe I now can build a prototype that connects to the Camera and provides control of one or more additional flashes, wired or wirelessly, including other Canon ETTL flashes.  My understanding is that the Canon flash IR mechanism doesn’t really work too well (high noise, low range, etc.), and this interface would potentially allow the use of RF for communication and allow >4 ETTL flash units over a larger distance.  I believe my solution should have a interface that connects to the camera’s ETTL hot-shoe (call it the “master”) and a remote interface that provide an effective ETTL hot-shoe for connection to each flash (call them the “remotes”) you want to control.  The master would be able to set the different remote flash intensities and control remote flash occurrence.  I don’t see any reason for limiting the number of remotes other than the user interface on the “master” to setup the different remote parameters.   This interface should also allow the high-speed sync mode to work correctly with the camera for any flash.

This would be similar to the commercial pocket wizard, but would take advantage of the ETTL interface and ETTL flash controllability.

I hope to finish the prototype soon.

Advertisement

Canon ETTL protocol

March 19, 2009

This is a continuing story from https://billgrundmann.wordpress.com/2009/03/18/sniffing-canons-ettl-protocol-2/ and previous posts.

Good news!  I found out today that the drop of CLK to ground (after command message 0xb4 0x3d) before the “X” pin drops is exactly 4.00 msec.  This has been measured several times.  This is good as we now have a leading indicator when the flash is requested to do its job!   This is sufficient time for even wireless modes.  Of course I don’t really have the data of the shutter curtain positions relative to the “X” pin.

I’m working on a collective document that describes everything that I’ve found so far.  This would be easier for people to look at than these piece-meal postings.

 

bill

Canon ETTL protocol continued

March 10, 2009

I’m getting back to this interface and looking more closely at the signaling between the XSi and 580ex flash.   This is a continuance of the post: https://billgrundmann.wordpress.com/2009/03/04/ettl-interface/

I realized that I needed to look at how the flash informs the camera that it exists and is turned on.

img_2598

This picture shows “D1” from the camera (on top) and the leading edge of “CLK” from the camera (on bottom).  It looks like the flash informs the camera of its “on” status by pulsing high right after the clock goes high.  This particular pulse starts about 1.6usec after the clock and last for about 11usec.

The flash also seems to indicate a ready concept using D1 as shown in the following picture.  This is a capture of D1 (on top) and CLK (on bottom).  D1 seems to go high before the camera starts to clock some data.  D1 stays high until the clock drops and then, for this example, changes for the first bit of the clocked data (in this example the data bit is “0”.    This D1 high before the clock is likely the flash ready to receive flag to the camera.  This also means that if the last data bit, for the current clocked byte, is “1”, then D1 has to drop to “0” so that it can rise again as ready later.

img_2599

The following picture shows a chain of clocked bytes from the flash (D1 on top, clock on bottom).  Notice that D1 always goes high before the first clock of a new byte and then changes to whatever is the value of the first bit after CLK 1st falls.  Notice also at the point marked with an “X”; this is a case where the last data bit is a “1” and D1 returns to zero and later returns to one to indicate ready for the next byte.

img_2600

So, you can see that there is a handshake between the flash and camera.  The camera can’t send another byte of data until the flash indicates it is ready to receive it.

I found no similar characteristics on the camera’s data, D2.

eTTL interface

March 4, 2009

I want to build a flash interface for my Canon XSi camera.  Unfortunately, it is Canon, which means it is a proprietary interface.  There is some information that has been found on the web and it is a very good starting point:

http://81.216.246.116/e/ettl/

For now I’m tapping into the communication by opening up my shoe cord adaptor instead of trying to build a hot-shoe adaptor myself.  Here’s a picture of the internal connections of the Canon off-camera shoe cord 2. 

img_2543

 The connections are blue: “X” or flash, white: “CLK” from the camera, green: “D1” or data from flash, red: “ID”,  black: “D2” or data from camera, and the braided wire is the ground reference.  I took a picture of the CLK waveform as it starts after I do a pre-focus:

img_2544

This is the leading operation of the CLK pin with a Canon XSi and Speedlite 580ex.  The CLK starts out at 0 volts and has a High of 4.6v and a signal low of 2.1v.  It looks like there is about 80ms between bytes of data (the smaller blips down to 2.1v).  If true, then this means we have plenty of time to analyze the received bytes and even send their data over the slower USB Serial connection.

Here is a close up of the clock chain for one byte of data transfer (one of those blips in the previous picture).  The clock as shown has a period of ~9.6usec, which is ~104KHz.  Measuring all 8 clocks; the average is 9.5usec per clock cycle.  The levels looks like we could use a comparator against 3.3v to determine “0” and “1” of the clock and another comparator with about 1.5 v to detect active clock or communication.

img_2545

The following picture has an example of the data from the flash + clock.  The data only transitions betweens 2.1v and 3.1v.  The voltage swing is probably limited by the battery in the flash which I measured to only be 4.5v (4 AA batteries = ~6v).  The other web site reported D1 swinging between 3.7 and 2.2.

img_25471

Now to go  build an Arduino interface circuit.  This protocol looks doable with Arduino with a little bit of hardware support – at least for sniffing the traffic.   It also looks possible to output the data bytes in real-time through the USB serial port.  To actually create an alternative flash will first take some studying of the traffic while changing different parameters (both camera and flash).  Second, I’ll have to come up with additional circuitry to do the level shifted outputs.

update.. march 5th:

I built a translation circuit for the Arduino.  I had an old LM339 comparator that I knew was fast enough for the purpose and with 7 resistors it was everything I needed.

opamp

I selected v1 = 2.6v, v2 = 1.5v.  I wrote a simple program for the Arduino to sample the bytes of data on both D1 and D2.  The program used interrupt on rising edge of CLK’.  “active” was needed to determine when I was in a commication window.

Here is a sampling of the data that occurred right after a cold start of the XSi camera (aka, I pushed the shutter button all the way when the camera was shutdown and the flash happened).  I haven’t captured data after the “X” pin is set to zero.  Counter to the other web’s information, I see a “8C” versus “86” acknowledgement byte from the flash.

D1 D2 with some translation:

 

8C FF
8C BD set zoom
AA 00
59 28
00 99
FF FF
8C B7 aperture
CC 4C
8C B9 camera mode
00 80
8C BD set zoom
18 00
61 20
32 FB flash mode
02 FF
8C F9 status
74 FF
8C B3 unknown
00 03
00 46
00 2F
00 F5 anoter status
53 FF
49 FF
5C FF
0F FF
00 BE ???
8C 20
8C BB ISO 400
00 58
00 FF
8C FF
9C A5 ???
CC 4C
8C B9 camera mode
00 80
8C BD set zoom
18 00
69 28
32 FB flash mode
02 FF
8C F9 status
54 FF
8C B3 unknown
00 13
00 46
00 2F
00 F5 snother status
53 FF
49 FF
5C FF
0F FF
00 BE ???
8C 20
8C BB ISO 400
00 58
00 FF
8C B3 unknown
00 13
00 46
00 2F
00 B7 aperture
8C 2D
 
March 6th update:
I reformed the output from Arduino to what seems to be messages.
 https://billgrundmann.files.wordpress.com/2009/03/cold_start_flash_taken1.docx
 
March 8th update:
I’ve done two things: 1) I’m using putty.exe as an interface to arduino.  It lets me log all of the messages. 2) I wrote a separate C++ program on windows to process the putty logs and reduce the total messages to the unique messages.  Since the messages from the camera are highly redundant, I needed to reduce it down to just those that are unique.  I can then sample different camera/flash switches to see what changes.  For instance, I now have the complete shutter speed and aperture numbers and their correspondence to the camera settings.
 
fstop
 
I also have the 54 entry shutter timing information.  I’ve written the C++ processing program to start to convert the camera/flash messages to english statement.  I’ll continue to see how the different camera/flash options show up in the messages.
 
 
Stay tuned…

The nature of gravity

March 2, 2009

Actually, I’m referring to things dropping and how long it takes for that thing to drop a certain distance.  If you use this information along with controlling a camera then you can capture things that are falling in a repeatable fashion.  For instance, a drop of water as it just hits a pool of water, or maybe just a little later when the water pool splashes back up after reacting to the water droplet.

The favorite equation used for this dropping behavior is

distance, acceleration and time

where “s” is the distance, “a” is the acceleration rate, and “t” is the amount of time.  This equation assumes the object starts at rest and t=0.  The acceleration “a” can be assumed constant with a value of approximately gravity constant

I was able to build a simple setup that allowed me to experiment with Arduino controlling a Laser, a light sensor, and a camera (Canon XSi).  The experiment performed the following steps:

1.   Turn on a laser and insure that the light sensor detected the laser

2.   Drop an object through the laser-sensor beam

3.   Upon sensing the laser-sensor beam broken, start a delay

4.   Once delay has finished, take a picture

5.   Turn off the laser

6.   Look at the picture to evaluate object’s dropped distance

7.   Repeat with different delay amounts

Ok, simple enough.  The problem I had was how to release the object repeatedly from a fixed position and as close to already breaking the laser-sensor beam as possible.  The object I chose was as ruler, permitting me to visually see the distance traveled. 

img_25221

My object (ruler) release was simple – a nail that I pulled back that released the ruler.  I carefully positioned the ruler to just before breaking the light between the laser and sensor.  I then release, recorded what the camera saw and repeated. 

I also changed the amount of delay.  After I had several interesting data points, I plotted the results.  I recorded 6 different results for the same delay, plotting the average/min/max.  I also plotted a curve-fitted line to determine the least-square best fit for the modified equation (instead of “t”, I used “(t + y)”, where “y” is the unknown amount of camera delay).  From this particular experiment, I determined that “y” is about 106msec, which is for some reason, different from other experiments for the same camera.

capture3

Here is an example picture taken:

img_2407

The arduino code is:

#define shutter_close PORTD |= _BV(2);
#define shutter_open PORTD &= ~_BV(2);

#define focus_on PORTD |= _BV(3);
#define focus_off PORTD &= ~_BV(3);

#define laser_on PORTD |= _BV(4);
#define laser_off PORTD &= ~_BV(4);

#define nolight (PINB & 1)  // digital pin #8
#define ledon PORTB |= _BV(1)
#define ledoff PORTB &= ~_BV(1)


void setup() {
  pinMode(2, OUTPUT);  // camera shutter
  pinMode(3, OUTPUT);  // focus control
  pinMode(4, OUTPUT);  // Laser control
  pinMode(8, INPUT);   // light input
  pinMode(9, OUTPUT);  // led indicator
  shutter_open;
  focus_off;
  ledoff;
  laser_off;
  Serial.begin(9600);
}
unsigned long amt = 0;  // 0 = no extra delay … just the inherent delay

void get_delay() {
  unsigned long delay = 0;
  unsigned char len = 0;
  while(1) {
    while(!Serial.available());  // wait for first character
    unsigned char c = Serial.read();
    if (c >= ‘0’ && c <= ‘9’) {
      delay = (delay * 10) + (c – ‘0’);  // add in digit
      len++;
    } else {
      if (len == 0) {
        Serial.println(“Have to enter a delay”);
        return;
      } else {
        amt = delay;
        Serial.print(“new extra delay of “);
        Serial.println(amt);
        return;
      }
    }
  }
}

void loop() {
  while(1) {
    Serial.println(“Command? (D, T, A)”);
    while(!Serial.available());  // wait for command
    unsigned char c = Serial.read();
    switch(c) {
      case ‘A’: case ‘a’:
        laser_on;
        while(!Serial.available()) {
          if (nolight) ledon;
          else ledoff;
        }
        Serial.read();
        laser_off;
        break;
       
      case ‘T’: case ‘t’: {
        Serial.print(“Delay is camera + “);
        Serial.print(amt);
        Serial.println(“ms”);
       
        laser_on;
        while(nolight);  // wait for laser and sensor together
        focus_on;
        delay(1000);  // pre-focus
        while(nolight == 0);  // wait for light trigger

        // turn off laser
        // laser_off;
        delay(amt);  // time to shutter
        shutter_close;  // close the shutter
        ledon;  // flag progresst
        delay(200);  // delay some amount for the shutter/flash to work
        shutter_open; // release shutter
        focus_off;
        ledoff; // flag progress
        laser_off;
      } break;
     
      case ‘D’: case ‘d’:
        get_delay();
        break;
     
      case ‘F’: case ‘f’:
        focus_on;
        delay(1000);
        focus_off;
        break;
       
    }
  }
}
 

 

Characterizing shutter curtain delay of Canon XSi

March 2, 2009
I wanted to know the delay from closing the shutter of my camera to when the actual picture is taken. With this information, then it becomes easier to setup various stop-motion picture captures.
For this experiment, I needed three things:
  • A way of controlling the Canon XSi camera
  • A bright enough LED with a short flash time while the camera was in total darkness
  • An accurate accounting for delay from control of camera to LED flash

The LED I used was a Luxeon I, which was controlled via a simple transistor driver (2N2222 + base resistor). The flash time for the LED was chosen to be only 1msec. To get an accurate delay I found I had to write my own delay routines. The delay routines provided by the Arduino library were not really adequate for my purpose.
My software hardware algorithm was simple. Have the arduino close the camera shutter, have it delay a predetermined (but user variable) amount, and flash the LED at a piece of paper, for which the camera was taking a picture. I then manually looked at the resulting picture to see the amount of light that was exposed in the picture. I recorded the results and changed the amount of delay and repeated. Because the LED flash time was only 1msec, I had to shoot with an ISO of 1600.
 
I did two different sets of pictures. The first picture set was just of an arbitrary piece of paper I had laying around. It had some garbage writing on it, but this was to determine if the setup worked ok. The shutter speed was set at 1/100. I approximated from these pictures the actual shutter speed at 1/100.6, which is within 0.6% of the camera’s setting. Also the delay begins at 84msec through 86msec depending upon the position in the camera’s sensor.
Notice how the sensor is opened from the bottom and the 2nd curtain also starts at the bottom (as it should).
 
The second set of pictures was of a sheet of paper that had printed on it lines labelled from 0 through 10. This ruling would permit me to better estimate the delay time to % position of the shutter open or closed. I carefully positioned the paper and camera zoom so that the “0” line was just at the bottom and the “10” line was just at the top of the camera’s sensor.
 
Here is an example of one of these shots.
 
Lastly, I used the perceived % opening/closing of shutter to plot the delay of the shutter. I posted these as two excel charts, the first for the shutter opening, the second for closing.      
 
 
 
 
 
 
 
 
 
 
 

my_flash program