Hello, I misunderstood the e-mail from tech support, so it is now two weeks since I last worked on this issue and called for support. The following is from memory, but I believe to be pretty thorough.
Symptom:
- normal (purposeful) finger touch/release events are consistently measured correctly.
- light touch/release events can repeatedly be measured as being at an inconsistently different coordinate pairs.
- for example:
- My screen is divided into 6 rows of 8 columns
- I have a [STOP] button in row 5, columns 3&4 (bottom center of screen)
- another button [DIAL] at row 3, columns 3&4
- another button [MAN] at row 1, columns 3&4
- and another [AUTO] at row 1, columns 0&1 (left edge of one row down on screen)
- if I (finger-tip) touch [STOP] with force which always activates my button, the measured values buffered (8 or 32 samples per touch, did not matter), then I typically see 0, 1 or maybe 2 samples with values not yet stabilized/settled, followed by the remainder of the samples being as expected.
- I was occasionally seeing [DONE] or [MAN] activating, instead of [STOP]
- (I'll call this "ghost" or "ghosting", when referenced below)
- (and rarely, but verified [AUTO], so sometimes column and row received measurements were errant in the same sample set).
- The buffered samples concurred with the visible result. I have also stepped through the hardware SPI receive buffer, which matches the buffer and display.
- note that when a ghost event occurs, the buffers show a full set of identical measurements, which to me, indicates a non-noise-induced issue(?) Also, the ghost values do not appear to be a power of 2 shift from the correct values
- I believe I have verified that my post-sampling processing is correct.
In attempting to determine cause / solutions I have:
- varied SCK from 150bps to 2Mbps (1.5Mbps was the top-end, possibly due to 3.3V operation(?) and/or small trace-widths(?) between the processor and the TSC2046)
- tested both phases of MISO sample
- tested both edges to change MOSI data
- There was no change in the occurrence of ghost measurements.
- Still repeatable,
- note: I observed that the entire Y (and possibly the X) shifted toward the low value edge, as bps increased. I would expect some change based upon sample rate, so I believe it is not an issue)
- single-ended vs differential makes no difference.
- added the ability to add delays (in integer multiples of Ms) between SPI (byte) exchanges, but saw no improvement in ghosting
- added 1nF capacitors to X- and Y- (each to ground) and only saw what might be a small improvement at 300 to 150bps.
- replaced the 1nF capacitors with 10nF's and, at 150bps have eliminated the ghosting
- grounded myself to the system, so as to reduce the possibility of inducing 60Hz via my finger, into the panel... no change
- the backlight DC regulator is filtered DC (not raw PWM) and the PWM %duty does not have any noticeable effect on the ghosting
- moving the display away from the processor board does not seem to have any effect
- Vref is decoupled (100nF), as is Vdd (100nF at the IC, and an electrolytic close by)
- there are PESD5V0S1BA,115 (low capacitance 5V TVS devices) from X+, X-, Y+ and Y- I/O pins (each to ground).
- there is a 3.25" Samtec pn: SFSD cable, from my TFT daughter board to my processor board (TSC2046 is on the processor board)
- the Samtec cable headers are close (i.e. less than 1/2" from the touch panel tail connector and the TSC2046
- the Samtec cable is located in a corner of the enclosure, 2.5" from the processor
As it can operate over a wide range of SCK bps, the SPI communications seems substantially dependable. Also, as the SCK bit-rate does not noticeably affect the symptoms, I believe the analog signal paths are not a contributing issue(?).
At this point, I am running my program with SPI set for 150bps and taking 8 X/Y samples, differential mode, ADC=8-bits. There have been zero ghosting events,to my knowledge, but I would like to increase the speed of response to touch events. The response time is slightly longer than the naturally expected response time (i.e. of a debounced mechanical switch.)
This year's build (first build of this generation of the product) is already complete and awaiting firmware. We can make it work, as I have done, though something marginal is likely to show up in the field, so I hope to determine a real solution.Has anyone seen this issue?
Does anyone have a solution?
Thank you.
Regards,
Jeff