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

[m. allan noah]

if you are seeing artifacts from buffers getting re-used, you can try 
using benoit's usb sniffer, and my perl script spike4.pl, which figures 
out the direction, and does not show the initial contents of the buffer. 
it is much less confusing.

my script is available if you search sane archives, or from 

http://www2.pfeiffer.edu/~anoah/spike4.pl

better download as text.

allan

On Wed, 15 Sep 2004, Bertrik Sikken wrote:

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

-- 
"so don't tell us it can't be done, putting down what you don't know.
money isn't our god, integrity will free our souls" - Max Cavalera