[sane-devel] Need help analyzing USBSnoopy logs for Microtek Scanmaker 5600

Bertrik Sikken bertrik@zonnet.nl
Sun, 26 Sep 2004 11:45:34 +0200


Indeed, the commands are identical as far as I can tell, except for a
difference how some of the SCSI command bytes are mapped to the USB
request, value and index fields and some commands that are sent
just before a bulk transfer is done.

I think it's worth linking to this thread from the scanner search
engine page for this scanner.


Karsten Festag wrote:
> Hi,
> I just looked curiously on the data and I think there are some similarities 
> between the scsi based scanners driven by the microtek2 backend and the 5600:
> command 0x24 is used to setup the scan window, probably first a fixed window 
> for calibration and second the actual scan window.
> command 0x28 0xnn 0x80 reads image information (width, height, bytes)
> command 0x28 0xnn 0x81 reads system status (Lamps on/off, buttons,) and 0x2a 
> 0xnn 0x81 should set the status.
> command 0x28 0xnn 0x82 reads scanner attributes (resolution, width, heigt of 
> the scan area.......)
> Maybe a look at the microtek2 sources helps you. I also have some (quite old) 
> documentation but it may help. Tell me if I shall send it to you (its an ugly 
> MS Word file :-()
> Regards,
> Karsten
> On Wednesday 15 September 2004 21:57, Susheel Yadav wrote:
>>Thanks a lot Bertrik for your analysis. I have figured
>>out some things - I have written those down in the
>>last  link on the web page.
>>*request=0x24 value=0x00 data=0x45 bytes
>>The data transferred in this request did not change
>>even if I moved the scan area horizontally keeping the
>>size constant. This makes me think that maybe it scans
>>the whole row and the software clips the image later.
>>What do you think?
>>*request=0x26 value=0x00 data=0xef00 bytes
>>This happens before bulk transfers, and the data
>>returned in Nth step is sent to the scanner in the
>>(N+1)th request.
>>*The bulk transfer is followed by a small transfer of
>>0x40 bytes. This returns 0x10 bytes. The last 0x30
>>bytes sent always remain same, and the first 0x10
>>bytes are the ones that were returned from the
>>previous cycle. Could this signify the position of the
>>next chunk of data?
>>*request=0x28, 0x40, 0x83, 0x12 repeat and I think
>>they are status check. The windows driver has a
>>scanner detector utility which when turned on, keeps
>>sending those packets.
>>*request=0x28 value=0x83
>>This request gets the data that is send back in some
>>0x40 0x2a 0x81 requests.
>>*request=0x29 seems to denote the end of transfer
>>since there is no more bulk data after that.
>>--- Bertrik Sikken <bertrik@zonnet.nl> wrote:
>>>Susheel Yadav wrote:
>>>>I am trying to write the linux driver for Microtek
>>>>Scanmaker 5600 scanner. I used USBSnoopy to
>>>>these logs from VMWare/Win2k. I have filtered out
>>>>big bulk transfers. The log files are still in
>>>>range. I am providing a link below with the log
>>>>I have made some progress in identifying the
>>>>check packets, and some pattern in the bulk
>>>>but I have no idea what those medium sized control
>>>>packets mean. I would appreciate any help.
>>>>Thank you very much!
>>>What medium sized control packets do you mean?
>>>I looked a bit at the logs and noticed 10 unique
>>>* request=0x12, value=0x00: read version info?
>>>The data returned by this transfer contains the
>>>"ScanMaker 5600  1.30"
>>>* request=0x24, value=0x00: write 0x45 bytes of scan
>>>This transfer contains numbers like 1200, 600, 300,
>>>which are likely
>>>DPI or LPI resolutions. I think that scan area is
>>>also coded in this
>>>transfer. It noticed this transfer happens twice
>>>(once for calibration,
>>>then once for the actual scan?)
>>>* request=0x26, value=0x00: prepare bulk read (index
>>>= length)
>>>This transfer always seems to happen just before a
>>>bulk read
>>>* request=0x28, value=0x80: get a bunch of bytes
>>>(don't know what)
>>>* request=0x28, value=0x81: read some 9-byte buffer
>>>* request=0x28, value=0x82: read scan capabilities?
>>>This transfer also has typical DPI numbers, but
>>>always seem to be
>>>the same (not always same length though)
>>>* request=0x28, value=0x83: read status byte?
>>>(00 = ready, 08 = not ready?)
>>>* request=0x29, value=0x2101: prepare bulk write
>>>Not sure yet what is written here, looks like 16-bit
>>>Could be calibration data.
>>>* request=0x2A, value=0x81: write some 9-byte buffer
>>>Same buffer as read by request=0x28,value=0x81
>>>* request=0x40, value=0x00: read scanner status
>>>This transfer seems to happen after about any other
>>>I think a good transfer to concentrate on is the one
>>>with request=0x24.
>>>This one seems to indicate scan settings, so try out
>>>some different
>>>scan area's, resolutions, etc. and see if you can
>>>spot any log changes
>>>in this transfer that match with your settings.
>>>The stuff written to the scanner using the transfer
>>>with request=0x29
>>>could be calibration data. I think that in initial
>>>tests you can get
>>>away with just writing some constant data like 0xFF.
>>>Hope this helps (and that I'm not telling you
>>>anything you knew