[sane-devel] Reflecta ProScan 7200

Tue Mar 8 23:04:19 UTC 2011

m. allan noah <kitno455 <at> gmail.com> writes:

> 
> On Mon, Feb 7, 2011 at 6:37 AM, Michael Rickmann <mrickma <at> gwdg.de>
> wrote:
> > I got a Reflecta USB film scanner to digitize my collection of old slides
> > and negatives.
> 
> <snip>
> 
> Some random thoughts:
> 
> 1. SCSI over USB is a fairly common way for makers to upgrade their products.
> 2. Makers tend not to change protocols unless they absolutely must.
> 3. Improving and existing backend generally preferred over writing new ones...
> 4. ... unless the existing code is ugly or broken.
> 
> So, I would first attempt to modify the PIE backend to know about USB
> scanners. You might be able to copy some of the gl6xx code. I actually
> prefer working with SCSI-based machines, they are the easiest.
> 
> You will find SANE's support for infrared is quite lacking, however...
> 
> allan

See below for some more input. I've got a similar scanner with the same
vendor/product ids and I'm curious about how far we can dissect this thing.

I hope I've appropriately summarized what I've done. If it's cryptic, ask
me to clarify. If you've got some additonal information, I'm interested. If it
is not leading anywhere, I'd like to know as well...

- Jan

---------
Summary

Scanner:
Reflecta CrystalScan 7200 - idVendor 0x05E3 idProduct 0x0145

Computer:
MSI u100 laptop with Ubuntu 10.04

Virtualbox installed, virtual XP machine created, Cyberview and drivers
installed, USB filter for scanner active

Five runs
1 Connect the scanner to the computer
2 Run virtual XP, then connect scanner to computer 
3 Run virtual XP, connect scanner to computer, start Cyberview 10s later
4 Run virtual XP, connect scanner to computer @0s, start Cyberview @10s,
request preview @95s
5 Run virtual XP, connect scanner to computer @0s, start Cyberview @10s, push
button @95s, request scan @190s

Run 1:
4 USB transfers (3 device descriptors, 1 set configuration); no USB activity
after a couple of milliseconds

Run 2:
14 standard USB transfers, then 5 "USB-wrapped SCSI-commands" (see below), 3 of
which return 0x84 bytes (as USB-bulk transfers), partly readable : "PIE SF
Scanner 1.70 ... 1.05 ... PIE 2010/03/". The other 2 return 0. Is this some
kind of probing? The commands are almost identical but differ in details.
No activity after 5 seconds.
The USB-wrapped SCSI-commands are sets of USB-control transfers, with:
- "function" 0x0c mostly (some 0x04)
- "index" in the range of 0x0080 - 0x0088
- "value" varies, but rather constant within a wrapped SCSI command
- the initial part ("setup SCSI"?) consists of a fixed series of data bytes:
ffaa5500 ff8778 e00504ff
- the following data bytes are the SCSI command
- the scanner returns one or two bytes: 0300 or 01 seem to mean OK; 0302, 0308
and 00 signify not-ready or an error
An example of a SCSI INQUIRY (6 0x00 bytes):
f0ci0088vfc64 >ffaa5500ff8778e0
   i0087      >0504
   i0088      >ff
   i0085v0000 >000000000000
   i0084v1274 <0300
(f:function, i:index, v:value, >:data out, <:data in; a new line means that f,
i or v changes; spaces indicate that the value of the previous line applies)

Run 3:
Starts as run 2.
- from 20s to 50s each 1.5 second a pair of commands is sent: a
TEST_UNIT_READY-command and a 0xDD-command, followed by a 0x0b byte Bulk-in
(0000004c070101ab004945), as in run 2
- from 50s to 75s the TEST_UNIT_READY-command gives a NOT_READY response, which
is followed by a REQUEST_SENSE with a return of "LOGICAL UNIT IS IN PROCESS OF
BECOMING READY"
- from 75s to 95s the TEST_UNIT_READY-command returns READY, and is followed by
a 0xDD command as before; the 0x0b response bytes differ from those returned
earlier in one bit: 0000284c060001aa000000
This is repeated until the end of the run. A kind of a wait state, apparently.

Run 4:
Starts as run 3, after that:
A. from 75s to 95s the wait state
B. at 97s (when the preview is called for), a set of WRITEs follows, the last
of which has a 1st data byte of 0x95 (see pie-scsidef.h: #define READ_CAL_INFO
0x95); the following Bulk-in response follows the format of pie_get_cal_info()
C. at 98s a WRITE SET_SCAN_FRAME 0x12 follow, as in pie_set_window()
Next follow a set of commands most of which I cannot interpret:
D. WRITE with 1st data byte 0x17, to which the scanner responds "Illegal
request, INVALID FIELD IN PARAMETER LIST"
E. D7-command (READ?) with 0x67 bytes response
F. DC-command (WRITE?) 0x17 bytes out
G. at 99s SCAN (command code 0x1B), see pie_scan()
H. after a couple of TEST_UNIT_READYs first 42728 bytes are read,
   then 555464 bytes
I. D7-command (READ?) with 0x67 bytes response
J. DC-command (WRITE?) 0x17 bytes out
K. READ 2110808 bytes 
L. SCAN (command 0x18, pie-scsidef.h) reads 5340 bytes, only hex 7s and 0s
M. PARAM (0x12): 888 pixels per line, 573 lines, 888 bytes per line, filter
   offsets 1 & 2 = 8 (see pie.c), and a scsi transfer rate of 38570 whatever
   that means
N. a set of READs, in total 1529910 bytes
After that, the preview appears in Cyberview (@ 130s) and the scanner goes into
the wait state (see run 3).

Run 5:
Similar to run 4 but with more data. I'm able to identify the button-push-bit
in the 0x0b-byte DD-response.