The following document is an overview of the Canon PowerShot serial and USB transfer protocols. It should be a valid reference for models ranging from PowerShot A5 to S20. It has been updated for cameras including the EOS D30, EOS D60, and PowerShot G2. It has not been verified against the EOS 1D or EOS 1Ds, hence there is no section on FireWire communication. No information present in this document was obtained from Canon. Everything is the result of observations and logical analysis. It is by no means guaranteed to be accurate, nor even right. Nevertheless, a lot of people have managed to communicate with their PowerShot cameras using these commands, so they cannot be completely wrong either! An implementation of this communication protocol was made for the GPhoto digital camera software, available at www.gphoto.org.

Here is a list of camera models we know about, those we think we understand, and those we're still working on. The introduction dates come from DPReview.com. The list is here to give you some sort of idea of how current this document is. Notice that the PowerShot S and SD series cameras are usually called that only in North America; they are generally "Digital IXUS" something in Europe and most of Asia, and "Digital IXY" something in Japan. I suspect it all has to do with trying to beat gray-market imports. Usually these brothers under the skin will share a USB product ID, but some early cameras (e.g. PowerShot S100 aka IXY Digital aka Digital IXUS) have different ID's. Camera modelDate of introductionKnown protocol?PowerShot 60013-May-96NOPowerShot 35016-Jul-97NOPowerShot Pro7027-Mar-98yesPowerShot A527-Mar-98yesPowerShot A5 Zoom18-Jan-99yesPowerShot A5030-Mar-99yesPowerShot S1027-Aug-99yesPowerShot S2006-Jan-00yesEOS D3017-May-00yesPowerShot S100 Digital Elph IXY Digital Digital IXUS 17-May-00yesPowerShot G118-Sep-00yesCanon PowerShot Pro90 IS06-Jan-01yesPowerShot A2011-Jan-01yesPowerShot A1011-Jan-01yesPowerShot S30011-Jan-01yesPowerShot S110 Digital IXUS v 10-Apr-01yesPowerShot G217-July-01yesEOS-1D25-Aug-01NOPowerShot S3002-Oct-01yesPowerShot S4002-Oct-01yesPowerShot A3022-Feb-02yesPowerShot A4022-Feb-02yesEOS D6022-Feb-02yesPowerShot A10022-Feb-02yesPowerShot S200 Digital IXUS v2 13-Mar-02yesPowerShot S330 Digital ELPH Digital IXUS 330 13-Mar-02yesPowerShot A20006-May-02yesPowerShot S4516-Aug-02yesPowerShot S230 Digital ELPH Digital IXUS v3 16-Aug-02yesPowerShot G319-Aug-02yesEOS 1Ds24-Aug-02NOPowerShot A7027-Feb-03yesPowerShot A6027-Feb-03yesPowerShot S5027-Feb-03yesPowerShot A30027-Feb-03yesPowerShot S400 Digital IXUS 400 27-Feb-03yesEOS 10D27-Feb-03yesPowerShot SD100 Digital IXUS II 02-Apr-03yesPowerShot G502-May-03yesPowerShot A8020-Aug-03yesEOS Digital Rebel EOS 300D Kiss Digital 20-Aug-03yesPowerShot SD10 Digital ELPH Digital IXUS i 12-Sep-03NOEOS-1D Mark II29-Jan-04NOPowerShot S410 Digital IXUS 430 IXY Digital 430 09-Feb-04yesPowerShot S500 Digital IXUS 500 IXY Digital 500 09-Feb-04yesPowerShot SD110 Digital IXUS IIs 09-Feb-04NOPowerShot A3109-Feb-04yesPowerShot Pro19-Feb-04NOPowerShot S1 IS9-Feb-04yesPowerShot A759-Feb-04yesPowerShot S6010-May-04yesPowerShot A8520-Jul-04yesPowerShot G619-Aug-04NOPowerShot A40019-Aug-04yesEOS 20D19-Aug-04yesPowerShot A9519-Aug-04yesPowerShot S7019-Aug-04yesEOS-1Ds Mark II21-Sep-04NODigital IXUS 40 PowerShot SD300 IXY Digital 50 21-Sep-04NODigital IXUS 30 PowerShot SD200 IXY Digital 40 21-Sep-04yesDigital IXUS i5 PowerShot SD20 IXY Digital L2 21-Sep-04yesPowerShot A51020-Jan-05NOPowerShot A52001-Feb-05NOPowerShot SD400 IXUS 50 IXY Digital 55 17-Feb-05NOPowerShot SD500 IXUS 700 IXY Digital 600 17-Feb-05NODigital Rebel XT EOS 350D EOS Kiss Digital N 17-Feb-05NOPowerShot S2 IS 22-Apr-05NO

This document was written thanks to the efforts of: Wolfgang G. Reissnegger, Werner Almesberger, Philippe Marzouk, Mikael Nyström, Edouard Lafargue, Stephen H. Westin.

The Canon Protocol information. Copyright © 2000, 2003, 2004, 2005 by its respective authors. (see the “Contributors” section). This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the: Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.

(send updates to the gphoto-devel mailing-list)

Update get_directory description to match what was discovered in USB. Describe the structure of the initial ID packet. Find out what the real meaning of the “fffb” command is. Describe error recovery protocol. Describe format of low batt condition. Find out the rest of the commands that were discovered in USB: Make directory Delete directory Change attribute etc. Describe File upload. Describe each command in detail.

Figure out at least basic functionality for newer protocol Delete file Capture sequence Set file attributes Find out the meaning of more values of the status code returned in the word at 0x50.

Add cross-reference links. Integrate serial and USB sections; there's really quite a bit of redundancy and overlap.

09 May 2000: first version with both USB and serial protocols described in the same document. 05 Dec 2002: import to AbiWord for XML output. 28 Jan 2003: Convert DocBook XML, expand USB information $Log$ Revision 1.22 2005/07/29 20:15:26 swestin Changed "Specificatyions" to "Description" in title; this is more truthful, as we aren't specifying, just trying to describe what's there. Revision 1.21 2005/06/21 16:45:13 swestin More info on PowerShot S1 IS. Revision 1.20 2005/06/10 01:38:26 swestin More info on EOS 20D. Cross-referenced new command codes to old. Some info on various models from which I have now seen debug logs. Started to convert ASCII art in serial section to HTML tables. Revision 1.19 2005/04/28 18:03:36 swestin Added some new info from init packet for certain models. Corrected init packet info for Optura 20, Optura 40 camcorders. Corrected one dangling link. Revision 1.18 2005/04/27 19:28:22 swestin We now know the contents of the init packet from PowerShot SD200. Revision 1.17 2005/04/14 20:31:10 swestin Corrected one erroneous output dump. Revision 1.16 2005/04/04 15:16:37 swestin Added information basically related to newer protocol (EOS 20D), especially remote control subcodes 0x1b/0x1c; also added a bit on D60. Revision 1.15 2005/03/31 17:22:10 swestin More insight into "get picture abilities" response. Content of init packet from EOS 350D, which might be a "new" camera like the 20D. "Delete file" for the new protocol (20D) is now understood. Slight revision of "TODO". Revision 1.14 2005/03/25 18:49:27 swestin Added S30, A510, A40, A200 to table of data in init response. Revision 1.13 2005/03/24 22:03:21 swestin Corrected some XML errors. Added info on command codes (new protocol) found by stupidly sending; these are the ones that got a reply. Revision 1.12 2005/03/21 13:44:07 swestin Updated copyright notice. Added more info on new protocol (EOS 20D). Added note on differing response lengths to "get camera photo abilities" with some newer cameras. Revision 1.11 2005/03/17 18:12:01 swestin Minor fix to "Models Covered" table. Added a model or two to the table of initial responses. Revision 1.9 2005/03/09 17:07:39 swestin Tidied up table of known models. More info on camera initial response message. Corrected length of response from "get photo abilities" in new protocol. Revision 1.8 2005/03/08 20:38:40 swestin Added section with list of known cameras. More info on EOS 20D, in various places. Details on EOS 300D's apparent oddball behavior during remote capture. Added A400 info on initialization response packet. Revision 1.7 2005/03/04 20:46:51 swestin Rewrote a bit on the response packet in initialization. Tightened borders on all tables. Added A400 to list of camera models for which we know the initialization response. Revision 1.6 2005/01/15 21:00:24 swestin Fixed inclusion of CVS log info in document. Added more info on response packet in camera initialization. Revision 1.5 2005/01/04 17:17:11 swestin Fixed various typographical errors. Added info observed from EOS 300D. Regularized structure of USB command descriptions. Added real example of interrupt packet received at camera init. Added formatted example of directory read.

We have chosen to describe the Canon Serial Protocol as successive layers. I used OSI-like names but the protocol is not really a network protocol. Data link layer: Responsible for framing, escaping and checksumming messages Transport (packet) layer: Responsible for dividing messages into packets of known length. This layer also handles handshaking, retries, etc. Session (message) layer: Last layer, carrying whole messages, such as download requests, image data, and such information. Currently, all these layers are documented, but we still lack information on how to handle protocol retries, and errors in general.

The following figure illustrates the lower layers of the protocol used by some Canon PowerShot cameras: Example: payload “00 C0 01”[Upper layers]│↑││00 C0 01<CRC>││00 C0 01 12 34 (fictitious CRC)<Escaping>││00 7E E0 01 12 34<Framing>││C0 00 7E E0 01 12 34 C1↓│[Wire format] The upper layers are described later in this file.

Initialization: PC sends sequences of “U” bytes at 9600 bps until the camera responds by sending its ID. Each sequence has a length of 2-8 bytes. The interval to wait between sequences is 0.9-1.04 sec (measured for 8 bytes). When the camera sends its ID, the computer can ask it to change to a higher speed. The speed can go up to 115200 bps. Afterward, a one/two seconds command timeout should be set. E.g. retrieving a directory with 1200 files takes several seconds. Opening a large capacity flash card takes time as well.

Each message begins with the byte C0 and ends with the byte C1. The length of a message including the framing bytes and any escape bytes (see below) never exceeds 1024 bytes.

The value 7E is used to XOR the following byte with the value 0x20. This is used for the following three combinations: 7E 5E → 7E 7E E0 → C0 7E E1 → C1

The last two bytes of a message (without framing and escaping) contain a 16-bit “CCITT” CRC in little-endian order. The CRC is calculated over the entire message, without framing and escaping, and without including the CRC bytes. The CRC generator Assuming the use of http://www.cse.fau.edu/~sam/course/dc_htm/src_dir/crc_att.c, generator polynomial 0102010 (octal), the initial value of “crc” is the CRC generator's initial value (in the original code always zero). is initialized to a length-dependent value. The algorithm for the initial value is not known. However, a table of values emitted by the camera has been compiled and is in crc.c:crc_init. It is indexed by the length, i.e. the number of bytes over which the CRC is taken.

Communication is done through messages, which may be split into several fragments, which are then sent as individual packets. Packets are framed as described earlier in this file.

Each packet consists of the following two-byte header: <sequence> <ptype> There are two sequence numbers: the message sequence number <mseq> and the fragment sequence number <fseq>. They are counted independently and start at zero. <mseq> is reset at the beginning of a session, while <fseq> is reset at the beginning of each message. The following packet types are known: 00 Message fragment 03 Speed message from computer 04 EOT 05 ACK 06 Compatibility? A packet with type 03 is sent once, early in the initialization for the computer to ask the camera to switch to a higher speed. Each message ends with an EOT packet, which is then confirmed by an ACK packet. EOT has the following format: xx 04 xx 00 00 00 | | | indication of the message length. Known values: <mseq> 00 empty message (no fragments) 01 short message (one fragment) 03 used when uploading ff maximum length data packet, more to follow else data packet, at end (observed values: 0f, 7f) ACK has the following format: xx 05 xx 00 00 00 | | | error code <mseq> 00 No error, acknowledged 01 Not acknowledged FF retransmit last sequence else other values not known A packet with type 06 is sent once, as the first packet coming from the camera. It contains a length, just like a normal message fragment, but the message structure is different. An empty message can be used to test if the camera is still responding. If yes, it will respond with an ACK. Example: PC→CAM xx 04 00 00 00 00 CAM→PC xx 05 00 00 00 00

Message fragments have the following structure: xx 00 xx xx ... | | | | | | | fragment data | | data length, MSB | data length, LSB <fseq> The data length is the length (in bytes) of the fragment data that follows the length. Fragment data is simply concatenated to form the complete message.

All messages (except the one with type 03) have the following structure: 00 02 00 00 xx 00 00 xx xx xx 00 00 ... | | | | | | | | | message payload | | | message length, MSB | | message length, LSB | direction code <dir> message type <mtype> The message length is the length of the entire message, including the header shown above. The first four bytes of the message payload <fffb> seem to depend on the message type. The following combinations have been sighted: <mtype><dir><fffb>Operation011214 f7 8a 00 Identify camera request012214 f7 8a 00 Identify camera response01116a 08 79 04 Download image request0111aa 06 79 04 Download “thumbnail” request (see below)01216a 08 79 04 Image data0121aa 06 79 04 “Thumbnail” data0311 Upload file031278 f3 64 01 Get Date041208 d3 9d 00 Set date0512fc d2 9d 00 Change Owner name0911d8 f7 8a 00 Disk info request0921d8 f7 8a 00 Disk info response0a11dc f7 8a 00 Get disk(s) request0a21dc f7 8a 00 Get disk(s) response0a1270 f6 8a 00 Power Supply Status0a2270 f6 8a 00 Power Supply Status response0b1194 f6 8a 00 List without date request0b2194 f6 8a 00 List without date response0b11a8 f6 8a 00 List with date request0b21a8 f6 8a 00 List with date response0d118c f4 7b 00 Delete image request0d218c f4 7b 00 Delete image response0e11— — — — Set file attributes. Important note: it seems that the “fffb” part can be set to 0 in every case, and the commands will still work. The exact meaning of this part of the packet is unknown. It is probably used as a unique ID for each transaction and can be chosen at random each time.

The identify camera request has no data. The identify camera response has the following structure: 00 00 00 00 00 02 00 00 00 00 00 01 <camera_name> 00 (more 00s) On the S10, the response has the following structure: 00 00 00 00 00 04 00 00 00 00 00 01 and then: <firmware rev> (32 bit word) (offset: 0x08) <model name> (C string) (offset: 12 / 0x0c) <owner name> (C string) (offset: 44 / 0x2c) Firmware version: 04 03 02 01 is version 1.2.3.4, 01 00 00 01 is version 1.0.0.1 Example (full packet): for a PowerShot S10 with firmware 1.0.0.0 RECV: (98 bytes) 00000000: 00 00 5C 00 02 00 00 00 01 00 00 22 5C 00 00 00 - ..\........"\... 00000010: 14 F7 8A 00 00 00 00 00 00 04 00 00 00 00 00 01 - ................ 00000020: 43 61 6E 6F 6E 20 50 6F 77 65 72 53 68 6F 74 20 - Canon PowerShot 00000030: 53 31 30 00 00 00 00 00 00 00 00 00 00 00 00 00 - S10............. 00000040: 45 64 6F 75 61 72 64 20 4C 61 66 61 72 67 75 65 - Edouard Lafargue 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - ................ 00000060: 9C EA - ..

Offsets in the payload: 0x04 contains a byte with power status: 0x6=good, 0x4=bad 0x07 contains a byte with power type: 0x10=ac-adapter, 0x30=battery Example (full packet): RECV: (30 bytes) 00000000: 00 00 18 00 02 00 00 00 0A 00 00 22 18 00 00 00 - ...........".... 00000010: 70 F6 8A 00 00 00 00 00 06 00 00 30 B5 5A - p..........0.Z

The name (payload) can be 30 characters max.

The payload of this message is 4 bytes. It must be the same Unix format as in the directory with date request. For example, 01/01/2000 is 80 43 6D 38.

The get disk(s) request has no data. The get disk response has the following structure: 00 00 00 00 <disk_name> 00 Disk name example: "C:"

Disk info requests have the following structure: <root_name> 00 Disk info responses have the following structure: 00 00 00 00 xx xx xx xx xx xx xx xx | | | Free space (in bytes) Total capacity (in bytes) Root name example: "C:\" (The trailing slash is required.)

Note: It seems that directory listing as described in the USB part is more accurate, when it comes to the meaning of the first byte (“date/without date”). List requests have the following structure: xx <directory_name> 00 00 00 | 00 if with date, 02 if without date Directory name example: "C:\PWRSHOT", "D:", or "D:\.", but not "D:\" (trailing slash), or "D:\.\FOO" (dot not allowed in path ?) List responses have the following structure: Failure: 00 00 00 00 01 00 00 00 00 00 00 00 Success: 00 00 00 00 xx 80 00 00 00 00 00 00 00 00 00 00 | 01 if last message, 00 if more <directory_name> 00 <type> 00 <size> <date> <entry_name> 00 ... <type> 00 <size> <date> <entry_name> 00 (many 00s) <type> is one byte containing the file attributes: bit0 (0x01)Set if this file is protected from deletionbit4 (0x10)Set if this directory contains an item but was not recursively entered (NOT used with the “set attributes” command)bit5 (0x20)Set if the file has not yet been downloaded (must be manually switched)bit7 (0x80)Set if this directory was entered recursively (NOT used with the “set attributes” command) <size> is the size in bytes. Directory size is always 0. Entry name example: "AUT_1201.JPG" or "MISC" The date is a four bytes Unix-style date. The list without date responses also contains the four data bytes, but sets them to zero. Note: it's unclear if the list with/without date commands differ in any other way than the inclusion of the date. If the directory is so large that additional messages are needed, they have the following structure: 00 00 00 00 xx <entry> | 1 if last message, 00 if more The boundary between messages is always chosen such that the terminating 00 of an entry is the last byte in the earlier message.

Download requests have the following structure: 00 00 00 00 00 xx 00 00 <name> 00 | Length of name (including terminating \0) Data messages have the following structure: 00 00 00 00 xx xx xx xx xx xx xx xx xx xx xx xx xx 00 00 00 ... | | | | | | | | | data | | | 00 if more, 01 at end | | data size in this message | current offset total length All lengths are measured in bytes. The camera only sends the first 10813 bytes from the image for the thumbnail download request. However it is not a valid thumbnail image, the first part is the EXIF header, the second part is the thumbnail itself between a FF D8 and a FF D9, the remaining is the beginning of the picture. The camera always sends 8 messages then waits for an ACK from the computer. If the computer has not received everything, it sends an ACK with an error value asking to retransmit one of the eight packets sent. These error values are not yet known.

