-----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-----
