DCITU - Serial Protocol for Kodak's DC3200

Digital Camera Image Transfer Utility
Serial Protocol for Kodak's DC3200

The serial protocol for Kodak's DC3200 digital camera has unfortunately been left undocumented by Kodak. The following text is part of the reply message received 2001/01/19 from DRG (Developer Relation Group) when I inquired on the serial protocol communication:

We are sorry but the DC3200 camera's protocol is not based on any other camera nor is it based on Digita, and it is not compatible with Kodak's other cameras and developer tools.

Two days prior, on 2001/01/17, the message I received from DRG contained the following:

Currently, there are no plans to provide an SDK for the DC3200 camera and none of the cameras listed in your message are compatible with the DC3200.
We are sorry that the information wasn't more positive.

Since Kodak does not plan on publishing the serial protocol, I've been left to figure it out on my own. While I have had some limited success, I don't understand enough of the protocol yet to write software that will interface with these cameras. What I have figured out is documented on this web page.

Feel free to comment on what is here; you can contact me directly by sending me e-mail.

All log files listed here were created with COMThrough, a serial port application I wrote to help analyze serial communication. The setup is as follows:
+-------------------+ +------------------------+ | PC running | | PC running COMThrough | | a Windows-based | | which links COM1 and | | operating system | | COM2 as well as log | | and Kodak's | | everything to a text | +--------+ | original software | | file | | | | | | | | Kodak | | Software --> COM1:|-------|COM1:-> file.txt <-COM2:|-------| DC3200 | | | | | | | +-------------------+ +------------------------+ +--------+

In the following logs:

COM1: always refers to the port connected to the software
COM2: always refers to the port connected to the digital camera
the communication speed is always set to 9600, the default speed at which the camera starts up
all values and offsets are specified in hexadecimal, starting at offset 0 (zero)

Observations Steps used to create the log Logs

all packets end with a 3-byte sequence, where XX YY ZZ is defined as follows:

XX is UNKNOWN at this time
YY is a checksum of all bytes up to but not including XX
ZZ is always 0xFF

the checksum (byte YY from above) is calculated as follows:
!0 + !byte0 + !byte1 + ... + !byteN
for example, in the packet AF 00 00 03 4D FF, the checksum is calculated using !0 + !AF + !00 + !00 == 4D
in quite a few places, though not all, the UNKNOWN byte before the checksum seems to be the number of characters in the packet; however, there doesn't seem to be any consistency on when this rule is being followed
the largest packet size seems to be 0x8a bytes (138 bytes) in length
except for the first few messages, packets from the software generally start with 0x01
except for the first few messages, packets from the camera generally start with 0x10
except for the first few messages, the 2nd byte of each packet seems to be some kind of counter; the packets from the software as well as those from the camera seem to be on two indendant counters
for the first few packets, at least 16 bytes of header information (and at times even more?) seems to be included at the start of each packet; this can be observed very well at line #54, where the data for this packet begins at offset 0x10
at line #26, the software is asking the camera for all filesystem entries in the subdirectory called \DCIM
offsets 0x1e, 0x1f, 0x20 and 0x21 at line #25 may make a 4-byte integer value that determines the number of characters sent at offset 0x24 of line #26
camera sends back 20-byte records when listing all files/directories found on the CF card; these can be seen in the packets starting at line #28, #41 and #53
structure of 20-byte filesystem records (line #20, 43) are:

bytes 0x00 to 0x0a are the filenames, without the "." between filename and extension
bytes 0x0b is an attribute byte composed of bit flags; 0x01 is a diretory, all other flags are currently UNKNOWN, though 0x02 may simply mean "archive bit"
bytes 0x0c to 0x0f are always 0x00 0x00 0x21 0x28
bytes 0x10 to 0x13 make a 4-byte integer value with the filesize

the filesystem record for DCP_0003.JPG starts on line #70, but isn't completed until offset 0x10 at line #54; what are the 16 bytes of header information?
the filesystem records for DCP_0002.JPG (line #47) and DCP_0003.JPG have an extra NULL inserted at offset 0x7c, thereby making one of these filesystem record be 21 bytes in length instead of 20; how is this handled?

connect to the camera
camera returns 4 images available on the CF card
download all 4 thumbnails
quit from the Kodak software, thereby closing the connection
2001_02_27.txt (300K)