Sniffing Canon’s ETTL protocol

I have been trying to stabilize the results I get from sniffing the protocol (https://billgrundmann.wordpress.com/2009/03/10/ettl-continued/).  Unfortunately, I’m finding the different approaches I’ve tried all seem speed limited and miss data.  I believe I have to have repeatable results before I can deduce any new information about the ETTL protocol.  For instance, I’ve finding similar messages to those reported in http://81.216.246.116/e/ettl/, but I’m also finding several messages that are both different and new.  Unfortunately, the new messages seem to change data values from sample to sample, so that it hard to deduce a parameter change dependency or even if the message was correct to begin with. 

I suspect some of my problems have to do with how I sample the data itself.  I’ve gone to a complex scheme that uses alternating change-on-pin interrupts.  First looking for an interrupt on rise of D1 and then a series of interrupts on rises of CLK for each data bit.  This scheme only has one of the interrupts enabled at a time, where each interrupt ultimately enabling the other interrupt while disabling its own.  I’ve learned that I had to flush pending interrupts on the disabled interrupt input.  Since there is some amount of time between bytes, I’m going to try staying in a spin-loop upon the first CLK rising interrupt and look for all of the bits within that event.  I hope this will allow enough time to still output the prior data bytes before the interrupt sequence resumes.

Here’s an example snap-shot of the data seen with normal settings on both flash and camera.  This snap-shot is the result of post-processing the original data.  The messages are NOT in the order they appear between the camera/flash; they are sorted by numeric message value instead and redundant messages have been eliminated.  For some messages I have the probable message meaning per interpretation at http://81.216.246.116/e/ettl/.  The syntax of the messages are the command bytes followed by the response bytes for that message.  Response bytes have already been deskewed and associated to the associated message.  New message shown in this sample is “0xbe”.  I have also seen messages with “0xfc”, “0xfd”, “0xfe”.  Messages that I’m confident with are the “0xb7” for Aperture setting, “0xb8” for shutter speed, “0xbb” for ISO setting and “0xbd” for zoom setting (but I don’t yet know what the other bytes of the zoom response mean).

 

0xb3 0x12 0x46 0x2f – 0x00 0x00 0x00 0x00
0xb3 0x13 0x46 0x2f – 0x00 0x00 0x00 0x00
0xb4 0x1d – 0x8c 0x8c
0xb5 0x4c – 0xcc 0x8c
Aperture: unknown @ 0x00 – 0xb7 0x00 – 0x8c 0x8c
Aperture: F/4 – 0xb7 0x28 – 0x8c 0x8c
Shutter: 1/60 – 0xb8 0x68 – 0x8c 0x8c
camera mode: 0xb9 0x80 – 0x00 0x8c
ISO: 1600 – 0xbb 0x58 0xff – 0x00 0x00 0x8c
zoom: 24 0xbd 0x00 0x18 – 0x18 0x69 0x18
zoom: 24 0xbd 0x00 0x18 – 0x18 0x69 0x1c
zoom: 24 0xbd 0x00 0x18 – 0x18 0x69 0x23
zoom: 24 0xbd 0x00 0x18 0x99 0xff – 0xaa 0x59 0x00 0xff 0x8c
0xbe 0x20 – 0x8c 0x8c
0xf5 0xff 0xff 0xff 0xff – 0x53 0x49 0x5c 0x0f 0x00
0xf9 0xff – 0x55 0x8c
0xf9 0xff – 0x75 0x8c
0xfb 0xff – 0x02 0x8c

Advertisements

Tags: , , , ,

7 Responses to “Sniffing Canon’s ETTL protocol”

  1. Strobit Triggr and Canons E-TTL » Everything Robotics…….and then some Says:

    […] https://billgrundmann.wordpress.com/2009/03/16/sniffing-canons-ettl-protocol/ […]

  2. Wallace Owen Says:

    I suggest throwing a little old hardware at the problem. Use the spi interface on the AVR to handle the high data rates.

    • billgrundmann Says:

      Maybe. Can you show me how?

      • Wallace Owen Says:

        Have you got the AVR datasheets for the chip used on your board? You basically read the section on the spi interface and it describes how you configure it to call your isr when 8 clocks have been seen on the spi clock line. You can tell the spi whether to sample the data on the rising or falling edge as well as tell it what direction the leading edge is. This way, when the interrupt calls your handler, you read the spi data port to get 8 data bits, throw them in a ring buffer and let your background loop read from that buffer to interpret the data stream.

        If the clock stream isn’t a multiple of 8, what you do is keep track of how many 8-bit chunks the spi port has given you, then you use a spare out pin and toggle the clock line enough to get the reamining bits to get shifted into the spi’s holding register.

  3. Wallace Owen Says:

    I can give you example assembly language code to initialize the spi port if you need it.

  4. billgrundmann Says:

    There are always multiple ways of doing the same thing. Remember several factors: 1) the ettl data rate is quite slow, and 2) there is a handshake that is required to allow the bytes to communicate. With this in mind, there isn’t really a requirement for a higher-speed comunication. It doesn’t mean however that one can by used if available. I’m not sure that the SPI interface can handle the communcation handshake – but I have dug into it enough to know for sure. As far as queuing messages with buffers – that can be done, but it’s a bit overkill as a simple message decoder doesn’t take too much time and would normally be waiting most of the time for the next byte anyway. Normal background queuing is a must if the data rate is high and there is a significant amount of processing that can be done.

    Go ahead and build something and post the results!

    bill

    • Wallace Owen Says:

      I once bit-banged an interface between car stereo components that used a proprietary protocol at 40 kbps rate. Using an 8MHz AVR processor I had just enough time before the next clock edge to do my accounting. WhenI had to revisit the design and squeeze more performance out of it to accomplish more background tasking, I couldn’t afford to have the cpu spend all it’s time on the interface. I recovered lots of cpu cycles by switching to using the SPI interface and it made me 1/8th as busy – I only had to attend to the bytes instead of the bits.

      When you said “I hope this will allow enough time to still output the prior data bytes before the interrupt sequence resumes” I thought using the spi and a ring buffer might give more of the cpu back to you. I didn’t look closely enough to see that there was some bit-level handshake you had to do.

      By the way, the site you list: “http://81.216.246.116/e/ettl/” seems to be down. Do you have a backup copy of what was on that site?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: