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:
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
(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
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
Hello Jeff,
Thanks for the detail description of the problem!
Does the problem occur often under weak/light touch but barely under strong/firm touch, does not it?
If yet, the problem should be related the resistance between the two layers (X layer and Y layer) of your touch panel, or Rz as normally denoted. The Rz is almost infinite while there is no pressure on the touch panel, and becomes some 100s ~ 1000s while touch is applied on the touch panel. Weak/light touch results in larger Rz, and strong/firm touch results in smaller Rz.
How does the Rz affect touch coordinate data accuracy? Refer to the attached touch signal equivalent circuitry –
When your software commands the TSC to measure, say, the X data, the +Vcc and GND is applied to X+ and X- respectively, and the X position signal is sampled at Y+, as shown in the attached circuit.
The voltage on the touch point (as indicated by the red arrow) is decided by the touch position, but the real voltage that is sampled by the TSC2046’s ADC is the voltage at Y+, which can be equal to the voltage at touch point, but with the transient time constant = (Rz + Ry1)*C, where C is the equivalent capacitance on the Y+ line.
Typically, we expect the Y+ voltage goes as shown in the black curve shown in the attached circuit. Then, if sampling at time t2 or t3, you can get reasonable good data, and however, if sampling at time t1, a measurement error will show up. The sampling time in TSC2046 is decided by your SPI clock rate, refer to Figure 9 on page 15 of the TSC2046 datasheet, where you can see that the TSC2046’s data acquisition time = 3 DCLK clocks, from the falling edge of the 5th DCLK to the falling edge of the 8th DCLK.
Under weak touch, the Rz is much larger and thus the signal at Y+ could behave as that shown in blue. Thus, you have to wait much longer to sample, otherwise, you will get measurement error, as shown in the blue curve of the attached circuit.
Hope the above has explained a lot what you observed during your test/debug!
About what you mentioned that the problem occurs often with your new build but barely with your previous build. Could it because the touch panel has been changed (so that the Rz changes under the similar pressure), or your PCB had been changed (so that the Y+ or X+ line equivalent capacitance C changes)?
ANyhow, to resolve such a problem, you may improve on hardware and/or software.
On hardware side: have the TSC and touch panel connection as short, as simple, as secure as possible, so that noise will be low and you may not need to add the external C for reducing noise (refer to Section 3 in the application report sbaa155).
On software side: you may use multiple samples, with the sequence as following:
3. Check /PENIRQ again, if low, go back 2. Otherwise, end.
Note that, (1) Do not read touch data in such a sequence: X1, Y1, X2, Y2, X3, Y3; and (2) do not turn off the driver and ADC between multi-samplings.
Please always feel free to ask if there is further question!
Best regards,Wendy F.
Hello Wendy,
Thank you for your response.
My current code reads in the X1 Y1 X2 Y2... Xn Yn format, BUT as slow as I am running SCK (DCLK), the ADC should have no issues. I am considering re-write of the sampling code, to use the X1 X2... Xn Y1 Y2... Yn format you recommend.
Since I found that I can repeatedly re-create the 'ghost' events, I have been able to probe the /PENIRQ signal, during the 'ghost' events. I found that /PENIRQ goes into a rapid oscillation (indicating a lack of hysteresis, to prevent tiny internal voltage shifts from producing oscillations.)
I am going to add a high-value (1M, or 100k) resistor, from /PENIRQ to each of X+ and Y+ terminals - as a test of the effects of a little bit of positive feedback. If /PENIRQ were a clean logical-LOW during entire touch cycles, I would use it to interrupt on any high-going edge(s), to abort the sampling, but that isn't the case. (note: If I remember correctly, the high pulses, during sampling, are not rising to IOVdd, but still rise to maybe a third of that voltage (to about 1V.) There is an interesting effect: specific locations on button 'c' will repeatedly trigger 'ghost' activations of other specific button locations. This is probably based upon a multiple of base-2 shift in value. (lightly touching just to the right of the button in screen-center, triggers one button to its left. lightly touching sightly farther to the right, triggers the button two buttons to the left. solidly touching those same spots always triggers the button being pressed.)
All solid touch events are clean (no 'ghosts') and repeatable, but previous experience tells me that I cannot depend on customers knowing the difference and being consistent in touching the screen.
Also, this is not a change from build to build. This generation of the product migrated from a 2-line x 20-char monochrome LCD, to the 7" TFT with touch panel. This is a whole new hardware animal for us.
Because the issue occurs during weak touch (not solid strong touch), I still think you should consider the suggested sequence for reading touch data, where please also note the PD0 setting in each of the reading command.
In TSC2046 (and in all of our older touch screen controllers, such as ADS7846, even newer TSC2007, TSC2008, and TSC2017), the /PENIRQ did not add hysteresis and thus can oscillating during touch on or off, or during weak touch. The interrupt signal were improved with our TSC2004/TSC2005/TSC2006 and TSC2014.
If you would like to do more experience and share with us, it will be welcomed! However, I usually do not suggest to connect the digital lines (such as /PENIRQ) to the analog input lines (such as X+, ... Y-). In fact, it is always a good practice to keep the analog interface simple and short, without interfere from any digital signal.
With the best,Wendy F.
Hi Wendy,
I experimented with adding hysteresis, but found that I do not need positive feedback in both /PENIRQ HIGH and /PENIRQ LOW. With even 1M ohm resistance added from X+ to /PENIRQ, the oscillation previously seen during a light-touch event, is eliminated. Lowering the value, even significantly, did not eliminate the 'ghosts', which remained consistent.
It seemed that the internal touch detection of the TSC2046 circuit needed to be made less sensitive, to ignore light-touch events, but once proper touch pressure is achieved, measurement is accurate. I thought a pull-up resistor to X+ would do the job, but did not want the non-linearity of the pull-up in circuit, during X/Y measurements.
I decided to use a schottky diode (in series with the resistor) to pass the logical-HIGH from /PENIRQ to X+ and block the logical-LOW. In this configuration, as I lowered the resistance to about 3k ohms, there was an elimination of the 'ghosts' two keys away. By lowering the resistance to 1.5k ohms, no 'ghost' keys are occurring!
SO: by adding a 1N5819 diode, cathode to X+ and anode to a 1.5k ohm resistor and the opposite end of the resistor to /PENIRQ, I am seeing no 'ghost' keys. On the oscilloscope, /PENIRQ transitions are clean.
Next I will increase the SPI clock-rate and see if I can remove the capacitors from X- & Y-. At this time, we could use the touch panel as-is (with the resistor+diode).
(Note: the TSC2046 is operating solely on +3.3V (Vcc & IOVdd), which is the reason I used a schottky diode (low forward voltage.))
As a follow-up, I have been working with the touch screen/panel since my last posting (after adding the diode+resistor circuit.)
1) I have not seen one occurrence of the 'ghost' symptom. (still cannot increase sampling rate)
2) I tested two other systems, in preparation to ship them to my customer:
> each displayed the 'ghost' symptom.
> after adding the diode+resistor circuit to each, they work without 'ghosts'.
It seems like the TSC2046 is just too sensitive to low-pressure touch. I looked at the other part numbers you provided. At this point in this year's build, we cannot justify a part number change, especially without a pin-for-pin replacement. We'll rework these PCBAs and revise the PCB layout, to add the components to the next batch. Once I get some time to concentrate on the sampling speed issue, I'll try to go back through the design (PCB and firmware) and see what is causing the communications issue.