[sane-devel] LiDE 90 half ccd

[Pierre Willenbrock]

Hi,

Guillaume Gastebois schrieb:
> Hello,
> 
>> Guillaume Gastebois schrieb:
>>> Hello,
>>>
>>> Me again !
>>>
>>> I'm trying to find what are GPIO14,13,12 and 11 for.
>>>
>>> I find GPIO11=home switch and must be 0.
>>> I thought I found GPIO14 was half CCD but by adding :
>>> /* gpio part. here: for canon lide 90 */
>>> if (dev->model->gpo_type == GPO_CANONLIDE90)
>>> {
>>> r = sanei_genesys_get_address (reg, 0x6c);
>>> if (half_ccd)
>>> r->value |= 0x20;
>>> else
>>> r->value &= ~0x20;
>>> }
>>>
> With code before and command scanimage, I get half sized image.
> Scanimage gives me these parameters :
>          pixels: 2574
>          lines: 3531
>          depth: 8
>          channels: 1
>          exposure_time: 5600
>          xres: 300
>          yres: 300
>          half_ccd: yes
>          stagger: 0
>          max_shift: 0
> 
> Why is half ccd activated ?

The parameters above represent what the backend tries to program. If you 
put a x-resolution below half of the optical resolution into scanimage, 
the backend determines it can use the faster scanning mode, i.E. half_ccd.

If you do not do anything to enable half_ccd-mode, you should get only 
half of the scanning area in x-direction for resolution below half 
optical resolution, and the full scanning area for resolutions above. Is 
it possible that your scanner is able to use not only a half-ccd-mode, 
but even a quarter-ccd-mode?

> I tryed with 0x1a=0x20 and it doesn't change anything. Doese it mean 
> that clk3 is not used ?

If you did that with ck3map and ck4map == 0, it would seem that clk3 and 
clk4 are unused. No idea why the windows driver sets these, then.

This is how i think your scanner works:

WM81xx  |                         | GL84x
OP[3:0] +--->--o---------->-------+ OP[3:0]
         |      |   .--------.     |
         |      |   | 4-bit- |     |
   MCLK  |      '->-+ latch  +-->--+ OP[7:4]
----^---'          '---^----'     |
     |                  '----<-----+ which clock?
     '------------<----------------+ MCLK

The 4-bit-latch is the VHC175.

This WM81xx frontend sends its 16bit data in 4 bit nibbles, changing 
state on the falling and rising edges of MCLK, or, more exactly, up to 
20ns later(from the WM8152 datasheet, this seems to be long considering 
the time for one MCLK period is 41ns):

MCLK     ______--------________-------
OP[3:0]  ##########><######><######><####
                |<----41ns----->|
               >|----|< less than 20ns
                        ^       ^  <<<<< sample here

therefore, it is probably safe to sample exactly on the edges. The 
WM8152 sets bits 7 to 4 when seeing a falling edge of MCLK, so the 4 bit 
latch can sample these on the next rising edge of MCLK. Then, it holds 
its output stable for the rest of the period. bits 3 to 0 are set when 
receiving a rising edge, so the GL84x should sample on the falling edge. 
The VHC175 samples on rising edges. This means, the clock used for the 
latch could be MCLK.

How does our problem with the high nibble of the second byte being 
similar to the low nibble of the first byte fit into this?

The 4 bit latch could be sampling at the same time as the WM81xx changes 
its outputs, this would lead to a mix of both informations. Maybe this 
does not happen for the first high nibble, because the WM81xx has 
slightly different timing for that case. This could be fixed by figuring 
out which clock the latch uses, and adjusting the rising/falling edges. 
When the latch does not get a clock, the gl84x should get the same 4 
bits over and over again(perhaps 0?) as high nibble, but usable low 
nibbles. (Similar can happen with the gl84x sampling at bad times, but i 
think the result would look different.)

Some random ideas:
It may be helpful if we could get the AFE to output an alternating bit 
pattern for each nibble. Lacking this possibility, reducing the gain and 
fiddling with the offset may be an option, too.

The above(including disabling clocks) will very probably lead to no 
usable image or working calibration. Instead, we need to examine the 
results of offset/coarse calibration. These two steps dump raw image data.

>>> in genesys_gl841.c line ~2053 I had image compressed x2 in the left and
>>> second right part black with 0x6c=12 and not with 0x6c=1a. Strange.
>>>
>>> I decided to comment out these lines yet for tests.
>>>
>>> In genesys_841.c I see conditions with GPO_CANONLIDE35 for gl841_feed
>>> function (lines ~4309 and ~4913). I added GPO_CANONLIDE90 too. What is
>>> this function for ? Is it usefull to add lide 90 ?
>> no, these don't help your scanner. the feed is used to position the 
>> scanning head at the white calibration strip. This is(should not) be 
>> needed for your scanner.
>>
> 
> Regards
> Guillaume
> 

Regards,
   Pierre