[sane-devel] LiDE 90 half ccd
pierre at pirsoft.dnsalias.org
Sat Apr 19 23:59:05 UTC 2008
Guillaume Gastebois schrieb:
>> Guillaume Gastebois schrieb:
>>> 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;
>>> 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?
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):
>|----|< 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.
More information about the sane-devel