BRT Community
General Category => Discussion - EVE => Topic started by: T.Pierret on June 10, 2020, 04:22:24 PM
-
Hi,
Am I wrong if I say that the Capacitive Touch Engine does not need a calibration in extended mode ?
Currently, we only own and tested resistive touch screens. The calibration process appears as a big constraint for a "mass" production.
Thanks in advance for any answer.
Regards.
-
Hello,
It is recommended to run the calibration routine for every display.
When using CMD_CALIBRATE the co-processor engine overlays the touch targets on the
current display list, gathers the calibration input and updates REG_TOUCH_TRANSFORM_A-F.
One option for mass production would be to calibrate one given display and read back the values stored in REG_TOUCH_TRANSFORM_A-F, you can then use these known 'good values' in your production line by writing the values into REG_TOUCH_TRANSFORM_A-F for subsequent displays. This should allow your displays to be approximately calibrated, after which you can provide a calibration routine in your code for your customers to use to re-calibrate the display if desired.
Best Regards,
BRT Community
-
While we are on the topic, there is something I have been confused about:
Are REG_TOUCH_TRANSFORM_A-F stored persistently in the EVE? And, if the chip has non-volatile memory, what else is there that doesn't clear on a power-cycle or reset?
-
Thanks for those info.
That what's we did (reusing the transformation matrix from one calibration), but this solution has some side effects. If the touches at the calibration are not accurate (and they always are in real life), it leads to area on the edges of the screen where one of the provided coordinates becomes 65535 (observed several times). So I figure out that this would also happen if the transformation matrix is arbitrary chosen from one calibration. This means that, in a mass production, some of the screens would be wrongly calibrated. This is not acceptable.
The real solution would be a transformation matrix that is the result of many calibrations. For this, the coordinates of the points that are drawn on the calibration screen should be known. Is it possible to get such info ?
Regards.
-
Hello,
Are REG_TOUCH_TRANSFORM_A-F stored persistently in the EVE? And, if the chip has non-volatile memory, what else is there that doesn't clear on a power-cycle or reset?
No, REG_TOUCH_TRANSFORM_A-F are not stored persistently in EVE, it is recommended to run the CMD_CALIBRATE command or write known good values to these registers on every start up.
The real solution would be a transformation matrix that is the result of many calibrations. For this, the coordinates of the points that are drawn on the calibration screen should be known. Is it possible to get such info ?
The point positioning varies depending on screen resolution. If you let me know what screen resolution you are using I can query the dev team for information on where the points would be located on the screen.
Best Regards,
BRT Community
-
I am storing the calibration values as constants in my code and I have a whole bunch of them in my example code.
Switching between different displays of the same type usually works well enough but I have no experience
on product level amounts of the same type of display.
And yes, the calibration requires some precision.
I am using a special stylus to calibrate my capacitive touch screens.
Regarding the points during calibration, Matrix Orbital added a manual calibration function to their library
that does not use EVEs CMD_CALIBRATE:
https://github.com/MatrixOrbital/EVE2-Library Calibrate_Manual()
I picked that up and adapted if for my library as well:
https://github.com/RudolphRiedel/FT800-FT813/blob/4.x/EVE_commands.c EVE_calibrate_manual()
This is needed for the more exotic displays like EVE3-38 with 480x116 for which EVEs own calibration does not work since the dots are partly displayed off-screen.
So you could even customize the positions of the dots with this function.
-
Hi,
Thanks for those answers.
If you let me know what screen resolution you are using I can query the dev team for information on where the points would be located on the screen.
We are currently testing the 4.3" screen, with a resolution of 480x272. We will probably migrate to a 7" screen for a resolution of 800x480.
@Rudolph
Thanks for the custom calibration function. This may be helpful if the calibration points of the CMD_CALIBRATE function cannot be known.
Best regards
-
Hello,
Thanks, I have pinged the dev team to see if they can provide the point positions.
Best Regards,
BRT Community
-
Hello,
the positioning of the three dots is as follows (X,Y) : (10%w,10%h), (90%w,50%h), (50%w, 90%h) w is the width of screen resolution, h is the height of screen resolution.
Best Regards,
BRT Community
-
Many thanks for this :)
-
Hi,
Thanks for those answers.
If you let me know what screen resolution you are using I can query the dev team for information on where the points would be located on the screen.
We are currently testing the 4.3" screen, with a resolution of 480x272. We will probably migrate to a 7" screen for a resolution of 800x480.
Hello T.Pierret,
Please contact me if we can help you with the hardware.
sales@matrixorbital.ca
Thank you!
-
In the domain of this topic, it happened that one of the coordinates provided by the REG_TOUCH_SCREEN_XY register has a value of 65xxx. Is it a negative value ?
The documentation mentions a value within the width/height of the screen.
Regards
-
Hello,
Theres a slightly better definition of the operation of the touch registers available in the BT81x programmers guide:
The raw touch screen (x, y) values are available in register REG_TOUCH_RAW_XY. The range of
these values is 0-1023. If the touch screen is not being pressed, both registers read 0xFFFF.
These touch values are transformed into screen coordinates using the matrix in registers
REG_TOUCH_TRANSFORM_A-F. The post-transform coordinates are available in register
REG_TOUCH_SCREEN_XY. If the touch screen is not being pressed, both registers read 0x8000
(-32768). The values for REG_TOUCH_TRANSFORM A-F may be computed using an on-screen
calibration process.
This indicates that the values stored in REG_TOUCH_SCREEN_XY represent a twos compliment number (0x8000 = -32768). A return value of 0x65xx for either the x or y value of the register would represent a positive number.
Is this value obtained pre or post screen calibration?
Best Regards,
BRT Community
-
Hi,
Thanks for this.
The mentionned value 65xxx was in decimal format, i.e. 0xF... in the hexadecimal format. This value is directly read from the REG_TOUCH_SCREEN_XY register.
The values have been observed in normal run, while the calibration process (CMD_CALIBRATE) has been executed.
Regards
-
Hello,
Just to clarify, are these the values you're seeing whilst running the CMD_Calibrate routine?
Best Regards,
BRT Community
-
Hi.
No. The calibration process has been successfully done at the beginning of the tests session.
During the tests sessions, 0xF... values have been read for one of the touch coordinates from the REG_TOUCH_SCREN_XY register, while the touch happens at the edge of the screen.
Regards.
-
Hi,
Today the trouble has been observed several times again. I can provide more data.
Touch transformation matrix (after calibration through CMD_CALIBRATE):
0x0000D9AA 0xFFFFFEFD 0xFFE5CC8C
0xFFFFFE4C 0xFFFF7696 0x0208B092
If the translation is correct, here are the float values:
0.85025 -0.00395203 -26.201
-0.00665283 -0.536774 520.69
Here is the recorded touch:
| Time | SmoothStep | Read | Tag | Pressure |
| 29570 | 65529,177 | 65529,177 | 0 | 143 |
| 29576 | 65521,177 | 311,366 | 0 | 1043 |
| 29582 | 65513,177 | 333,357 | 0 | 983 |
| 29587 | 65508,177 | 343,369 | 16 | 872 |
| 29846 | 54657,200 | 336,320 | 16 | 583 |
| 30104 | 45664,206 | 271,239 | 16 | 1328 |
| 30362 | 21878,223 | 32768,32768 | 16 | 32767 |
Hoping this may help
Regards
-
Hello,
It seems like your other post regarding tags may be related to this.
http://www.brtcommunity.com/index.php?topic=147.0 (http://www.brtcommunity.com/index.php?topic=147.0)
The calibration on the screen should affect the tagging and track properties on the screen equally. Its possible that this behaviour could be related to the CTP as it might jitter between coordinates slightly and so eve might see coordinate inside tag and then outside, etc.
Would it be possible for you to create a simple example which exhibits the behaviour you are seeing?
e.g. can we see it by just drawing a rectangle and tracker on it and a small tag number printed beside?
This should help narrow down where the issue might lie.
I would appreciate if you could email this example into: support.emea@brtchip.com, along with a description of the symptoms you are seeing. We can then try this on some hardware here to further the investigation into this behaviour.
We can post the resolution here for any interested parties.
Best Regards,
BRT Community
-
Hello,
OK. I will try to provide that :P. I'm not sure I will get the time for since the decision about the screen controller to be used should fall soon.
To summarize our observations: the tag value (read from REG_TOUCH_TAG) is nearly always 0 for the first readings (let me say within the ~20 first milliseconds of the touch). Within this delay, the touch coordinates are also observed shifting.
For info, the touch registers are read in a single shot: 5 registers from the REG_TOUCH_RAW_XY address. Could this be a problem ?
In a general way, how is data consistency guaranteed while the touch registers are continuously polled ?
Many thanks for your support.
Regards
-
As suggested, the mail has been sent to the support with some test code.
-
For calibration process of capacitive touch screen, it shall be done in compatability mode (single touch) only.
It is not possible to do the calibration at the extended mode.
So to read the final touch point coordinate (after the calibration process), REG_CTOUCH_TOUCH_XY at address 0x302124 shall be read. The coordinate before the calibration process is stored to REG_CTOUCH_RAW_XY at 0x30211c.
These are what I understand from programming guide.
-
Hi,
Thanks for your answers.
The issue is solved by using data from the REG_TOUCH_TAG_XY register instead of those from the REG_TOUCH_SCREEN_XY. When the coordinates are weird in REG_TOUCH_SCREEN_XY, the data in REG_TOUCH_TAG_XY are invalid (0x8000 value) and can then be ignored. In this way, many touch information are ignored but at least, the touch can be correctly managed to get the expected behaviour.
@pauljiao
We have ordered a capacitive screen for comparison. The info you provided shall be taken into account. Thanks.
Regards.