Arduino eTTL Protocol Sniffer

The easiest way to investigate the Canon eTTL protocol was to eavesdrop on the conversation between the camera and a flash. This approach would allow me to observe a real working system. I needed to learn about the Cannon eTTL protocol supported by my G16. There was some reference material available on the web but they all cautioned about model differences and misunderstood features. So a sniffer was the way to go.

This required a couple of things I did not have:

  • a means to connect my Arduino to the hot shoe contacts
  • an appropriate flash

Getting access to the hot shoe contacts meant tearing something apart. No guarantee it would go back together afterwards. So cheap is best. eBay yielded a Canon hot shoe compatible flash extension cable. About $20. I placed my order with the supplier in China and waited.

The flash was easy: rent one for a week from my local camera shop: Henry's. All I had to do was make sure I obtained the proper flash. I took my G16 into the retail store and tested it with a number of different flashes. The low end 270EX II did not support continuous burst mode. Time to go upscale. I ended up with a 430EX II flash, $400 retail. Or $40 a week to rent.

I had my ducks in a row. Time to get to work on my Arduino sniffer.

Based upon the prior work and a few hints in the Canon patent, I suspected that Canon used the industry standard Serial_Peripheral_Interface (SPI) as the digital interface. And the Arduino also supports SPI. This is a simple electrical protocol used to support bi-directional data exchange between a master and a slave device. Only 3 pins are required: CLCK, MOSI, MISO.

This seems to good to be true. It was. No free lunch. First obstacle was that the voltage levels were off by a few volts - some external circuitry may fix that? After some additional fiddling research I ultimately determined that the Arduino SPI hardware was unsuitable for use as a sniffer. It was not designed to eavesdrop on 2 different data signal lines. It was designed to receive as a Slave device or drive as a Master device. It could only "eavesdrop" on 1 side of the conversation. IF I could get it to work, I could only sense either the camera data or the flash data. Not both.

This meant that my only remaining option was to monitor the 3 digital lines via low level bit bashing. My next step was to create a bit bashed sniffer program.