[sane-devel] Re: strange problems LIDE30
Chris McKeever <email@example.com>
Fri, 8 Oct 2004 08:48:22 -0500
n Thu, 7 Oct 2004 09:01:59 +0200, Gerhard Jaeger <firstname.lastname@example.org> wrote:
> 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.
Thanks everyone for all your information! - I have gotten it all
working, and just want to summarize (again) what was laerned found
- yes the canon 30 is only 1.1USB
- when moving from a 2.4 kernel to a 2.6 kernel the startup time for the scanner
decreased significantly (I think the is a libusb v. scanner.o issue).
I am now able to remote scan @ 1200 (it is however slow)
- originally I had a generic USB2 card - that was causing me some
grief in-and-of-itself with the scanner, dropping it to the onboard
1.1 solved at least some of the issue
- I am using the stock kernel and libusb from SUSE 9.1 (2.6.5) - I am
not having any issue thus far w/ 1.0.14
once again - thanks
> 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.
> sane-devel mailing list: email@example.com
> Unsubscribe: Send mail with subject "unsubscribe your_password"
> to firstname.lastname@example.org