The serial upload protocol description is not done yet. These are just ideas on what it could be. Maybe it's right, maybe it's wrong. This command sends a file to the camera. Request structure: xx 00 00 00 00 xx 00 00 <name> Each data block has the following format: 00 00 00 02 XX XX XX XX - YY YY YY YY filename - datablock XX XX XX XX : offset within the file for this block YY YY YY YY : len2: length of this block filename : 0-terminated string datablock: the data itself.

In order to switch the camera off, you need to send the following characters (directly, without extra framing): C0 00 02 55 2C C1 C0 00 04 01 00 00 00 24 C6 C1

If the camera batteries run too low during a transfer and the camera needs to switch itself off, it will send a special packet just before going down. You can see how it is handled in psa50.c

When mentioning word, 32bit word little-endian is implied. References to usb11.pdf (Chapter 9.3 page 199): http://www.usb.org/developers/data/usbspec.zip (1.8Mb) bmRequestType is 0xC0 during read and 0x40 during write. bRequest is 0x4 if length of data is >1, 0x0c otherwise (length >1 ? 0x04 : 0x0C) wValue differs between operations. wIndex is always 0x00 wLength is simply the length of data. In Linux sending/receiving commands is using usb_control_msg (in usb.c). usb11.pdf nameusb.c name bmRequestTyperequesttype bRequestrequest wValuevalue wIndexindex wLengthsize

Control_transfer_read requesttype=0xC0 value=0x55 length=1 Camera responds with following data (single char): “A” Camera was already active “C” Camera was woken up “I” Unknown (some kind of error; seen with a hotplug problem on Linux) “E” Unknown (some kind of error) Control_transfer_read requesttype=0xC0 value=0x1 length=0x58 The first 0x48 bytes can be trashed, save the last 0x10 bytes and use them as data in next step. Example: 00000000 18 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 00000040 01 00 02 00 43 30 A9 04-00 08 00 00 FF FF FF FF ....C0.......... 00000050 00 FD 00 00 00 FD 00 00 ........ The bytes 0x40-0x43 seem to vary from camera to camera: the S20 here has 01 00 02 00. These bytes might identify which version of the protocol is used. The following table summarizes our observations to date. Models0x400x440x480x4C0x500x54G1, Pro90 IS, Digital IXUS00 05 07 00USBid0x800 (2048)-10xfd00 (64768)0xfd00 (64768)S10, S2001 00 02 00USBid0x800 (2048)-10xfd00 (64768)0xfd00 (64768)G2, D30, D60, 300D, S110, A10, A20, S30, S30001 00 05 03USBid0x800 (2048)-10xfd00 (64768)0xfd00 (64768)300D01 00 05 83USBid0x800 (2048)-10xfd00 (64768)0xfd00 (64768)G3, A60, A70, A75, A80, A300, A400, A510, S45, S50, S230, S400, SD20001 06 15 83USBid0x800 (2048)-10xfd00 (64768)0xfd00 (64768)S1 IS01 06 15 8304 a9 30 850x800 (2048)-10xfd00 (64768)0xfd00 (64768)20D01 06 15 830x800001750x800 (2048)0x10000 (65536)0xfd00 (64768)0x10000 (65536)350D01 06 15 830x800001890x800 (2048)0x10000 (65536)0xfd00 (64768)0x10000 (65536)Optura 200 MC camcorder03 05 04 81USBid0x800 (2048)-10xfd00 (64768)0xfd00 (64768)Optura 20, Optura 40 camcorders03 05 04 81USBid0x200 (512)-10x200 (512)0xfd00 (64768)S200, S330, A30, A40, A20003 05 15 81USBid0x800 (2048)-10xfd00 (64768)0xfd00 (64768) In the older version of the protocol, the USB vendor and product ID are normally contained in bytes 0x44-0x47 of this packet: here 0x04A93043 for vendor 0x04a9, product 0x3043 identifies this as a PowerShot S20. Unfortunately, the meaning of these bytes seems to have changed in the newer protocol; for an EOS 20D, we get 0x80000175, which is identical with bytes 0x56-0x59 of a response to the Get Photo Abilities request. This is interesting, because the same bytes wind up in each JPEG or CR2 file as a LONG value for tag 0x10 within the MakerNote. That may be a model identifier for the camera. Even stranger, there seems to be a group of cameras (apparently using the older protocol) that all report 0x3085 as the product ID, which is correct for the PowerShot G5. The bytes 0x48-0x57 also vary from camera to camera. I think they are 4-byte integers, and suspect that they specify maximum transfer sizes in some way. If the response to step 1 was 'A', Control_transfer_read requesttype=0x4 value=0x4 length=0x50. Example: 0000 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0040 00 08 00 00 ff ff ff ff 00 fd 00 00 00 fd 00 00 ................ This looks to me like the payload (here from an EOS D30) duplicates the last 16 bytes of the previous packet. Throw away the data and we are finished with the initializationMany cameras fail the first camera command after this (the command response is returned without the first 0x40 bytes). It seems Canon got the same problem and worked around it in the Windows driver instead of fixing the firmware. The workaround is to retry the first camera command (Identify camera is a suitable command) up to four times.. If the response to step 1 was 'C', Take the packet from step 2, change the byte at offset 0 to 0x10, move the last 0x10 bytes to position 0x40 and Control_transfer_write requesttype=0x40 value=0x11 length=0x50 PC sign should now appear on the LCD. Not all cameras have PC signs though. We should now read a total of 0x44 bytes from bulk_in, but some cameras are picky at this stage and we must first read 0x40 bytes and then 0x4 bytes (the symptoms if not doing this right is that camera initialization only works every second time). Newer Canon USB cameras return 0x54 0x78 0x00 0x00 ('Tx\0\0') under some circumstancesIt seems this was due to an error in the init sequence described in earlier versions of this document. When done as the Windows driver does it, we always get 00 00 00 00 back as the last four bytes of step 5.as the last four bytes in either of these two reads. If we get that from the first read we should not try to read the next 0x4 bytes. Example: 00000000 04 00 00 00 02 03 00 00-00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 00000040 00 00 00 00 .... Read 16 (0x10) bytes from the interrupt endpoint. Some newer cameras (e.g. the PowerShot S50) return the bytes 8 at a time, so two reads may be needed. The code in bytes 0x44-0x47 is 0x20. Example (EOS 300D): 0000 02 00 00 00 20 00 00 00-10 00 00 00 00 00 00 00 .... ........... Note: The EOS 20D seems to return the 16 bytes (8 at a time) after the “Power supply status” command, rather than here.

0000000: xx xx xx xx yy yy yy yy - 00 00 00 00 00 00 00 00 0000010: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 0000020: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 0000030: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 0000040: 02 00 00 00 UU 00 cc VV - xx xx xx xx SS SS SS SS 0000050: ... (payload/arguments) xx xx xx xx : length (word) yy yy yy yy : cmd3 (word) UU : cmd1 (byte) VV : cmd2 (byte) xx xx xx xx : Length (again) SS SS SS SS : sequence number (word) cc : must be zero in old-style protocol. In the new protocol, this byte must contain 0x10 for commands with cmd3=0x201, 0x20 for commands with cmd3=0x202. “length” is the length of the block, excluding the first 0x40 bytes in block, and is never less than 0x10. cmd1 and cmd2 are each a single byte cmd3 is a word Sequence number is a word, sent back in command reply. This may have more meaning than meets the eye; for example, the last byte is nearly always zero, and similar commands tend to have the same last two bytes in this field. USB arguments: value is always 0x10 length is TOTAL length (0x54 in example below) Example command block: Disk info request 0000000: 14 00 00 00 01 02 00 00-00 00 00 00 00 00 00 00 ................ 0000010: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0000020: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0000030: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0000040: 02 00 00 00 09 00 00 11-14 00 00 00 78 56 34 12 ............xV4. 0000050: 44 3A 5C 00 D:\.

A normal response block will be at least 0x54 bytes long. 0000 00 00 00 00 yy yy 00 00 00 00 00 00 00 00 00 00 ................ 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0000 02 00 00 00 UU 00 00 VV xx xx xx xx SS SS SS SS ......."........ 0010 kk kk kk kk .... yyyy will contain an altered copy of cmd3. The high-order byte of cmd3 will be incremented from 2 to 3 (0x201→0x301, 0x202→0x302). UU will contain a copy of cmd1. VV will contain an altered copy of cmd2, incremented by 0x10 (0x11→0x21, 0x12→0x22). The first word of the response block will not contain the length xxxxxxxx will contain the length as a low-endian 32-bit integer at 0x48. This is the length of the useful information, i.e. (total block length)-0x40. SSSSSSSS at 0x4c is just a copy of the word that was sent to the camera in this location; it can be used to match a response to the command that elicited it. kkkkkkkk at 0x50 seems to be a status code; it will be zero if the command succeeded. Here is an example of a successful response of 0x58 bytes; there is a word of information after the status code. 0000 00 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ................ 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0000 02 00 00 00 0a 00 00 22 18 00 00 00 a4 f4 d6 00 ......."........ 0010 00 00 00 00 06 00 00 20 ....... Responses of variable length (those where cmd3 is 0x202 rather than 0x201) are handled differently. For these, the first response will have length 0x40 and contain only the length of the variable response. Here is an example 00000000 00 00 00 00 02 03 CF 1F-0D 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ Here we must read 0x00001fcf = 8143 bytes, which will come in unformatted blocks, to be read in chunks as described below. When a response is greater than 0x40 in length (i.e. almost all responses), it must be read in multiple operations. First read the largest subset divisible by 0x40, then a short read with the remainder. The longest bulk reads will be to download images and thumbnails, but generally it's not a good idea to read more than 0x1400 bytes. The first read may need to be split into shorter operations. To read a response of “length” bytes, #define MAX_BULK_XFER 0x1400 do { if(length - bytes_read >MAX_BULK_XFER) read_chunk = MAX_BULK_XFER; else if(length - bytes_read >0x40) read_chunk = (length - bytes_read) / 0x40 * 0x40; else read_chunk = length - bytes_read; actually_read = usb_bulk_read(handle, CAMERA_BULK_READ_EP, buffer + bytes_read, read_chunk, USB_TIMEOUT); if(actually_read != read_chunk) error; bytes_read += read_chunk; } while(bytes_read <length);

A status code is returned in the word at 0x50 in the response. Here is a list of known status codes. Code Meaning 0x00000000 Success. This is the code most commonly seen. 0x02000022 File not found 0x02000029 File was protected 0x0200002a Compact Flash card full (on “set transfer mode” and “release shutter”) 0x02000081 “EOS lock keys” failed, e.g. shutter release is half-depressed or camera is in review or menu mode. 0x02000082 “EOS unlock keys” failed, e.g. tried to unlock keys when they weren't locked to begin with. 0x02000085 “camera control initialization” failed. Couldn't extend lens (on G2) Camera was left in camera control mode For D60: we just filled the CF card (on next “camera control initialization”; power cycle clears this) 0x02000086 Path not found or invalid parameters. Indicates either that the pathname wasn't found, e.g. for “Get Directory”, or that the command block was in error, e.g. the length wasn't correct, or the command for Set File Attributes had only one string, rather than a pathname followed by a filename. 0x00000086 Returned by camera in newer protocol (e.g. EOS 20D) from “Unlock keys” when keys weren't locked. 0x02000087 No Compact Flash card

cmd1cmd3Argument(e.g.)Response LengthOperation0x010x202 0x00000000 0x00001400 "DCIM\100CANON\IMG_0100.JPG" <NUL> LGet picture0x050x201 "D:\DCIM" <NUL>0x5 Make directory0x060x201 "D:\DCIM" <NUL>0x54 Delete directory0x090x201 "D:\" <NUL>0x5c Disk info request0x0A0x202 noneL Flash device identification0x0B0x202 0x01 "D:\DCIM"<NUL> <NUL> <NUL>L Get directory0x0D0x201 "D:\DCIM\100CANON" <NUL> "IMG_0002.JPG" <NUL>0x54 Delete file0x0E0x201 0x00000021 "D:\DCIM\100CANON" <NUL> "IMG_0002.JPG" <NUL>0x54 Set file attributes0x0F0x201 0x00000021 "D:\DCIM\158CANON\AUT_0001.JPG" <NUL> <NUL>0x54 Set file time cmd1cmd3Argument(e.g.)Response LengthOperation0x010x201 none0x9c Identify camera0x030x201 none0x60 Get time0x040x201 0x390873f0 0x000000000x54 Set time0x050x201 "Donald Duck" <NUL>0x54 Change owner0x0A0x201 none0x58 Power supply status0x130x201 variesvaries Remote camera control0x170x202 0, 0x1400, 1, 0x2d011516L Download Captured Image0x1A0x201 44 bytes0x80 Unknown: EOS D30 only0x1B0x201 0x000000060x54 EOS (D30/D60) Lock Keys0x1C0x201 none0x54 EOS (D30/D60) Unlock Keys0x1D0x201 none0x58 Get EOS Body ID0x1F0x201 none0x384 Get camera photo abilities0x200x201 none0x54 Lock keys, turn off LCD A length of L corresponds to a cmd3 of 0x202 and means that the program reads 0x40 from bulk in, checks for a word at position 0x06 for the length, and then reads the rest in 0x1400 buffers as described above.

Downloads a full image or thumbnail from camera storage. requesttype=0x01 Example command: 0x76 bytes. Command length will vary with length of pathname string. 0000 36 00 00 00 02 02 00 00-00 00 00 00 00 00 00 00 6............... 0010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0040 02 00 00 00 01 00 00 11-36 00 00 00 08 00 00 00 ........6....... 0050 00 00 00 00 00 30 00 00-44 3a 5c 44 43 49 4d 5c .....0..D:\DCIM\ 0060 31 35 35 43 41 4e 4f 4e-5c 49 4d 47 5f 35 35 39 155CANON\IMG_559 0070 33 2e 4a 50 47 00 - 3.JPG. Parameters: Flag for download of thumbnail: 0x00000001 to download thumbnail, 0x00000000 to download full image file. Size of bulk transfers to use (Canon ZoomBrowser EX uses 0x1400) Pathname of file to download, terminated by a NUL byte This example requests download of the full image in file “D:\DCIM\155CANON\IMG_5593.JPG”, using transfers of 0x3000 bytes. The response (from a PowerShot G2) was 0x40 bytes: 0000 00 00 00 00 02 03 84 24-19 00 00 00 00 00 00 00 .......$........ 0010 00 00 00 00 00 30 00 00-44 3a 5c 44 43 49 4d 5c .....0..D:\DCIM\ 0020 31 35 35 43 41 4e 4f 4e-5c 49 4d 47 5f 35 35 39 155CANON\IMG_559 0030 33 2e 4a 50 47 00 81 ce-58 39 00 00 f8 95 f1 3b 3.JPG...X9.....; This indicates a total file size of 1647748 bytes (0x00192484 from offset 0x06). After this, a series of messages with length 0x3000 was read. Finally, a read of 0x484 finished download of the image. Example command: 0x76 bytes. Command length will vary depending on the length of the pathname string. 0000 36 00 00 00 02 02 00 00-00 00 00 00 00 00 00 00 6............... 0010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0040 02 00 00 00 01 00 00 11-36 00 00 00 06 00 00 00 ........6....... 0050 01 00 00 00 00 30 00 00-44 3a 5c 44 43 49 4d 5c .....0..D:\DCIM\ 0060 31 35 35 43 41 4e 4f 4e-5c 49 4d 47 5f 35 35 39 155CANON\IMG_559 0070 33 2e 4a 50 47 00 - 3.JPG. This requests the download of just the thumbnail from the file “D:\DCIM\155CANON\IMG_5593.JPG”, in chunks of 0x3000 bytes. Initial response (from a PowerShot G2): 0x40 bytes 0000 00 00 00 00 02 03 9b 18-00 00 00 00 00 00 00 00 ................ 0010 01 00 00 00 00 30 00 00-44 3a 5c 44 43 49 4d 5c .....0..D:\DCIM\ 0020 31 35 35 43 41 4e 4f 4e-5c 49 4d 47 5f 35 35 39 155CANON\IMG_559 0030 33 2e 4a 50 47 00 fe d0-08 5a 00 00 90 12 17 2c 3.JPG....Z....., This indicates a length of 6299 bytes for the thumbnail (0x0000189b at offset 0x06). This is followed by a single read of 6299 bytes, downloading EXIF thumbnail info.

