If not, then please click on the following link: http://users.bigpond.net.au/blmiller/linux/rdc2e/protocol.html
Please update any links to this page you may have had.
Both DTR & RTS on the DTE side should be raised, resulting in DRT & CTS being raised by the camera. These seem to remain up during the whole camera session and don't seem to be a hardware flow control... well, I have never seen RTS or CTS change. When all transfers are finished, the PC drops RTS & DTR, which the camera sees, returning the camera to the default communications settings. i.e. 2400 bps.
STX
| Data
| ETX
| CRC
| Length
| Frame #
| 10 02 |
...Data... |
10 03 |
xx xx |
xx |
xx |
|
|---|
| Field | Length | Description |
|---|---|---|
| STX | 2 bytes | Start of Text sequence. All frames start with 0x1002. |
| Data | n bytes | Data content of frame. Any byte with a value of 0x10 within the frame MUST be escaped by prepending a 0x10 to it. |
| ETX | 2 bytes | End of Text sequence. Always has the value of 0x1003. |
| CRC | 2 bytes | The CRC is worked out on the DATA portion of the frame and uses the same one as used in zmodem. |
| Length | 1 byte | Length of the data in theData field of the frame. This does not include the 0x10's that are used to escape special chatacters within the data. |
| Frame # | 1 byte | Frames are given a sequence number. This number starts at 0x00 and increments by 0x01 for each frame in a single transfer. i.e. you will see this incrementing in the transfer of a picture. |
When ever a frame is sent in one direction, the receiving end resopnds immediately with a 0x05 which I assume is a possitive response. I haven't seen a negative response yet, so I have no idea what they look like.
Command
| Control
| Optional Data
| 1 byte |
1 byte |
0-n bytes |
|
|---|
List of Commands Command Description 0x31 Set interface speed 0x40 Request to download a picture
Response with picture name0x44 Downloading picture from camera 0x49 Request/response for number of pictures currently in camera. 0x4C Swap source of pictures in camera between internal 2MB memory, and the (optional) PCMCIA card.
Bit Fields of Control Bits Description 0x80 This is set if there are more frames to follow.
Normally seen in a picture download,
except in last frame.
When communication is initially being set up between the PC and the camera, the forst thing that is done is to set the speed of the PC and camera interface.Initially, the speed of both ends starts at 2400 bps, and is negotated to a higher speed. By default, the PC software that came with the camera (Photo Studio) goes straight to 115200 bps.
I have seen that the PC sends out a first a Set Serial Speed command, waits for about a second for a response, then sends a second. The camera generally responds to the second request with a 0x05. After the camera responds, the PC and camera step up to the new speed, ready for the next command.
Set Serial Speed Speed Frame Data 2400 31 00 00 00 4800 31 00 00 01 9600 31 00 00 02 19200 31 00 00 03 38400 31 00 00 04 57600 31 00 00 05 115200 31 00 00 07
The PC request for the number of pictures in the camera is very simple.
Frame Data 49 00 The camera then responds with a 0x05, followed by a Number of Pictures - Camera response.
After the PC has sent in a request for the number of pictures held in the cameras memory, it responds with:
Frame Data 49 00 mp ll hh ll hh The PC should reply with a 0x05, acknowledging the receipt of this frame.
Where mp is 0x00 for the internal 2MB of Memory, and 0x01 is for PCMCIA.
Where ll hh is the number of pictures present in camera memory. This is in fact an Intel ordered short integer, where ll is the low order byte, and hh is the low order byte (usually 0x00). Why there are two occurances of ll hh I don't know.
(please note that I don't have a PCMCIA memory card, so I am only going on what Hugo Visser has told me.)
Frame Data 4C 00 mp Where mp is 0x00 for the internal 2MB of Memory, and 0x01 is for PCMCIA.
The camera will respond with a 0x05 followed by a Number of Pictures On Media - Camera response.
Note: This is the same as a Number of Pictures - Camera Response except that the command is 0x4C instead of 0x49.
After the PC has sent in a request to change to the source of pictures to either internal 2MB memory or the PCMCIA card, it responds with:
Frame Data 4C 00 mp ll hh ll hh The PC should reply with a 0x05, acknowledging the receipt of this frame.
Where mp is 0x00 for the internal 2MB of Memory, and 0x01 is for PCMCIA.
Where ll hh is the number of pictures present in camera memory. This is in fact an Intel ordered short integer, where ll is the low order byte, and hh is the low order byte (usually 0x00). Why there are two occurances of ll hh I don't know.
(please note that I don't have a PCMCIA memory card, so I am only going on what Hugo Visser has told me.)
Frame Data 40 00 nn 00 Where nn is the number of the picture to download.
The camera will respond with a 0x05.
When you request a photo to be downloaded, the first thing you get back is a frame that tells you the name that it is called in the camera. These are names like R0100001.J6I or R0100002.J6I, etc.
Frame Data 40 00 aa aa aa aa aa aa aa aa aa aa aa aa 00 ss ss 00 The PC should reply with a 0x05, acknowledging the receipt of this frame.
Where aa are ASCII characters that make up a full file name like that described just above. I don't see any reason why you have to use this file name; it's just given though. Also the file size is given by ss ss. This is a short integer number (Intel byte order) of 256 byte blocks that make up the size of the file.
Straight after the File Name that is about to be Downloaded frame has been acknowledged, the camera starts sending the actual photo.
Frame Data 44 80 80 3e 44 53 43 49 4d 00 01 00 00 .......... There are a few things to note about these frames:
The last frame of the transfer contains no data, and the more bit is not set.
- the 0x80 as the second character of the data. This is the more bit that signifies that more data is to follow. The last frame doesn't have this set.
- The Frame # on the very end of each frame increments by one. This starts at 0x00 for the first frame.
- beware of the 0x10's in the data, these are there to escape legitimate 0x10's that should not be thought of ETX or other characters.
Frame Data 44 00
By no means is this a full breakdown of the protocol, just enough I think
to get a basic downloading of pictures from the camera to work. There must
be more; it's just my software doesn't do any more... like make the camera
take a picture...
Some Sample Frames
The data section of the frame is in blue and the checksums are in
red.
Setting the speed....
10 02 31 00 00 00 10 03 a4 36 04 00
10 02 31 00 00 01 10 03 a5 36 04 00
10 02 31 00 00 02 10 03 a6 36 04 00
10 02 31 00 00 03 10 03 a7 36 04 00
10 02 31 00 00 04 10 03 a0 36 04 00
10 02 31 00 00 05 10 03 a1 36 04 00
10 02 31 00 00 07 10 03 a3 36 04 00
How many pictures do you have?
10 02 49 00 10 03 00 49 02 00
I have 2 pictures in memory...
10 02 49 00 00 02 00 02 00 10 03 76 dd 07 00
Please download picture #1
10 02 40 00 01 00 10 03 cc 0c 04 00
Please download picture #2
10 02 40 00 02 00 10 03 cc 0f 04 00
Picture #1 is called R0100001.J6I
10 02 40 00 52 30 31 30 30 30 30 31 2e 4a 36 49 00 c0 00 00 10 03 78 44 12 00
The first frame of picture #1 to be downloaded
10 02 44 80 80 3e 44 53 43 49 4d 00 01 00 00 00 00 00 00 00 56 49 44 45 4f 31
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00
00 00 00 00 03 00 00 00 00 00 00 ac 00 00 b2 d3 81 08 09 00 99 01 08 14 00 29
82 20 1f 52 49 43 4f 48 00 01 00 00 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 00 00 82 0c 0b 52 49 43 4f 48 00 01 00 01 00 00 82 14 13 52
49 43 10 03 3a 42 82 01
The last frame of picture #1 to be downloaded
10 02 44 00 10 03 00 44 02 81