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://188.8.131.52/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://184.108.40.206/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