requesttype=0x05 Command: variable length (here 0x58) 0000 18 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 ................ 0010 47 71 cf e1 5a cb 63 28 ab bd 3e f3 9c 9b c5 1a Gq..Z.c(..>..... 0020 6d c6 a1 05 c4 92 dc c5 2d a1 dc 86 18 c3 6f cf m.......-.....o. 0030 50 72 c3 1d 3f 5a ec 74 6f 88 51 cf 73 6d 71 72 Pr..?Z.to.Q.smqr 0040 02 00 00 00 05 00 00 11 18 00 00 00 a4 e7 12 00 ................ 0050 44 3a 5c 44 43 49 4d 00 D:\DCIM. Response: 0x54 bytes 0000 14 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ................ 0010 81 7d 80 80 80 84 80 7c 7e 7f 7f 7e 78 77 79 7e .}.....|~..~xwy~ 0020 82 82 7f 7e 7f 84 80 7b 7f 7f 80 87 85 81 80 7f ...~...{........ 0030 83 84 80 7e 7f 80 83 82 82 83 84 8a 89 83 81 7c ...~...........| 0000 02 00 00 00 05 00 00 21 14 00 00 00 a4 e7 12 00 .......!........ 0010 00 00 00 00 ....

requesttype=0x06 Command: 0x54 bytes 00000000 00 00 00 00 01 03 00 00-00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 00000040 02 00 00 00 06 00 00 21-14 00 00 00 78 56 34 12 .......!....xV4. 00000050 00 00 00 00 ....

requesttype=0x09 Command: variable length (here 0x54) 0000 14 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 ................ 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0040 02 00 00 00 09 00 00 11 14 00 00 00 68 f1 12 00 ............h... 0050 43 3a 5c 00 C:\. Argument structure: Null-terminated string containing the name of the disk. Response: 0x5c bytes 0000 00 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ................ 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0000 02 00 00 00 09 00 00 21 1c 00 00 00 68 f1 12 00 .......!....h... 0010 00 00 00 00 00 a0 a7 07 00 a0 a4 07 ............ 0x54 contains a word with total bytes on flash. 0x58 contains a word with bytes free.

requesttype=0x0a Command: 0x50 bytes 0000 10 00 00 00 02 02 00 00 00 00 00 00 00 00 00 00 ................ 0010 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 ................ 0020 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 ................ 0030 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 ................ 0040 02 00 00 00 0a 00 00 11 10 00 00 00 20 f6 12 00 ............ ... Response: variable length (here 0x44 bytes) (PowerShot G2) 0000 00 00 00 00 02 03 04 00 00 00 00 00 00 00 00 00 ................ 0010 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 ................ 0020 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 ................ 0030 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 ................ 0000 44 3a 00 00 D:..

requesttype=0x0b Command: variable length (here 0x5b bytes) 0000 1b 00 00 00 02 02 00 00-00 00 00 00 00 00 00 00 ................ 0010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0040 02 00 00 00 0b 00 00 11-1b 00 00 00 06 00 00 00 ................ 0050 00 44 3a 5c 44 43 49 4d-00 00 00 .D:\DCIM... The byte at offset 0x50 gives the level of recursion allowed, here zero (no recursion). This is followed by the directory pathname, here “D:\DCIM”. Response: 0x40 bytes (PowerShot G2) 0000 00 00 00 00 02 03 56 00-00 00 00 00 00 00 00 00 ......V......... 0010 40 04 fe 15 d3 78 6a fb-54 bf d1 3c ed 63 4a 5d @....xj.T..<.cJ] 0020 2a f7 cf 75 10 db cd e6-a3 47 9f 95 c3 e0 67 23 *..u.....G....g# 0030 a8 20 63 df ad 22 bc 8d-c8 6f 01 8a 56 78 8a 24 . c.."...o..Vx.$ As with all “long” dialogues, the message contains only the length of data to follow, as a word starting at offset 0x06. In this case, the subsequent data will be 0x56 bytes long. The next message from the camera is: 0000 80 00 00 00 00 00 48 e2-48 3e 44 3a 5c 44 43 49 ......H.H>D:\DCI 0010 4d 00 10 00 00 00 00 00-44 e6 43 3e 43 41 4e 4f M.......D.C>CANO 0020 4e 4d 53 43 00 10 00 00-00 00 00 64 f6 48 3e 31 NMSC.......d.H>1 0030 35 35 43 41 4e 4f 4e 00-10 00 00 00 00 00 52 fb 55CANON.......R. 0040 48 3e 31 35 36 43 41 4e-4f 4e 00 00 00 00 00 00 H>156CANON...... 0050 00 00 00 00 00 00 - ...... Error codes: 0x00000000 No errors 0x02000022 File not found 0x02000029 File was protected 0x02000086 Path not found The example shows four entries. Each entry contains 1 byte attribute bits (described in ) 1 zero byte 4 bytes file size in bytes (zero if directory) 4 bytes UNIX time File name (null-terminated string of arbitrary length) “..” in name means “leave directory”. An entry with attribute, date, length, and name all zero indicates the end of the directory listing. Since these are all directory entries, each shows a file size of zero.: “D:\DCIM”, attribute byte 0x80. This is the name of the directory listed. . “CANONMSC”, attribute byte 0x10, time Fri Feb 7 22:00:52 2003 (0x3e43e644). “155CANON”, attribute byte 0x10, time Tue Feb 11 18:11:00 2003 (0x3e48f664). “156CANON”, attribute byte 0x10, time Tue Feb 11 18:32:02 2003 (0x3e48fb52). Here is an example of dealing with multiple levels in the directory hierarchy. The contents of this camera are: Thu May 4 00:11:40 2000 D:\DCIM\100CANON\IMG_0001.JPG 778435 Thu May 4 00:28:32 2000 D:\DCIM\100CANON\IMG_0002.JPG 44409 Thu May 4 00:28:32 2000 D:\DCIM\CANONMSC\100.CTG 2634 Thu May 4 00:28:32 2000 D:\DCIM\CANONMSC\D.CTG 383 Directory contents: "D:" (recurse = 0x0) 00000000 80 00 00 00 00 00 00 00-00 00 44 3A 00 10 00 00 ..........D:.... 00000010 00 00 00 C6 B5 10 39 44-43 49 4D 00 00 00 00 00 ......9DCIM..... 00000020 00 00 00 00 00 00 00 ....... Directory contents: "D:" (recurse = 0x1) 00000000 80 00 00 00 00 00 00 00-00 00 44 3A 00 80 00 00 ..........D:.... 00000010 00 00 00 36 C0 10 39 2E-5C 44 43 49 4D 00 10 00 ...6..9.\DCIM... 00000020 00 00 00 00 36 C0 10 39-31 30 30 43 41 4E 4F 4E ....6..9100CANON 00000030 00 10 00 00 00 00 00 CC-B5 10 39 43 41 4E 4F 4E ..........9CANON 00000040 4D 53 43 00 80 00 00 00-00 00 00 00 00 00 2E 2E MSC............. 00000050 00 00 00 00 00 00 00 00-00 00 00 00 ............ Directory contents: "D:" (recurse = 0x2) 00000000 80 00 00 00 00 00 00 00-00 00 44 3A 00 80 00 00 ..........D:.... 00000010 00 00 00 36 C0 10 39 2E-5C 44 43 49 4D 00 80 00 ...6..9.\DCIM... 00000020 00 00 00 00 3C C0 10 39-2E 5C 31 30 30 43 41 4E ....<..9.\100CAN 00000030 4F 4E 00 20 00 C3 E0 0B-00 3C C0 10 39 49 4D 47 ON. .....<..9IMG 00000040 5F 30 30 30 31 2E 4A 50-47 00 20 00 79 AD 00 00 _0001.JPG. .y... 00000050 30 C4 10 39 49 4D 47 5F-30 30 30 32 2E 4A 50 47 0..9IMG_0002.JPG 00000060 00 80 00 00 00 00 00 00-00 00 00 2E 2E 00 80 00 ................ 00000070 00 00 00 00 30 C4 10 39-2E 5C 43 41 4E 4F 4E 4D ....0..9.\CANONM 00000080 53 43 00 20 00 4A 0A 00-00 30 C4 10 39 31 30 30 SC. .J...0..9100 00000090 2E 43 54 47 00 20 00 7F-01 00 00 30 C4 10 39 44 .CTG. .....0..9D 000000A0 2E 43 54 47 00 80 00 00-00 00 00 00 00 00 00 2E .CTG............ 000000B0 2E 00 80 00 00 00 00 00-00 00 00 00 2E 2E 00 00 ................ 000000C0 00 00 00 00 00 00 00 00-00 00 .......... Here is a formatted listing of the entries: D : 0000: 0080 00000000 00000000 44 3A 00 . \ D C I M 000D: 0080 00000000 3910C036 2E 5C 44 43 49 4D 00 . \ 1 0 0 C A N O N 001E: 0080 00000000 3910C03C 2E 5C 31 30 30 43 41 4E 4F 4E 00 I M G _ 0 0 0 1 . J P G 0033: 0020 000BE0C3 3910C03C 49 4D 47 5F 30 30 30 31 2E 4A 50-47 00 I M G _ 0 0 0 2 . J P G 004A: 0020 0000AD79 3910C430 49 4D 47 5F 30 30 30 32 2E 4A 50 47 00 . . 0061: 0080 00000000 00000000 2E 2E 00 . \ C A N O N M S C 006E: 0080 00000000 3910C430 2E 5C 43 41 4E 4F 4E 4D 53 43 00 1 0 0 . C T G 0083: 0020 00000A4A 3910C430 31 30 30 2E 43 54 47 00 D . C T G 0095: 0020 0000017F 3910C430 44 2E 43 54 47 00 . . 00A6: 0080 00000000 00000000 2E 2E 00 . . 00B2: 0080 00000000 00000000 2E 2E 00 00BF: 0000 00000000 00000000 00

requesttype=0x0d Command: variable length (here 0x7e) 0000 3c 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 <............... 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0040 02 00 00 00 0d 00 00 11 3c 00 00 00 f8 f6 12 00 ........<....... 0050 43 3a 5c 44 43 49 4d 5c 31 33 33 43 41 4e 4f 4e C:\DCIM\133CANON 0060 00 43 52 57 5f 33 33 34 31 2e 43 52 57 00 43 52 .CRW_3341.CRW.CR 0070 57 5f 33 33 34 31 2e 54 48 4d 00 00 W_3341.THM.. Here we delete both a raw image and its corresponding thumbnail file. Response: 0x54 bytes 0000 00 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ................ 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0000 02 00 00 00 0d 00 00 21 14 00 00 00 f8 f6 12 00 .......!........ 0010 00 00 00 00 .... Status codes: 0x00000000 No errors 0x02000022 File not found 0x02000029 File was protected 0x02000086 Path not found (success on at least G2 and EOS D30/D60) Example command (delete JPEG image): 0000 2f 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 /............... 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0040 02 00 00 00 0d 00 00 11 2f 00 00 00 a8 f6 12 00 ......../....... 0050 43 3a 5c 44 43 49 4d 5c 31 33 33 43 41 4e 4f 4e C:\DCIM\133CANON 0060 00 49 4d 47 5f 33 33 34 33 2e 4a 50 47 00 00 .IMG_3343.JPG.. We can specify a series of file names separated by NULs, with a double NUL at the end. Data received via bulk_in after a command block: (Delete file) (file did not exist). 00000000 00 00 00 00 01 03 00 00-00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 00000040 02 00 00 00 0D 00 00 21-14 00 00 00 78 56 34 12 .......!....xV4. 00000050 22 00 00 02 "... Data received via bulk_in after a command block: (Delete file) (file was protected) 00000000 00 00 00 00 01 03 00 00-00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 00000040 02 00 00 00 0D 00 00 21-14 00 00 00 78 56 34 12 .......!....xV4. 00000050 29 00 00 02 )... Data received via bulk_in after a command block: (Delete file) (successful) 00000000 00 00 00 00 01 03 00 00-00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 00000040 02 00 00 00 0D 00 00 21-14 00 00 00 78 56 34 12 .......!....xV4. 00000050 00 00 00 00 .... Data received via bulk_in from a PowerShot G2 after a command block: (Delete file) (successful) 00000000 14 00 00 00 01 03 00 00-00 00 00 00 00 00 00 00 ................ 00000010 20 00 00 00 00 00 00 00-00 00 00 00 00 00 01 00 ............... 00000020 00 00 c2 00 00 00 00 02-00 00 40 00 00 00 00 00 ..........@..... 00000030 02 00 00 00 00 00 00 00-00 02 20 00 00 00 20 00 .......... ... . 00000040 02 00 00 00 0d 00 00 21-14 00 00 00 07 00 00 00 .......!........ 00000050 86 00 00 02 - ....

