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.
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
Command protocol - this is a description of the actual commands and data
which are sent between the camera and the computer.
The serial port should be set to
8 data bits
1 stop bit
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
Send DLE-STX (Start of text = 0x10 0x02) to indicate the beginning of a
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
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
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
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
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
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.
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.