Chapter 3. USB Interface

Table of Contents

Init of camera
USB Command Protocol
Structure of a command block
Structure of a response block
Status Codes
Summary of available (known) commands
Get Picture
Make directory
Delete directory
Disk Info Request
Flash Device Identification
Get Directory
Delete file
Set File Attributes
Set File Time
Identify Camera
Get time
Set Time
Change Owner
Power supply status
Remote Camera Control
Camera control initialization: 00
Exit release control: 01
Start viewfinder: 02
Stop viewfinder: 03
Release shutter: 04
Set release parameters: 07
Set transfer mode: 09
Get release parameters: 0A
Get zoom position: 0B
Set zoom position: 0C
Get available shot: 0D
0E Set custom function
Get custom function: 0F
Get size of extended release parameters: 10
11 Get version of extended release parameters
Get extended release parameters: 12
13 Set extended parameters
Select camera output: 14
15 Do auto exposure, focus, and white balance
Download Captured Image
Download Captured Preview
Unknown
EOS (D30/D60) Lock Keys
EOS Unlock Keys
Get EOS Body ID
Get Camera Photo Abilities
Lock Keys
USB Upload (a little bit special)

Notes

Init of camera

  1. 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)

  2. 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 01000200. These bytes might identify which version of the protocol is used. The following table summarizes our observations to date.

    Table 3.1. Unknown contents of response packet

    Models0x400x440x480x4C0x500x54
    G1, 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.

  3. 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 initialization[2].

  4. 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

  5. PC sign should now appear on the LCD. Not all cameras have PC signs though.

  6. 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 circumstances[3]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                                     ....
              
  7. 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.



[2] Many 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.

[3] It 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.