All contents on this page were obtained through observing the communication between the Windows WIA and TWAIN drivers (using the standard windows scanning wizzart) and the multi-function printer connected on the LAN (using wireshark). The purpose is solely for documentational purposes, so that I will be able to write a proper SANE backend to support this device. I do not have any access to any internal documentation of the device or protocol :( I also did not disassemble the windows driver, just looked at the commands sent over the local network.

The protocol described in this document is used at least by the following devices (other devices might use the same protocol, but I have not had access to any of them):

• KONICA MINOLTA magicolor 1690MF, USB-ID: 0x132b:2098

The following values need to be hardcoded in the driver, There is no command to retrieve those values from the scanner!

The scanner uses a binary protocol and reacts to 03 xx xx commands, which might have additional arguments. Each command sent to the scanner has a fixed size (LAN: 64 bytes, USB: 72 bytes), which is padded with 00 if the command does not use arguments of the full length.

NOTE: The padded bytes to fill the 64/72-byte blocks are truncated in all commands and sniffs below.

• USB: No communication wrapper, only 03 xx xx commands; basically polling for status with 03 09 01 until the scan is initiated.

• LAN: General communication wrapper (using 04 xx xx commands, which have no fixed data size):

<= 04 00 00       (Some HELO/READY message)
=> 04 01 00 89 20 (Greeting by computer)
<= 04 02 00       (ACK by scanner)
[Lots of ''03 xx xx'' commands by computer, response data by scanner]
=> 04 03 00       (BYE)

The device uses endpoint #3 (0x03, OUT) for requests sent to the scanner and endpoint #5 (0x85, IN as bit #7 determines IN/OUT of the endpoint as seen from the host=computer) for data sent by the scanner.

Each command sent to the scanner on endpoint 0x03 is answered on endpoint 0x03 by „00 00 00 00 00 00 00 00“. Similarly, when reading data from endpoint 0x85, the computer first sends „00 00 00 00 00 00 00 00“ to the scanner on endpoing 0x85, after which the data is received. This is the general way USB data transfers work. See for example http://wiki.wireshark.org/USB:

The completion event for transfers to the scanner and the submit event for transfers from the scanner are always '00 00 00 00 00 00 00 00' and will be neglected in all data sniffs below. The events containing the data seem to have an 8-byte header, too, which is also always null, i.e. '00 00 00 00 00 00 00 00'.

The network functionality uses TCP port 4567 on the scanner.

When talking to a network-attached device, the communication is established by special 04 … commands. If they are successfull, then the usual 03 commands are used for the actual scanner commands. At the end of a session, 04 commands are again used to close the session.

These commands are only used when the scanner is connected via the LAN (not via USB). The data length is not padded and is 3 (or 5) bytes exactly, with no further trailing 00.

03 08 (Bytes 1-2)			Initiate the scan with given parameters
	04 00 00 00 (Bytes 3-6)		Length arg1 (4 bytes)
		Bytes 1-4 (7-10)	arg1: Expected return data size: Lines*BytesPerLine (see below)
	01 00 00 00 (Bytes 11-14)		Length arg2 (1 byte)
		Byte 1 (15)	Unknown
Response: NONE

Notes for data size (bytes 7-10):

• Lines: Value from Bits 3-4 of the 03 0b return value
• BytesPerLine: image pixels per line (bits 1-2 of the 03 0b call) * depth/8 * colors

Typical call:

    03 08 04 00 00 00 00 6e  10 00 01 00 00 00 00 ...

Typical call:

   03 09 01 00 ...
        01

Typical call:

   03 0a 00 00 00 00 ...

This command is sent when either the scan was cancelled manually (i.e. the cancel button in the frontend was pressed), or to reset the printer when an error occured (like a paper jam).

03 0b (Bytes 1-2)			Query image parameters
	08 00 00 00 (Bytes 3-6)		Length arg1 (8 bytes)
		Bytes 1-8 (7-14)	arg1: Unused? Always 00
Response:
		Byte 1-2	#pixels returned per line(*), padding to multiples of 512 bytes is included, little endian
		Byte 3-4	#lines returned; y-extent*resolution/600dpi, little endian
		Byte 5-6	image pixel per line; x-extent*resolution/600dpi, little endian
		Byte 7-8	image lines, typically same as byte 3-4

(*) E.g. in B/W a value of 0x1000 means 4096 pixel = 512 bytes at 1 bit depth. In Grayscale a value of 0x0200 means 512 pixel = 512 bytes at 8 bith depth, 0x0600 means 1536 pixel(=bytes). In Color a value of 0x0a00 means 2560 pixel (i.e. 2560 bytes per color channel at 8 bith depth).

Only the number of pixels given in bytes 5-6 is really used, the remaining pixels returned by the scanner appear to be random memory dump data (i.e. some intermediate data from internal image processing, without any useful purpose).

Typical call:

   03 0b 08 00 00 00 00 00 00 00 00 00 00 00 ...
        00 10 e5 06 e4 04 e5 06

03 0c (Bytes 1-2)			Set scan options
	11 00 00 00 (Bytes 3-6)		Length arg1 (17 bytes)
		Byte 1 (7)	Resolution: (00=150dpi, 01=300dpi, 02=600dpi), 1200dpi/2400dpi not supported (also uses 02)
		Byte 2 (8)	Color type: (00=B/W, 02=Grayscale, 03=Color)
		Byte 3 (9)	Brightness: 05=0, 01=-127, 09=+127
		Byte 4 (10)	Unknown. Always 'ff'
		Byte 5-6 (11-12)	x-Start, little endian, pixel in optical resolution(=600dpi)
		Byte 7-8 (13-14)	y-Start, little endian, pixel in optical resolution(=600dpi)
		Byte 9-10 (15-16)	x-Extent, little endian, pixel in optical resolution(=600dpi) (1)
		Byte 11-12 (17-18)	y-Extent, little endian, pixel in optical resolution(=600dpi) (1)
		Byte 13 (19)	Source (00 is flatbed, 01 is ADF)
		Bytes 14-17 (20-23)	Unknown. Always 00 00 00 00 ?
Response: NONE

(1) The x-/y-Extents are given in 600dpi (i.e. optical resolution), but with some additional padding. For example, A4 (21×29.7cm) would be 4960,63×7015,75 pixel, but the actual extent sent to the scanner is 5008×7060. The values are not padded to some multiple of 8, 16 or so! Some reference values:

Typical call:

   03 0c 11 00 00 00 00 00  05 ff 00 00 00 00 f8 13  dc 20 00 00 00 00 00

03 0d (Bytes 1-2)			Get status?
	0b 00 00 00 (Bytes 3-6)		Length arg1 (11 bytes)
		Bytes 1-11 (7-18)	arg1: Unused? Always 00
Response:
		Byte 1	Unknown, LAN: always ff, USB: 00
		Byte 2	ADF status (00=no doc loaded, 01=doc loaded)
		Byte 3-11	Unknown, always 00?

Typical call:

   03 0d 0b 00 00 00 00 00  00 00 00 00 00 00 00 00  00
        ff 00 00 00 00 00 00 00  00 00 00

Typical response:

  LAN: ff 00 00 00 00 00 00 00  00 00 00
  USB: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   00 02 00
  
  

Typical call:

   03 0e 04 00 00 00 00 fe  00 00
       [0xFE00 bytes of scan data sent to computer]
       

Typical call:

   03 0f 01 00 00 00 00
       00

Ilia Sotnikov: function is „Get buttons“

Typical call:

   03 12 0b 00 00 00 00 00  00 00 00 00 00 00 00 00  00
       00 00 00 00 00 00 00 00  00 00 00

Typical response:

   LAN: 00 00 00 00 00 00 00 00  00 00 00
   USB: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   00 02 00

Ilia Sotnikov has decoded the USB data flow of the BizHub 162/132 and DiMage 1611 devices, which are B/W only and USB only.

'⇒' indicates data/command sent to scanner, '⇐' indicated data returned by the scanner (request data packet omitted here!):

The Windows installer apparently employs SNMP to detect network-connected devices. An SNMP broadcast is sent to the address 255.255.255.255, and if SNMP is enabled on the scanner, it will respond properly.

Interesting OIDs (used by the windows driver to detect the device):

• 1.3.6.1.2.1.1.1.0 (SNMPv2-MIB::sysDescr.0) = STRING: KONICA MINOLTA magicolor 1690MF
• 1.3.6.1.2.1.1.2.0 (SNMPv2-MIB::sysObjectID.0) = OID: SNMPv2-SMI::enterprises.18334.1.1.1.1.1.23.1.1
• 1.3.6.1.2.1.2.2.1.6.1 (IF-MIB::ifPhysAddress.1) = STRING: 0:20:6b:cc:6:77

All SNMP OIDs supported by the device

The data format is fairly simple: Simply one pixel after each other, one line after each other (without any newline indicators).

There is no image header returned. All image size information must be used from the 03 0b request call for pixels_per_line and from the argument passed to the 03 08 start scan command for the BytesPerLine value.

The only pitfall is that each line always uses a multiple of 512 bytes (the exact number of data pixels per line is returned in the 03 08 call and needs to be uses, as there is no other obvious way to calculate the value), so some additional bytes are added to pad each line to such a multiple. When passing on the image data to a scanning frontend, one needs to make sure these additional padding pixels are ignored. The following image shows an example of the whole FBF area and the actuall image sent by the scanner (where each line uses at least 512 bytes). Most of the image data sent by the scanner must be ignored:

The scanned FBF area is only a small part of the whole image returned from the scanner. The extensions of the scanned area (framed in red) and the whole returned area are both returned by the ''03 0b'' command.

The image data for 1-bit B/W is simply a bit-by-bit representation of the scanned data, i.e. 8 pixels per byte, one byte after the other. Each line uses exactly BytesPerLine bytes (i.e. a multiple of 512 bytes!), where only the first PixelsPerLine bits are used, the rest can and should be ignored.

The image data for 8-bit Grayscale is simply a byte-by-byte representation of the scanned data, i.e. 1 pixel per byte, one byte after the other. Each line uses exactly BytesPerLine bytes (i.e. a multiple of 512 bytes!), where only the first PixelsPerLine bytes are used, the rest can and should be ignored.

The format of color scans is the same as for Grayscale images, with the only difference that the R/G/B scan data is returned one line after the other (each of them is padded as described above!). So the individual values for the RGB bytes of one pixel are actually scan_pixels_per_line apart in the returned data.

• Are the padding bytes useful in any way?

• Scans with various settings (only those parts of the communication containing the parameters)
• LAN preview scan
• USB scan