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

[Bertrik Sikken]

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?

I'm not sure about this. At higher resolutions, the
amount of data to be transferred (and processed)
is quite a lot, especially if it has to be transferred
over a USB 1.1 connection.

In your log, there were two of these transfers. I think that
one of them (the first) might be settings for a calibration
scan that always uses the same scan settings. Does the
second one in the log also stay the same?

> *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.

This may be an artifact of the USB logger.
A bulk transfer is either from scanner-to-PC or the
other way around, while the logs seem to suggest that
data is sent in both ways in one transfer.
I think we should disregard the bulk data "sent to the scanner"
for endpoint 0x81.
The scan software is probably just reusing the buffer, therefore
we are seeing the same data in the next transfer.

> *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?

I think this is the same artifact again.
The software is asking for 0x40 bytes, but gets only 0x10 from
the scanner, therefore the last 0x30 bytes in the buffer do not
get updated.
The 0x10 bytes make sense because the transfer with request=0x26
told the scanner that 0xef10 bytes would be read, while only
0xef00 were actually read by the bulk read, so 0x10 bytes remained.

> *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.

Yes, I think so too, but they may be status bits for different
purposes.

> *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.

I see still some bulk transfers after the 0x29 control transfers.
The total amount of data is 0x780+0x680+0x10=3600, exactly the
amount of data you would expect for a 0.2inchx0.2inch@300DPI scan.
So this leads me to think that the first (relatively big) bulk
packets are for a calibration scan, then the bulk packets after 
request=0x29 are calibration data, then the final bulk packets
are for the scan.

Kind regards,
Bertrik