1This is the gphoto's description of the Canon PowerShot serial/USB 2protocol, s10sh is based on this document. 3 4(read/print this document with a non-proportional font such as courier) 5 6============================================ 7====== Canon Powershot Series ====== 8==== Transfer Protocol Specifications ===== 9============================================ 10 11Timestamp: 2000-06-29 12 13* About this document 14 15The following document is an overview of the Canon Powershot serial 16and USB transfer protocols. It should be a valid reference for models 17ranging from Powershot A5 to S100. 18 19No information present in this document was obtained from Canon. 20Everything is the result of observations and logical analysis. It is 21by no means guaranteed to be accurate, nor even right. Nevertheless, a 22lot of people have managed to communicate with their Powershot cameras 23using these commands, so they cannot be completely wrong either ! 24 25An implementation of this communication protocol was made for the 26GPhoto digital camera software, available at www.gphoto.org. Another 27program implements this protocol: s10sh, which is a command-line 28interface. Look for their records on freshmeat.net ! 29 30* Contributors: 31 32 This document was written thanks to the efforts of: 33 34 Wolfgang G. Reissnegger, Werner Almesberger, Philippe Marzouk, Mikael 35 Nystr�m, Edouard Lafargue, Salvatore Sanfilippo <antirez@linuxcare.com> 36 37 38* Copyright : 39 40 The Canon Protocol information. Copyright (c) 2000 by its respective 41 authors (see the Contributors section). 42 43 This program is free software; you can redistribute it and/or modify 44 it under the terms of the GNU General Public License as published by 45 the Free Software Foundation; either version 2 of the License, or (at 46 your option) any later version. 47 48 This program is distributed in the hope that it will be useful, but 49 WITHOUT ANY WARRANTY; without even the implied warranty of 50 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU 51 General Public License for more details. 52 53 You should have received a copy of the GNU General Public License 54 along with this program; if not, write to the: 55 56 Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, 57 USA. 58 59* To Do : 60 61 (send updates to Edouard.Lafargue@bigfoot.com or to the 62 gphoto-devel mailing-list) 63 64 - Serial: 65 66 Describe the structure of the initial ID packet. 67 Find out what the real meaning of the "fffb" command is. 68 Describe error recovery protocol. 69 Describe format of low batt condition. 70 Find out the rest of the commands that were discovered in USB: 71 - Make dir 72 - Delete dir 73 - Change attribute 74 - etc. 75 Describe File upload. 76 Describe each command in detail. 77 78 - USB: 79 80 Describe the generic get_directory reply packet with the location of 81 the error code offset. 82 83 - General: 84 85 Rewrite this document in XML (LinuxDoc). 86 87* Changelog: 88 89 09 May 2000: first version with both USB and serial protocols 90 described in the same document. 91 92 28 June 2000: Merged the changes from Salvatore. 93 94 95 96========================================================================= 97 98============================================ 99== Background information on the == 100=== Canon Powershot series === 101============================================ 102 103 Here's some information about the hardware found in the canon 104powershot series cameras, in case you are interested: 105 106 - Processor: 8086-compatible chip () 107 - Running the datalight embedded DOS (www.datalight.com) 108 - Canon had their own name, "DigitalEye" for the OS/camera environment. 109 110 It is possible to look into the camera embedded softare by listing 111other drives than the default flash card: 112 113 A: -> Main camera application (to be confirmed) 114 B: -> Data, tables (to be confirmed) 115 C: -> 116 D: -> CF card one 117 E: -> On the powershot 70, probably CF card two (to be confirmed) 118 119 120============================================ 121== Serial Protocol == 122=== Specifications === 123============================================ 124 125 126Introduction 127============ 128 129 We have chosen to describe the Canon Serial Protocol as successive 130layers. I used OSI-like names but the protocol is not really a network 131protocol. 132 133 a. Data link layer: 134 Responsible for framing, escaping and checksuming messages 135 136 b. Transport (packet) layer: 137 Responsible for dividing messages into packets of known length. 138 This layer also handles handshaking, retries, etc. 139 140 c. Session (message) layer: 141 Last layer, carrying whole messages, such as download requests, 142 image data, and such information. 143 144 Currently, all these layers are documented, but we still lack 145 information on how to handle protocol retries, and errors in general. 146 147 148Data link layer 149===================== 150 151The following figure illustrates the lower layers of the protocol 152used by some Canon PowerShot cameras: 153 154[ Upper layers ] Example: payload "00 C0 01" 155 | ^ 156 | | 00 C0 01 157 <CRC> 158 | | 00 C0 01 12 34 (fictious CRC) 159 <Escaping> 160 | | 00 7E E0 01 12 34 161 <Framing> 162 | | C0 00 7E E0 01 12 34 C1 163 v | 164[ Wire format ] 165 166The upper layers are described later in this file. 167 168Note that even the checksum bytes must be escaped. 169 170 1710) Serial timing 172---------------- 173 174Initialization: PC sends sequences of "U" bytes at 9600 bps until the 175camera responds by sending its ID. Each sequence has a length of 2-8 176bytes. The interval to wait between sequences is 0.9-1.04 sec 177(measured for 8 bytes). 178 179On the S-series (S10/S20), the interval can be even shorter, like 0.4 180sec, so initialization is faster. 181 182When the camera sends its ID, the computer can ask it to change to a 183higher speed. The speed can go up to 115200 bps. 184 185Afterwards, a four/five second command timeout should be set. E.g. 186retrieving a directory with 1200 files takes several seconds. Opening 187a large capacity flash card takes time as well. It looks like 4/5 188seconds is the camera's own timeout for receiving commands. 189 190 191 1921) Framing 193---------- 194 195Each message begins with the byte C0 and ends with the byte C1. The 196length of a message including the framing bytes and any escape bytes 197(see below) never exceeds 1024 bytes. 198 199 2002) Escaping 201----------- 202 203The value 7E is used to XOR the following byte with the value 0x20. This 204is used for the following three combinations: 205 7E 5E -> 7E 206 7E E0 -> C0 207 7E E1 -> C1 208 209 2103) CRC 211------ 212 213The last two bytes of a message (without framing and escaping) contain 214a 16-bit "CCITT" CRC in little-endian order. The CRC is calculated 215over the entire message, without framing and escaping, and without 216including the CRC bytes. The CRC generator [1] is initialized to a 217length-dependent value. The algorithim for the initial value is not 218known. However, a table of values emitted by the camera has been 219compiled and is in crc.c:crc_init. It is indexed by the length, 220i.e. the number of bytes over which the CRC is taken. 221 222 223[1] Assuming the use of 224 http://www.cse.fau.edu/~sam/course/dc_htm/src_dir/crc_att.c, 225 generator polynom 0102010 (octal), the initial value of "crc" is 226 the CRC generator's initial value (in the original code always 227 zero). 228 229 230 231Transport layer 232===================== 233 234Communication is done through messages, which may be split into 235several fragments, which are then sent as individual packets. Packets 236are framed as described earlier in this file. 237 238 239Packet level 240------------ 241 242Each packet consists of the following two-byte header: 243 244<sequence> <ptype> 245 246There are two sequence numbers: the message sequence number <mseq> and 247the fragment sequence number <fseq>. They are counted independently 248and start at zero. <mseq> is reset at the beginning of a session, 249while <fseq> is reset at the beginning of each message. 250 251The following packet types are known: 252 00 Message fragment 253 02 Switch the camera off 254 03 Speed message from computer 255 04 EOT 256 05 ACK 257 06 Compatibility? 258 259A packet with type 03 is sent once, early in the initialization for 260the computer to ask the camera to switch to a higher speed. 261 262Each message ends with an EOT packet, which is then confirmed by an 263ACK packet. If the camera does not get the ACK it resends the EOT 264several times. 265 266 267EOT has the following format: 268xx 04 xx 00 00 00 269| | 270| indication of the message length. Known values: 271<mseq> 00 empty message (no fragments) 272 01 short message (one fragment) 273 ff maximum length data packet, more to follow 274 else data packet, at end (observed values: 0f, 7f) 275 276ACK has the following format: 277xx 05 xx 00 00 00 278| | 279| error code 280<mseq> 281 282The ACK error code is 00 to ACKnowledge the packet, a packet with 01 283ask to the camera to resend the first fragment of the last message, 02 284ask to the camera to resend the second fragment and so on. the code 2850xFF retransmits all the packets of the last message. The ACK 286sequence number is initally 0, then it is incremented for every _good_ 287ACK. If you send an ack with error code != 0 you must NOT increment 288the ACK sequence. 289 290A packet with type 06 is sent once, as the first packet coming from 291the camera. It contains a length, just like a normal message fragment, 292but the message structure is different. 293 294An empty message can be used to test if the camera is still responding. 295If yes, it will respond with an ACK. Example: 296PC->CAM xx 04 00 00 00 00 297CAM->PC xx 05 00 00 00 00 298 299 300Message fragment level 301---------------------- 302 303Message fragments have the following structure: 304 305xx 00 xx xx ... 306| | | | 307| | | fragment data 308| | data length, MSB 309| data length, LSB 310<fseq> 311 312The data length is the length (in bytes) of the fragment data that 313follows the length. Fragment data is simply concatenated to form the 314complete message. 315 316 317Session (message) Layer 318======================= 319 320All messages sent to/from the camera have the following structure: 321 32202 00 00 00 xx 00 00 xx xx xx 00 00 xx xx xx xx ... 323 | | | | | | 324 | | | | Serial nb. message payload 325 | | | message length, MSB 326 | | message length, LSB 327 | direction code <dir> 328 message type <mtype> 329 330The message length is the length of the entire message, including the 331header shown above. 332 333The serial number can be chosen at random (use the date for example) and will be 334returned in the response of the camera. 335 336List of known message types/directions: 337 338<mtype><dir> Operation 339 34001 11 Download file 34101 12 Identify camera 34203 11 Upload file (?) 34303 12 Get Date 34404 12 Set date 34505 11 Make directory 34605 12 Change Owner name 34706 11 Remove directory 34809 11 Disk info request 3490a 11 Get flash device identification 3500a 12 Power Supply Status 3510b 11 List directory 3520d 11 Delete file 3530e 11 Set file attributes 354 355 35601 22 Identify camera response 35701 21 File download data 35803 22 Get Date response 35909 21 Disk info response 3600a 21 Get disk(s) response 3610a 22 Power Supply Status response 3620b 21 List without date response 3630b 21 List with date response 3640d 21 Delete image response 365 366 367A message with <mtype> 02 is sent by the camera to notify that it 368isn't no longer if PC-transfer mode (<-._> symbol), this happens when 369the user switches the camera to some other mode. 370 371The four first bytes of each response message is the error code of the 372operation. Here's the list of known codes: 373 374 0x00000000 : Success 375 0x02000022 : No such file 376 0x02000029 : File is protected 377 0x02000040 : No such directory 378 0x02000087 : No such disk 379 0x02000086 : Path not found (?) 380 381------------------------------------------ 382- List Of commands 383------------------------------------------ 384 385 Each command is described in the following format: 386 387Command name 388------------ 389 390 * Explanation of what the command does 391 392 * Format of the request packet. 393 394 * Format of the response packet with offsets to 395 each part of the data. Offset zero is the first 396 byte after the error code. 397 398 * Example of request packet (with framing/escaping) 399 * Example of response packet (after unescaping/without framing/CRC) 400 401 402Identify camera 403--------------- 404 405 * Asks the camera for some of its parameters: model, firmware, owner. 406 407 * The identify camera request has no data. 408 409 * The identify camera response has the following structure: 410 411 - A5/A50 models : 412 413 00 02 00 00 00 00 00 01 <camera_name> 00 (more 00s) 414 415 - S10/S20 : 416 417 00 04 00 00 00 00 00 01 and then: 418 <firmware rev> (32 bit word) (offset: 0x08) 419 <model name> (C string) (offset: 12 / 0x0c) 420 <owner name> (C string) (offset: 44 / 0x2c) 421 422 Firmware version: 04 03 02 01 is version 1.2.3.4 423 01 00 00 01 is version 1.0.0.1 424 425 * Example of id camera request: 426WRITE: (24 bytes) 42700000000: C0 00 00 10 00 02 00 00 00 01 00 00 12 10 00 00 - ................ 42800000010: 00 14 F7 8A 00 AD 7A C1 - ......z. 429 430 * Example of id camera response, for a PowerShot S10 431 with firmware 1.0.0.0 432RECV: (98 bytes) 43300000000: 00 00 5C 00 02 00 00 00 01 00 00 22 5C 00 00 00 - ..\........"\... 43400000010: 14 F7 8A 00 00 00 00 00 00 04 00 00 00 00 00 01 - ................ 43500000020: 43 61 6E 6F 6E 20 50 6F 77 65 72 53 68 6F 74 20 - Canon PowerShot 43600000030: 53 31 30 00 00 00 00 00 00 00 00 00 00 00 00 00 - S10............. 43700000040: 45 64 6F 75 61 72 64 20 4C 61 66 61 72 67 75 65 - Edouard Lafargue 43800000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - ................ 43900000060: 9C EA - .. 440 441 442Get Power Status 443---------------- 444 445 * This command show the current power status of the camera 446 447 * The get power status command has no data. 448 449 * The get power status response has the following structure: 450 451 0x00 contains a byte with power status: 0x6=good, 0x4=bad 452 0x03 contains a byte with powertype: 0x10=ac-adaptor, 0x30=battery 453 454 * Example of get power status request: 455WRITE: (24 bytes) 45600000000: C0 00 00 10 00 02 00 00 00 0A 00 00 12 10 00 00 - ................ 45700000010: 00 70 F6 8A 00 7B 46 C1 - .p...{F. 458 459 * Example of get power status response: 460RECV: (30 bytes) 46100000000: 00 00 18 00 02 00 00 00 0A 00 00 22 18 00 00 00 - ...........".... 46200000010: 70 F6 8A 00 00 00 00 00 06 00 00 30 B5 5A - p..........0.Z 463 464 465 466Change Owner Name 467---------------- 468 469 * This command sets the owner name in the camera. I am not sure 470this command is supported in the A-series, but both the S10 and the 471S20 support it. 472 473 * The payload is a C string (null-terminated) of 30 characters max. 474 475 * Response: the response contains the error code only. 476 477 478Get Date 479-------- 480 481 * This command returns the internal date of the camera. As powershots 482 don't contain a timezone, the date is returned must not be converted 483 to local time. 484 485 * Payload: no data 486 487 * Response format: 488 Offsets: 489 0x00 : Date, unix format, local time, little-endian 490 491 * Example of request packet: 492WRITE: (24 bytes) 49300000000: C0 00 00 10 00 02 00 00 00 03 00 00 12 10 00 00 - ................ 49400000010: 00 78 F3 64 01 A7 77 C1 - .x.d..w. 495 496 * Example of response packet: 497RECV: (38 bytes) 49800000000: 00 00 20 00 02 00 00 00 03 00 00 22 20 00 00 00 - .. ........" ... 49900000010: 78 F3 64 01 00 00 00 00 90 1B 5A 39 00 00 00 00 - x.d.......Z9.... 50000000020: 00 00 00 00 57 CC - ....W. 501 502 503Set Date 504-------- 505 506 * This command sets the date in the camera. 507 508 * Request format: 509The payload of this message is 4 bytes, it must be the same unix 510format as in the directory with date request, for example the 51101/01/2000 is 80 43 6D 38. 512 513 * Response format 514 515 * Example of request packet: 516 517 * Example of response packet: 518 519 520Make directory 521-------------- 522 523 * Creates a directory in the camera. 524 525 * Request format: 526The payload of this message is a null-terminated string containing the 527name of the directory to create. 528 529 * Response format: 530The response packet only contains the error code: 531 532 * Example of request packet: 533[Canon PowerShot S10] D:> mkdir ED 534WRITE: (30 bytes) 53500000000: C0 00 00 16 00 02 00 00 00 05 00 00 11 16 00 00 - ................ 53600000010: 00 00 00 00 00 44 3A 5C 45 44 00 13 7F C1 - .....D:\ED.... 537 538 * Example of response packet: 539RECV: (26 bytes) 54000000000: 00 00 14 00 02 00 00 00 05 00 00 21 14 00 00 00 - ...........!.... 54100000010: 00 00 00 00 00 00 00 00 48 6E - ........Hn 542 543 544Remove directory 545---------------- 546 547 * Removes a directory in the camera. 548 549 * Request format: 550The payload of this message is a null-terminated string containing the 551name of the directory to delete. 552 553 * Response format: 554The response packet only contains the error code: 555 0x0 in case of success 556 0x2000040 in case of error (no such directory) 557 558 * Example of request packet: 559WRITE: (31 bytes) 56000000000: C0 00 00 16 00 02 00 00 00 06 00 00 11 16 00 00 - ................ 56100000010: 00 00 00 00 00 44 3A 5C 45 44 00 2B 7E 5E C1 - .....D:\ED.+.^. 562 563 * Example of response packet: 564 565 Returned packet after a successful directory deletion : 566RECV: (26 bytes) 56700000000: 00 00 14 00 02 00 00 00 06 00 00 21 14 00 00 00 - ...........!.... 56800000010: 00 00 00 00 00 00 00 00 69 F4 - ........i. 569 570 Returned packet after a rmdir of a non-existing dir: 571RECV: (26 bytes) 57200000000: 00 00 14 00 02 00 00 00 06 00 00 21 14 00 00 00 - ...........!.... 57300000010: 00 00 00 00 40 00 00 02 CC C1 - ....@..... 574 575 576 577Flash device identification 578--------------------------- 579 580 * Returns the name of the flash drive where pictures are stored. 581 582 * The flash device request has no arguments. 583 584 * The flash device response has the following structure: 585 0x0: C-string containing the disk name. 586 587 * Example of request: 588WRITE: (24 bytes) 58900000000: C0 00 00 10 00 02 00 00 00 0A 00 00 11 10 00 00 - ................ 59000000010: 00 DC F7 8A 00 A9 FF C1 - ........ 591 592 * Example of response: 593RECV: (30 bytes) 59400000000: 00 00 18 00 02 00 00 00 0A 00 00 21 18 00 00 00 - ...........!.... 59500000010: DC F7 8A 00 00 00 00 00 44 3A 00 00 49 5E - ........D:..I^ 596 597 598Disk info 599--------- 600 601 * Disk info returns the total capacity and free space 602 on the requested device. 603 604 * Disk info requests have the following structure: 605 0x0: C-String containing the name of the device ("D:\") 606 607 Root name example: "C:\" (The trailing slash is required.) 608 609 * Disk info responses have the following structure: 610 0x0: 32bit integer representing total capacity 611 0x4: 32bit integer representing free space 612 613 xx xx xx xx xx xx xx xx 614 | | 615 | Free space (in bytes) 616 Total capacity (in bytes) 617 618 Error code: 0x00000000 in case of success 619 0x02000087 in case of error (non-existing drive) 620 621 * Request example: 622WRITE: (28 bytes) 62300000000: C0 00 00 14 00 02 00 00 00 09 00 00 11 14 00 00 - ................ 62400000010: 00 D8 F7 8A 00 44 3A 5C 00 74 B6 C1 - .....D:\.t.. 625 626 * Response example: 627 628 Error: (diskinfo Z:) 629RECV: (34 bytes) 63000000000: 00 00 1C 00 02 00 00 00 09 00 00 21 1C 00 00 00 - ...........!.... 63100000010: D8 F7 8A 00 87 00 00 02 18 00 3C 19 94 2A 0E 00 - ..........<..*.. 63200000020: DD 4B - .K 633 634 Success: (diskinfo A:) 635RECV: (34 bytes) 63600000000: 00 00 1C 00 02 00 00 00 09 00 00 21 1C 00 00 00 - ...........!.... 63700000010: D8 F7 8A 00 00 00 00 00 80 E8 06 00 00 00 00 00 - ................ 63800000020: A5 C0 - .. 639 640 641 642List (show directory contents) 643------------------------------ 644 645 * This command lists directory contents for a specified directory. 646 647 * Structure of request packets: 648 649List requests have the following structure: 650xx <directory_name> 00 00 00 651| 652recursion byte 653 654The "recursion byte" can take the following values: 655 656 0x00: non-recursive query 657 0x01: One level of recursion 658 0x02: Complete recursive directory listing ("ls -lR") 659 660 661Directory name example: "C:\PWRSHOT", "D:", or "D:\.", but not "D:\" 662(trailing slash), or "D:\.\FOO" (dot not allowed in path ?). A 663double-dot can be included in the path: "D:\DCIM\..". 664 665 666 * Structure of response packets: 667 668List responses have the following structure (after the error code 669which is always at "0x0" in case of dir lists). 670 671Failure: 672 01 00 00 00 00 00 00 00 673Success: 674 xx 80 00 00 675 00 00 00 00 676 00 00 00 00 677 <directory_name> 678 <type> 00 <size> <date> <entry_name> 679 ... 680 <type> 00 <size> <date> <entry_name> 681 <one entry with all bytes to zero> 682 683 - <directory_name> and <entry_name> are C-strings (null-terminated) 684 - <xx> is: 01 if the packet is the last message 685 00 if more packets are to follow. 686 - <type> is one byte containing the file attributes: 687 File attributes: 688 bit 0: 1= write protected, 0=NOT write protected 689 bit 4: 1=directory contains item but not recursived entered 690 bit 5: 1=NOT downloaded, 0=downloaded (must be manually switched) 691 bit 7: 1=recurively entered directory 692 - <size> is the size in bytes (4 bytes/little-endian). 693 Directory size is always 0. 694 - <date> is a four bytes Unix-style date in little-endian format. 695 696 697 * Example of a directory get sequence on a S10: 698 699[Canon PowerShot S10] D:> dir d: 700WRITE: (30 bytes) 70100000000: C0 00 00 16 00 02 00 00 00 0B 00 00 11 16 00 00 - ................ 70200000010: 00 A8 F6 8A 00 00 64 3A 00 00 00 65 4C C1 - ......d:...eL. 703WRITE: (10 bytes) 70400000000: C0 04 04 01 00 00 00 88 D6 C1 - .......... 705RECV: (8 bytes) 70600000000: 04 05 00 00 00 00 77 C1 - ......w. 707RECV: (66 bytes) 70800000000: 00 00 3C 00 02 00 00 00 0B 00 00 21 3C 00 00 00 - ..<........!<... 70900000010: A8 F6 8A 00 00 00 00 00 01 80 00 00 00 00 00 00 - ................ 71000000020: 00 00 00 64 3A 00 10 00 00 00 00 00 C4 6A 42 39 - ...d:........jB9 71100000030: 44 43 49 4D 00 00 00 00 00 00 00 00 00 00 00 00 - DCIM............ 71200000040: DC CA - .. 713RECV: (8 bytes) 71400000000: 03 04 01 00 00 00 59 CA - ......Y. 715WRITE: (10 bytes) 71600000000: C0 03 05 00 00 00 00 A6 DD C1 - .......... 717 718-i-- DCIM <DIR> Sat Jun 10 18:20:20 2000 719 1 files 0 bytes 720 721 722On S10/S20, if the directory is so large that several message 723fragments are needed, the fragments are transmitted the normal way as 724and the sequence is terminated by an EOT (usual way of transmitting a 725multi-fragment message). 726 727On the A5/A50 however, the following behaviour was described: 728 729If the directory is so large that additional messages are needed, the 730following messages have the following structure: 731 732 00 00 00 00 xx <entry> 733 | 734 1 if last message, 00 if more 735 736The boundary between messages is always chosen such that the terminating 73700 of an entry is the last byte in the earlier message. 738 739 740Download file 741------------- 742 743 * This command gets a file from the camera. An option allows to get 744 the thumbnail instead of the whole file. 745 746 * Structure of request packets: 747 748Download requests have the following structure: 749xx 00 00 00 00 xx 00 00 <name> 750 | | 751 | Length of name (including terminating \0) 752 0x00 for image 753 0x01 for thumbnail 754 755 * Structure of response packets: 756 757Data messages have the following structure: 75800 00 00 00 xx xx xx xx xx xx xx xx xx xx xx xx xx 00 00 00 ... 759 | | | | | 760 | | | | data 761 | | | 00 if more, 01 at end 762 | | data size in this message 763 | current offset 764 total length 765 766You can check if the request generated an error checking for the byte 767at offset 0x16 (00 if more, 01 at end) since it is set to 01 in the 768first packet if the downloaded failed (this is just an hack since this 769detection method will fail is the file is shorter than one fragment) 770 771All lengths are measured in bytes/little-endian. 772 773The camera always sends 8 messages then sends an EOT and waits for an 774ACK from the computer, if the computer has not received everything, it 775sends an ACK with an error value asking to retransmit one of the 776eighth packet sent. These error values are not yet known. 777 778Note about thumbnails for S10/S20 models: 779 780The camera only sends the 10813 first bytes of the image for the 781thumbnail download request. However it is not a valid image: the 782camera response you get just contains enough data to parse the EXIF 783header and extract the thumbnail. The remaining bytes left after 784parsing are the beginning of the actual image and should be discarded. 785In order to get the thumbnail, you will have to look for values "FF 786D8" and "FF D9" in the data , and the thumbnail (valid jpeg image) is 787between these two values (including ffd8 and ffd9). This is not the 788prefered method as "ffd8" and "ffd9" can appear anywhere in the data. 789It is best to parse the header properly. Gphoto offers an EXIF parsing 790API. 791 792 793 * Example of request: 794WRITE: (62 bytes) 79500000000: C0 00 00 36 00 02 00 00 00 01 00 00 11 36 00 00 - ...6.........6.. 79600000010: 00 6A 08 79 04 01 00 00 00 00 1E 00 00 44 3A 5C - .j.y.........D:\ 79700000020: 64 63 69 6D 5C 31 31 38 63 61 6E 6F 6E 5C 69 6D - dcim\118canon\im 79800000030: 67 5F 31 38 34 31 2E 6A 70 67 00 62 C4 C1 - g_1841.jpg.b.. 799 800 * Examples of answers: 801 802 - Error for a get on a non-existing file: 803RECV: (42 bytes) 80400000000: 00 00 24 00 02 00 00 00 01 00 00 21 24 00 00 00 - ..$........!$... 80500000010: 6A 08 79 04 22 00 00 02 00 00 00 00 00 00 00 00 - j.y."........... 80600000020: 00 00 00 00 01 00 00 00 A4 A3 - .......... 807 808 - First bytes of the first fragment in case of success: 809RECV: (1022 bytes) 81000000000: 00 00 F8 03 02 00 00 00 01 00 00 21 24 1E 00 00 - ...........!$... 81100000010: 6A 08 79 04 00 00 00 00 9B 1E 00 00 00 00 00 00 - j.y............. 81200000020: 00 1E 00 00 00 00 00 00 FF D8 FF E1 1D FE 45 78 - ..............Ex 81300000030: 69 66 00 00 49 49 2A 00 08 00 00 00 09 00 0F 01 - if..II*......... 81400000040: 02 00 06 00 00 00 7A 00 00 00 10 01 02 00 14 00 - ......z......... 81500000050: 00 00 80 00 00 00 12 01 03 00 01 00 00 00 01 00 - ................ 81600000060: 00 00 1A 01 05 00 01 00 00 00 94 00 00 00 1B 01 - ................ 81700000070: 05 00 01 00 00 00 9C 00 00 00 28 01 03 00 01 00 - ..........(..... 818........: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. - 819 820 821 822Upload file 823----------- 824 825 The serial upload protocol description is not done yet. These are just 826 ideas on what it could be. Maybe it's right, maybe it's wrong. 827 828 * This command sends a file to the camera. 829 830 * Request structure: 831xx 00 00 00 00 xx 00 00 <name> 832 833Each data block has the following format: 834 83500 00 00 02 XX XX XX XX - YY YY YY YY filename - datablock 836 837 XX XX XX XX : offset within the file for this block 838 YY YY YY YY : len2: length of this block 839 filename : 0-terminated string 840 datablock: the data itself. 841 842 843Switch Camera off 844----------------- 845 846In order to switch the camera off, you need to send the following 847characters (directly, without extra framing) : 848 849 C0 00 02 55 2C C1 850 C0 00 04 01 00 00 00 24 C6 C1 851 852 853Low Battery warning 854------------------- 855 856If the camera batteries run too low during a transfer and the camera 857needs to switch itself off, it will send a special packet just before 858going down. You can see how it is handled in psa50.c 859 860 861 862=============================================== 863= 864= USB Interface 865= 866=============================================== 867 868Nota: 869 When mentioning word, 32bit word little_endian is implied. 870 871References to usb11.pdf (Chaper 9.3 page 199): 872http://www.usb.org/developers/data/usbspec.zip (1.8Mb) 873 874bmRequestType is 0xC0 during read and 0x40 during write. 875bRequest is 0x4 if length of data is >1, 0x0c otherwise (length > 1 ? 0x04 : 0x0C) 876wValue differs between operations. 877wIndex is always 0x00 878wLength is simply the length of data 879 880In linux sending/reciving commands is using usb_control_msg (in usb.c). 881 882 usb11.pdf name | usb.c name) 883-------------------------------- 884 bmRequestType | requesttype 885 bRequest | request 886 wValue | value 887 wIndex | index 888 wLength | length 889 890================================================================================ 891Init of camera: 892================================================================================ 893 8941. Control_transfer_read requesttype=0xC0 value=0x55 length=1 895 896Camera responds with following data (single char): 897"A" = Camera was already active 898"C" = Camera was woken up 899"I" = Unknown (some kind of error) 900"E" = Unknown (some kind of error) 901 9022. Control_transfer_read requesttype=0xC0 value=0x1 length=0x58 903 904The first 0x48 bytes can be trashed, save the last 0x10 byte and us it as 905data in next step. 906Example: 90700000000 18 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 90800000010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 90900000020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 91000000030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 91100000040 01 00 02 00 43 30 A9 04-00 08 00 00 FF FF FF FF ....C0.......... 91200000050 00 FD 00 00 00 FD 00 00 ........ 913 9143. Control_transfer_write requesttype=0x40 value=0x11 length=0x10 data=[from step 2] 915 9164. PC sign should now appear on the LCD 917 9185. Receive 0x44 bytes from bulk_in and throw it away. 919Example: 92000000000 04 00 00 00 02 03 00 00-00 00 00 00 00 00 00 00 ................ 92100000010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 92200000020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 92300000030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 92400000040 00 00 00 00 .... 925 926================================================================================ 927USB Commands 928================================================================================ 929 9301. Structure of a command block 931 932Example: 933 934* Command block sent in general: (Example:Disk info request) 935 0000000: 14 00 00 00 01 02 00 00-00 00 00 00 00 00 00 00 ................ 936 0000010: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 937 0000020: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 938 0000030: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 939 0000040: 02 00 00 00 09 00 00 11-14 00 00 00 78 56 34 12 ............xV4. 940 0000050: 44 3A 5C 00 D:\. 941 942USB arguments: 943 - value is always 0x10 944 - length is TOTAL length (0x54 in example above) 945 946* Generic format of block sent: 947 9480000000: xx xx xx xx yy yy yy yy - 00 00 00 00 00 00 00 00 9490000010: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 9500000020: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 9510000030: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 9520000040: 02 00 00 00 UU 00 00 VV - xx xx xx xx SS SS SS SS 9530000050: ... (payload/arguments) 954 955 xx xx xx xx : Length (word) 956 yy yy yy yy : cmd3 (word) 957 UU : cmd1 (byte) 958 VV : cmd2 (byte) 959 xx xx xx xx : Length (again) 960 SS SS SS SS : serial number (word) 961 962 - 'length' is the length of the block, excluding the first 0x40 bytes 963 in block, and is never less than 0x10. 964 - cmd1 and cmd2 are a single byte 965 - cmd3 is a word 966 - Serial number is a word, sent back in command reply. 967 9682. Summary of available (known) commands: 969 970cmd1 | cmd2 | cmd3 | Argument(eg.) Response Length | Operation 971----------------------------------------------------------------------------------------------- 9720x01 0x11 0x202 | 0x00000000 0x00001400 "D:\DCIM\100CANON\IMG_0100.JPG" 0x00 L | Get picture 9730x01 0x11 0x202 | 0x00000001 0x00001400 "D:\DCIM\100CANON\IMG_0100.JPG" 0x00 L | Get thumbnail 9740x01 0x12 0x201 | none 0x9c | Identify camera request 9750x03 0x12 0x201 | none 0x60 | Get time 9760x04 0x12 0x201 | 0x390873f0 0x00000000 0x00000000 0x54 | Set time (0x390873f0) (UNIX-type) 9770x05 0x11 0x201 | "D:\DCIM" 0x00 0x54 | Make directory 9780x05 0x12 0x201 | "Donald Duck" 0x00 0x54 | Change owner 9790x06 0x11 0x201 | "D:\DCIM" 0x00 0x54 | Remove directory 9800x09 0x11 0x201 | "D:\" 0x00 0x5c | Disk info request 9810x0A 0x11 0x202 | none L | Flash device identification 9820x0A 0x12 0x201 | none 0x58 | Power supply status 9830x0b 0x11 0x202 | 0x1 "D:\DCIM" 0x00 0x00 0x00 L | Get directory (0x1 = max depth of recursion) 9840x0d 0x11 0x201 | "D:\DCIM\100CANON" 0x00 "IMG_0002.JPG" 0x00 0x54 | Delete file 9850x0E 0x11 0x201 | 0x00000021 "D:\DCIM\100CANON" 0x00 "IMG_0002.JPG" 0x00 0x54 | Set file attribute 986 987L means that the program reads 0x40 from bulk in, checks for a word at 988position 0x6 for the length (0xd1fcf in this case), and then reads the 989rest in 0x1400 buffers. (long bulk in read) 990 99100000000 00 00 00 00 02 03 CF 1F-0D 00 00 00 00 00 00 00 ................ 99200000010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 99300000020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 99400000030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 995 996**** 997** Disk Info Request: 998**** 999 1000* Argument structure: 1001 1002 Null-terminated string containing the name of the disk. 1003 1004* Camera response block: 1005 1006Data received via bulk in after a command block: (Disk info request) 10070000000: 00 00 00 00 01 03 00 00 00 00 00 00 00 00 00 00 ................ 10080000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 10090000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 10100000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 10110000040: 02 00 00 00 09 00 00 21 1C 00 00 00 78 56 34 12 .......!....xV4. 10120000050: 00 00 00 00 00 80 E8 03 00 A0 AF 03 ............ 1013 1014 First 0x40 bytes is throwable. 1015 0x54 contains a word with totalbytes on flash. 1016 0x58 contains a word with bytes free. 1017 1018**** 1019** Delete directory 1020**** 1021Data received via bulk in after a command block: (Delete directory) 102200000000 00 00 00 00 01 03 00 00-00 00 00 00 00 00 00 00 ................ 102300000010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 102400000020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 102500000030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 102600000040 02 00 00 00 06 00 00 21-14 00 00 00 78 56 34 12 .......!....xV4. 102700000050 00 00 00 00 .... 1028 1029**** 1030** Make directory 1031**** 1032Data received via bulk in after a command block: (Make directory) 103300000000 00 00 00 00 01 03 00 00-00 00 00 00 00 00 00 00 ................ 103400000010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 103500000020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 103600000030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 103700000040 02 00 00 00 05 00 00 21-14 00 00 00 78 56 34 12 .......!....xV4. 103800000050 00 00 00 00 .... 1039 1040 1041**** 1042** Get time 1043**** 1044 1045Data received via bulk_in after a command block: (Get time) 104600000000 00 00 00 00 01 03 00 00-00 00 00 00 00 00 00 00 ................ 104700000010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 104800000020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 104900000030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 105000000040 02 00 00 00 03 00 00 22-20 00 00 00 78 56 34 12 ......." ...xV4. 105100000050 00 00 00 00 8D 1D 12 39-00 00 00 00 00 00 00 00 .......9........ 1052 1053 First 0x40 bytes is throwable. 1054 0x54 contains a UNIX time 1055 1056**** 1057** Power supply status 1058**** 1059 1060Data received via bulk_in after a command block: (Power supply status) 106100000000 00 00 00 00 01 03 00 00-00 00 00 00 00 00 00 00 ................ 106200000010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 106300000020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 106400000030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 106500000040 02 00 00 00 0A 00 00 22-18 00 00 00 78 56 34 12 ......."....xV4. 106600000050 00 00 00 00 06 00 00 10- ........ 1067 1068 First 0x40 bytes is throwable. 1069 0x54 contains a byte with power status: 0x6=good, 0x4=bad 1070 0x57 contains a byte with powertype: 0x10=ac-adaptor, 0x30=battery 1071 1072**** 1073** Identify Camera request 1074**** 1075 1076Data received via bulk_in after a command block: (Identify camera request) 107700000000 00 00 00 00 01 03 00 00-00 00 00 00 00 00 00 00 ................ 107800000010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 107900000020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 108000000030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 108100000040 02 00 00 00 01 00 00 22-5C 00 00 00 78 56 34 12 ......."\...xV4. 108200000050 00 00 00 00 00 04 00 00-01 00 00 01 43 61 6E 6F ............Cano 108300000060 6E 20 50 6F 77 65 72 53-68 6F 74 20 53 32 30 00 n PowerShot S20. 108400000070 00 00 00 00 00 00 00 00-00 00 00 00 44 6F 6E 61 ............Dona 108500000080 6C 64 20 44 75 63 6B 00-00 00 00 00 00 00 00 00 ld Duck......... 108600000090 00 00 00 00 00 00 00 00-00 00 00 00 ............ 1087 1088 First 0x40 bytes is throwable (as usual) 1089 At 0x5c a string with camera type exist 1090 At 0x7c a string with owner name exist. 1091 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) 1092 Data at 0x54-0x57 has unknown purpose. 1093 1094**** 1095** Flash device identification 1096**** 1097 1098Data received via a long_bulk_in_read: (Flash device identification) 109900000000 44 3A 00 00 D:.. 1100 1101**** 1102** Set File Attribute 1103**** 1104 1105Data received via bulk_in after a command block: (Set file attribute) 110600000000 00 00 00 00 01 03 00 00-00 00 00 00 00 00 00 00 ................ 110700000010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 110800000020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 110900000030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 111000000040 02 00 00 00 0E 00 00 21-14 00 00 00 78 56 34 12 .......!....xV4. 111100000050 00 00 00 00 .... 1112 1113Data received via bulk_in after a command block: (Set file attribute) (file did not exist). 111400000000 00 00 00 00 01 03 00 00-00 00 00 00 00 00 00 00 ................ 111500000010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 111600000020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 111700000030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 111800000040 02 00 00 00 0E 00 00 21-14 00 00 00 78 56 34 12 .......!....xV4. 111900000050 22 00 00 02 "... 1120 1121 1122File attributes: 1123 bit0 (1= write protected, 0=NOT write protected) 1124 bit4 (1=directory contains item but not recursived entered) 1125 (NOT used with the attrib command) 1126 bit5 (1=NOT downloaded, 0=downloaded) 1127 (must be manually switched) 1128 bit7 (1=recurively entered directory) 1129 (NOT used with the attrib command) 1130 1131Example: 0x21 file is NOT downloaded but deleteprotected 1132 1133 1134**** 1135** Delete file 1136**** 1137 1138Data received via bulk_in after a command block: (Delete file) (file did not exist). 113900000000 00 00 00 00 01 03 00 00-00 00 00 00 00 00 00 00 ................ 114000000010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 114100000020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 114200000030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 114300000040 02 00 00 00 0D 00 00 21-14 00 00 00 78 56 34 12 .......!....xV4. 114400000050 22 00 00 02 "... 1145 1146Data received via bulk_in after a command block: (Delete file) (file was protected) 114700000000 00 00 00 00 01 03 00 00-00 00 00 00 00 00 00 00 ................ 114800000010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 114900000020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 115000000030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 115100000040 02 00 00 00 0D 00 00 21-14 00 00 00 78 56 34 12 .......!....xV4. 115200000050 29 00 00 02 )... 1153 1154Data received via bulk_in after a command block: (Delete file) (successful) 115500000000 00 00 00 00 01 03 00 00-00 00 00 00 00 00 00 00 ................ 115600000010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 115700000020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 115800000030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 115900000040 02 00 00 00 0D 00 00 21-14 00 00 00 78 56 34 12 .......!....xV4. 116000000050 00 00 00 00 .... 1161 1162 1163**** 1164** Change Owner 1165**** 1166 1167Data received via bulk_in after a command block: (Change owner) (no errorcodes) 116800000000 00 00 00 00 01 03 00 00-00 00 00 00 00 00 00 00 ................ 116900000010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 117000000020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 117100000030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 117200000040 02 00 00 00 05 00 00 22-14 00 00 00 78 56 34 12 ......."....xV4. 117300000050 00 00 00 00 .... 1174 1175**** 1176** Directory Listing 1177**** 1178 1179Errorcodes: 11800x02000022 File not found 11810x00000000 No errors 11820x02000086 Path not found 11830x02000029 File was protected 1184 1185File attributes: 1186bit1 (1=deleteprotected, 0=NOT deleteprotected) 1187bit4 (1=directory contains item but not recursived entered) (NOT used with the attrib command) 1188bit5 (1=NOT downloaded, 0=downloaded) (must be manually switched) 1189bit8 (1=recurively entered directory) (NOT used with the attrib command) 1190 1191Example: 0x21 file is NOT downloaded but deleteprotected 1192 1193Directory handling: 1194Thu May 4 00:11:40 2000 D:\DCIM\100CANON\IMG_0001.JPG 778435 1195Thu May 4 00:28:32 2000 D:\DCIM\100CANON\IMG_0002.JPG 44409 1196Thu May 4 00:28:32 2000 D:\DCIM\CANONMSC\100.CTG 2634 1197Thu May 4 00:28:32 2000 D:\DCIM\CANONMSC\D.CTG 383 1198 1199Directory contents: "D:" (recurse =0x0) 120000000000 80 00 00 00 00 00 00 00-00 00 44 3A 00 10 00 00 ..........D:.... 120100000010 00 00 00 C6 B5 10 39 44-43 49 4D 00 00 00 00 00 ......9DCIM..... 120200000020 00 00 00 00 00 00 00 ....... 1203 1204Directory contents: "D:" (recurse =0x1) 120500000000 80 00 00 00 00 00 00 00-00 00 44 3A 00 80 00 00 ..........D:.... 120600000010 00 00 00 36 C0 10 39 2E-5C 44 43 49 4D 00 10 00 ...6..9.\DCIM... 120700000020 00 00 00 00 36 C0 10 39-31 30 30 43 41 4E 4F 4E ....6..9100CANON 120800000030 00 10 00 00 00 00 00 CC-B5 10 39 43 41 4E 4F 4E ..........9CANON 120900000040 4D 53 43 00 80 00 00 00-00 00 00 00 00 00 2E 2E MSC............. 121000000050 00 00 00 00 00 00 00 00-00 00 00 00 ............ 1211 1212Directory contents: "D:" (recurse =0x2) 121300000000 80 00 00 00 00 00 00 00-00 00 44 3A 00 80 00 00 ..........D:.... 121400000010 00 00 00 36 C0 10 39 2E-5C 44 43 49 4D 00 80 00 ...6..9.\DCIM... 121500000020 00 00 00 00 3C C0 10 39-2E 5C 31 30 30 43 41 4E ....<..9.\100CAN 121600000030 4F 4E 00 20 00 C3 E0 0B-00 3C C0 10 39 49 4D 47 ON. .....<..9IMG 121700000040 5F 30 30 30 31 2E 4A 50-47 00 20 00 79 AD 00 00 _0001.JPG. .y... 121800000050 30 C4 10 39 49 4D 47 5F-30 30 30 32 2E 4A 50 47 0..9IMG_0002.JPG 121900000060 00 80 00 00 00 00 00 00-00 00 00 2E 2E 00 80 00 ................ 122000000070 00 00 00 00 30 C4 10 39-2E 5C 43 41 4E 4F 4E 4D ....0..9.\CANONM 122100000080 53 43 00 20 00 4A 0A 00-00 30 C4 10 39 31 30 30 SC. .J...0..9100 122200000090 2E 43 54 47 00 20 00 7F-01 00 00 30 C4 10 39 44 .CTG. ....0..9D 1223000000A0 2E 43 54 47 00 80 00 00-00 00 00 00 00 00 00 2E .CTG............ 1224000000B0 2E 00 80 00 00 00 00 00-00 00 00 00 2E 2E 00 00 ................ 1225000000C0 00 00 00 00 00 00 00 00-00 00 .......... 1226 1227Directory contents: 1228attribute 0x00 size date "name" 0x00 1229attribute is a byte describe little earlier in this document 1230 (0 in attribute, date, length and name means end of direntry, ".." in name means "leave directory". 1231size is a word (filesize in byte) 1232time is a word (UNIX time) 1233 1234 1235**** 1236** Upload (a little bit special): 1237**** 1238 1239Control_transfer_write 1240 requesttype=0x40 1241 value=0x10 1242 length=0x40 1243 data=0x00000000 0x0203 0x40+len1[explained later] [0x00 repeated 0x38] 1244 1245Example: 124600000000 00 00 00 00 03 02 7A 14-00 00 00 00 00 00 00 00 ......z......... 124700000010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 124800000020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 124900000030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 1250 1251bulk_in_read [0x40 bytes] 1252Example: 125300000000 00 00 00 00 03 03 00 00-00 00 00 00 00 00 00 00 ................ 125400000010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 125500000020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 125600000030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 1257 1258bulk_write [data below] 1259 1260len1[explained later] 0x00 0x00 0x00000403 0x00000000 0x00000000 1261[0x00 repeated 0x30 times] 12620x00000002 0x03 0x00 0x00 0x11 len1 0x00 0x00 serial (this line looks very similar to "ordinary" commands) 12630x00000002 offs len2 filename 0x00 datablock 1264 1265bulk_in_read [0x5c bytes] 1266 1267This is repeated until the whole file is transmitted: 1268 1269- offs is a word that starts at 0 and increments with blocksize each time. 1270 1271- len1 is the length of the "bulk_write_data" block above, minus 0x40 (the 1272 first length and padded zeros is not counted as in all other commands). 1273 len1 is typically 0x143A using a standard 0x1400 (ms-windows) block 1274 using the filename below (29 chars), last block is shorter. 1275 1276- len2 is length of datablock (0x1400 is used in ms-windows), last 1277 block is shorter 1278 1279- serial is a random word that is returned as a reply. 1280 1281- filename is "D:\DCIM\100CANON\IMG_0002.JPG" for example (files cannot 1282 be created in non-existing directory.) 1283 1284- datablock is the datablock itself (the fragment of the JPG file). 1285 1286Example of beginning of a block (first one): 128700000000 3A 14 00 00 03 04 00 00-00 00 00 00 00 00 00 00 :............... 128800000010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 128900000020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 129000000030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 129100000040 02 00 00 00 03 00 00 11-3A 14 00 00 78 56 34 12 ........:...xV4. 129200000050 02 00 00 00 00 00 00 00-00 14 00 00 44 3A 5C 44 ............D:\D 129300000060 43 49 4D 5C 31 30 30 43-41 4E 4F 4E 5C 49 4D 47 CIM\100CANON\IMG 129400000070 5F 30 30 30 32 2E 4A 50-47 00 FF D8 FF E1 17 FE _0002.JPG....... 129500000080 45 78 69 66 00 00 49 49-2A 00 08 00 00 00 09 00 Exif..II*....... 129600000090 0F 01 02 00 06 00 00 00-7A 00 00 00 10 01 02 00 ........z....... 1297 1298 * ALL THIRD PARTY BRAND, PRODUCT AND SERVICE NAMES MENTIONED ARE 1299 * THE TRADEMARK OR REGISTERED TRADEMARK OF THEIR RESPECTIVE OWNERS 1300