requesttype=0x0e Command: variable length (here 0x73, from a PowerShot G2) 0000 33 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 3............... 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0040 02 00 00 00 0e 00 00 11 33 00 00 00 f4 f1 12 00 ........3....... 0050 00 00 00 00 44 3a 5c 44 43 49 4d 5c 31 35 38 43 ....D:\DCIM\158C 0060 41 4e 4f 4e 00 41 55 54 5f 30 30 30 31 2e 4a 50 ANON.AUT_0001.JP 0070 47 00 00 G.. I don't know where the data are put, unless it's the word at 0x50. Response: 0x54 bytes 0000 14 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ................ 0010 31 2e 4a 50 47 00 5e 26 77 98 c7 07 87 6d 3d 5e 1.JPG.^&w....m=^ 0020 c7 76 07 0c eb d4 5d 8f 67 06 cf 47 b2 5b 4b 28 .v....].g..G.[K( 0030 92 35 41 80 14 74 c5 79 77 c4 bf 88 96 da 44 6f .5A..t.yw.....Do 0040 02 00 00 00 0e 00 00 21 14 00 00 00 f4 f1 12 00 .......!........ 0050 00 00 00 00 .... Error codes: 0x00000000 No errors 0x02000022 File not found Data received via bulk_in after a command block: (Set file attributes) (file did not exist). 00000000 00 00 00 00 01 03 00 00-00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 00000040 02 00 00 00 0E 00 00 21-14 00 00 00 78 56 34 12 .......!....xV4. 00000050 22 00 00 02 "... File attributes: see

requesttype=0x0f Command: variable length (here 0x73, from a PowerShot G2) 0000 33 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 3............... 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0040 02 00 00 00 0f 00 00 11 33 00 00 00 98 e7 12 00 ........3....... 0050 5a 59 63 3e 44 3a 5c 44 43 49 4d 5c 31 35 38 43 ZYc>D:\DCIM\158C 0060 41 4e 4f 4e 5c 41 55 54 5f 30 30 30 31 2e 4a 50 ANON\AUT_0001.JP 0070 47 00 00 G.. Parameters: 32-bit Unix time, full pathname of file. Terminated by two NUL characters, not just one. This command ended the upload of a file to “D:\DCIM\158CANON\AUT_0001.JPG” on a PowerShot G2 camera. Response (0x54 bytes): 0000 14 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ................ 0010 e6 24 e3 a5 31 8c 20 71 90 69 46 40 07 93 40 87 .$..1. q.iF@..@. 0020 29 04 92 4f a7 14 80 73 d3 ad 20 18 aa 03 71 de )..O...s.. ...q. 0030 94 f5 e7 a5 0c 18 84 63 22 b0 34 1f 9f 5c be 94 .......c".4..\.. 0040 02 00 00 00 0f 00 00 21 14 00 00 00 98 e7 12 00 .......!........ 0050 00 00 00 00 .... Error codes: unknown

requesttype=0x01 Command: 0x50 bytes 0000 10 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 ................ 0010 43 3a 5c 44 6f 63 75 6d 65 6e 74 73 20 61 6e 64 C:\Documents and 0020 20 53 65 74 74 69 6e 67 73 5c 44 65 66 61 75 6c Settings\Defaul 0030 74 20 55 73 65 72 00 77 69 6e 64 69 72 3d 43 3a t User.windir=C: 0040 02 00 00 00 01 00 00 12 10 00 00 00 00 f5 d6 00 ................ Response: 0x9c bytes (from an EOS D60): 0000 00 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ................ 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0040 02 00 00 00 01 00 00 22 5c 00 00 00 00 f5 d6 00 ......."\....... 0050 00 00 00 00 00 05 77 00 00 04 00 01 43 61 6e 6f ......w.....Cano 0060 6e 20 45 4f 53 20 44 36 30 00 00 00 00 00 00 00 n EOS D60....... 0070 00 00 00 00 00 00 00 00 00 00 00 00 43 6f 72 6e ............Corn 0080 65 6c 6c 20 50 72 6f 67 2e 20 43 6f 6d 70 75 74 ell Prog. Comput 0090 65 72 20 47 72 61 70 68 69 63 73 00 er Graphics. from a PowerShot S20: 00000000 00 00 00 00 01 03 00 00-00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 00000040 02 00 00 00 01 00 00 22-5C 00 00 00 78 56 34 12 ......."\...xV4. 00000050 00 00 00 00 00 04 00 00-01 00 00 01 43 61 6E 6F ............Cano 00000060 6E 20 50 6F 77 65 72 53-68 6F 74 20 53 32 30 00 n PowerShot S20. 00000070 00 00 00 00 00 00 00 00-00 00 00 00 44 6F 6E 61 ............Dona 00000080 6C 64 20 44 75 63 6B 00-00 00 00 00 00 00 00 00 ld Duck......... 00000090 00 00 00 00 00 00 00 00-00 00 00 00 ............ First 0x40 bytes is throwable (as usual) At 0x5c is a string with camera type. At 0x7c is a string with owner name. 0x58-0x5b is firmware version (04 03 02 01 is version 1.2.3.4; 01 00 00 01 is version 1.0.0.1) Data at 0x54-0x57 (here 0x00000400) has unknown purpose.

requesttype=0x03 Command: 0x50 bytes 0000 10 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 ................ 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0040 02 00 00 00 03 00 00 12 10 00 00 00 f0 35 12 00 .............5.. Response: 0x60 bytes 0000 00 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ................ 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0040 02 00 00 00 03 00 00 22 20 00 00 00 f0 35 12 00 ......." ....5.. 0050 00 00 00 00 44 cf 27 3e 00 00 00 00 00 00 00 00 ....D.'>........ 0x54 contains a 4-byte UNIX time Other bytes are zero

requesttype=0x04 Command: 0x5c bytes 0x50 contains a UNIX time Other bytes are zero Status codes: 0x02000086 Invalid parameters (e.g. command block wrong length)

requesttype=0x05 Command: 0x50 bytes Response: 0x54 bytes (no error codes) 00000000 00 00 00 00 01 03 00 00-00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 00000040 02 00 00 00 05 00 00 22-14 00 00 00 78 56 34 12 ......."....xV4. 00000050 00 00 00 00 ....

requesttype=0x0a Command: 0x50 bytes 0000 10 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 ................ 0010 43 3a 5c 44 6f 63 75 6d 65 6e 74 73 20 61 6e 64 C:\Documents and 0020 20 53 65 74 74 69 6e 67 73 5c 44 65 66 61 75 6c Settings\Defaul 0030 74 20 55 73 65 72 00 77 69 6e 64 69 72 3d 43 3a t User.windir=C: 0040 02 00 00 00 0a 00 00 12 10 00 00 00 a4 f4 79 00 ..............y. Response: 0x58 bytes (from an EOS D60 on battery power): 0000 00 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ................ 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0040 02 00 00 00 0a 00 00 22 18 00 00 00 a4 f4 d6 00 ......."........ 0050 00 00 00 00 06 00 00 20 ....... from a PowerShot S20? 00000000 00 00 00 00 01 03 00 00-00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 00000040 02 00 00 00 0A 00 00 22-18 00 00 00 78 56 34 12 ......."....xV4. 00000050 00 00 00 00 06 00 00 10- ........ First 0x50 bytes are throwable. 0x54 contains a byte with power status: 0x6=good, 0x4=bad 0x57 contains a byte with power type in bit 4: ((value &0x20) == 0) running from ac-adapter ((value &0x20) != 0) running from battery The original document claimed that this byte contained “a byte with power type: 0x10=ac-adapter, 0x30=battery”, whereas a PowerShot G2 just toggles one bit.

requesttype=0x13 This command actually has 19 subcommands: SubcommandSample ParametersReply LengthFunction00none5C Camera control initialization01none5C Exit release control02none5C Start viewfinder03none5C Stop viewfinder04none5C Release shutter07buffer of 0x34 bytes 5CSet release parameters0904 00 00 00 09 00 00 005C Set transfer mode0Anone8C Get release parameters0Bnone60 Get zoom position0C04 00 00 00 01 00 00 005c Set zoom position0Dnone60 Get available shot0E????? Set custom function0F14 bytes66 Get custom function10none60 Get size of extended release parameters11???????? Get version of extended release parameters12nonevaries Get extended release parameters13?????? Set extended parameters1401 00 00 00 00 035C Select camera output15?????? Do auto exposure, focus, and white balance The subcommand is stored as a little-endian 4-byte number at the start of the message payload (i.e. starting 0x50 bytes from the start of the buffer). Parameters vary by subcommand, as noted below; they follow the subcommand in the message payload. The minimum is <subcommand> 0, so the minimum length of a command packet is 0x58. In the reply, the payload will always start with status, <subcommand>. After that, the minimum is one more zero word, or there may be more information. The minimum length is 0x5c.

Takes no parameters. With some models, this command extends the lens to make the camera ready to capture images. With others, there is no visible effect, but Canon software seems to issue it anyway. Command: 0x58 bytes 0000 18 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 ................ 0010 00 00 00 00 00 05 7f 00 00 02 00 01 43 61 6e 6f ............Cano 0020 6e 20 45 4f 53 20 44 33 30 00 00 00 00 00 00 00 n.EOS.D30....... 0030 00 00 00 00 00 00 00 00 00 00 00 00 43 6f 72 6e ............Corn 0040 02 00 00 00 13 00 00 12 18 00 00 00 00 c5 12 00 ................ 0050 00 00 00 00 00 00 00 00 ........ Response: 0x5c bytes (after ~5 seconds on PowerShot G2) 0000 00 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ................ 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0000 02 00 00 00 13 00 00 22 1c 00 00 00 00 c5 12 00 ......."........ 0010 00 00 00 00 00 00 00 00 00 00 00 00 ............ If the lens cap is left on a PowerShot G2, the lens can’t extend. The response takes about 10 seconds (as apparently the camera tries more than once to extend the lens), and the response block looks like this. Note that bytes 0x50 and 0x53 are non-zero, which is not the case when the lens extends properly. 0000: 1c 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ................ 0010: 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 ................ 0020: 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 ................ 0030: 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 ................ 0040: 02 00 00 00 13 00 00 22 1c 00 00 00 78 56 34 12 ......."....xV4. 0050: 85 00 00 02 00 00 00 00 00 00 00 00 ............ If there is no CF card in an EOS D30, the response will be only 0x40 bytes long, and will look like this: 0000 00 00 00 00 01 03 00 00-00 00 00 00 00 00 00 00 ................ 0010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ The PowerShot G2 returns normally, even if no CF card is present. The error will be signaled later, at “set transfer mode” and “release shutter”

Takes no parameters Command: 0x58 bytes 0000 18 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 ................ 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0040 02 00 00 00 13 00 00 12 18 00 00 00 18 cd 12 00 ................ 0050 01 00 00 00 00 00 00 00 ........ Response: 0x5c bytes 0000 00 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ................ 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0000 02 00 00 00 13 00 00 22 1c 00 00 00 18 cd 12 00 ......."........ 0010 00 00 00 00 01 00 00 00 00 00 00 00 ............

Takes no parameters; returns minimum message of 0x5c bytes.

Takes no parameters; returns minimum message of 0x5c bytes.

Takes no parameters; returns minimum message of 0x5c bytes. The camera does, however, signal through the interrupt pipe. The sequence goes: Issue “release shutter” command, read reply of 0x5c bytes. From a D60, this reply was 0000 00 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ................ 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0000 02 00 00 00 13 00 00 22 1c 00 00 00 28 f6 12 00 ......."....(... 0010 00 00 00 00 04 00 00 00 00 00 00 00 ............ Read 0x10 bytes from interrupt endpoint, using timeout of 50 milliseconds and retrying until success. The camera will normally respond in about 32 milliseconds (EOS D60, G2). Most responses have a length of zero, but the response after the “release shutter” is complete will be 0x10 bytes in length. The bytes seem always to be “02 00 00 00 0a 00 00 00 10 00 00 00 1c 00 00 00", whether the shot succeeded or failed. For the G2, the 0x10 response takes about 3.6 seconds. I believe that this signals that the capture is complete. The time seems relatively independent of image size or compression. For the D60, it seems to come within about 10ms of the “release shutter” command. For the 300D, response takes about 0.35 seconds. If transfer mode includes THUMB_TO_PC (see “Set transfer mode” below), read 0x17 bytes from interrupt endpoint as above. For a D60, these bytes were 0000: 02 00 00 00 08 00 00 00 17 00 00 00 eb 00 b0 17 0010: 01 00 1e 00 00 00 af For a G2, the bytes were 0000: 02 00 00 00 08 00 00 00 17 00 00 00 01 00 00 00 0010: 01 09 0c 00 00 00 b0 At byte 12 (0x0c) is a 4-byte integer with some sort of “image index”; you must specify this in a “download captured image” command to make it work. Starting at byte 0x11 is a 4-byte integer with the size of the thumbnail image to download. NOTE: This doesn’t arrive if the capture fails. Instead, a reply of 0x10 bytes arrives (for D60): 0000: 02 00 00 00 0a 00 00 00 10 00 00 00 1d 00 00 00 If transfer mode includes FULL_TO_PC, read 0x17 bytes from interrupt endpoint as above. For a D60, these bytes were 0000: 02 00 00 00 0c 00 00 00 17 00 00 00 eb 00 b0 17 0010: 01 c5 80 06 00 00 af For a G2, the bytes were 0000: 02 00 00 00 0c 00 00 00 17 00 00 00 01 00 00 00 0010: 01 5a cb 09 00 00 b0 A 4-byte integer at 0x0c has the image index for the “download captured image” command. A 4-byte integer at 0x11 has the main image size. I don’t know what the other bytes are. I suspect that byte 4 has some sort of flags for the type of image. I also guess that the last byte (at 0x16) may encode the camera model somehow. NOTE: This block doesn’t arrive if the capture fails. Instead, a reply of 0x14 bytes arrives (for D60): 0000 02 00 00 00 0a 00 00 00 14 00 00 00 0a 00 00 00 0010 01 00 00 00 Read 0x10 bytes from interrupt endpoint as above. For EOS cameras, this seems to signify that capture is complete and the image has been written to the storage card. For a D60, this can take from about 1.6 seconds (for small, low-quality JPEG) to about 16.5 seconds (for RAW), plus the shutter open time. For the G2, this returns immediately. For the EOS 20D, this message never comes. This response always seems to be 0000: 02 00 00 00 0a 00 00 00 10 00 00 00 1d 00 00 00 regardless of success or failure. The sequence of messages 0x0a/0x1c; 0x0a/0x1d may be repeated once or twice if the image captured is the last one that will fit on the camera's storage device. For EOS cameras, only after successful write to camera storage, read another 0x10 bytes from interrupt endpoint as above. This returns immediately. The result is 0000: 02 00 00 00 0e 00 00 00 10 00 00 00 00 00 00 00 for success. If the capture failed, or if neither THUMB_TO_DRIVE or FULL_TO_DRIVE is set in the current transfer mode, this message is skipped and we go on to the final message (below). The code “0e” may signify that the thumbnail is ready for download; at any rate, Chris Breeze’s D30Capture starts to download the thumbnail immediately after this message is received. For EOS cameras, read the final message: 0000: 02 00 00 00 0f 00 00 00 10 00 00 00 00 00 00 00 NOTE: This message seems never to arrive from an EOS 300D. Interrupt reads always have a code in byte 0x04 (actually, it’s probably a 4-byte integer with a small value). This code is 0x01 Unknown; sometimes seen with PowerShot G2. 0x08 Image descriptor for captured thumbnail (only if THUMB_TO_PC bit is set in the current transfer mode); 0x17 bytes including the length of the thumbnail image and a key that must be supplied in the “get captured image” command. 0x0c Image descriptor for full-size captured image (only if FULL_TO_PC bit is set in the current transfer mode); 0x17 bytes including the length of the full image and a key that must be supplied in the “get captured image” command. The key seems to be identical for thumbnail and full image that correspond to each other. 0x0a Capture status: 0x10 bytes. The byte at offset 0x0c contains a code: 0x1c for start of capture, 0x1d for end of capture (completion for PowerShot cameras, still in progress for EOS cameras), and 0x0a (with a length of 0x14 bytes) if there was a photographic failure. There also is a code of 0x1b that seems to tell us to wait for the flash to fire; it has been seen when using the internal flash on EOS D30 and D60. 0x0e EOS write to flash storage successful: 0x10 bytes. This will never come if the current transfer mode doesn't include either THUMB_TO_DRIVE or FULL_TO_DRIVE 0x0f EOS capture complete: 0x10 bytes. 0x20 Response to camera initialization; not seen during capture dialog.

Takes a payload of 0x38 bytes: 0x34 after subcommand code. Offset 14 in these bytes (18 from the start of the payload) controls the flash: #define FLASH_OFF 0x00 #define FLASH_ON 0x01 #define FLASH_AUTO 0x02 Response: 0x5c bytes (failure): 0000: 00 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ................ 0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0040: 02 00 00 00 13 00 00 22 1c 00 00 00 2f 00 00 00 ......."..../... 0050: 00 00 00 00 07 01 00 ff 00 00 00 00 ............ (success): 0000: 00 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ................ 0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0040: 02 00 00 00 13 00 00 22 1c 00 00 00 2f 00 00 00 ......."..../... 0050: 00 00 00 00 07 00 00 00 00 00 00 00 ............

Takes 2 parameters: 4, <code> where <code> is a combination of the following bits: #define THUMB_TO_PC 0x0001 #define FULL_TO_PC 0x0002 #define THUMB_TO_DRIVE 0x0004 #define FULL_TO_DRIVE 0x0008 These may be combined in any way. Command: 0x5c bytes 0000 1c 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 ................ 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0040 02 00 00 00 13 00 00 12 1c 00 00 00 2c c4 12 00 ............,... 0050 09 00 00 00 04 00 00 00 0d 00 00 00 ............ Error codes: 0x00000000 No errors 0x0200002a Camera storage is full Response 0x5c bytes: 0000 00 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ................ 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0000 02 00 00 00 13 00 00 22 1c 00 00 00 8c c5 12 00 ......."........ 0010 00 00 00 00 09 00 00 00 00 00 00 00 ............ This has just set the camera to send the next captured image to the camera's local storage, with the thumbnail image both to storage and to the PC.

Takes no parameters. Returns 0x34 bytes after the echo of the subcommand code. First 4-byte integer is 0x00000030, which is the count of remaining bytes. I assume that the 0x34 bytes are the same as is sent down by code 07, “set release parameters”. Command: 0x58 bytes 0000 18 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 ................ 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0040 02 00 00 00 13 00 00 12 18 00 00 00 14 c4 12 00 ................ 0050 0a 00 00 00 00 00 00 00 ........ Response 0x8C bytes: 0000 00 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ................ 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0040 02 00 00 00 13 00 00 22 4c 00 00 00 14 c4 12 00 ......."L....... 0050 00 00 00 00 0a 00 00 00 30 00 00 00 00 04 02 00 ........0....... 0060 00 00 00 00 04 01 01 ff 03 ff 01 30 00 ff 00 ff ...........0.... 0070 00 00 00 7f 10 00 60 00 38 00 7c 00 18 18 18 ff ......`.8.|..... 0000 20 00 50 00 14 00 14 00 14 00 01 00 ..P.........

No parameters Command: 0x58 bytes 0000 18 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 ................ 0010 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 ................ 0020 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 ................ 0030 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 ................ 0040 02 00 00 00 13 00 00 12 18 00 00 00 a4 f6 12 00 ................ 0050 0b 00 00 00 00 00 00 00 ........ Reply: 0x60 bytes 0000 20 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ............... 0010 82 81 80 7f 7f 80 81 83 84 84 83 81 80 7f 7f 80 ................ 0020 81 83 83 81 80 7f 7d 7d 7e 7f 80 81 80 7f 7e 7c ......}}~.....~| 0030 7c 7d 7f 80 81 81 81 80 7f 7f 80 81 82 84 84 83 |}.............. 0000 02 00 00 00 13 00 00 22 20 00 00 00 a4 f6 12 00 ......." ....... 0010 00 00 00 00 0b 00 00 00 04 00 00 00 00 00 3c 00 ..............<. Response has a 4-byte count (4), and I think two 2-byte integers (0,60). This was for a G2 at full-wide position (7mm).

