Notes and questions send to: Stanislav Brabec
Main page of Penguin's UTX WWW
There is basic description of Minolta DiMAGE Capture USB Remote Computer Control Protocol, which is used by Dimage Capture software and Dimage Capture SDK. For more look into MltRec source codes.
All numbers are in low endian notation (LSB first).
All values in tables are hexadecimal numbers. In Notes decimals are used.
| byte | meaning | values | source code |
|---|---|---|---|
| 00-03 | frame size | in bytes | |
| 04 | command | commands.h: #define MLTREC_* | |
| 05 | direction | 10: computer→camera 20: camera→computer | joined with previous |
| 06-07 | 0000 | unknown meaning | |
| 08-0b | transaction serial | <a0000000: computer→camera ≥a0000000: camera→computer both starts with ??000001 | used in code |
| ≥0c | optional data | commands.h: #define MLTHDR_DEFINE_FUNCTION for offsets (generic are called extval*) commands.c for usage and size |
| byte | meaning | values | source code |
|---|---|---|---|
| 00-03 | frame size | in bytes | |
| 04 | command | commands.h: #define MLTREC_* | |
| 05 | direction | 10: computer→camera 20: camera→computer | joined with previous |
| 06-07 | 0000 | unknown meaning | |
| 08-0b | transaction serial | <a0000000: computer→camera ≥a0000000: camera→computer both starts with ??000001 | used in code |
| 0c-0d | command status | 0000: OK ffff: error | |
| ≥0e | optional data | commands.h: #define MLTHDR_DEFINE_FUNCTION for offsets (generic are called extval*) protocol.c: mltprot_read_loop() for usage and size nothing for computer reply (see below) |
Computer sends a command block. Then computer can deduce, whether to send next command or start to read.
Typical transaction is command and camera reply. First 12 bytes of camera reply are the same as our command and identifies transaction, next two bytes are status and optional rest is particular camera status report.
If computer starts to read reply, camera can send either reply for the command or camera originated data.
If camera sends camera originated data, computer must immediately reply. First 12 bytes of our reply are the same as camera's data and identifies transaction, next two bytes are zeroes (meaning OK status). Then computer can continue in reading.
Data are typically read in following way: Read 16 bytes, evaluate them, read the rest in blocks up to 4096 bytes. First 16 bytes read can return less bytes, if block size is below 16 (at least 12).
There is only one data type, which is not covered upper mentioned data frames. It is live image data. Camera sends data block, where frame size declares only preamble size. Size of live image itself is stored elsewhere and it is expected, that data will be read immediately.
One command returns no reply: Camera shutdown.
There are any data to read, if:
If those conditions, camera can reply, if something happens (most probably settings change notify). But you read command can time-out and it blocks write endpoint.
It is not possible to arbitrary combine reading and writing.
Atomic operations are:
Minolta A1 has a limitation in firmware: If more than one concurrent commands (with identical command code) are pending, camera replies with serial of last concurrent command, not to serial of command it really answers. We have to check queue commands before issuing any command and suspend writing, until we get a reply for concurrent command. Example: AE+AF lock and AE+AF unlock use the same command MLTREC_LOCK_AE_AF. We cannot send AE+AF unlock command before we get a reply for AE+AF lock command, however there is no problem to send any other command.
Camera is not error proof. If you send one of terminating commands without completing all previous transactions, camera stays in undefined state. Sometimes it is possible to reset it by power button, but sometimes you need to replace batteries.
