[sane-devel] PF1800i - Preview

[Alexander Feldman]

Thanks,

This small shit (the scanner) drives me nuts. Reverse engineering the
protocol takes much more time than I initially anticipated.

The bridge is GL640, I have raised the level of the protocol one level up.
The real trouble is figuring out what the registers do. To help myself
reading the log I have also disassembled the windows driver. It is probably
crappy C code + the stupid MSVC6 that compiled in crappy assembler :(

Below is what I have discovered till now (not much):
===
Little Endian Format (LSB First)
Register  Type  Description
-------------------------------------------------
96h, 97h  word  Scan width in pixels.
9ch, 9dh  word  Motor speed.
85h       byte  Device control. See bits below.
                Mask            Description
                --------------------------------
                04h             Motor on.
                20h             Lamp on.
                40h             Green led on.
===
I looked at some SANE backends and didn't see anything that resembles this.
Does it speak to you?

At this moment I have working "lamp on" and "lamp off" and almost working
"scanner go home". Unfortunately I am lacking some general scanner knowledge
what should happen next. How do the scanner finds the beginning of the
slide? Is there a sensor or you scan in some low resolution mode until the
image begins? Do you know a place where I can find some more info about the
TWAIN interface?

I am now trying to understand how the scanned image is read. It seems that
first the whole image is scanned and then it is transferred in blocks of 30
lines.

Thanks to all for the help.

Rgds:

-- Alex

> -----Original Message-----
> From: sane-devel-admin@www.mostang.com
> [mailto:sane-devel-admin@www.mostang.com]On Behalf Of Henning
> Meier-Geinitz
> Sent: Thursday, August 21, 2003 3:09 PM
> To: Sane-Devel@Www. Mostang. Com
> Subject: Re: [sane-devel] PF1800i - Preview
>
>
> Hi,
>
> On Sat, Aug 16, 2003 at 11:55:04PM +0200, Alexander Feldman wrote:
> > I have taken some USB logs for the PrimeFilm 1800i and turned
> them into a
> > userland program, the ultimate goal of which is to get a preview of the
> > slide and to write it in a file. After some scrolling I have
> found several
> > patterns and how to reset the head to the initial position (although
> > sometime it starts in the reverse direction, reaches the end
> and produces
> > frightening sound).
> >
> > The results are available from:
> >
> > http://www.llama.gs/pf1800i/
>
> I had a quick look at the init log. The log looks very similar to those
> produced by the gl646 chip. However, only the USB transport mechanism
> seems to be the same, not the lower level stuff (register setting etc.).
>
> I'm interpreting one example as if it were a gl646 chip:
>
> | [248522 ms]  >>>  URB 1403 going down  >>>
> | -- URB_FUNCTION_VENDOR_DEVICE:
> |   TransferFlags          = 00000000
> (USBD_TRANSFER_DIRECTION_OUT, ~USBD_SHORT_TRANSFER_OK)
> |   TransferBufferLength = 00000008
> |   TransferBuffer       = 80e23720
> |   TransferBufferMDL    = 00000000
> |     00000000: 01 11 00 00 08 00 00 00
>
> 01 = write (00 = read)
> 11 = registers (00 = ram)
> 08 00 00 00 = transfer size (little endian), in this case the number
>               of registers * 2
>
> |   UrbLink                 = 00000000
> |   RequestTypeReservedBits = 00000040
>
> 40 = vedor request, write
>
> |  Request                 = 00000004
>
> I'm not sure about the meaning, with ram and bulk register writes 04
> is used, otherwise 0c.
>
> |   Value                   = 00000082
>
> 82 = read/write buffer (registers or ram)
> 83 = set register address
> 84 = read register
> 85 = write register
> 87 = init scanner
>
> |   Index                   = 0000ffff
>
> This is set to 0 with my scanner.
>
> | [248526 ms]  >>>  URB 1404 going down  >>>
> | -- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
> |   PipeHandle           = 80dbfcf4 [endpoint 0x00000002]
> |   TransferFlags        = 00000002 (USBD_TRANSFER_DIRECTION_OUT,
> |   USBD_SHORT_TRANSFER_OK)
> |   TransferBufferLength = 00000008
> |   TransferBuffer       = 00000000
> |   TransferBufferMDL    = 80e3bdf0
> |   00000000: 85 20 ad 0b 85 00 ad 4b
>
> Now the actual data is tranferred. With my gl646 scanner the first
> byte is the register number, the second one the value for that
> register. However, the gl646 doesn't have these high register numbers
> like 0x85 so there is some difference.
>
> Maybe the information helps anyway.
>
> Bye,
>   Henning
> _______________________________________________
> Sane-devel mailing list
> Sane-devel@www.mostang.com
> http://www.mostang.com/mailman/listinfo/sane-devel
>