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
- Physical layer
- Hardware used
- Frame composition (command, payload, CRC)
- Sending a frame
- Detailed description
- Typical Communication
- Regular Polling
- Firing the AF-ILL
- Firing a Flash
- Data that is not send
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.
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.
Four lines (and ground) connect the flash and the camera:
acknowledge and enable line, driven only by the camera; camera acknowledges each byte
bidirectional data line, signals start of frame, transports transmitted data and receivers "frame acknowledge"
clock line, driven only by the speedlight during data transfer
when pulled low the speedlight fires a flash
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.
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.
Let me briefly describe which hardware I used to sniff and decipher the lines, figure out the meaning of the frames and the timing.
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.
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.
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.
Header (1 byte)
Checksum (1 byte)
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.
Wait until the bus is clear: CLOCK, DATA, ACK must be high for at least 600µs
The camera initiates the frame by pulling DATA low for 370µs
t = 100µs .. 600µs
As soon as the flash recognizes DATA low it acknowledges by pulling DATA low as well for 600µs
The camera releases the DATA line (which is held low if a flash is present)
t = 600µs .. 700µs
The camera checks whether DATA is low: This signals the presence of a flash
As soon as the camera has detected a flash it pulls the ACK line low to signal the start of the data transmission
The flash releases the DATA line: Ready for Step 2
The flash pulles the CLOCK line low for 16µs; as soon as the sender detects the CLOCK line low it applies the first bit (LSB) to the DATA line
On the rising edge the data is shifted into the receiver
The CLOCK line is high for 16µs. Steps a-c are repeated until all 8 bits are send
The camera acknowledges the byte within about 120µs by pulsing the ACK line for 71µs.
The next byte is transmitted as soon as the flash starts pulsing CLOCK low again. This usually happens within 100µ - 450µs.
All consecutive bytes are transferred in the same manner as in steps 2 a-f.
Send the CRC. This is done as in steps 2 a-c
Signal the successful transmission of the frame
If the flash was the receiver of the payload:
Immediately after the last rising edge of the CLOCK the camera releases the DATA line
The camera acknowledges the byte within about 120µs by releasing the ACK line.
Within 300µs the flash signals the successful reception of the frame (correct number of bytes and valid CRC) by pulling DATA low for about 2ms after it detects the rise of the ACK line.
If the camera received the payload:
The camera acknowledges the byte within about 120µs by releasing the ACK line.
After the flash detects the rise of the ACK it releases DATA (in the case the last transmitted bit was 0) (typ. after 30µs)
After the camera detects DATA high for 140µs it acknowledges the frame by pulling DATA low for 1.30ms
The bus has to be free (all lines high) for at least 600ms until the next transmission (step 1) can be started.
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: