http://cms.diodenring.de/de/electronic/microcontroller/110-ittlanalysis 

Analysis of the Nikon iTTL protocol

In this article I describe my findings on the iTTL protocol used by Nikon to control on-camera electronic speed lights. I will include information on the physical layer, serial data transmission, commands, timing, frame composition, and standard sequences like ON/OFF, and firing a flash.

Note: In this article I will only describe the iTTL protocol. In contrary to the TTL (Trough The Lens) protocol iTTL uses a series of pre-flashes to determine the strength of the main flash light output.

Note: These findings are based on sniffing the lines between flash and camera. I also send fake bytes to camera and flash to determine its behavior in case of a broken connection. No device has been hacked into and no firmware has been downloaded, analyzed or broken. No camera or flash took physical or software damage. Most of my findings are based on the combination D700 and SB800. The sole purpose of the information presented on this page is to for academic reasons.

Note: Implementing this protocol in a commercial product may violate the rights of Nikon

Contents:

• Overview
• Physical layer
  • Hot shoe, dimensions, pin numbering
  • Signals
  • Electrical specifications
• Hardware used
• Frame composition (command,  payload, CRC)
• Sending a frame
• Detailed description
  • Header
  • Payload
  • CRC
• Typical Communication
  • Initializing
  • Regular Polling
  • Firing the AF-ILL
  • Firing a Flash
• Data that is not send
• Analysis
• Summary
• Resources

Overview: iTTL Data transmission

The iTTL interface uses two signal lines that form a synchronous serial interface plus one acknowledge and one trigger line. In total there are four signals. Data to and from the flash is send in packets consisting of at least one byte, possibly multiple data bytes and usually a one byte checksum. The camera always initiates a data transmission, during transmission the flash provides the clock signal. Each byte send is acknowledged as well as the reception of the whole frame. 

Physical Layer

Hardware

The hot shoe connector of the camera. The big middle contact is the old X-SYNC contact, the metal framing is ground. The hole top middle is part of a locking mechanism.

 The flash-side of the interface as seen from the bottom. The bolt on the top middle is used to lock the flash onto the camera and prevent removal by sliding it off. The golden contacts are used for an external AF illumination light.

Missing: Dimensions

Signals

Four lines (and ground) connect the flash and the camera:

Each line (except for the good old X-sync) has multiple functions, for example the camera starts a transmission by pulling the data line low then the data is being transmitted in both directions and in the end the speedlight signals the successful reception of a frame by pulsing the DATA line low. So there is a start, data and acknowledge on this one line.

Electrical specifications

Flash side:

In the flash connector the pins ACK, DATA, CLOCK are bypassed to GND via a 220pF capacitor. The digital circuitry in the SB800 is powered by 4V suggesting 4V TTL levels. I strongly recommend not to use voltages above this level. On my test bench the electronics is powered by 3.3V and works flawless.

 

 

The CLOCK line is handled by the flash only. If the bus is idle the CLOCK is at a high level. Data is shifted in and out on the DATA line on every rising CLOCK edge. The CLOCK line is actively driven by the flash via a 330 Ohm resistor.

DATA and ACK are pulled up via a resistor of some 10K Ohms (micro controller internal pull-up), I think the actual value does not matter. Both, the flash and the camera cam pull each of the lines low - either via a chip internal open collector/drain or by setting the corresponding output buffer as output. This way data and acknowledge pulses can be send in both directions.

Note: keeping the ACK line low effectively blocks any user input on the flash.

The X-SYNC is special: Due to historical reasons the voltage on an arbitrary flash unit can be as high as several hundreds of volts. The SB800 however only outputs around 3.6V. If you pull this line low without any previous data communication the flash will fire at full power.

More information can be distilled out of the SB800 Service Manual.

Camera side:

unknown

Hardware used

Let me briefly describe which hardware I used to sniff and decipher the lines, figure out the meaning of the frames and the timing.

Logic analyzer

I used my saleae logic (external link) to capture the data, and the built-in SPI decoder to decode the raw data. Further processing is done by means of a python script that looks for frame start conditions and compresses repeating frames into one data block containing a counter that shows how many times this particular frame occurred.

Interface

To interface with the camera I build a small battery powered circuit that sits on the hot shoe and allows me to tap the contacts of the camera as well as to simulate a flash. For this purpose the circuit contains a micro-controller and an RF transceiver that allows communication in real time.  Connection to the flash is done via the connector of a TTL extension cord. The circuit also serves as a remote shutter release for future use.

Missing: Picture

Frame composition

A data frame consists of exactly one header byte (command) which is always send by the camera, multiple data bytes and a checksum byte. There are a few frames that are obviously time critical and therefore contain no data and/or no checksum to reduce latency.

Sending a frame

The data is transferred in a synchronous serial way, with one acknowledge/enable line. It differs from all serial protocols I know in that special conditions signal the start of a frame, acknowledge each byte and finally acknowledge the whole frame. Data is send LSB first at a peak bit rate of about 30kbp, but due to the protocol overhead the average bit rate is only 12kbps.

Only the camera is allowed to start a frame.

If the flash is the receiver it can stop any data transfer from the camera after each byte by not issuing any more CLOCK pulses until the camera releases the ACK line. This takes about 5.5ms.

Below you find a few snapshots of the communication. I also uploaded a series of data dumps at Resource Section of this article.

Start of frame:

Transmission of a single byte:

End of frame:

One frame: