[sane-devel] HP Scanjet 3670

[Ralph Little]

Hi,

On 2019-12-01 1:22 a.m., Povilas Kanapickas wrote:
>
>> However, scan motor movement is still broken for 50: the motor hums but
>> does not advance the scan head during the acquisition phase.
>> Presumably, the motor is setup using rates etc that it cannot physically do.
>> Even updating the scanner's motor tables to use the same slope settings
>> as 100dpi (which does work) but with FULL phase for the motor (as we do
>> for the 2400C) does not do the trick. Not sure why.
>>
>> I am looking at a working 50dpi USB trace from Windows to see what it
>> does differently and I will apply that back to the driver.
>>
>> Patch forthcoming to fix the above when I have it done.
>
OK, so the progress so far:

I have a wireshark dissector in Lua that tracks the scanner register and 
table state as the conversation progresses.
It's a bit like the awk script tools package that operates on the usb 
sniffer output but I can use this directly on a Wireshark trace and it 
allows me to slice and dice the analysis.

I am trying to understand what is happening with the slope table upload 
to the scanner with the official scanner driver.

My reading is that just before the actual scan, we see USB bulk 
transfers to 0x010000, which is supposed to be the slope table for 
1200dpi) according to the values of register 0x2a and 0x2b.

However, I don't really understand fully what I'm seeing. There are two 
separate USB Bulk OUT transfers one directly after the other: one for 
0x1ca bytes, the next for 0x78 bytes, both presumably to 0x010000. These 
two transfers follow separate 0x82 control commands so they really are 
completely distinct operations. The value of 0x21 (STEPNO) however is 
only 4.

The first 4 little-endian words of the first transfer are 0x0919, 
0x0543, 0x045d and 0x03ab.
The first 4 little-endian words of the second transfer are 0x6001, 
0x3902, 0x0317 and 0x0413.

The first looks reasonable and if I try those settings in half step mode 
(which the trace also shows) it seems fairly workable, although the 
sensor timings in colour are all off and there is seriously bad colour 
separation. The second looks like complete rubbish.

I see similar behaviour for the fast slope table at 0x010100.

My questions are:

1) Why are there two transfers to the same area, one directly after the 
other? (surely the second will overwrite the first)
2) Why such a large transfer when only 8 bytes (4 steps * 2bytes/step) 
are required?

Any help, greatly appreciated.

Cheers,
Ralph