Serial Protocol of Some Digital Cameras

> Disclaimer: This description is completely unofficial, Epson even does not know about its existance. Most of the informaion presented here is discovered by me, Eugene Crosser, while snooping the serial line and by trial and error. I never had an official protocol description, have never seen any related software source code, and have never done reverse engineering of any related software. This description may be incomplete, inaccurate or completely wrong. You are warned.

> Some information is taken from `camediaplay' package by Jun-ichiro Itoh <itojun@itojun.org> and from other (open) sources and not checked by me.

# Serial Protocol of Some Digital Cameras

Several models of digital cameras, namely Epson, Sanyo, Agfa and Olympus cameras, seem to use the same protocol for communication with the host. Follows the description of the high-level protocol they use over the serial line.

## Protocol Basics

The host and the camera exchange with data packets and individual bytes. Serial line paramaters used are: 8bit, no parity. No flow control is used. All arithmetic data is transmitted in the "network order" - least significant byte first.

## Protocol Elements

The elementary units of the protocol are:

Initialization Byte | NUL | 0x00
Action Complete Notification | ENQ | 0x05
Positive Achnowledgement | ACK | 0x06
Unable to Execute Command | DC1 | 0x11
Negative Acknowledgement, also Camera Signature | NAK | 0x15
Packet | Variable length sequence of bytes
Termination Byte |  | 0xff

### Packet structure

The packet has the following structure:

Offset | Length | Meaning
--- | --- | ---
0 | 1 | Packet type
1 | 1 | Packet subtype/sequence
2 | 2 | Length of data
4 | variable | Data
-2 | 2 | checksum

Known packet types are:

Type | Description
--- | ---
0x02 | Data packet that is not last in sequence
0x03 | Data packet that is last in sequence
0x1b | Command packet

Data packets that are sent in responce to a single command are numbered starting from zero. If all requested data fits in one packet, it has type 0x03 and sequence 0.

Command packet has subtype 0x43 or 0x53. Only the first command packet in a session has subtype 0x53.

Maximum length of data field in a packet is 2048 bytes, which yields in 2054 total packet length.

Checksum is a simple 16 bit arithmetic sum of all bytes in the data field. As already mentioned above, length and checksum values are transmitted least significant byte first.

## Flow of Control

A communication session flow is as follows:

Host | Camera
--- | ---
Port speed set to 19200 baud
Host sends init byte 0x00 |
| Camera responds with signature 0x15
Host sends command packet with subtype 0x53 and "set speed" command |
| Camera sends ACK 0x06
Port speed set to the new value
Host sends command |
| Camera responds with either ACK plus optionally "action taken" notifier or data packet sequence
Host sends ACK to every data packet |
... Command - reply cycle repeated ...
| Camera sends 0xff and resets after a few seconds (value is model-dependant) of inactivity

If the camera does not respond to a command in reasonable time, or responds with a NAK, the command can be resent. If the camera does not provide a complete data packet in reasonable time, or the data packet is corrupt (checksum does not match), the host can request resending of the packet by sending NAK instead of ACK.

## Command format and codes

Command is a sequance of bytes sent in the data field of a command packet. Command format is as follows:

Offset | Length | Description
--- | --- | ---
0 | 1 | Command code
1 | 1 | Register number or subcode
2 | variable | Optional argument

Five command codes are known:

Code | Argument | Description
--- | --- | ---
0 | int32 | Set value of integer register
1 | none | Read value of integer register
2 | vdata | Take action unrelated to registers
3 | vdata | Set value of vdata register
4 | none | Read value of vdata register

Commands 1 and 3 are replied with a single ACK 0x06. Command 2 is replied with an ACK 0x06 followed by an "action complete" notifier 0x05. Commands 1 and 4 are replied with a sequence of data packets, each of them must be ACK'ed by the host.

Command 0 must be issued with a 4 byte argument containg the new value for the register (bytes in network order). Command 2 typically is issued with a single zero byte as an argument. Command 3 is issued with an argument of variable number of bytes. If this is a printable string, it should not include the trailing zero byte.

Camera replies to the command 1 with a single data packet containing 4 bytes of a 32bit integer (in network order). Camera replies to the command 4 with a sequence of data packets with variable number of data bytes. Note that if a printable string is returned, it is terminated with a zero byte, and thus may be safely printed or otherwise treated as a normal C language character string.

## Registers

The following registers are known (read/writablity info is inaccurate):

No. | Type | R/W | Description
--- | --- | --- | ---
1 | int32 | R/W | Resolution: 1 - Std, 2 - Hi, 3 - Ext
2 | int32 | R/W | Clock in UNIX time_t format
3 | int32 | R/W | Shutter speed (microseconds)
4 | int32 | W | Current frame number
5 | int32 | R/W | Unknown (5)
6 | int32 | R/W | Color mode: 1 - Color, 2 - B/W
7 | int32 | R/W | Flash mode: 0 - Auto, 1 - Force, 2 - Off, 3 - Anti RedEye
8 | int32 | R/W | Unknown (128)
9 | int32 | R/W | Unknown (128)
10 | int32 | R | No. of frames taken
11 | int32 | R | No. of frames left
12 | int32 | R | Length of current frame *
13 | int32 | R | Length of current thumbnail *
14 | vdata | R | Current frame JFIF data *
15 | vdata | R | Current thumbnail JFIF data *
16 | int32 | R | Battery capacity percentage
17 | int32 | W | Communication speed 1 - 9600 .. 5 - 115200
18 | int32 | R | Unknown (1)
19 | vdata | R/W | Unused
20 | vdata | R/W | Unused
21 | vdata | R/W | Unused
22 | vdata | R/W | Camera I.D.
23 | int32 | R/W | Autoshut on host timer (seconds)
24 | int32 | R/W | Autoshut in field timer (seconds)
25 | vdata | R/W | Serial No. (string)
26 | vdata | R | Version
27 | vdata | R/W | Model
28 | int32 | R | Available memory left
29 | vdata | R/W | Upload image JFIF data to this register
30 | vdata | R | Unknown ("")
31 | vdata | R | Unknown ("\0")
32 | int32 | R | Put "magic spell" 0x0FEC000E here before uploading image data
33 | int32 | R/W | Lens mode: 1 - Macro, 2 - Normal
34 | int32 | R | Unknown (0)
35 | int32 | R | LCD brightness 1 to 7
36 | int32 | R | Unknown (3)
37 | vdata | R | Unknown ("\0")
38 | int32 | R | LCD autoshut timer (seconds)
39 | int32 | R | Protection state of current frame *
40 | int32 | R | Unknown (0)
41 | int32 | R/W | LCD date format: 1 - 'YY MM DD, 2 - DD MM 'HH
42-45 | vdata | R | Unknown ("")
46 | vdata | R | Summary data: 32 bytes with copies of 8 other registers
47 | vdata | R | Unknown ("")
48 | vdata | R | Manufacturer
49-71 | vdata | R | Unknown ("")
72 | int32 | R/W | Digital zoom

* Note: registers 12 thru 15 and 39 only become useful for reading after setting register 4. If value of 0 assigned to register 4 after doing action 5, subsequent retrieval of picture data gives the "live preview".

For command 2, the second byte is action code not register number. The following action codes are known:

Code | Argument | Description
--- | --- | ---
1 | single zero byte | Erase all picures
2 | single zero byte | Take picture
4 | single zero byte | Finish session immediately
5 | single zero byte | Take preview snapshot (retreivable as frame zero)
7 | single zero byte | Erase current frame *
9 | single byte | Set protection state of current frame to the value of parameter (binary 0 or 1)*
11 | single zero byte | Store freshly uploaded image into NVRAM

* Note: actions 7 and 9 only useful after setting register 0x04. Please mail your corrections/additions to <crosser@average.org>
See http://www.average.org/digicam/ for possible updates.