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