Two parameters. Command: 0x5c bytes 0000 1c 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 ................ 0010 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 ................ 0020 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 ................ 0030 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 ................ 0040 02 00 00 00 13 00 00 12 1c 00 00 00 a8 f6 12 00 ................ 0050 0c 00 00 00 04 00 00 00 01 00 00 00 ............ Parameters are (4,1). Reply: 0x5c bytes 0000 1c 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ................ 0010 7f 7f 80 80 80 80 7f 7d 7c 7b 7c 7e 7f 80 80 80 .......}|{|~.... 0020 7f 7e 7f 7f 80 82 83 84 83 82 81 80 80 81 82 84 .~.............. 0030 84 83 81 80 7f 7f 7f 80 80 80 80 7f 7e 7c 7b 7b ............~|{{ 0000 02 00 00 00 13 00 00 22 1c 00 00 00 a8 f6 12 00 ......."........ 0010 00 00 00 00 0c 00 00 00 00 00 00 00 ............

No parameters Command: 0x58 bytes 0000 18 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 ................ 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0040 02 00 00 00 13 00 00 12 18 00 00 00 ec f4 25 01 ..............%. 0050 0d 00 00 00 00 00 00 00 ........ Reply 0x60 bytes: 0000 00 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ................ 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0000 02 00 00 00 13 00 00 22 20 00 00 00 ec f4 25 01 ......."......%. 0010 00 00 00 00 0d 00 00 00 04 00 00 00 02 00 00 00 ................ The last word is the estimated number of shots remaining: i.e. the free storage space divided by the estimated size of an image file in the current mode.

No documentation; not yet seen in USB stream.

14 bytes of parameters. The first 4 bytes is a 32-bit little-endian count of the number of bytes following. In the example, there are 10 bytes of actual data. But the next 2 bytes seems to be an index for the custom function to read; the value comes back in the reply, which has a payload just as long, but with just the index/value pair repeated and then the setting of that function. A zero value is the default setting for all functions. Command: 0x62 bytes 0000 22 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 "............... 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0040 02 00 00 00 13 00 00 12 22 00 00 00 d4 c5 12 00 ........"....... 0050 0f 00 00 00 0a 00 00 00 04 00 e8 77 00 00 13 00 ...........w.... 0060 08 00 .. Reply 0x66 bytes: 0000 00 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ................ 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0000 02 00 00 00 13 00 00 22 26 00 00 00 d4 c5 12 00 ......."&....... 0010 00 00 00 00 0f 00 00 00 0a 00 00 00 04 00 04 00 ................ 0020 00 00 00 00 00 00 ...... Command: 0x62 bytes. In this case, we read custom function 1 ("Long exposure noise reduction"), which was set to 1. 0000 22 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 "............... 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0040 02 00 00 00 13 00 00 12 22 00 00 00 54 f6 12 00 ........"...T... 0050 0f 00 00 00 0a 00 00 00 01 00 ff ff 00 00 00 00 ................ 0060 00 00 .. Reply 0x66 bytes: 0000 00 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ................ 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0040 02 00 00 00 13 00 00 22 26 00 00 00 54 f6 12 00 ......."&...T... 0050 00 00 00 00 0f 00 00 00 0a 00 00 00 01 00 01 00 ................ 0060 01 00 00 00 00 00 ...... The value of the given custom function is given starting at byte 0x60. I don't know if this is a 2-byte or 4-byte value, or if it's possible to read more than one custom function at a time; Canon RemoteCapture reads them one at a time, even when it reads all the available functions. The custom functions (as seen in Canon RemoteCapture and on the camera menu) are as follows: CodeFunctionValues0x01Long exposure noise reduction 0: Off 1: On (not on D60)0x02Shutter button/AE lock button 0: AF/AE lock 1: AE lock/AF 2: AF/AF lock 3: AE+release/AE+AF0x03Mirror lockup 0: Disable 1: Enable0x04Tv, Av and exposure steps 0: ½ stop 1: 1/3 stop0x05AF-assist beam/ Flash firing 0: Emits/fires 1: Does not emit/Fires 2: Only ext. flash emits/Fires 3: Emits/Does not fire0x06Shutter speed in Av mode 0: Auto 1: 1/200 (fixed)0x07AEB sequence/auto cancellation 0: 0 - + /Enable 1: 0 - + /Disable 2: 0 + - /Enable 3: 0 + - /Disable0x08Shutter curtain sync 0: 1st-curtain sync 1: 2nd-curtain sync0x09Lens AF stop button Fn, switch 0: AF stop 1: AF start 2: AE lock while metering0x0aAuto reduction of fill flash 0: Enable 1: Disable0x0bMenu button return position 0: Top 1: Previous (top if powered off) 2: Previous0x0cSET button func, when shooting 0: Default (no function) 1: Change quality 2: Change ISO speed 3: Change parameters0x0dSensor cleaning 0: Disable 1: Enable0x0eSuperimposed display 0: On 1: Off (not on D30)0x0fShutter release without CF card 0: Possible w/o CF card 1: Not possible (not on D30))

No parameters Command: 0x58 bytes 0000 18 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 ................ 0010 7f 7f 80 80 80 80 7f 7d 7c 7b 7c 7e 7f 80 80 80 .......}|{|~.... 0020 7f 7e 7f 7f 80 82 83 84 83 82 81 80 80 81 82 84 .~.............. 0030 84 83 81 80 7f 7f 7f 80 80 80 80 7f 7e 7c 7b 7b ............~|{{ 0040 02 00 00 00 13 00 00 12 18 00 00 00 50 f6 12 00 ............P... 0050 10 00 00 00 00 00 00 00 ........ Reply: 0x60 bytes 0000 20 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ............... 0010 87 8b 8d 8a 87 88 89 89 87 88 8b 8b 89 86 87 89 ................ 0020 89 86 84 85 85 83 81 82 85 84 80 7e 7e 7f 7f 7e ...........~~..~ 0030 7f 82 83 80 7b 7b 7e 80 80 82 85 86 82 7e 7d 80 ....{{~......~}. 0000 02 00 00 00 13 00 00 22 20 00 00 00 50 f6 12 00 ......." ...P... 0010 00 00 00 00 10 00 00 00 04 00 00 00 10 00 00 00 ................ I think this means to expect 16 (0x10) bytes of “extended release parameters”.

No documentation; not yet seen in USB stream.

Command: 0x5c bytes 0000 1c 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 ................ 0010 7f 7f 80 80 80 80 7f 7d 7c 7b 7c 7e 7f 80 80 80 .......}|{|~.... 0020 7f 7e 7f 7f 80 82 83 84 83 82 81 80 80 81 82 84 .~.............. 0030 84 83 81 80 7f 7f 7f 80 80 80 80 7f 7e 7c 7b 7b ............~|{{ 0040 02 00 00 00 13 00 00 12 1c 00 00 00 50 f6 12 00 ............P... 0050 12 00 00 00 04 00 00 00 10 00 00 00 ............ Reply: 0x6c bytes 0000 2c 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ,............... 0010 71 72 75 76 79 7e 80 7f 7b 7c 7f 81 82 84 86 87 qruvy~..{|...... 0020 85 81 80 81 83 82 80 7f 80 7c 77 76 78 7a 79 77 .........|wvxzyw 0030 75 76 78 79 79 7b 7f 7f 7e 7d 80 84 84 84 87 8b uvxyy{..~}...... 0000 02 00 00 00 13 00 00 22 2c 00 00 00 50 f6 12 00 .......",...P... 0010 00 00 00 00 12 00 00 00 10 00 00 00 10 00 00 00 ................ 0020 00 00 02 00 00 00 18 00 e0 08 54 aa ..........T.

No documentation; not yet seen in USB stream.

Sends a 9-byte payload: 0x00000014, 0x00000001, and a single byte with the code LCD (0x1), Video out (0x2), or OFF (0x3).

No documentation; not yet seen in USB stream.

requesttype=0x17 Command: 0x60 bytes: 0000 20 00 00 00 02 02 00 00 00 00 00 00 00 00 00 00 ................ 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0040 02 00 00 00 17 00 00 12 20 00 00 00 22 29 05 01 ............").. 0050 00 00 00 00 00 14 00 00 01 00 00 00 16 15 01 2d ...............- The information is all 4-byte integers. 0x50: zero 0x54: maximum block length to be used for bulk transfer of the image (0x00001400 here) 0x58: code: 1=fetch thumbnail, 2=fetch full image 0x5c: “image index” obtained from an interrupt read just after capture. The G2 seems less finicky about this: it’s an integer that counts up from 1 in each session. The EOS cameras have some inscrutable code that must be gotten from the camera. Response packet of 0x40 bytes: 0000 00 00 00 00 02 03 30 17 00 00 00 00 00 00 00 00 ......0......... 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Bytes 6-10 of the reply packet contain the 32-bit total length of the image data transfers, here 0x00001730. We must then issue a series of bulk reads as explained above.

requesttype=0x18? No documentation; not yet seen in USB stream.

requesttype=0x1a Not seen with EOS D60 and Canon RemoteCapture. Seen only with D30. If byte 0x50 is some sort of opcode, it may come in sequence: 01, 02, 03 in consecutive commands. Command: 0x7C bytes 0000 3c 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 <............... 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0040 02 00 00 00 1a 00 00 12 3c 00 00 00 f8 c4 12 00 ........<....... 0050 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................ 0060 00 00 00 00 b8 c7 12 00 9b 2b 40 00 58 c8 12 00 .........+@.X... 0070 b8 6d 4f 00 02 00 00 00 01 e6 12 00 .mO......... Reply: 0x80 bytes 0000 00 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ................ 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0040 02 00 00 00 1a 00 00 22 40 00 00 00 f8 c4 12 00 ......."@....... 0050 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 ................ 0060 ac 00 00 00 5e b5 ff ff 55 1b 00 00 10 00 54 1b ....^...U.....T. 0070 0c 00 ef 19 9c 0f 53 02 58 9d 0c 00 ef 19 ee 26 ......S.X......& So the reply message is just the same length as the command, with 4 bytes of status code inserted. I can't see any mapping between what goes out and what comes back, though. Here the first three words of both command payload and response payload are 1,0,1, but then they diverge. 0000 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 ac 00 00 00 0010 00 00 00 00 b8 c7 12 00 9b 2b 40 00 58 c8 12 00 5e b5 ff ff 55 1b 00 00 10 00 54 1b 0c 00 ef 19 0020 b8 6d 4f 00 02 00 00 00 01 e6 12 00 9c 0f 53 02 58 9d 0c 00 ef 19 ee 26

requesttype=0x1b This command will normally be issued immediately before a "release shutter" command, unlike the non-EOS “lock keys” command, which is issued at camera initialization. This late locking is so that the EOS camera can still be operated directly, even when connected to the USB port. The PowerShot cameras don't have this capability, so they can (should) be locked as soon as the USB connection is made. Command: 0x54 bytes 0000 14 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 ................ 0010 00 00 00 00 0a 00 00 00 30 00 00 00 00 03 01 00 ........0....... 0020 00 00 00 00 01 01 00 ff 03 ff 01 30 06 ff 01 ff ...........0.... 0030 00 00 00 7f 10 00 48 00 ff ff ff ff 18 c8 18 ff ......H......... 0040 02 00 00 00 1b 00 00 12 14 00 00 00 a4 f6 12 00 ................ 0050 06 00 00 00 .... Response: 0x54 bytes 0000 00 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ................ 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0000 02 00 00 00 1b 00 00 22 14 00 00 00 a4 f6 12 00 ......."........ 0010 00 00 00 00 .... Status codes: 0x00000000 No errors 0x02000086 Unknown

requesttype=0x1c This command is normally issued during the interrupt sequence after a "release shutter" command, so as to make the camera available as soon as possible. Command: 0x50 bytes 0000 10 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 ................ 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0040 02 00 00 00 1c 00 00 12 10 00 00 00 58 f7 12 00 ............X... Response: 0x54 bytes 0000 00 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ................ 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0000 02 00 00 00 1c 00 00 22 14 00 00 00 58 f7 12 00 ......."....X... 0010 00 00 00 00 ....

requesttype=0x1d Used only with EOS cameras. Canon RemoteCapture issues it immediately before entering remote capture mode. Command: 0x50 bytes 0000 10 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 ................ 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0040 02 00 00 00 1d 00 00 12 10 00 00 00 f4 f4 12 00 ................ Response: 0x58 bytes (EOS D30) 0000 00 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ................ 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0000 02 00 00 00 1d 00 00 22 18 00 00 00 f4 f4 12 00 ......."........ 0010 00 00 00 00 ea 01 28 18 ......(. There’s one zero word, then four bytes containing the body ID. With a D30, the upper 16 bits should be used directly as hexadecimal digits, and the lower 16 bits should be converted to decimal. For this camera, it’s 182800490: 0x1828 concatenated with 00490, which is the decimal equivalent of 0x01ea. The following C code fragment will do the trick: char serialnumber[10]; sprintf ( serialnumber, "%04x%05d", (body_id>>16)&0xffff, body_id&0xffff ); For a D60, it’s a simple binary number: convert it to decimal to get the body ID. “1e ab d6 3c” becomes 0x3cd6ab1e; the decimal equivalent is 1020701470, the number on the sticker on the base of the camera. This C code fragment will convert this to ASCII correctly: char serialnumber[10]; sprintf ( serialnumber, "%d", body_id );

requesttype=0x1f Command: 0x50 bytes 0000: 10 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 ................ 0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0040: 02 00 00 00 1f 00 00 12 10 00 00 00 78 56 34 12 ............xV4. Reply is 0x384 bytes (PowerShot G2): 0000: 44 03 00 00 01 03 00 00 00 00 00 00 00 00 00 00 D............... 0010: aa 55 aa 55 aa 55 aa 55 aa 55 aa 55 aa 55 aa 55 .U.U.U.U.U.U.U.U 0020: aa 55 aa 55 aa 55 aa 55 aa 55 aa 55 aa 55 aa 55 .U.U.U.U.U.U.U.U 0030: aa 55 aa 55 aa 55 aa 55 aa 55 aa 55 aa 55 aa 55 .U.U.U.U.U.U.U.U 0040: 02 00 00 00 1f 00 00 22 44 03 00 00 78 56 34 12 ......."D...xV4. 0050: 00 00 00 00 30 03 00 00 10 01 50 6f 77 65 72 53 ....0.....PowerS 0060: 68 6f 74 20 47 32 00 00 00 14 00 00 80 28 00 00 hot G2.......(.. 0070: 00 40 00 00 00 00 00 00 00 00 0d 00 00 00 4c 61 .@............La 0080: 72 67 65 3a 53 75 70 65 72 46 69 6e 65 00 00 00 rge:SuperFine... 0090: 00 00 a8 06 00 00 e0 08 00 00 01 00 00 00 4c 61 ..............La 00a0: 72 67 65 3a 46 69 6e 65 00 00 40 00 00 00 00 00 rge:Fine..@..... 00b0: 00 00 a8 06 00 00 e0 08 00 00 02 00 00 00 4c 61 ..............La 00c0: 72 67 65 3a 4e 6f 72 6d 61 6c 00 00 00 20 00 00 rge:Normal... .. 00d0: 00 00 a8 06 00 00 e0 08 00 00 03 00 00 00 4d 65 ..............Me 00e0: 64 69 75 6d 20 31 3a 53 75 70 65 72 46 69 6e 65 dium 1:SuperFine 00f0: 00 00 b0 04 00 00 40 06 00 00 01 00 00 00 4d 65 ......@.......Me 0100: 64 69 75 6d 20 31 3a 46 69 6e 65 00 00 00 00 00 dium 1:Fine..... 0110: 00 00 b0 04 00 00 40 06 00 00 02 00 00 00 4d 65 ......@.......Me 0120: 64 69 75 6d 20 31 3a 4e 6f 72 6d 61 6c 00 00 00 dium 1:Normal... 0130: 00 00 b0 04 00 00 40 06 00 00 03 00 00 00 4d 65 ......@.......Me 0140: 64 69 75 6d 20 32 3a 53 75 70 65 72 46 69 6e 65 dium 2:SuperFine 0150: 00 55 00 03 00 00 00 04 00 00 01 00 00 00 4d 65 .U............Me 0160: 64 69 75 6d 20 32 3a 46 69 6e 65 00 a8 71 aa 55 dium 2:Fine..q.U 0170: aa 55 00 03 00 00 00 04 00 00 02 00 00 00 4d 65 .U............Me 0180: 64 69 75 6d 20 32 3a 4e 6f 72 6d 61 6c 00 aa 55 dium 2:Normal..U 0190: ae 55 00 03 00 00 00 04 00 00 03 00 00 00 53 6d .U............Sm 01a0: 61 6c 6c 3a 53 75 70 65 72 46 69 6e 65 00 aa 55 all:SuperFine..U 01b0: aa 51 e0 01 00 00 80 02 00 00 01 00 00 00 53 6d .Q............Sm 01c0: 61 6c 6c 3a 46 69 6e 65 00 d5 aa 15 ab 55 aa 55 all:Fine.....U.U 01d0: aa 55 e0 01 00 00 80 02 00 00 02 00 00 00 53 6d .U............Sm 01e0: 61 6c 6c 3a 4e 6f 72 6d 61 6c 00 55 aa 55 aa 55 all:Normal.U.U.U 01f0: 2b 55 e0 01 00 00 80 02 00 00 03 00 00 00 43 52 +U............CR 0200: 57 00 aa 75 aa 15 aa 55 a8 54 aa 55 2a 57 aa 55 W..u...U.T.U*W.U 0210: 0a 75 a8 06 00 00 e0 08 00 00 04 00 00 00 aa 55 .u.............U 0220: aa d5 2a 54 aa 55 aa 55 aa c7 aa 55 aa 15 aa 55 ..*T.U.U...U...U 0230: ee 75 a2 55 a8 55 ff ff fe ff ff ff 7d f9 ff ff .u.U.U......}... 0240: ff af ff ff df ff ff ff ff ef ff ff fb ff ff ff ................ 0250: be ff df ff fb fb ff ff ff ff ff ff fd ff ff ff ................ 0260: 7d df bf f7 7f fe ff ff 3f ff be ff ff 57 ff ff }.......?....W.. 0270: bf fb ff f7 ef 9f ff fb af ff ff ff ff ff 78 00 ..............x. 0280: 00 00 00 00 00 00 a0 00 00 00 00 00 00 00 14 00 ................ 0290: 00 00 00 80 00 00 00 80 00 00 00 80 00 00 00 80 ................ 02a0: 00 00 00 80 00 00 00 00 00 00 00 00 00 00 00 80 ................ 02b0: 00 00 00 80 03 00 00 80 66 00 00 80 00 00 00 00 ........f....... 02c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 02d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 02e0: 28 00 00 50 00 80 00 14 00 c0 00 00 00 80 00 00 (..P............ 02f0: 00 80 00 00 00 80 00 00 00 80 00 00 00 80 00 00 ................ 0300: 00 80 00 00 00 80 00 00 00 80 00 00 00 80 00 00 ................ 0310: 00 c0 00 00 00 80 00 00 00 80 00 00 00 80 00 00 ................ 0320: 00 00 00 00 00 00 00 00 00 80 00 00 00 80 00 00 ................ 0330: 00 80 00 00 00 80 00 00 00 00 00 00 00 00 00 00 ................ 0340: 00 00 00 00 00 00 00 00 00 00 00 00 00 f0 00 00 ................ 0350: 00 80 00 00 00 80 00 00 00 80 00 00 00 80 00 50 ...............P 0360: 00 80 00 00 00 80 00 14 00 c0 00 00 00 00 00 00 ................ 0370: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0380: 00 00 55 aa ..U. offsetbytesvalue0x50:4status code0x54:2size of structure (here 0x330=816 bytes)0x56:4Camera model identifier? (here 0x01100000). This will show up as the value of the image file tag 0x0010 (EXIF) or 0x5834 (CRW)0x5a:32camera identification (ASCII)0x7a:4Count n of number of entries in image-quality table0x7c:n*32Table of image quality levels allowed The observed values at 0x56 are: 0x00000110 (G2) 0x000125 (A70), 0x00000127 (IXUS 400), 0x00000129 (G5), 0x00000134 (A80), 0x00000145 (A400), 0x00000157 (A510), 0x80000166 (D60), 0x80000170 (300D), 0x8003024a (Optura 20). Each entry in the table seems to be struct { char imageType[20]; /* ASCII name of this image type */ long imageHeight, imageWidth; long compressionType; /* 1: SuperFine 2:Fine 3:Normal 4:RAW */ } tableEntry; So we can see that the PowerShot G2 can produce the following image types: HeightWidthCompressionName17042272JPEG superfineLarge:17042272JPEG fineLarge:17042272JPEG normalLarge:12001600JPEG superfineMedium 1:12001600JPEG fineMedium 1:12001600JPEG normalMedium 1:7681024JPEG superfineMedium 2:7681024JPEG fineMedium 2:7681024JPEG normalMedium 2:480640JPEG superfineSmall:480640JPEG fineSmall:480640JPEG normalSmall:17042272RawCRW I suspect that the remaining bytes after 0x21c are garbage. Note: This command doesn't seem to be implemented on the EOS D30/D60 or the PowerShot S45 or G3. I suspect that it's being phased out, and new cameras from now on (February 2003) won't implement it. The new protocol uses a different code for what seems to be the same function. Some recent models return responses of different length, so code must be ready for this and read the length from the first four bytes of the response. Cameras known to give different response lengths are ModelResponse lengthCommentsPowerShot A400 0x394 No entries in table (count=0). PowerShot A80, G5 0x394 No entries in table (count=0). Camera name is unprintable garbage.

requesttype=0x20 Not used for EOS D30/D60 cameras: use “EOS Lock Keys” instead. This command is normally issued during camera initialization for a non-EOS camera, as those cameras can't share control between the host computer and the on-camera controls. We don't know how to reverse this command, i.e. unlock the keys on a non-EOS camera. To regain control of a non-EOS camera, unplug the USB cable. Command: 0x50 bytes 0000 10 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 ................ 0010 20 46 69 6c 65 73 00 43 4f 4d 50 55 54 45 52 4e Files.COMPUTERN 0020 41 4d 45 3d 52 41 4c 50 48 00 43 6f 6d 53 70 65 AME=RALPH.ComSpe 0030 63 3d 43 3a 5c 57 49 4e 4e 54 5c 73 79 73 74 65 c=C:\WINNT\syste 0040 02 00 00 00 20 00 00 12 10 00 00 00 94 f7 e1 00 .... ........... Reply: 0x54 bytes 0000 14 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ................ 0010 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 ................ 0020 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 ................ 0030 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 ................ 0000 02 00 00 00 1f 00 00 22 14 00 00 00 94 f7 e1 00 ......."........ 0010 00 00 00 00 ....

Control_transfer_write requesttype=0x40 value=0x10 length=0x40 data=0x00000000 0x0203 0x40+len1[explained later] [0x00 repeated 0x38] Example: 0000 00 00 00 00 03 02 7a 14 00 00 00 00 00 00 00 00 ......z......... 0010 8e 58 63 3e 44 2e 43 54 47 00 00 00 00 00 00 00 .Xc>D.CTG....... 0020 00 00 00 00 00 83 85 82 87 84 7f 81 7f 7d 7b 77 .............}{w 0030 7e 81 7e 7d 7c 7d 81 80 82 80 7c 80 81 7f 84 83 ~.~}|}....|..... This is identical to the response to “Download Captured Image”, except for the cmd3 halfword at 0x04. The cmd3 halfword is 0x0203 here, 0x0302 there. bulk_in_read [0x40 bytes] Example: 0000 00 00 00 00 03 03 00 00 00 00 00 00 00 00 00 00 ................ 0010 8e 58 63 3e 44 2e 43 54 47 00 00 00 00 00 00 00 .Xc>D.CTG....... 0020 00 00 00 00 00 83 85 82 87 84 7f 81 7f 7d 7b 77 .............}{w 0030 7e 81 7e 7d 7c 7d 81 80 82 80 7c 80 81 7f 84 83 ~.~}|}....|..... The following block obeys the normal command block structure. The exact layout is: 0000000: xx xx xx xx 03 04 00 00 - 00 00 00 00 00 00 00 00 0000010: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 0000020: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 0000030: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 0000040: 02 00 00 00 03 00 00 11 - xx xx xx xx SS SS SS SS 0000050: 00 00 00 00 UU UU UU UU - VV VV VV VV pathname data ... xx xx xx xx : len1, the length of the payload (total block length - 0x40) cmd3 = 0x00000403 cmd1 = 0x03 cmd2 = 0x11 xx xx xx xx : len1 (again) SS SS SS SS : sequence number UU UU UU UU : Offset within file; starts at zero, increments by len2 (below) for next block VV VV VV VV : len2, length of data in this block. Normally 0x1400 or less. pathname : full path name of file on camera, terminated by one NUL. File cannot be created in nonexistent directory. data : image data (len2 bytes) Example of beginning of a block: 0000 3a 14 00 00 03 04 00 00 00 00 00 00 00 00 00 00 :............... 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0040 02 00 00 00 03 00 00 11 3a 14 00 00 a2 4c 10 02 ........:....L.. 0050 00 00 00 00 00 00 00 00 00 14 00 00 44 3a 5c 44 ............D:\D 0060 43 49 4d 5c 31 35 38 43 41 4e 4f 4e 5c 41 55 54 CIM\158CANON\AUT 0070 5f 30 30 30 31 2e 4a 50 47 00 ff d8 ff e1 18 ba _0001.JPG....... 0080 45 78 69 66 00 00 49 49 2a 00 08 00 00 00 09 00 Exif..II*....... 0090 0f 01 02 00 06 00 00 00 7a 00 00 00 10 01 02 00 ........z....... 00A0 .... The filename here is “D:\DCIM\158CANON\AUT_0001.JPG”; the offset is zero (i.e. this is the first block of this file) and length is 0x1400. Len1 is 0x143a, which is 0x1400 + 0x10 + 0xc (three full words) + 0x1e (length of pathname+1). Response to this block (0x5c bytes): 0000 00 00 00 00 03 03 00 00 00 00 00 00 00 00 00 00 ................ 0010 00 00 00 00 00 00 00 00 78 00 00 00 76 00 00 00 ........x...v... 0020 36 00 00 00 02 02 00 00 00 00 00 00 00 00 00 00 6............... 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0040 02 00 00 00 03 00 00 21 1c 00 00 00 a2 4c 10 02 .......!.....L.. 0050 00 00 00 00 00 14 00 00 00 14 00 00 ............ The interesting words are: 0x50 Status 0x54 Count of bytes already transferred in this upload? 0x58 Number of bytes of real data transferred in the latest bulk write. Unfortunately, the number at 0x54 seems to jump too fast; after the second write of 0x1400 bytes, it reads 0x3c00, not 0x2800. And after the next, it's 0x6400, not 0x3c00. In fact, it counts up by multiples of the 0x1400 data length: 1, 3, 5, 7, 9, ... This transaction is repeated until the whole file is transmitted. At the end of the transfer, there will usually be one “short” transfer. Here it is 0x117e bytes: 0000 b8 11 00 00 03 04 00 00 00 00 00 00 00 00 00 00 ................ 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0040 02 00 00 00 03 00 00 11 b8 11 00 00 a2 4c 10 02 .............L.. 0050 00 00 00 00 00 4c 04 00 7e 11 00 00 44 3a 5c 44 .....L..~...D:\D 0060 43 49 4d 5c 31 35 38 43 41 4e 4f 4e 5c 41 55 54 CIM\158CANON\AUT 0070 5f 30 30 30 31 2e 4a 50 47 00 02 8a 00 28 a0 02 _0001.JPG....(.. 0080 8a 00 28 a0 02 8a 00 28 a0 02 8a 00 28 a0 02 8a ..(....(....(... 0090 00 28 a0 02 8a 00 28 a0 02 8a 00 28 a0 02 8a 00 .(....(....(.... Here the offset is 0x44c00. The response is 0x5c bytes 0000 00 00 00 00 03 03 00 00 00 00 00 00 00 00 00 00 ................ 0010 7a 8c f2 3e 94 98 6a 3b 19 01 14 ee 3d f2 79 14 z..>..j;....=.y. 0020 a0 07 f9 17 0c ab d4 e7 9a 43 bb ec 3c 6d 7e 4e .........C..<m~N 0030 0a 2f 71 9c d2 ae 1f 32 37 cd 8e 87 1c d1 61 58 ./q....27.....aX 0040 02 00 00 00 03 00 00 21 1c 00 00 00 a2 4c 10 02 .......!.....L.. 0050 00 00 00 00 7e a9 08 00 7e 11 00 00 ....~...~... The “total byte count” (or whatever it is) is now 0x8a97e. After this the caller must set the file time; otherwise it is left at -1.

The EOS 20D introduced a new version of the Canon native protocol. While it still seems to use the same basic format of command and response blocks, some command codes have been abandoned, new ones added, and, worst of all, some codes have changed their meanings. This section describes what we know so far about this revised protocol. I assume that there will be other cameras using this new protocol; the first candidates would be the EOS 1D Mk. II and 1D Mk. II, which share the CR2 raw image format with the 20D.

cmd1cmd3Argument(e.g.)Response LengthOperationOld code0x010x202 0x00000001 "A:/DCIM/100CANON\IMG_0098.CR2" <NUL> LGet picture0x010x040x201 none0x54 Unknown0x050x201 none0x54 Unknown0x060x201 none0x54 Unknown0x070x201 none0x54 Unknown0x090x201 none0x54 Unknown0x0A0x201 "A:/DCIM/101CANON/IMG_0105.JPG" 0x0007 0x0005 0x0100 0x0008 0x008f7668 0x008f8078 "A:/DCIM/101CANON/" L Delete file0x0D0x0B0x202 0x01 "D:\DCIM"<NUL> <NUL> <NUL>L Get directory0x0B0x0D0x201 "A:" <NUL>0x5c Disk info request0x090x0E0x202 noneL Flash Device Identification0x0A cmd1cmd3Argument(e.g.)Response LengthOperationOld code0x010x201 none0x9c Identify camera0x010x030x201 none0x60 Get time0x030x040x201 0x390873f0 0x000000000x54 Set time0x040x050x201 none0x74 Get ownerNA0x060x201 "Cornell University" <NUL>0x54 Set owner0x050x130x201 none0x58 Power supply status0x0A0x1D0x201 0x000000000x94 Get custom function settings0x13/???0x210x201 0x000000000x54 Unknown command0x220x201 0x0000000f0x54 Unknown command0x230x201 none0x58 Get Body ID0x1D0x240x201 none0x458 Get Photo Abilities0x1F0x250x201 9 bytes: 00 00 00 00 00 00 00 00 000x5c Remote Capture Control0x130x260x202 0x10 bytes: 00 00 00 00 00 00 01 00 02 00 00 00 07 00 00 00varies Get captured image0x170x350x201 none0x5c Lock keys0x1B0x360x201 00 00 00 00 00 00 00 000x54 Unknown

requesttype=0x01 Downloads a full image or thumbnail from camera storage. Similar with command in old protocol, but parameters differ. Command: variable length (here 0x76 bytes) 00000000 33 00 00 00 02 02 00 00 00 00 00 00 00 00 00 00 3............... 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040 02 00 00 00 01 00 20 11 33 00 00 00 18 cd 12 00 ...... .3....... 00000050 01 00 00 00 41 3a 2f 44 43 49 4d 2f 31 30 30 43 ....A:/DCIM/100C 00000060 41 4e 4f 4e 2f 49 4d 47 5f 30 30 39 38 2e 43 52 ANON/IMG_0098.CR 00000070 32 00 00 2.. Parameters: 0x50: Flag for download of thumbnail: 0x00000001 for thumbnail, 0x00000000 for full image. 0x54: Pathname of file to download, terminated by a two NUL bytes The example requests download of the full image in file “A:/DCIM/100CANON/IMG_0098.C2R”. Notice the forward slashes in this pathname. Response: 0x40 bytes (EOS 20D) 00000000 00 00 00 00 02 03 d6 3a 0e 00 00 00 00 00 00 00 .......:........ 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ This indicates a total file size of 1647748 bytes (0x000e3ad6 from offset 0x06). After this, a series of 14 messages with length 0x10000 was read, then one read of length 0x3ac0. Finally, a read of 0x16 finished download of the image. This example seems to be downloading a CR2 raw image file; notice the TIFF magic II* at the sbeginning. 00000000 49 49 2a 00 10 00 00 00 43 52 02 00 20 ee 07 00 II*.....CR.. ... 00000010 0e 00 00 01 03 00 01 00 00 00 00 06 4c cc 01 01 ............L... 00000020 03 00 01 00 00 00 00 04 33 33 02 01 03 00 03 00 ........33...... 00000030 00 00 be 00 00 00 03 01 03 00 01 00 00 00 06 00 ................ 00000040 cc cc 0f 01 02 00 06 00 00 00 c4 00 00 00 10 01 ................ 00000050 02 00 0e 00 00 00 ca 00 00 00 11 01 04 00 01 00 ................ 00000060 00 00 00 26 00 00 12 01 03 00 01 00 00 00 01 00 ...&............ 00000070 22 33 17 01 04 00 01 00 00 00 28 2a 03 00 1a 01 "3........(*.... 00000080 05 00 01 00 00 00 ea 00 00 00 1b 01 05 00 01 00 ................ 00000090 00 00 f2 00 00 00 28 01 03 00 01 00 00 00 02 00 ......(......... 000000a0 27 33 32 01 02 00 14 00 00 00 fa 00 00 00 69 87 '32...........i. 000000b0 04 00 01 00 00 00 0e 01 00 00 28 50 03 00 08 00 ..........(P.... 000000c0 08 00 08 00 43 61 6e 6f 6e 00 43 61 6e 6f 6e 20 ....Canon.Canon 000000d0 45 4f 53 20 32 30 44 00 dc cc cc cc 8c cc cc de EOS 20D......... 000000e0 33 33 77 b3 13 b6 cf f9 32 33 48 00 00 00 01 00 33w.....23H..... 000000f0 00 00 48 00 00 00 01 00 00 00 32 30 30 34 3a 31 ..H.......2004:1 00000100 31 3a 31 30 20 30 36 3a 34 33 3a 30 36 00 1c 00 1:10 06:43:06... 00000110 9a 82 05 00 01 00 00 00 64 02 00 00 9d 82 05 00 ........d....... 00000120 01 00 00 00 6c 02 00 00 22 88 03 00 01 00 00 00 ....l..."....... ... 00000000 ec ca cc cc ec cc ed ee cc d6 cc cc ef cc cc 48 ...............H 00000010 cc ae 33 33 b3 b7 ..33..

requesttype=0x04 When called as for "set file attributes": 0000 33 00 00 00 01 02 00 00-00 00 00 00 00 00 00 00 3............... 0010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0040 02 00 00 00 04 00 10 11-33 00 00 00 0a 00 00 00 ........3....... 0050 00 00 00 00 41 3a 5c 44-43 49 4d 5c 31 37 32 43 ....A:\DCIM\172C 0060 41 4e 4f 4e 00 49 4d 47-5f 37 32 35 32 2e 4a 50 ANON.IMG_7252.JP 0070 47 00 00 - G.. returns 0x58 bytes: 0000 18 00 00 00 01 03 00 00-00 00 00 00 00 00 00 00 ................ 0010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0000 02 00 00 00 04 00 10 21-18 00 00 00 0a 00 00 00 .......!........ 0010 87 00 40 82 ff ff ff ff- ..@..... The status code is nonzero, indicating some sort of error.

requesttype=0x05 When called as for "set file attributes": 0000 33 00 00 00 01 02 00 00-00 00 00 00 00 00 00 00 3............... 0010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0040 02 00 00 00 05 00 10 11-33 00 00 00 0a 00 00 00 ........3....... 0050 00 00 00 00 41 3a 5c 44-43 49 4d 5c 31 37 32 43 ....A:\DCIM\172C 0060 41 4e 4f 4e 00 49 4d 47-5f 37 32 35 32 2e 4a 50 ANON.IMG_7252.JP 0070 47 00 00 - G.. returns 0x54 bytes: 0000 14 00 00 00 01 03 00 00-00 00 00 00 00 00 00 00 ................ 0010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0000 02 00 00 00 05 00 10 21-14 00 00 00 0a 00 00 00 .......!........ 0010 20 00 40 82 - .@. The status code is nonzero, indicating some sort of error.

requesttype=0x06 When called as for "set file attributes": 0000 33 00 00 00 01 02 00 00-00 00 00 00 00 00 00 00 3............... 0010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0040 02 00 00 00 06 00 10 11-33 00 00 00 09 00 00 00 ........3....... 0050 00 00 00 00 41 3a 5c 44-43 49 4d 5c 31 37 32 43 ....A:\DCIM\172C 0060 41 4e 4f 4e 00 49 4d 47-5f 37 32 35 32 2e 4a 50 ANON.IMG_7252.JP 0070 47 00 00 - G.. returns 0x54 bytes: 0000 14 00 00 00 01 03 00 00-00 00 00 00 00 00 00 00 ................ 0010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0000 02 00 00 00 06 00 10 21-14 00 00 00 09 00 00 00 .......!........ 0010 20 00 40 82 - .@. The status code is nonzero, indicating some sort of error.

requesttype=0x07 When called as for "set file attributes": 0000 33 00 00 00 01 02 00 00-00 00 00 00 00 00 00 00 3............... 0010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0040 02 00 00 00 07 00 10 11-33 00 00 00 09 00 00 00 ........3....... 0050 00 00 00 00 41 3a 5c 44-43 49 4d 5c 31 37 32 43 ....A:\DCIM\172C 0060 41 4e 4f 4e 00 49 4d 47-5f 37 32 35 32 2e 4a 50 ANON.IMG_7252.JP 0070 47 00 00 - G.. returns 0x54 bytes: 0000 14 00 00 00 01 03 00 00-00 00 00 00 00 00 00 00 ................ 0010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0000 02 00 00 00 07 00 10 21-14 00 00 00 09 00 00 00 .......!........ 0010 00 00 00 00 - .... The status code is zero, indicating success, but success at what? The state of the named file on the storage card doesn't change.

requesttype=0x09 When called as for "set file attributes": 0000 33 00 00 00 01 02 00 00-00 00 00 00 00 00 00 00 3............... 0010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0040 02 00 00 00 09 00 10 11-33 00 00 00 0a 00 00 00 ........3....... 0050 20 00 00 00 41 3a 5c 44-43 49 4d 5c 31 37 32 43 ...A:\DCIM\172C 0060 41 4e 4f 4e 00 49 4d 47-5f 37 32 35 32 2e 4a 50 ANON.IMG_7252.JP 0070 47 00 00 - G.. returns 0x54 bytes: 0000 14 00 00 00 01 03 00 00-00 00 00 00 00 00 00 00 ................ 0010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0000 02 00 00 00 09 00 10 21-14 00 00 00 0a 00 00 00 .......!........ 0010 20 00 40 82 - .@. That status code hasn't been seen before.

requesttype=0x0a This differs from the command 0x0d in the older protocol; instead of separate strings for directory and file name, we have a complete path specification (directory/file), then another copy of the directory name. Each seems to be allowed 48 bytes (0x30). Command: variable length (here 0x91 bytes) 00000000 51 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 Q............... 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040 02 00 00 00 0a 00 10 11 51 00 00 00 2c d8 12 00 ........Q...,... 00000050 41 3a 2f 44 43 49 4d 2f 31 30 31 43 41 4e 4f 4e A:/DCIM/101CANON 00000060 2f 49 4d 47 5f 30 31 30 35 2e 4a 50 47 00 00 00 /IMG_0105.JPG... 00000070 07 00 05 00 00 01 08 00 68 76 8f 00 78 80 8f 00 ........hv..x... 00000080 41 3a 2f 44 43 49 4d 2f 31 30 31 43 41 4e 4f 4e A:/DCIM/101CANON 00000090 2f / Here we delete a JPEG file. The complete path string is terminated by (at least one) zero byte, followed by garbage. At offset 0x80 of the packet (0x30 of the payload), we have the directory name, with no trailing zero byte. Response: 0x54 bytes 00000000 14 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000000 02 00 00 00 0a 00 10 21 14 00 00 00 2c d8 12 00 .......!....,... 00000010 00 00 00 00 .... Status codes: 0x00000000 No errors 0x82200040 ?? 0x82220040 Bad parameters? Directory not found?

requesttype=0x0b Error codes: 0x00000000 No errors 0x02000022 File not found 0x02000029 File was protected 0x02000086 Path not found Command: variable length (here 0x64 bytes) 00000000 24 00 00 00 02 02 00 00 00 00 00 00 00 00 00 00 $............... 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040 02 00 00 00 0b 00 20 11 24 00 00 00 78 80 8f 00 ...... .$...x... 00000050 00 41 3a 5c 44 43 49 4d 5c 31 30 30 43 41 4e 4f .A:\DCIM\100CANO 00000060 4e 00 00 00 N... The byte at offset 0x50 gives the level of recursion allowed, here zero (no recursion). This is followed by the directory pathname, here “A:\DCIM\100CANON”. Response: 0x40 bytes 00000000 00 00 00 00 02 03 78 00 00 00 00 00 00 00 00 00 ......x......... 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ As with all “long” dialogues, the message contains only the length of data to follow, as a word starting at offset 0x06. In this case, the subsequent data will be 0x78 bytes long. The next message from the camera is: 00000000 a0 00 00 00 00 00 cc 54 8b 41 41 3a 5c 44 43 49 .......T.AA:\DCI 00000010 4d 5c 31 30 30 43 41 4e 4f 4e 00 20 00 d3 9a 9f M\100CANON. .... 00000020 00 98 0f 90 41 49 4d 47 5f 30 30 39 38 2e 43 52 ....AIMG_0098.CR 00000030 32 00 20 00 52 b0 68 00 7a b8 91 41 49 4d 47 5f 2. .R.h.z..AIMG_ 00000000 30 30 39 39 2e 43 52 32 00 20 00 f3 2e 69 00 8a 0099.CR2. ...i.. 00000010 b8 91 41 49 4d 47 5f 30 31 30 30 2e 43 52 32 00 ..AIMG_0100.CR2. 00000020 80 00 00 00 00 00 00 00 00 00 2e 2e 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 ........ This shows four entries. Each entry contains 1 byte attribute bits (described in ) 1 zero byte 4 bytes file size in bytes (zero if directory) 4 bytes UNIX time File name (null-terminated string of arbitrary length) “..” in name means “leave directory”. An entry with attributes, date, and length all zero indicates the end of the directory listing. It seems that with this camera, Canon has changed to putting the string ".." in this empty entry; formerly, the name contained only a single NUL. The contents of this listing: “A:\DCIM\100CANON”, attribute byte 0xa0. This is the name of the directory listed. “IMG_0098.CR2”, attribute byte 0x20, size 0x009f9ad3 (10,459,869) time 0x41900f98. “IMG_0099.CR2”, attribute byte 0x20, size 0x0068b052 (6,860,882) time 0x4191b87a. “IMG_0100.CR2”, attribute byte 0x20, size 0x00692ef3 (6,893,299) time 0x4191b88a.

requesttype=0x0d This seems to be similar to the command 0x09 in the older protocol, but note that the device name has no trailing backslash. Command: variable length (here 0x53 bytes) 00000000 13 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040 02 00 00 00 0d 00 10 11 13 00 00 00 a8 d9 12 00 ................ 00000050 41 3a 00 A:. Argument: null-terminated string containing the name of the disk. Response: 0x5c bytes 00000000 1c 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000000 02 00 00 00 0d 00 10 21 1c 00 00 00 a8 d9 12 00 .......!........ 00000010 00 00 00 00 c0 44 0f 00 80 ac 0e 00 .....D...... 0x54 contains a word with total bytes on flash. 0x58 contains a word with bytes free. So this camera seems to have a card with 1,000,640 bytes, and 961,664 bytes free. I would guess that we need to multiply by, say, 1024, since I think the card was 1GB.

requesttype=0x0e Command: 0x50 bytes 00000000 10 00 00 00 02 02 00 00 00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040 02 00 00 00 0e 00 20 11 10 00 00 00 84 d9 12 00 ...... ......... Response: 0x44 bytes 00000000 00 00 00 00 02 03 04 00 00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000000 41 3a 00 00 A:..

requesttype=0x01 This command is similar to “Identify Camera” from the original protocol, but doesn't return the owner name. To get the owner name, issue the “Get Owner” command. Command: 0x50 bytes 00000000 10 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040 02 00 00 00 01 00 10 12 10 00 00 00 08 e4 d5 00 ................ Response: 0x9c bytes (EOS 20D): 00000000 5c 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 \............... 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040 02 00 00 00 01 00 10 22 5c 00 00 00 08 e4 d5 00 ......."\....... 00000050 00 00 00 00 00 08 77 81 00 05 00 01 43 61 6e 6f ......w.....Cano 00000060 6e 20 45 4f 53 20 32 30 44 00 00 00 00 00 00 00 n EOS 20D....... 00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000010 01 00 00 00 00 00 00 00 00 00 00 00 ............ First 0x40 bytes is throwable (as usual) Data at 0x54-0x57 (here 00 08 77 81) have unknown purpose. 0x58-0x5b is firmware version (04 03 02 01 is version 1.2.3.4; 00 05 00 01 here is version 1.0.5.0) At 0x5c is a string with camera type. Bytes starting at 0x7c seem to be either zero or garbage.

requesttype=0x03 No parameters. Identical with previous protocol. Command: 0x50 bytes 00000000 10 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040 02 00 00 00 03 00 10 12 10 00 00 00 30 dc 12 00 ............0... Response (0x60 bytes): 00000000 20 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ............... 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000000 02 00 00 00 03 00 10 22 20 00 00 00 30 dc 12 00 ......." ...0... 00000010 00 00 00 00 de de a1 41 00 00 00 00 00 00 00 00 .......A........ 0x54 contains a 4-byte UNIX time Other bytes are zero

requesttype=0x04 Command: 0x5c bytes. 00000000 1c 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040 02 00 00 00 04 00 10 12 1c 00 00 00 04 df 12 00 ................ 00000050 f5 de a1 41 00 00 00 00 00 00 00 00 ...A........ 0x50 contains a 4-byte UNIX time Other bytes are zero Response: 0x54 bytes. 00000000 14 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000000 02 00 00 00 04 00 10 22 14 00 00 00 04 df 12 00 ......."........ 00000010 00 00 00 00 .... Status codes: 0x02000086 Invalid parameters (e.g. command block wrong length)

requesttype=0x05 Command: 0x50 bytes. 00000000 10 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040 02 00 00 00 05 00 10 12 10 00 00 00 58 dc 12 00 ............X... Response: 0x74 bytes. 00000000 34 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 4............... 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000000 02 00 00 00 05 00 10 22 34 00 00 00 58 dc 12 00 ......."4...X... 00000010 00 00 00 00 43 6f 72 6e 65 6c 6c 20 55 6e 69 76 ....Cornell Univ 00000020 65 72 73 69 74 79 20 32 35 35 2d 38 33 36 37 00 ersity 255-8367. 00000030 00 00 00 00 .... Status code is 4 bytes at 0x50, followed by null-terminated string. in a 32-byte field (i.e. maximum text length is 31 bytes, I think.

requesttype=0x06 Command is variable in length, here 0x63 bytes. 00000000 23 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 #............... 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040 02 00 00 00 06 00 10 12 23 00 00 00 58 df 12 00 ........#...X... 00000050 43 6f 72 6e 65 6c 6c 20 55 6e 69 76 65 72 73 69 Cornell Universi 00000060 74 79 00 ty. Response: 0x54 bytes. 00000000 14 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000000 02 00 00 00 06 00 10 22 14 00 00 00 58 df 12 00 ......."....X... 00000010 00 00 00 00 .... Status code is 4 bytes at 0x50.

requesttype=0x13 Command: 0x50 bytes 00000000 10 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040 02 00 00 00 13 00 10 12 10 00 00 00 28 ed f9 00 ............(... Response: 0x58 bytes (from an EOS 20D on battery power): 00000000 18 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000000 02 00 00 00 13 00 10 22 18 00 00 00 28 ed f9 00 ......."....(... 00000010 00 00 00 00 06 00 00 20 ....... First 0x50 bytes are throwable. 0x54 contains a byte with power status. 0x6=good, 0x4=bad 0x57 contains a byte with power type in bit 4: ((value &0x20) == 0) running from ac-adapter ((value &0x20) != 0) running from battery The last two values also form the end of the response to an “Identify camera” request.

requesttype=0x1d Command: 0x54 bytes 00000000 14 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040 02 00 00 00 1d 00 10 12 14 00 00 00 a4 e7 12 00 ................ 00000050 00 00 00 00 .... Response: 0x94 bytes 00000000 54 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 T............... 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040 02 00 00 00 1d 00 10 22 54 00 00 00 a4 e7 12 00 ......."T....... 00000050 00 00 00 00 28 00 00 00 00 01 00 02 00 03 00 04 ....(........... 00000060 00 05 01 06 00 07 01 08 00 09 00 0a 00 0b 00 0c ................ 00000070 00 0d 00 0e 00 0f 00 10 00 11 00 12 7c ae 10 00 ............|... 00000000 40 49 b1 ff 70 af 10 00 28 82 b1 ff 00 00 00 00 @I..p...(....... 00000010 00 00 00 00 .... At 0x50 is a 4-byte status code followed by a 4-byte count of bytes (including the 4 bytes of the count), then apparently the custom function settings for the camera. Then at 0x7c is the same sequence as starting at offset 0x84 of the reply to Identify Camera. I suspect that this is garbage in the buffer. Here are the meanings of all custom functions. Note that this table is not the same as that for the earlier EOS cameras. FunctionIndexValuesSET button func, when shooting10: Default (no function) 1: Change quality 2: Change parameters 3: Menu display 4: Image replayLong exposure noise reduction21: onShutter speed in Av mode30: auto 1: 1/250Shutter button/AE lock button function40: AF/AE lock 1: AE lock/AF 2: AF/AF lock, no AE lock 3: AE/AF, no AE lockDisable AF-assist light5TV,AV and exposure increments60: 1/2 stop 1: 1/3 stopFlash firing70: Fires 1: Does not fireISO expansion80: Off 1: OnAEB sequence/auto cancellation90:0..-..+/enable 1:0..-..+/disable 2:-..0..+/enable 3:-..0..+/disableSuperimposed display100: On 1: OffMenu button return position110: Previous (top if power off) 1: previous 2: TopMirror lockup121: onAf point selection method130: Normal 1: Multi-controler direct 2: Quick Control Dial directE-TTL II140: Evaluative 1: AverageShutter curtain sync150: first 1: secondSafety shift in Av or TV160: Disable 1: EnableLens AF stop button Fn, switch170: AF stop 1: AF start 2: AE lock while metering 3: AF point: M→Auto/Auto→ctr. 4: ONE SHOT ↔ AI SERVO 5: IS startAdd original decision data180: Off 1: On

requesttype=0x21 Issued after Power supply status, Identify Camera, unknown command 2, or Get captured image. Command: 0x54 bytes 00000000 14 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040 02 00 00 00 21 00 10 12 14 00 00 00 a8 e7 12 00 ....!........... 00000050 0f 00 00 00 .... Camera Response: 0x54 bytes (EOS 20D) 00000000 14 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000000 02 00 00 00 21 00 10 22 14 00 00 00 a8 e7 12 00 ....!.."........ 00000010 00 00 00 00 ....

requesttype=0x22 One parameter: 0x0000000f. Seems to be issued after a “Remote Capture Control” with subcode of 0x1c (unknown) or 0x04 (release shutter), or at the endo of a file download. Command: 0x54 bytes 00000000 14 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040 02 00 00 00 22 00 10 12 14 00 00 00 b0 e7 12 00 ...."........... 00000050 0f 00 00 00 .... Camera Response: 0x54 bytes (EOS 20D) 00000000 14 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000000 02 00 00 00 22 00 10 22 14 00 00 00 b0 e7 12 00 ....".."........ 00000010 00 00 00 00 .... After this, there seems to be an interrupt read of 0x17 (23) bytes: 00000000 02 00 00 00 0c 00 00 00 17 00 00 00 07 00 00 00 ................ 00000010 02 2d a4 81 00 83 ad .-..... This looks a whole lot like the second interrupt message after release on an older Canon camera. 4-byte integer at byte 0 is 2 4-byte integer at byte 4 is 0xc 4-byte integer at byte 8 is total length 4-byte integer at byte 0x0c may be length of payload (i.e. <total length> - 0x10) 4-byte integer at byte 0x0c apparently gives the image handle for download The byte at 0x10 is 2, whereas earlier cameras gave a 1 4-byte integer at byte 0x11 is the size of the image file, just as with older cameras The byte at 0x15 happens to be the endpoint index of the interrupt endpoint of this device, but this may be coincidence The final byte was 0xb0 for the G2, 0xaf for the D60. Could this be some sort of camera model ID? But there seem to be other versions of the command, e.g.: 00000000 14 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040 02 00 00 00 21 00 10 12 14 00 00 00 a8 e7 12 00 ....!........... 00000050 0f 00 00 00 .... with the following response: 00000000 14 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000000 02 00 00 00 21 00 10 22 14 00 00 00 a8 e7 12 00 ....!.."........ 00000010 00 00 00 00 ....

requesttype=0x23 Issued after “Identify Camera” Command: 0x50 bytes. 00000000 10 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040 02 00 00 00 23 00 10 12 10 00 00 00 f0 df e4 00 ....#........... Response: 0x58 bytes 00000000 18 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040 02 00 00 00 23 00 10 22 18 00 00 00 f0 df e4 00 ....#.."........ 00000050 00 00 00 00 0e 46 03 1f .....F.. The 4 bytes at 0x50 are presumably a status code (0 for success); the next four bytes are the camera Body ID (hardware serial number) in binary. Printing this number as a 10-digit decimal with leading zeroes gives the “Camera Body No.” seen in the EOS Viewer Utility. This camera has a body ID of 0520308238.

requesttype=0x24 I think this replaces the “Get Camera Photo Abilities” command. The response block for this command is longer, but contains a similar list of image type names, resolutions, and compression types. Command: 0x50 bytes 00000000 10 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040 02 00 00 00 24 00 10 12 10 00 00 00 f0 df e4 00 ....$........... Camera response: 0x474 bytes (EOS 20D) 00000000 34 04 00 00 01 03 00 00 00 00 00 00 00 00 00 00 4............... 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040 02 00 00 00 24 00 10 22 34 04 00 00 f0 df e4 00 ....$.."4....... 00000050 00 00 00 00 20 04 75 01 00 80 43 61 6e 6f 6e 20 .... .u...Canon 00000060 45 4f 53 20 32 30 44 00 00 00 00 00 00 00 00 00 EOS 20D......... 00000070 00 00 00 00 00 00 00 00 00 00 07 00 00 00 4c 61 ..............La 00000080 72 67 65 3a 46 69 6e 65 00 00 00 00 00 00 00 00 rge:Fine........ 00000090 00 00 20 09 00 00 b0 0d 00 00 02 00 00 00 4c 61 .. ...........La 000000a0 72 67 65 3a 4e 6f 72 6d 61 6c 00 00 00 00 00 00 rge:Normal...... 000000b0 00 00 20 09 00 00 b0 0d 00 00 03 00 00 00 4d 69 .. ...........Mi 000000c0 64 64 6c 65 3a 46 69 6e 65 00 00 00 00 00 00 00 ddle:Fine....... 000000d0 00 00 a0 06 00 00 f0 09 00 00 02 00 00 00 4d 69 ..............Mi 000000e0 64 64 6c 65 3a 4e 6f 72 6d 61 6c 00 00 00 00 00 ddle:Normal..... 000000f0 00 00 a0 06 00 00 f0 09 00 00 03 00 00 00 53 6d ..............Sm 00000100 61 6c 6c 3a 46 69 6e 65 00 00 00 00 00 00 00 00 all:Fine........ 00000110 00 00 80 04 00 00 c0 06 00 00 02 00 00 00 53 6d ..............Sm 00000120 61 6c 6c 3a 4e 6f 72 6d 61 6c 00 00 00 00 00 00 all:Normal...... 00000130 00 00 80 04 00 00 c0 06 00 00 03 00 00 00 43 52 ..............CR 00000140 57 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 W............... 00000150 00 00 20 09 00 00 b0 0d 00 00 04 00 00 00 00 00 .. ............. 00000160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000001a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000001c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000220 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000230 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000240 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000250 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000260 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000270 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70 00 ..............p. 00000280 00 00 00 00 00 00 9f 00 00 00 07 00 00 00 0f 00 ................ 00000290 00 00 00 80 00 00 00 80 00 00 00 80 00 00 00 80 ................ 000002a0 00 00 00 80 0f 00 00 80 00 00 00 80 00 00 00 80 ................ 000002b0 00 00 00 80 03 00 00 80 21 00 00 80 00 00 00 80 ........!....... 000002c0 00 00 00 00 00 00 00 80 00 00 00 80 00 00 00 00 ................ 000002d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000002e0 50 00 00 00 01 c0 00 00 01 80 00 00 00 80 0b 00 P............... 000002f0 00 80 00 00 00 80 00 00 00 80 00 00 00 80 00 00 ................ 00000300 00 80 00 00 00 a0 00 00 00 80 00 00 00 80 00 00 ................ 00000310 00 00 00 00 00 80 00 00 00 80 00 00 00 80 00 00 ................ 00000320 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000330 00 80 00 00 00 80 00 00 00 00 00 00 00 00 00 00 ................ 00000340 00 80 00 00 00 80 00 00 00 90 00 00 25 a0 00 00 ............%... 00000350 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000360 00 00 00 00 00 00 00 00 00 fc 00 00 00 00 00 00 ................ 00000370 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000380 00 80 00 00 00 00 00 00 00 a0 00 00 00 80 00 00 ................ 00000390 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000003a0 00 00 00 00 00 00 00 00 00 00 00 00 00 80 00 00 ................ 000003b0 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000003c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000003d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000003e0 00 80 00 00 00 80 00 00 00 00 00 00 00 00 13 00 ................ 000003f0 00 80 13 00 00 80 00 00 00 00 00 00 00 00 00 00 ................ 00000400 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000440 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000450 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000460 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000470 00 00 00 00 .... offsetbytesvalue0x50:4status code0x54:2?Length of structure (here 0x420=1056)0x56:2?unknown (here 0x175=373, 2236/6 rounded to nearest integer)0x58:2unknown (here 0x8000=32,768)0x5a:32camera identification (ASCII)0x7a:4Count n-1 where n is the number of entries in image-quality table0x7e:n*32Table of image quality levels allowed Each entry in the table seems to be struct { char imageType[20]; /* ASCII name of this image type */ long imageHeight, imageWidth; long compressionType; /* 2:Fine 3:Normal 4:RAW */ } tableEntry; So we can see that the EOS 20D can produce the following image types: HeightWidthCompressionName22363504JPEG fineLarge:Fine22363504JPEG normalLarge:Normal16962544JPEG fineMiddle:Fine16962544JPEG normalMiddle:Normal11521728JPEG fineSmall:Fine11521728JPEG normalSmall:Normal22363504RawCRW I suspect that the remaining bytes after 0x15d are garbage.

requesttype=0x25 I think this is the new version of Remote Camera Control. Subcommands seen so far: SubcommandSample ParametersReply LengthFunction00none5C Camera control initialization01none5C Exit release control04none5C Release shutter07buffer of 0x34 bytes 5CSet release parameters0904 00 00 00 09 00 00 005C Set transfer mode0Anone8C Get release parameters0Dnone60 Get available shot10none60 Get size of extended release parameters12nonevaries Get extended release parameters13<block of parameters>5c Set extended parameters1B0x4 0xb5e Unknown1Cnone67, 6d, 70, 66, 65 Unknown The following functions haven't been seen yet. Some (e.g. “get custom functions”) have, I think, been superseded by other opcodes; others (e.g. “Start viewfinder”, “Set zoom position”) don't really apply to the EOS cameras that, so far, are the only ones using this protocol. SubcommandSample ParametersReply LengthFunction02none5C Start viewfinder03none5C Stop viewfinder0Bnone60 Get zoom position0C04 00 00 00 01 00 00 005c Set zoom position0E????? Set custom function0F14 bytes66 Get custom function11???????? Get version of extended release parameters1401 00 00 00 00 035C Select camera output15?????? Do auto exposure, focus, and white balance The subcommand is stored as a little-endian 4-byte number at the start of the message payload (i.e. starting 0x50 bytes from the start of the buffer). Parameters vary by subcommand, as noted below; they follow the subcommand in the message payload. The minimum is <subcommand> 0 with another zero byte, so the minimum length of a command packet is 0x59. The extra byte means that the length of this command will always be odd. In the reply, the payload will always start with status, <subcommand>. After that, the minimum is one more zero word (plus an extra zero byte), or there may be more information. The minimum length is 0x5c.

Takes no parameters. Command: 0x59 bytes 00000000 19 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040 02 00 00 00 25 00 10 12 19 00 00 00 68 e7 12 00 ....%.......h... 00000050 00 00 00 00 00 00 00 00 00 ......... Camera response: 0x5c bytes 00000000 1c 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000000 02 00 00 00 25 00 10 22 1c 00 00 00 68 e7 12 00 ....%.."....h... 00000010 00 00 00 00 00 00 00 00 00 00 00 00 ............

Takes no parameters Command: 0x59 bytes 00000000 19 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040 02 00 00 00 25 00 10 12 19 00 00 00 58 e7 12 00 ....%.......X... 00000050 01 00 00 00 00 00 00 00 00 ......... Response: 0x5c bytes 00000000 1c 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000000 02 00 00 00 25 00 10 22 1c 00 00 00 58 e7 12 00 ....%.."....X... 00000010 00 00 00 00 01 00 00 00 00 00 00 00 ............

Takes no parameters. We haven't figured out interrupt communication yet. Command: 0x59 bytes 00000000 19 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040 02 00 00 00 25 00 10 12 19 00 00 00 44 e9 17 01 ....%.......D... 00000050 04 00 00 00 00 00 00 00 00 ......... Response: 0x5c bytes 00000000 1c 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000000 02 00 00 00 25 00 10 22 1c 00 00 00 44 e9 17 01 ....%.."....D... 00000010 00 00 00 00 04 00 00 00 00 00 00 00 ............

Takes a payload of 0x39 bytes: 0x35 after subcommand code. Command: 0x59 bytes 00000000 49 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 I............... 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040 02 00 00 00 25 00 10 12 49 00 00 00 44 e9 17 01 ....%...I...D... 00000050 07 00 00 00 30 00 00 00 20 02 01 02 00 00 ff 00 ....0... ....... 00000060 03 01 00 ff 03 ff 02 90 08 ff 00 ff 7f 7f 7f 7f ................ 00000070 ff ff 58 00 20 00 70 00 00 00 ff ff 18 00 50 00 ..X. .p.......P. 00000080 ff ff ff ff ff ff 01 00 00 ......... Response: 0x5c bytes (success): 00000000 1c 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000000 02 00 00 00 25 00 10 22 1c 00 00 00 44 e9 17 01 ....%.."....D... 00000010 00 00 00 00 07 00 00 00 00 00 00 00 ............

Takes 2 parameters: 4, <code> where <code> is a combination of the following bits: #define THUMB_TO_PC 0x0001 #define FULL_TO_PC 0x0002 #define THUMB_TO_DRIVE 0x0004 #define FULL_TO_DRIVE 0x0008 These may be combined in any way. 00000000 1d 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040 02 00 00 00 25 00 10 12 1d 00 00 00 58 e7 12 00 ....%.......X... 00000050 09 00 00 00 04 00 00 00 02 00 00 00 00 ............. Response: 0x5c bytes 00000000 1c 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000000 02 00 00 00 25 00 10 22 1c 00 00 00 58 e7 12 00 ....%.."....X... 00000010 00 00 00 00 09 00 00 00 00 00 00 00 ............

Takes no parameters. Returns 0x34 bytes after the echo of the subcommand code. First 4-byte integer is 0x00000030, which is the count of remaining bytes. I assume that the 0x34 bytes are the same as is sent down by code 07, “set release parameters”. Command: 0x59 bytes 00000000 19 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040 02 00 00 00 25 00 10 12 19 00 00 00 4c e7 12 00 ....%.......L... 00000050 0a 00 00 00 00 00 00 00 00 ......... Response: 8c bytes 00000000 4c 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 L............... 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040 02 00 00 00 25 00 10 22 4c 00 00 00 4c e7 12 00 ....%.."L...L... 00000050 00 00 00 00 0a 00 00 00 30 00 00 00 20 04 02 00 ........0... ... 00000060 00 00 ff 00 01 01 00 ff 03 ff 02 90 02 ff 00 ff ................ 00000070 7f 7f 7f 7f ff ff 58 00 1c 00 74 00 00 00 ff ff ......X...t..... 00000000 18 00 50 00 ff ff ff ff ff ff 01 00 ..P.........

No parameters Command: 0x59 bytes 0000 19 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 ................ 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0040 02 00 00 00 13 00 10 12 18 00 00 00 1f 00 00 00 ..............%. 0050 0d 00 00 00 00 00 00 00 00 ........ Reply 0x60 bytes: 0000: 20 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ............... 0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0040: 02 00 00 00 25 00 10 22 20 00 00 00 1f 00 00 00 ....%.." ....... 0050: 00 00 00 00 0d 00 00 00 04 00 00 00 e8 03 00 00 ................ The last word is the estimated number of shots remaining: i.e. the free storage space divided by the estimated size of an image file in the current mode.

No parameters Command: 0x59 bytes 00000000 19 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040 02 00 00 00 25 00 10 12 19 00 00 00 5c e7 12 00 ....%.......\... 00000050 10 00 00 00 00 00 00 00 00 ......... Response: 0x60 bytes 00000000 20 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ............... 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000000 02 00 00 00 25 00 10 22 20 00 00 00 5c e7 12 00 ....%.." ...\... 00000010 00 00 00 00 10 00 00 00 04 00 00 00 3c 00 00 00 ............<...

Parameters are the 8-byte result from Get size of extended release parameters. Command: 0x5d bytes 00000000 1d 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040 02 00 00 00 25 00 10 12 1d 00 00 00 4c e7 12 00 ....%.......L... 00000050 12 00 00 00 04 00 00 00 3c 00 00 00 00 ........<.... Response: 0x98 bytes 00000000 58 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 X............... 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040 02 00 00 00 25 00 10 22 58 00 00 00 4c e7 12 00 ....%.."X...L... 00000050 00 00 00 00 12 00 00 00 3c 00 00 00 3c 00 00 00 ........<...<... 00000060 00 00 05 00 00 00 00 00 ff ff ff ff 00 00 00 00 ................ 00000070 ff ff ff ff ff ff ff ff 00 00 ff ff ff ff ff ff ................ 00000000 ff ff 00 00 50 14 ff ff 01 00 ff ff ff ff 00 00 ....P........... 00000010 ff ff 00 00 00 00 00 00 ........ OffsetContentMeaning0x000x0000003cLength of block0x040x0000??0x060x0005??0x080x00000000??0x0c0xffffffff (-1)??0x100x00000000??0x140xffffffff (-1)??0x180xffffffff (-1)??0x1c0x0000??0x1e0xffff (-1)??0x200xffffffff (-1)??0x240xffff (-1)??0x260x0000??0x280x1450??0x2a0xffff (-1)??0x2c0x0001??0x2e0xffff (-1)??0x300xffff (-1)??0x320x0000??0x340xffff (-1)??0x360x0000??0x380x00000000??

Command: 0x95 bytes 00000000 55 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 U............... 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040 02 00 00 00 25 00 10 12 55 00 00 00 44 e9 17 01 ....%...U...D... 00000050 13 00 00 00 3c 00 00 00 3c 00 00 00 00 00 05 00 ....<...<....... 00000060 00 00 00 00 ff ff ff ff 00 00 00 00 ff ff ff ff ................ 00000070 ff ff ff ff 00 00 ff ff ff ff ff ff ff ff 00 00 ................ 00000080 50 14 ff ff 01 00 ff ff ff ff 00 00 ff ff 00 00 P............... 00000090 00 00 00 00 00 ..... OffsetContentMeaning0x000x0000003cLength of block0x040x0000??0x060x0005??0x080x00000000??0x0c0xffffffff (-1)??0x100x00000000??0x140xffffffff (-1)??0x180xffffffff (-1)??0x1c0x0000??0x1e0xffff (-1)??0x200xffffffff (-1)??0x240xffff (-1)??0x260x0000??0x280x1450??0x2a0xffff (-1)??0x2c0x0001??0x2e0xffff (-1)??0x300xffff (-1)??0x320x0000??0x340xffff (-1)??0x360x0000??0x380x00000000??0x3c0x00padding Response: 0x5c bytes 00000000 1c 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000000 02 00 00 00 25 00 10 22 1c 00 00 00 44 e9 17 01 ....%.."....D... 00000010 00 00 00 00 13 00 00 00 00 00 00 00 ............

This command might just set up for command code 0x1c, which has no parameters but seems to give various responses. Two parameters: count of following bytes (4), subcode {0x0b,0x0e,0x17,0x18,0x19,0x1a}. Commands seem to come in that order, and each is immediately followed by a command with subcode 0x1c. 00000000 1d 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040 02 00 00 00 25 00 10 12 1d 00 00 00 4c e7 12 00 ....%.......L... 00000050 1b 00 00 00 04 00 00 00 0b 00 00 00 00 ............. Response: 0x5e bytes 4-byte status code, echo of major code (0x1b), count of remaining bytes (2), 16 bit byte count for the result of the subsequent 0x1c command. This varies with the command subcode: 0x0b 0x000b 0x0e 0x0011 0x17 0x0014 0x18 0x0026, 0x000a 0x19 0x0052, 0x0009 0x1a 0x0009, 0x0011

Command: 0x59 bytes 00000000 19 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040 02 00 00 00 25 00 10 12 19 00 00 00 4c e7 12 00 ....%.......L... 00000050 1c 00 00 00 00 00 00 00 00 ......... Response after 0x25/0x1b/0x0b: 0x67 bytes 00000000 27 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 '............... 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000000 02 00 00 00 25 00 10 22 27 00 00 00 4c e7 12 00 ....%.."'...L... 00000010 00 00 00 00 1c 00 00 00 0b 00 00 00 03 00 00 00 ................ 00000020 02 00 00 00 03 04 05 ....... At offset 0x50, there is the customary 4-byte status code, followed by an echo of the 4-byte command code 0x0000001c, followed by a byte count which is identical to the value returned by the previous command with subcode 0x1b. After the byte count comes a count N of entities, then what I think is an entity type. 2 seems to be a single-byte entity; 4 is a 2-byte entity. Then come N data elements. At least sub-subcodes 0x18, 0x19, 0x1a can vary their length. Response after 0x25/0x1b/0x0e: 0x6d bytes 00000000 2d 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 -............... 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000000 02 00 00 00 25 00 10 22 2d 00 00 00 4c e7 12 00 ....%.."-...L... 00000010 00 00 00 00 1c 00 00 00 11 00 00 00 09 00 00 00 ................ 00000020 02 00 00 00 00 01 02 03 04 05 06 08 09 ............. Response after 0x25/0x1b/0x17: 0x70 bytes 00000000 30 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 0............... 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000000 02 00 00 00 25 00 10 22 30 00 00 00 4c e7 12 00 ....%.."0...L... 00000010 00 00 00 00 1c 00 00 00 14 00 00 00 06 00 00 00 ................ 00000020 04 00 00 00 48 00 50 00 58 00 60 00 68 00 70 00 ....H.P.X.`.h.p. Response after 0x25/0x1b/0x18: 0x66 bytes 00000000 26 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 &............... 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000000 02 00 00 00 25 00 10 22 26 00 00 00 4c e7 12 00 ....%.."&...L... 00000010 00 00 00 00 1c 00 00 00 0a 00 00 00 00 00 00 00 ................ 00000020 04 00 00 00 ff ff ...... Response after 0x25/0x1b/0x18: 0x82 bytes 00000000 42 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 B............... 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040 02 00 00 00 25 00 10 22 42 00 00 00 4c e7 12 00 ....%.."B...L... 00000050 00 00 00 00 1c 00 00 00 26 00 00 00 0f 00 00 00 ........&....... 00000060 04 00 00 00 18 00 1c 00 20 00 24 00 28 00 2c 00 ........ .$.(.,. 00000070 30 00 34 00 38 00 3c 00 40 00 44 00 48 00 4c 00 0.4.8.<.@.D.H.L. 00000000 50 00 P. This has status code, 4-byte count of following bytes, 4-byte 0xf (15), 4-byte 0x4, then 15 2-byte integers that start at 0x18 (24) and count up by 4. Response after 0x25/0x1b/0x19: 0x65 bytes 00000000 25 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 %............... 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000000 02 00 00 00 25 00 10 22 25 00 00 00 4c e7 12 00 ....%.."%...L... 00000010 00 00 00 00 1c 00 00 00 09 00 00 00 00 00 00 00 ................ 00000020 02 00 00 00 ff ..... Response after 0x25/0x1b/0x1a: 0x6d bytes 00000000 2d 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 -............... 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000000 02 00 00 00 25 00 10 22 2d 00 00 00 4c e7 12 00 ....%.."-...L... 00000010 00 00 00 00 1c 00 00 00 11 00 00 00 09 00 00 00 ................ 00000020 02 00 00 00 f0 f4 f8 fc 00 04 08 0c 10 ............. After the byte count, a 4-byte 0x9, 4-byte 0x2, then single bytes counting up by 4: -16, -12, -8, -4, 0, 4, 8, 12, 16.

requesttype=0x26 Similar to the Download Captured Image command in the older protocol. Command: 0x60 bytes 00000000 20 00 00 00 02 02 00 00 00 00 00 00 00 00 00 00 ............... 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040 02 00 00 00 26 00 20 12 20 00 00 00 d0 53 7e 00 ....&. . ....S~. 00000050 00 00 00 00 00 00 01 00 02 00 00 00 07 00 00 00 ................ This is very similar to the old “Download Captured Image” command block. Offset 0x50 presumably has the 4-byte status code, 0x54 has the transfer length (here 0x10000, 65536 bytes), 0x58 has the image type (here 2 for full image), and 0x5c has the image handle of 7. Camera response: variable length 00000000 00 00 00 00 02 03 f8 0e 03 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ As before, bytes 6-10 of the reply packet contain the 32-bit total length of the image data transfers, here 0x00030ef8. We must then issue a series of bulk reads. then many blocks. First is length 0x10000, then 0x10c0, then (0x40, 0xfec0) twice, then 0x38 bytes. Total is 0x00030ef8 (200,440) bytes. I think this is a JPEG image being downloaded; note the JFIF EXIF tag at the start. 00000000 ff d8 ff e1 2d 9a 45 78 69 66 00 00 49 49 2a 00 ....-.Exif..II*. 00000010 08 00 00 00 09 00 0f 01 02 00 06 00 00 00 7a 00 ..............z. 00000020 00 00 10 01 02 00 0e 00 00 00 80 00 00 00 12 01 ................ 00000030 03 00 01 00 00 00 01 00 00 00 1a 01 05 00 01 00 ................ 00000040 00 00 a0 00 00 00 1b 01 05 00 01 00 00 00 a8 00 ................ 00000050 00 00 28 01 03 00 01 00 00 00 02 00 00 00 32 01 ..(...........2. 00000060 02 00 14 00 00 00 b0 00 00 00 13 02 03 00 01 00 ................ 00000070 00 00 02 00 00 00 69 87 04 00 01 00 00 00 c4 00 ......i......... 00000080 00 00 50 24 00 00 43 61 6e 6f 6e 00 43 61 6e 6f ..P$..Canon.Cano 00000090 6e 20 45 4f 53 20 32 30 44 00 00 00 00 00 00 00 n EOS 20D....... 000000a0 00 00 00 00 00 00 00 00 00 00 00 00 48 00 00 00 ............H... 000000b0 01 00 00 00 48 00 00 00 01 00 00 00 32 30 30 34 ....H.......2004 000000c0 3a 31 31 3a 32 32 20 31 32 3a 35 35 3a 31 36 00 :11:22 12:55:16. 000000d0 1c 00 9a 82 05 00 01 00 00 00 1a 02 00 00 9d 82 ................ 000000e0 05 00 01 00 00 00 22 02 00 00 22 88 03 00 01 00 ......"..."..... 000000f0 00 00 01 00 00 10 27 88 03 00 01 00 00 00 64 00 ......'.......d. 00000100 00 00 00 90 07 00 04 00 00 00 30 32 32 31 03 90 ..........0221.. 00000110 02 00 14 00 00 00 2a 02 00 00 04 90 02 00 14 00 ......*......... 00000120 00 00 3e 02 00 00 01 91 07 00 04 00 00 00 01 02 ..>............. ... 00000000 b8 cd 23 64 b6 07 03 d4 50 f5 0d 80 a6 18 12 4f ..#d....P......O 00000010 1e b4 31 2c 71 b7 34 b7 04 ae 01 f0 40 23 93 da ..1,q.4.....@#.. 00000020 80 7e 6c 37 5f 6a 00 45 4c 64 0f cc d2 ee da c0 .~l7_j.ELd...... 00000030 63 83 de 9d c5 73 ff d9 c....s..

requesttype=0x35 Equivalent to Lock Keys But this command is shorter (no parameter “6”), and the response is longer (12 zero bytes, not just 4). Command: 0x50 bytes 00000000 10 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040 02 00 00 00 35 00 10 12 10 00 00 00 a8 eb 12 00 ....5........... Camera response: 0x5c bytes 00000000 1c 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000000 02 00 00 00 35 00 10 22 1c 00 00 00 a8 eb 12 00 ....5.."........ 00000010 00 00 00 00 00 00 00 00 00 00 00 00 ............

requesttype=0x36 Thought this was equivalent to EOS Unlock Keys, but doesn't work in symmetry with 0x35. Command is longer; response is the same. Command: 0x58 bytes 00000000 18 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040 02 00 00 00 36 00 10 12 18 00 00 00 98 ed 17 01 ....6........... 00000050 00 00 00 00 00 00 00 00 ........ Response: 0x54 bytes 00000000 14 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000000 02 00 00 00 36 00 10 22 14 00 00 00 98 ed 17 01 ....6.."........ 00000010 00 00 00 00 .... When issued at the wrong time, the command returns a status code of 0x00000086: 0000 14 00 00 00 01 03 00 00-00 00 00 00 00 00 00 00 ................ 0010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0040 02 00 00 00 36 00 10 22-14 00 00 00 43 00 00 00 ....6.."....C... 0050 86 00 00 00 - ....