I am finding that the input from the touch doesn’t seem to properly get to the application that is running. I noticed this first in my application but now see it also in for example the explorer.
This seems specific to the touch as mouse clicks get through correctly.
Ocassionally when tapping a button, the button graphic changes indicating the touch has been seen, but this doesn’t get through to the application so nothing actually happens in the application.
This is happening regularly enough that I can create a video if necessary.
Dear @dnicholls
There’s various issues which could explain the behavior.
- First I would like to mention that a resistive touch screen requires physical force to get activated. This is different than a capacitive touch screen as you have it on your phone, where the slightest touch is sufficient to activate it.
- Another common issue with resistive touch screens is noise on the signal and too fast measurement timings. This is especially true for larger screens.
As a simple indication, try to pull up a rectangle on the desktop - is it stable or does it jitter somehow?
If you have an oscilloscope around, measure the touch signals while you press on the screen. The signal should look kind of square-shaped, If there are signal edges before the charging-e-curves are stable, timings are too fast.
- For the non-working buttons: is it possible that you touch on the button, then slide away and release the screen when you are not on the button anymore?
If all of the hints above don’t help, I would appreciate a short video of the behavior.
Regards,
Andy
Hi Andy,
I understand your points but I don’t think they are correct in this case. I have attached a video to demonstrate.
For your first two points, then I would expect to see no reaction on the graphics of the button if there was a light touch or a problem with the signals. For the third point, I hope you can see in the video that I am not sliding off the buttons.
Regards,
David.
Toradex Buttons_small.mp4
Hi @dnicholls
Thank you for the video. I was able to reproduce the issue.
The problem is, that sometimes the touch coordinate jumps completely off the real position in the moment when releasing the screen. This makes the system think you released the screen away from the button, as I described as (3.) in my first answer above.
I will have to talk to the developer of the driver in order to see what we can do about it. Please give me a few days, I will keep you updated.
Regards,
Andy
Hi @andy.tx
Thanks I’m surprised you haven’t seen this before.
Do you think this is due to the actual touch screen being used, or will it apply to all touch screens? The reason for asking is that in production we will most likely be using a different touch screen, although still resistive.
Regards, David.
Hi @dnicholls
I’m also surprised we didn’t see it before. We used a different touch controller on other modules which didn’t show this behavior, so we were not sensitive to this problem.
I guess the effect is a combination of the touch controller’s measuring/filtering algorithm and the analog properties of the touch screen itself. So I assume it will happen with other screens, too, although the problem could be weaker or even stronger. Anyway I recommend to do tests with the final device to be on the safe side.
Regards, Andy
Hi @dnicholls
We will implement an appropriate filter in the driver. The plan is to do it within 2 months. Please let me know if this is too late for you.
Regards, Andy
Hi @andy.tx
At the moment, this fits with our project timing. I will prepare in addition an alternative touch screen for testing. Will you able to send me a test build before making a public release?
Regards, David.
Hi @dnicholls
We will send you a test build. It’s also valuable for us to have it tested on various hardware.
Regards, Andy
Hi Andy,
I have now progressed to prototyping some different screens. I am now also seeing the jitter as you described in point 2. Therefore how can I go about modifying/slowing the timings to suit these different RTPs?
Regards,
Dave.
Dear @dnicholls
Here’s a link to the supported registry settings.
As originally stated, I recommend using an oscilloscope to make sure the jitter is related to the timing, not to other analog noise.
Regards, Andy
Hi @andy.tx,
Those settings aren’t currently in the registry so can I assume that it is OK just to add them as new entries?
Do you have an example of what a good signal should like so that I can determine if it is noise or timing? The signals do look noisy at the moment but I am prototyping with some longish wires which won’t help.
Regards, Dave.
Dear @dnicholls
You’re correct, it is normal that not all registry settings are actually stored. Whenever the system doesn’t find a particular entry, it takes hard-coded default values.
Here’s an example of a good Touch signal measured on my 7" LCD:
You see that the signal always gets to a stable level before any following edge.
(To show a bad example: Reducing the timing of the center low-going pulse to 100µs, would lead to an instable reading, as the signal would not have sufficient time to settle).
Regards, Andy
Hi,
We are currently experiencing the same behavior on our system with a iMx7 Solo 256MB on WEC2013 CE8 1.3b2. What is the current status of this bug?
We tried to play with the provided registry entries in
It was nevertheless impossible to completely eliminate the issue.
Would someone have some insight on how to solve this issue?
Regards, Thomas
Hi,
I can unfortunately not invest more time on this issue.
We could actually find a work around in our software application.
Regards, Thomas
The Touch Controller on iMX7 does all X, Y and Pressure measurements autonomously.
The default settings are to use 512 microseconds between measurements, an acquisition time of 4 microseconds and 8 samples per measurements (the median 4 of which will be averaged).
This settings lead to X, Y and Pressure samples that are spaced apart in time by 512+32=544us.
So in worst case there is 544*2=1.088 ms between the X measurement and the Pressure measurement.
Since we use the pressure measurement to validate the X and Y measurements (with too little pressure the X and Y measurements will be completely wrong), it can still happen that the Pressure measurement was valid, but 1 ms before it was not when sampling the X coordinate. This can lead to a sudden jump in X or Y coordinates.
To alleviate the problem the interval between the X,Y and Pressure measurements has to be reduced to the minimum that the touch still allows (settling times)
The first thing to try out is to reduce the “FirstConversionDelay” setting. Try 0 (128 us) or 1 (256us)
Reducing the “MedianFilterSize” setting can also help to reduce the delay a little bit.
Lastly “AcquisitionTime” can also be reduced to the minimum to reduce the delay even further is necessary.
For a description of the iMX7 Touich registry settings:
