Fwd: Re: Openmoko Bug #1194: Touchscreen Jitter

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:

| Dunno whether that's you, Andy...

Yes it is, I went through triaging the trac bugs tonight and closing the
ones that honestly didn't look like they are going to get addressed.

| anyway, this very strongly suggests the jitter is associated to one
PLANE of
| the ts only (like I guessed quite some time ago). This means: either

It flat out says it, rather than strongly suggests it :-)

| the "long-axis" X+,Y- rails on powered pane are on the "inside"(near
LCD).
| Touchpoint contacts to the outer plane, and there some sort of hum,
EMI, RF,
| or god knows what is introduced to the relatively highZ "target"plane
from
| environment and is spoiling the A/D for this axis.
| OR outer and inner plane are reversed (means (+) and (-) rails are on the
| short parts of outer plane), and the interference comes from our
| LED-power-converter (or the LCD itself - though I can't imagine this)
| coupling to the inner plane that goes to A/D-in.

LED power didn't seem to have much ripple last I looked, but then I was
looking at 5V/div.

| Once more I like to ask whether one of the coder wizards can setup a
| simple "sample at 500k/s and dump to some file"-type debug helper tiny
| program, so we might analyze for the real waveform we see on "long axis".
|
| We may need this to improve hardware circuitry (filters!) of future
| resistive-ts designs, as well as to know what we have to tune the
ts-lib to
| cope with for recent devices.
|
| A *GOOD* scope probe printout _maybe_ is even better, but this simple
| A/D-thingy will serve perfectly for a first approach (a least we know for
| *sure* this is what the A/D-converter (and thus tslib) got)

As I mentioned it's hard to find a place to probe.

What I did is a weaker version of what you asked for, at

~  http://warmcat.com/ts-dump

is a short file made from

~  ts_print_raw > /tmp/ts-dump

Normally the ADC samples are averaged in batches of 32 in the kernel
(before whatever tslib plans to do), I cranked up the ADC speed to
500kHz and removed the averaging.  I think by this method we miss a lot
of samples, but the samples that are captured should be truly raw single
ADC events.

The results in the file (with me holding a pencil head to the screen)
are pretty ugly in the first coordinate compared to the high stability
of the second coordinate -- the average is like 511, 590:

1213744740.484058:    511    589      1
1213744740.489078:    513    588      1
1213744740.494059:    511    588      1
1213744740.499058:    509    588      1
1213744740.504078:    485    591      1  <===
1213744740.509058:    509    591      1
1213744740.514079:    506    586      1
1213744740.519078:    511    589      1
1213744740.524078:    507    587      1
1213744740.529079:    511    586      1
1213744740.534059:    511    590      1
1213744740.539058:    509    590      1
1213744740.544078:    420    589      1  <===
1213744740.549079:    509    591      1
1213744740.554078:    501    589      1
1213744740.559078:    511    588      1
1213744740.564079:    490    589      1  <===
1213744740.569058:    511    589      1
1213744740.574078:    512    588      1
1213744740.579078:    511    589      1
1213744740.584078:    513    588      1
1213744740.589078:    512    583      1
1213744740.594079:    510    589      1
1213744740.599098:    514    589      1
1213744740.604078:    510    588      1
1213744740.609058:    509    588      1
1213744740.614058:    514    588      1
1213744740.619078:    511    589      1
1213744740.624059:    517    589      1
1213744740.629057:    505    589      1
1213744740.634058:    511    589      1
1213744740.639089:    523    589      1  <===
1213744740.644116:    508    590      1


So if the "selfselection" of samples from the firehose don't make it a
nonsense to look at it this way, it means we get excursions in the first
coordinate of up to +/- 20% at about 10% probability.

What we could do is refuse to accept samples too far outside a running
average into the average reported back to userspace....

- -Andy

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkhYPjoACgkQOjLpvpq7dMobEACdFJ8d1qNA9ezHbD/H75zqms1r
E4MAoIfeRnAUbWj0/Go+d4aXsG4L2dSW
=HrZl
-----END PGP SIGNATURE-----