I spent a couple of days trying to figure out how the serial interface worked and I
thought I'd publish the result of that effort here. I did not start from scratch,
but collected what I could from two other homepages
(see references) and then added some of my own. I
developed this with the MX-700, but it should also work with an MX-500. Apparently
the DX-7 also has a subset of these commands.
I have written a piece of Amiga software which will perform most of the
functions implemented in the camera. I tried to write it in a manner that it is
easily portable to other platforms, since the only proprietary part is the handling
of the serial port, which I have kept in a separate module. This module would be
the only part which needs rewriting for other computers.
There are still some commands which are unknown to me. If you have any
information that's missing here, please let me know so I add it on this page
If you find this page useful, please let me know
If I have omitted any crucial information or you just can't get it to work,
just email me and I will try to provide additional help.
I do not know if an official protocol description is available. If
you know of one let me know.
The information on these pages was partly gathered from the two web pages
metioned in the references, while the rest I found out experimentally.
General description
As with most means of communication, the communication is carried out at a number
of levels, each level providing the transport for the next higher level. For theses
cameras I have identified the levels as such (my names):
Hardware - the first level is the standard RS232 protocol. I will not be
discussing th RS232 protocol itself here because it is such a common thing. However
I have listed the specific settings that you must use - and that's all you really
need to know
Low level transmission protocol - is a set of rules which define how packets of
data are sent and received. It is concerned with packaging the data in such a way
that it is reliably transferred, and also by providing a way of determining that
the data has arrived intact at the destination. It does not however concern itself
with the actual contents of the packets, so it just ensured that packets
supplied by Level 3 are received verbatim by the level 3 protocol at the other
end.
Command protocol - this is a description of the actual commands and data
which are sent between the camera and the computer.
Serial port
The serial port should be set to
8 data bits
1 stop bit
even parity
no hardware handshaking (i.e. 3 wire rather than 7 wire)
baud rate 9600 initially.
Higher speeds may be used, however the camera defaults to 9600 each time it is
switched on or the control switch is set onto PC mode. Thus normally you would
establish contact at 9600 and then increas the speed - exactly how this is done is
described further on.
I don't know whether XON/XOFF should be used, however I seemed to notice no
difference in operation with or without it.
Low level Transmission Protocol
The FUJI MX serial interface uses a standard ISO protocol (but I don't know its
name) for the low level data link protocol.
This works as follows:
Sequence of events
Communication is started by sending an ENQ by any one side of the link (Enquiry = 0x05)
An ACK (Acknowledge 0x06) should be received to confirm the link is in
operation
Send DLE-STX (Start of text = 0x10 0x02) to indicate the beginning of a
message
The first packet of data pertaining to this message is transmitted upto a
maximum of 512 bytes (see paragraph below about 0x10 characters contained
in the data).
If the message length exceeds 512 bytes, intervening packets are sent as
follows
Send a DLE-ETB (end transmission block = 0x10 0x17) to indicate the end
of the packet currently being sent - however this indicates that more
packets relating to this message will be sent
Send a Block Check Character (this is described below)
An ACK (Acknowledge 0x06) should be received from the camera, meaning
that the data was received correctly at the other end
Send DLE-STX (Start of text = 0x10 0x02) to indicate the start of
another block of data (continuation of the message)
Transmit the next block of data upto a maximum of 512 bytes (remember to
take care of 0x10s)
If still more data needs to be transmitted, repeat process from
sending of the DLE-ETB until all the data has been sent.
A DLE-ETX (end of text = 0x10 0x03) is sent
A Block Check Character is sent (this is a sort of checksum)
An ACK (Acknowledge 0x06) should be received, meaning that the data was
received correctly at the other end
Any further messages to be sent repeat procedure from sending of the DLE-STX
When all communication is ready (for example before quitting the program) an
EOT (end of text = 0x04) is sent
Character 0x10 contained in data
The character 0x10 is known as DLE (data link escape). Its function is to indicate
that the following character is a control character rather than data. A problem
would thus arise if we want to send a data byte with the value of 0x10 since this
would be interpreted as a DLE and the following character would be interpreted as a
control character.
In order to avoid this problem, any character 0x10 which needs to be transmitted by
data is preceeded by another 0x10 character. Thus if for example we want to send in
the data:
07 08 09 10 11 12 13 we would change this into:
07 08 09 10 10 11 12 13
Note the extra 0x10 shown in bold.
It is important that when considering lengths of
transmitted packets you do not count the extra 0x10s inserted. for example the
above packet should be counted as 7 bytes of actual data, not 8. Thus for example
the maximum packet length of 512 bytes does not include the extra 0x10 characters
in the count. The same also applies for checksums, where only the 'real' 0x10 is
counted.
The BCC - Block Check Character
The block check character is a form of checksum. It is calculated simply as the XOR
of all the transmitted data.
In calculating the BCC, the following must be ignored (skipped)
The initial DLE and STX
The DLE preceeding the ETX or ETB
The DLEs preceeding character 0x10s in the data portion.
Thus to summarize, the BCC takes into account the actual data and the ETX or ETB
character that marks the end of the packet.
The value of BCC is initialised to zero after each STX. Thus each BCC
covers the data in one single packet.
Specific command protocol for the camera
The camera sends and receives packets encapsulated in the protocol described above.
This part describes the contents of those packets sent.
Thus at this stage we shall not concern ourselves with checksums STX and such
things as these have been described above in the low level protocol. However some examples will
be given showing the actual bytes going over the serial link, and identifying the
protocol level.
General format
First of all the host (i.e. the computer) always originates the commands, and the camera gives
responses. That is: the computer gives the orders and the camera obeys and replies.
Each message has the following format:
two bytes to indicate the command (or response) type
two bytes to indicate the length of the data in the packet
the data itself - upto a maximum of 512 bytes
The camera should reply to each command by sending a response message as
soon as the command has executed. (Note however that the low level protocol should
check that an ACK is received immediately. If an ACK is not received within a
second or two, the low level protocol should signal trouble).
When a command (or response) must contain more that 512 bytes of data, since the
low level protocol can only handle packets of 512 bytes, the data to be transmitted
must be split into several 512 byte chunks. Note that the four byte header
containing the command (or response) and the data length indicator must be repeated
at the beginning of each packet related to that message. Thus for example when
uploading a picture, the first two bytes of each packet sent must contain the
command type, while the next two bytes must contain the data length of that
particular packet not the size of the full data to be transmitted.
The same occurs when receiving data from the camera - that is, the camera puts
the four byte response at the beginning of each packet it sends, the length
indicator indicating the packet length and not the full message length.
Not all commands take the same time to execute. In particular the shoot and
charge flash commands. Thus allowance must be made for them when waiting for a response.
Data formats
The following types of data are used in the messages transferred:
byte - a single byte representing either a small number or a set of flags
char - actually also a byte, but representing an ascii character
string - a sequence of characters used for names and so on
int - a 16 bit integer. The low byte is first, followed by the high byte
long - a long integer (32 bits) the first byte is the LSB, the last one
is the MSB
Preview - a preview image (i dont know much about this). This will
invariably consist of a number of packets of bytes. Thus several packets will be
required per message to transport it
Image - as in preview, but this time a standard JPEG image.
Note that the only times when multiple packets per message are required is for
the transfer of images and previews. All other messages contain much less than
512 bytes and can thus be transmitted in a single packet. You may be better off
writing separate functions for the handling of image data and short commands.
Specific command details
The following table lists all the available commands for the MX-700. The command and
response columns show the bytes to be transmitted and received. This does not
include the control characters substitution of DLEs and other things that are
done by the low level protocol.
You will notice that the information is incomplete for some commands. I am
trying to find out more about them - if you know the missing info please let me
know so I don't waste time re-inventing the wheel.
Some of the command meanings have links to a more detailed explanation.
list of supported commands (one byte for each command)
00 51 01 00 xx
(byte) command? <\td>
(?) Get command information
00 52 02 00 xx xx
2 bytes or int - unknown meaning
00 62 00 00
none <\td>
Download preview
00 63 nn nn xx-xx
Packet of preview image data
00 64 00 00
none <\td>
Shoot Preview
00 65 02 00 xx xx
Unknown
00 80 00 00
none <\td>
What is camera ID
00 81 nn 00 xx-xx
Ascii string
00 82 nn 00 xx-xx
sString - variable<\td>
Set camera ID
00 83 01 00 xx
(?) result 0=ok
00 84 00 00
none <\td>
What is date
00 85 0e 00 xx-xx
Date in ascii YYYY MM DD HH MM SS
00 86 0E 00 xx-xx
(14 bytes) date in ascii YYYY MM DD HH MM SS<\td>
Set date (and time)
00 87 01 00 xx
(?) (byte) result 0=ok
00 C0 02 00 xx xx
Unknown<\td>
(?) Send image information
00 c1 01 00 xx
Unknown
Examples
Here I give some examples of the actual bytes that are transferred between the
computer and the camera. This will help to illustrate some of the concepts
which may not be too clear in the above text.