[sane-devel] Reflecta ProScan 7200
Michael Rickmann
mrickma at gwdg.de
Mon Feb 7 11:37:38 UTC 2011
I got a Reflecta USB film scanner to digitize my collection of old
slides and negatives. I bought it because a test says that it has an
effective resolution of 3250 dpi, has a relative high density and is not
so slow.
Under Windows this film scanner can be operated with CyberView (from
PIE), ViewScan and Silverfast. It handles data aquisition including
infrared in one pass. With Cyberview I find it too difficult to get
optimal results. ViewScan is awfully slow when set at the highest
resolution, 3600 dpi, and its preview runs the scanner against the end
for a few motor steps. I use Silverfast on an old WinXP-SP2 machine
(under Win7-64bit Silverfast's
infrared dust removal is missing something) although it stalls the
computer after about 4 hours when the scanner hangs.
Under Linux after switching on, the scanner needs about half a minute to
settle. During this time it scans a few lines at high resolution
(judging from sound). And it also switches lights off after a while.
lsusb -vv :
Bus 002 Device 012: ID 05e3:0145 Genesys Logic, Inc.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 255 Vendor Specific Subclass
bDeviceProtocol 255 Vendor Specific Protocol
bMaxPacketSize0 64
idVendor 0x05e3 Genesys Logic, Inc.
idProduct 0x0145
bcdDevice 3.02
iManufacturer 0
iProduct 0
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 39
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 10mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type Nonpie-scsidef.he
Usage Type Data
wMaxPacketSize 0x0001 1x 1 bytes
bInterval 8
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 255 Vendor Specific Subclass
bDeviceProtocol 255 Vendor Specific Protocol
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0001
Self Powered
sudo sane-find-scanner :
# sane-find-scanner will now attempt to detect your scanner. If the
# result is different from what you expected, first make sure your
# scanner is powered up and properly connected to your computer.
# No SCSI scanners found. If you expected something different, make
sure that
# you have loaded a kernel SCSI driver for your SCSI adapter.
found USB scanner (vendor=0x0471, product=0x0311) at libusb:003:002
found USB scanner (vendor=0x05e3, product=0x0145, chip=GL842?) at
libusb:002:003
# Your USB scanner was (probably) detected. It may or may not be
supported by
# SANE. Try scanimage -L and read the backend's manpage.
# Not checking for parallel port scanners.
# Most Scanners connected to the parallel port or other proprietary ports
# can't be detected by this program.
I think that it is not a GL842 based scanner. I managed to identify
most, but not all chips on the circuit board. It is mostly hidden under
mechanical parts which I did not dare to dismantle.
GL660USB / 1012MSP1201-53G
USB2.0 to IEEE-1284 / DMA Bridge
A3967SLBT / A 1021 / 1021454KDAA
microstepping driver
B008KK14 / Lattice / ispMACH / LC40032V / 75TN44-1?
CPLD
ISSI / IS41LV16100B-50KL / RPN6870T1 1019
1M x 16 DRAM
Chiplus / nextline is difficult to read, perhaps CS18LV10245CCR70
SRAM ?, next to the ISSI chip
PS007 / 2170006G / F05PA-000 / 1019
is a rather large chip with lots of pins, custom?
PF7250S / U3 / V1.01 / 27C512
print on white label covering the chip, 64Kbx8 EPROM
another similar looking chip (to the PF7250S), only visible from the side
others
74HCT157D / NXP / L9H9Y501 / Un61008E
LD1117A / L33ANE
When using Wireshark to capture from WinXP/Virtualbox the Win driver
only seems to use endpoint_number 0x00 and 0x81. I also did an usbsnoop
on the genuine WinXP machine capturing switch on of the scanner and
Silverfast doing a preview scan. When running the result through the
scripts which we I used for the GL842 based OpticBook 3600 (endpoints
seem the same) no string "genesys" can be detected.
I have mused about the log for a while. You can find the original log,
my interpreted one and the scripts with which I did that at
http://wwwuser.gwdg.de/~mrickma/sane-proscan-7200/preview0-logs/ .
When looking at the first bulkin of the Proscan there are a number of
consecutive ASCII characters containing the word PIE. Using the
definitions contained in Sane's backend/pie-scsidef.h the block would
decode into
URB 47 bulk_in len 132 read 0x06 0x00 0x02 0x01 0xb4 0x00 0x00
0x00
0x50 0x49 0x45 0x20 0x20 0x20 0x20 0x20
# get_inquiry_vendor "PIE "
0x53 0x46 0x20 0x53 0x63 0x61 0x6e 0x6e 0x65 0x72 0x00 0x00 0x00 0x00
0x00 0x00
# get_inquiry_product "SF Scanner"
0x31 0x2e 0x37 0x30
# get_inquiry_version "1.70"
0x10 0x0e # get_inquiry_max_x_res 3600
0x10 0x0e # get_inquiry_max_y_res 3600
0xdc 0x14 # get_inquiry_fb_max_scan_width 5340
0x74 0x0d # get_inquiry_fb_max_scan_length 3444
0x9e # get_inquiry_filters
0x35 # get_inquiry_color_depths
0x07 # inquiry_color_format
0x00
0x09 # get_inquiry_image_format
0x4b # get_inquiry_scan_capability
0x61 # get_inquiry_optional_devices
0x02 # get_inquiry_enhancements
0x0c # get_inquiry_gamma_bits
0x00 # get_inquiry_last_filter
0x2c 0x01 # get_inquiry_fast_preview_res 300
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x31 # get_inquiry_halftones
0x2e # get_inquiry_halftone_max_width
0x30 # get_inquiry_halftone_max_heighgt
0x31 # get_inquiry_max_windows
0x08 # get_inquiry_min_highlight
0x64 # get_inquiry_max_shadow
0x64 # get_inquiry_cal_eqn
0x01 0xc4 # get_inquiry_max_exp 50177
0x09 0x64 # get_inquiry_min_exp 25609
0x00 0xd0 # get_inquiry_trans_x1 53248
0x02 0x86 # get_inquiry_trans_y1 34306
0x04 0xbc # get_inquiry_trans_x2 48132
0x10 0xc0 # get_inquiry_trans_y2 49168
0x15 0x36 0x00 0x00 0x00
0x50 0x49 0x45 # "PIE"
0x00
0x32 0x30 0x30 0x39 0x2f 0x30 0x39 0x2f # 2009/09/
Does this make sense?
When looking at the other URBs there are 3 different stereotype
sequences of control URBs. Sequences of 6 URBs with request type 0x85 I
interpret as SCSI commands. Unfortunately among them there are 3 custom
commands 0xd7, 0xdd to read and 0xdc to write something. Another control
URB (request 0x82) seems to setup bulkin reads. The one byte control
reads with request 0x84 I would interpret as:
read result; if (result == 3) { read another result; if (result == 8)
busy; } ok;
When looking at really long bulkin sequences I can find the characters
RR, GG, BB or II at regular intervals. So the image data seem to be
indexed in a similar but not equal way as the code in Sane's pie backend
expects.
I feel so bored scanning slides and negatives that I would also like to
spend some time inbetween using the scanner in a more intelligent way.
So I need some guidance with the following questions.
Has anybody else here have experience with PIE / Reflecta USB film scanners?
Is my attempt to interpret the snoop as a SCSI over USB protocol a
sensible attempt or is it just wishful thinking?
If it is sensible what would be the best approach to get the scanner
going with Sane? Write a new backend, e.g. by mixing pie and genesys, or
extending an existing backend?
Regards
Michael
More information about the sane-devel
mailing list