[sane-devel] Re: strange problems LIDE30

Gerhard Jaeger gerhard@gjaeger.de
Thu, 7 Oct 2004 09:01:59 +0200


let's try and shed some light on the plustek-backend and the LiDE30

- The scanner is a USB1.1 device, as the used chipset, a LM9833 is only
  capable to do USB1.1. 
- The LM9833 is able to scan @ 8bit per color-channel or @ 16bit
  where did you get the "full-color" from? You either scan with the
  "color" option, then it's 8bit per channel or you scan with the
  "color 42/48" option, then it's 16bit.
- The LiDE30 is able to scan @1200dpi in X direction, because it's the
  native resolution of the sensor, and the motor is able to do 2400dpi
  steps. Therefore X direction information is doubled.
- The backend does some calibration @ the start of each scan, this might
  take a while. This time has also been increased from 1.0.13 up to 1.0.14
  This is necessary to avoid stripes. To reduce the time, it's now possible
  to let the backend save the information of the coarse calibration 
  (option cacheCalData in the config file, or --calibration-cache=yes for
   scanimage). This is working for the latest CVs snapshots.

Please note, all backend before 1.0.14 are not recommendend for use with the
LiDE devices, as the calibration does not work correctly!
Also using kernel 2.6.x (x < 8) might cause problems with the USB.

Also note, that full-size scanning using the 2400dpi might not work. At least
I've never tested, because I've not that much memory in my boxes. 
2400dpi also create that much data, that a USB1.1 device really needs some
time to send the data to the box. Here the bandwidth is the limiting factor.
We might can tweak the motor settings for the 2400dpi to avoid backtracking.

Before continuing, I suggest to use the latest CVS snapshots, a kernel > 2.6.7
and the latests libusb. The next step will be to check if you really need to
do scans @2400dpi, at least full-size ones.