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
