[sane-devel] Reflecta ProScan 7200
J.M.Vleeshouwers at tue.nl
Thu Jun 2 19:37:31 UTC 2011
(not including all of your email)
>> If you have a chance to try my new files and I have guessed correctly
>> your scanner should now advertise as PIE/Reflecta CrystalScan 7200 in
>> answer to scanimage -L. We may even get around the difference in MODE
>> SELECT byte 9 which has stalled your scanner so far. I tried to provide
>> for it (see crystalscan_7200_model in pie_usb.c).
It detects alright:
~/Projecten/PF7250u/SANEdevel$ scanimage -L 2> pf7250u.dbg
device `pie:libusb:001:007' is a PIE/Reflecta CrystalScan 7200 film scanner
Xsane works fine as well.
The scanner did not identify right away, though, it probably needed
switching off and on, I'm not sure. Therefore I was already creating a
debug file, in which I noticed something curious (see
At line 1313 SANE reads something that I recognise from the firmware.
Where does this come from?
>> Is my assumption right that your scanner fakes the 7200 dpi?
Yes. At 7200 dpi, the 5340-byte COPY-reponse contains all zeroes,
as it does for a 3600dpi scan. I haven't been able to snoop a 7200dpi scan
completely: it takes about an hour and than the Cyberview program crashes
with an unclear error message. I tried twice. But if I reproduce a 7200dpi
scan, it simply returns a stretched image: there are 7200 lines per inch
but only 3600 pixels per inch on a line. Cyberview interpolates the missing
pixels, I suppose.
I have been trying to reproduce the basic preview+scan runs, using
SCSI-command as ingredients and following the logged runs, including
wait loops for the device to get ready. I (accidently) noticed that the
available-lines value in the PARAM response actually works. If you start
a scan (COPY), don't read the available scanned data, but repeatedly call
PARAM, the number increases. For larger resolution settings the scan head
will eventually stop moving, long before it has scanned the whole slide.
The number of available lines stops increasing, and the scanner hangs.
Byte 16 of the DC-settings has something to do with this. I overlooked
it, but for larger resolutions this byte has several different values between
0 and 8 in the snoops. Setting the value to 0 for a 7200 or 3600 dpi scan
results in an error after reading about 2Mb of data.
You suggest motor settings, but might it be related to how the scanner treats
its internal buffer memory?
For a first draft document: www.stadspartijeindhoven.nl/jv/Reflecta7200.odt
For some experiments with the infrared:
They cover bytes 18 to 22 of the SCSI-DC-structure. Byte 21, which I named
"val", remains a mystery. The other ones behave as expected.
More information about the sane-devel