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

[Karsten Festag]

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:
> > > Hi,
> > > I am trying to write the linux driver for Microtek
> > > Scanmaker 5600 scanner. I used USBSnoopy to
> >
> > generate
> >
> > > these logs from VMWare/Win2k. I have filtered out
> >
> > the
> >
> > > big bulk transfers. The log files are still in
> >
> > ~200KB
> >
> > > range. I am providing a link below with the log
> >
> > files.
> >
> > > I have made some progress in identifying the
> >
> > status
> >
> > > check packets, and some pattern in the bulk
> >
> > transfers,
> >
> > > but I have no idea what those medium sized control
> > > packets mean. I would appreciate any help.
> > >
> > > http://blanca.homelinux.com/usblogs/
> > >
> > > Thank you very much!
> >
> > What medium sized control packets do you mean?
> >
> >
> > I looked a bit at the logs and noticed 10 unique
> > patterns:
> >
> > * request=0x12, value=0x00: read version info?
> > The data returned by this transfer contains the
> > strings
> > "ScanMaker 5600  1.30"
> > "NowV0.10NewV0.10"
> >
> > * request=0x24, value=0x00: write 0x45 bytes of scan
> > settings?
> > 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
> > (index=length=20400)
> > Not sure yet what is written here, looks like 16-bit
> > data.
> > 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
> > transfer.
> >
> >
> > 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
> > already)
> >
> > Bertrik
> >
> >
> >
> >
> >
> > --
> > sane-devel mailing list:
> > sane-devel@lists.alioth.debian.org
>
> http://lists.alioth.debian.org/mailman/listinfo/sane-devel
>
> > Unsubscribe: Send mail with subject "unsubscribe
> > your_password"
> >              to
> > sane-devel-request@lists.alioth.debian.org
>
> __________________________________
> Do you Yahoo!?
> Take Yahoo! Mail with you! Get it on your mobile phone.
> http://mobile.yahoo.com/maildemo