[sane-devel] LiDE 90 half ccd
Hello, OK, if i understand test values you proposed gives : 0xf f0 3f bit of 0x79! 0x78 !0x77! 0x79 0 1 2 3 4 5 6 7!0 1 2 3 4 5 6 7!0 1!0 1 2 3 4 5 6... 1 1 1 1 1 1 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 ___ |__|| 0xff 80 1f bit of 0x79! 0x78 !0x77! 0x79 0 1 2 3 4 5 6 7!0 1 2 3 4 5 6 7!0 1!0 1 2 3 4 5 6... 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 0 _ ___ |___| |__ 0xff c0 0f bit of 0x79! 0x78 !0x77! 0x79 0 1 2 3 4 5 6 7!0 1 2 3 4 5 6 7!0 1!0 1 2 3 4 5 6... 1 1 1 1 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 0 0 ___ ___ |___| | 0x0 01 c7 bit of 0x79! 0x78 !0x77! 0x79 0 1 2 3 4 5 6 7!0 1 2 3 4 5 6 7!0 1!0 1 2 3 4 5 6... 1 1 1 0 0 0 1 1 1 0 0 0 0 0 0 0 0 0 1 1 1 0 0 0 1... _ _ _ __ |_| |_| |_| I'll give them a try. Do you think 0x7D is needing tuning ? (what are CCD CP and CCD RS ?) Regards Guillaume
[sane-devel] LiDE 90 half ccd
Hello, OK, if i understand test values you proposed gives : 0xf f0 3f bit of 0x79! 0x78 !0x77! 0x79 0 1 2 3 4 5 6 7!0 1 2 3 4 5 6 7!0 1!0 1 2 3 4 5 6... 1 1 1 1 1 1 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 ___ |__|| see entropy result on : http://ggastebois.free.fr/lide90_snoop/3f03f.pnm 0xff 80 1f bit of 0x79! 0x78 !0x77! 0x79 0 1 2 3 4 5 6 7!0 1 2 3 4 5 6 7!0 1!0 1 2 3 4 5 6... 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 0 _ ___ |___| |__ same as before 0xff c0 0f bit of 0x79! 0x78 !0x77! 0x79 0 1 2 3 4 5 6 7!0 1 2 3 4 5 6 7!0 1!0 1 2 3 4 5 6... 1 1 1 1 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 0 0 ___ ___ |___| | same as before 0x0 01 c7 bit of 0x79! 0x78 !0x77! 0x79 0 1 2 3 4 5 6 7!0 1 2 3 4 5 6 7!0 1!0 1 2 3 4 5 6... 1 1 1 0 0 0 1 1 1 0 0 0 0 0 0 0 0 0 1 1 1 0 0 0 1... _ _ _ __ |_| |_| |_| gray image with horizontal black lines I'll give them a try. Do you think 0x7D is needing tuning ? (what are CCD CP and CCD RS ?) Regards Guillaume I'll now try with clk1 and clk4. Regards Guillaume
[sane-devel] LiDE 90 half ccd
Hello, No progress on 2400dpi. DPIHW is 2400 and dpiset 600 for a 300dpi scan. Don't know where to look yet for that problem ! about byte nibbles modifying reg_0x79 from 0x3f to 0x3e (very few contrasted image) or 0x40(black image) gives me bad images !!! What is effect of this register on clk3 ?? It's very sensible. Ideas ? regards, Guillaume
[sane-devel] LiDE 90 half ccd
Guillaume Gastebois schrieb: Hello, No progress on 2400dpi. DPIHW is 2400 and dpiset 600 for a 300dpi scan. Don't know where to look yet for that problem ! I'd try to get a log from a 2400dpi scan from windows and compare. about byte nibbles modifying reg_0x79 from 0x3f to 0x3e (very few contrasted image) or 0x40(black image) gives me bad images !!! What is effect of this register on clk3 ?? It's very sensible. register 0x77 to 0x79 describe a bitmask, that determines when the clk3 signal is high or low. For 0x0003f(lsb is register 0x79), this would give: time=== ! next pixel bit of 0x79! 0x78 !0x77! 0x79 0 1 2 3 4 5 6 7!0 1 2 3 4 5 6 7!0 1!0 1 2 3 4 5 6... 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 ___ ___ |___| | 0x40 is this: bit of 0x79! 0x78 !0x77! 0x79 0 1 2 3 4 5 6 7!0 1 2 3 4 5 6 7!0 1!0 1 2 3 4 5 6... 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 _ _ ___| |_| | As you can see, this gives a very short pulse, which will probably not be recognized by the ccd, while 0x3e just shortens the clock pulse at the beginning. The datasheet mentions that the scanner does not need to use the full 18 bits of the bitmask, but uses the first 6, 12 or 18 bits depending on the scanning mode. 12 seems to be correct for the mode the backend programs for cis scanners. Please try if modifying bitmask for clk4(0x7a to 0x7c iirc) shows any effects. Also, other values you may want to try on clk3: 0xff03f, 0xff801f, 0xffc00f. Another thing to try may be to send two clock pulses, for example 0x001c7. If clk3 is connected to the ccd, this may give interesting results(like, reducing the resolution by half), but for the 4-bit latch/D-FlipFlop, only the last clock pulse before the gl841 samples the data bits is relevant. regards, Guillaume Regards, Pierre
[sane-devel] LiDE 90 half ccd
Guillaume Gastebois schrieb: Hello, I remember that LiDE 90 is a 2400DPI scanner. And I did nothing in code to port that. I backend ready for 2400dpi (I think so regarding portion of code) ? I am not sure, as there could not happen any testing. But in theory, it should work. In the future, there should be some afford made to make other resolutions than 2400, 1200 and 600 work, but these 3 are trivial with this chip. I write 2400 dpi in genesys_sensor for lide 90. But how to know pixel number for CCD sensor ? I guess the manufacturer is not lying about the density of the ccd, so that should be enough. The rest of the settings is in real units. The backend calculates the exact number of pixel from the density and the width of the scanning area. After writing 2400 dpi in sensor, I get quarter sized images !!! Why ? With 600 dpi in sensor I get full sized images with (300dpi scanning) or without half_ccd (1200dpi scanning) (with my code for gpio 14). Regards Guillaume I'd first try to get the correct gpio setting for a full resolution scan(i.E. at 2400dpi). If you cannot get a full-width-scan, look for the DPISET register, and try half/twice the dpi there. Also, make sure the DPIHW is set for the 2400dpi mode. When that works, figure out how to setup gpios for half_ccd mode. From the view of the current code base, you are done here. You can try to find a quarter_ccd mode(which would show up as half-width in the half_ccd modes), and leave a comment in the code, or even implement the quarter_ccd mode for real. Regards, Pierre
[sane-devel] LiDE 90 half ccd
Hello, I remember that LiDE 90 is a 2400DPI scanner. And I did nothing in code to port that. I backend ready for 2400dpi (I think so regarding portion of code) ? I write 2400 dpi in genesys_sensor for lide 90. But how to know pixel number for CCD sensor ? After writing 2400 dpi in sensor, I get quarter sized images !!! Why ? With 600 dpi in sensor I get full sized images with (300dpi scanning) or without half_ccd (1200dpi scanning) (with my code for gpio 14). Regards Guillaume
[sane-devel] LiDE 90 half ccd
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 ?
I tryed with 0x1a=0x20 and it doesn't change anything. Doese it mean
that clk3 is not used ?
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
[sane-devel] LiDE 90 half ccd
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
[sane-devel] LiDE 90 Half CCD
Hello, I see in genesys_gl841.c line 2503 : /* gpio part. here: for canon lide 35 */ r = sanei_genesys_get_address (reg, 0x6c); if (half_ccd) r-value = ~0x80; else r-value |= 0x80; Does it mean that for LiDE 35 GPIO16 is half CCD IO ? Because in LiDE 90, I identify GPIO 14 for that. Another thing : In windows snoop, only GPIO 14, 13, 12 and 11 changes state. Is it possible that scanner need different gpio state between calibration and scanning (and different calibration phases) ? Where to add gpio state change code in backend to change gpio between different phases ? Thank you. Regards Guillaume
[sane-devel] LiDE 90 Half CCD
Guillaume Gastebois schrieb: Hello, I see in genesys_gl841.c line 2503 : /* gpio part. here: for canon lide 35 */ r = sanei_genesys_get_address (reg, 0x6c); if (half_ccd) r-value = ~0x80; else r-value |= 0x80; Does it mean that for LiDE 35 GPIO16 is half CCD IO ? Because in LiDE 90, I identify GPIO 14 for that. The GPIO16 is used as half CCD IO. Correct. Another thing : In windows snoop, only GPIO 14, 13, 12 and 11 changes state. Is it possible that scanner need different gpio state between calibration and scanning (and different calibration phases) ? Where to add gpio state change code in backend to change gpio between different phases ? There is no way to know what GPIO 11, 12, 13 do without some experiments (or tracing the wires on the pcb, which i advise against). For example, one GPIO could shut off the LED drivers(thus making black level calibration easier), another could be used to save power(as is GPIO 9 in Canon LiDE 35). Currently, i think the only possibly useful GPIOs for calibration and scanning are the half ccd and the black led selectors, of which the latter is not needed(At least my scanner does not need it, even when doing black-level calibration on a white target). Thank you. Regards Guillaume Regards, Pierre
